0 votes

Seeking some advice. V 3.0

I want my enemy characters to be a bit like the lemmings game.

They will move from start point to various end points (depending on their goals).

Various obstacles will be placed in their way and they will climb over them on their way to their goal location as they come across them.

I was first considering navigation / A* or similar but I am thinking that may not be the best bet. It's a 2d side scroller like lemmings.

What advice can the community offer to suggest how I should approach this?

Thanks SO much...

in Engine by (810 points)

don't know if i understood correctly but cant you just make them move towards the end point and before every movement check if they need to climb?

Indeed. I was hoping for this exact type of comment. Feedback and suggestions to mull over before I begin. I'm still making stand in artwork but will start coding in a day or so and start seeing what comes of it all.

2 Answers

+1 vote
Best answer

Ouh I loved this game so much - back in the good old days :D

I'm not sure what you mean with "climbing over obstacles". As far as I know the lemmings slide (like move_and_slide) on the floor (StaticBody) until the sliding-vectors angle is too high (floor_max_angle). Then they are mirrored and move into the other direction. This is a typical Kinematic Character movement but you should also consider gravity (with move_and_collide) in case they should be able to fall from a cliff or into a hole.

If climbing means real climbing on an obstacle with a 90° angle to the ground (like a box) then another behaviour can be implemented when the sliding-vectors angle is too high. If the obstacles height is not greater than their body-height + arms-length the climbing animation is played and they are moving upwards (move_and_collide and gravity off) and after reaching the top they can switch their behaviour state to walking again.

Note that functions like is_on_ceiling( ), is_on_floor( ) and is_on_wall( ) could be useful too.

So lemmings are more like stupid robots which are told to move and if they fail at this they turn around and repeat the process. If they walk into a hole they will fall and then move again. It is not much AI behind this. AI in enemies like these is more like reacting on events and changing the behaviour state accordingly.

by (1,010 points)
selected by

This is a great answer, thank you.
I see you note StaticBody and Kinematic Character. Would the character's best type be of StaticBody?

I'll do some experimentation but obviously welcome any help / feedback.

My plan yes, is to have states as you suggest above. One for walking, one for climbing, falling, firing, doing other actions etc. So I can trigger those states.

To consider this further I was thinking of having them move like a lemming basically but when they die they can be manipulated by bombs etc. So if you throw a bomb at a pile of them they explode and move around.

I'm GUESSING that I'd need to do a swapout when they die. So I could have them as say a Kinematic Character or a staticbody whilst alive and moving then when die, swap them out to be say a RigidBody2d? I don't know if that's too much CPU hit with a few hundred of them in a pile dead, all performing physics calculations? I'll give it a run and see.

"I see you note StaticBody and Kinematic Character. Would the character's best type be of StaticBody?"
StaticBody is meant to be used with static stuff like floors, walls, trees and so on. The KinematicCharacter is used for moving stuff like players, enemies, moving platforms. The Physics introduction and the Kinematic Character overview might help you to understand this better.

"I don't know if that's too much CPU hit with a few hundred of them in a pile dead, all performing physics calculations?"
I have a RigidBody2d benchmark with about 1400 bodies (circle collisionshapes, no script attached, all use the same sprite) stacked on top of each other. Around 1000 are sleeping or only awake each 5-10 physics steps. The rest collide in each step and the benchmark is running at 60 fps when vsync deactivated.
So the physics system is capable of doing a lot if you use it wisely.

"So I could have them as say a Kinematic Character or a staticbody whilst alive and moving then when die, swap them out to be say a RigidBody2d?"
You can achieve this with the RigidBody2d alone as it has 4 behavior modes.

That's awesome, I really appreciate your effort in replying. That's helped a lot. I'll work with those ideas. The RigidBody2D's ability to swap behavior is perfect. Also it's great to know about the sleep behavior for the bodies. RigidBody2D it is. :-)

Just a thank you again and an update. I'm getting the hang of this with your guidance above. I've setup a state machine and depending on the state the lemming character moves either left and right, falls, is idle, and I'm about to tackle climbing. It's all pretty cool and a bit hit and miss until I tighten the bolts but it's mostly working. Thanks again.

Nice to get some kind of progress report! Hope you are getting into a stable state somewhen - I will glady help playtesting :)

Thank you I'll definitely drop you a copy when it's ready. For now though, are you able to suggest anything with this?

(It's recorded at 60fps but playing back REALLY slow, not sure why but it shows the problem which is good)

enter image description here

I have 3 states so far:
- Walk
- Fall
- Climb

Basically its this:

IN WALK
if floorRay hits floor.  WALK
else start falling
if forwardRay hits floor.  CLIMB

IN FALL
if floorRay hits floor.  WALK
if forwardRay hits floor.  CLIMB
else fall

IN CLIMB
if forwardRay NO LONGER hits floor. WALK

So I know there's more logic to go but I needed to stop due to the stuttering / jumping between states. I've had a think about maybe putting a timer in? Making them stay in any state for X time before changing. That could impact how they traverse though and they could float above the ground in that case when climbing. I'm a little stumped.

You can see in a climb they will change between FALL and CLIMB repeatedly until they reach the tip and it's a bit strange. Even the odd WALK gets thrown in. So it's probably the climb logic that needs love and attention.

Do you have any suggestions? Thanks so much...

Sorry for the delay - didn't see your comment. Nice video and I can see your problem quite well.

There are several possibilities to handle this. The timer version is one way to go - it's like playing an animation and waiting for it to finish before scanning the environment again.

But you could also tweak your FSM with some more "behavior modes". For example when falling the lemming can't climb, walk or do something else. So as long as the lemming is falling there can't be a state switch to another state apart from "hitting the ground". This could also be coupled with an animation (biologically falling to and hitting the ground often leads to bending the knees and standing up). After "hitting the ground" the state can change to another state - apart from "FALL" because this would make no sense (so there might be a STAND state which then automatically lead to a WALK state).

The climbing action is almost the same. You are trying to decide if the lemming should climb depending on the ray that is shoot. But while climbing the ray doesn't hit the floor after moving over the tipping point and so the WALK state is acitvated. Here another state could help which is the only state the CLIMB state could switch to. And if you think about it, it makes much sense to reuse the "hitting the ground" state. Because after overcoming the tipping point the climbing can't be over because the lemming is not standing on the floor and therefore there can't be a switch to a WALK state.

So there could be a STANDING or GROUND_HIT state which is the only state FALL and CLIMB can switch to and it is activated if the feed of the lemming touch a floor.

0 votes

I think you should use raycast to check if it can climb and them respond to this.

http://docs.godotengine.org/en/3.0/tutorials/physics/ray-casting.html?highlight=raycast

by (189 points)

Thank you, I'll definitely look into raycasting and seeing which of the types the character will work with properly (kinematic, staticbody etc)

Welcome to Godot Engine Q&A, where you can ask questions and receive answers from other members of the community.

Please make sure to read How to use this Q&A? before posting your first questions.
Social login is currently unavailable. If you've previously logged in with a Facebook or GitHub account, use the I forgot my password link in the login box to set a password for your account. If you still can't access your account, send an email to webmaster@godotengine.org with your username.

Categories