next »

[tanis]

Hey all!

This is a kind of generic question that isn't really tied to any framework or engine.

My AI design is pretty simple. I have different entities that can be possessed either by the player or the AI.
Those entities have an "Input" component that holds the states of the actual inputs, like right, left, up, down, fire. (and wasRight, wasLeft, wasUp, wasDown, wasFire to perform checks on whether the input was just triggered or not).

My PlayerController class is driving that component by reading inputs from either the keyboard or the gamepad or whathever is needed.

In a similar way, my AIController comes up with that same input through logic functions.

Now I've hit a wall with this kind of approach when dealing with movement. Let's say that I'm in 2D space and that I'm moving the AI horizontally. I am moving from (0, 0) to (10, 0) so I'm activating the "right" input all the way until I reach the (10, 0) position.
But if the speed of my entity is high, I might actually go over the position and trigger a movement back, and then again forward and so on as it can't actually settle.
I know that I could just check if the previous movement was in the same direction and that if I went through the target I could just force the position to be in the exact spot that I want to reach. But it doesn't really look like a clean solution.

Do you guys have any suggestion? Is this approach completely wrong?
Thanks for all the advices in advance!

[eerr]

Well first off, input should be a singleton class in unity, attached to the camera.
Any script that needs input should register with this singleton.

a single script to rule them,
another script(per object) to bind them together.

I would make the enemy slow down when he gets close, then he won't overshoot.

It looks really cool to make him slow down gradually, but that is unnecessary.

[voidSkipper]

How does a human player know when to release the button so as not to overshoot their mark?

[tanis]

Well first off, input should be a singleton class in unity, attached to the camera.
Any script that needs input should register with this singleton.

a single script to rule them,
another script(per object) to bind them together.

You're giving for granted that I'm using Unity, but actually I'm using my own ECS with a different framework, so that doesn't apply. But even if it was Unity, I wouldn't do it that way and I can't see how it would help to solve my issue

I would make the enemy slow down when he gets close, then he won't overshoot.

It looks really cool to make him slow down gradually, but that is unnecessary.

That's a solution, but it requires my AIController to know about how the movement works, making it coupled with that. I would like to keep them separated instead.

How does a human player know when to release the button so as not to overshoot their mark?

That's a good question. Humans have far more inputs than my AIController though
You know that you'd release the button when you see you're about to get there to the place you want to be. So that makes tolerance an option. But it would still require my controller to know about how movement works.

[Agecaf]

How does the movement work? with acceleration or without?

The problem should not exist for non-accelerating movement, or be very little if there's a sharp deceleration to zero speed.

The other solution I can think of is that... you don't always say "I want to be precisely at (10, 0)". Maybe you want to get nearer / further from a point, or go towards a direction. You could change your AI to reflect that.

For a very simple example, say the AI wants to pick up an item, at (0, 0), which can be picked from anywhere within distance 1. Then you program your AI to look for the next movement as soon as it enters that region (effectively skidding towards the item a bit afterwards).

In other words, make your AI know in which region it wants to be, then decide the best way to reach it. (Again, it could be getting away from the player's range, for example).

[Thaumaturge]

I would make the enemy slow down when he gets close, then he won't overshoot.

It looks really cool to make him slow down gradually, but that is unnecessary.

That's a solution, but it requires my AIController to know about how the movement works, making it coupled with that. I would like to keep them separated instead.

I take it that your AI controller already has access to the position of its host, as well as the position of its target (in order to determine which way it should be moving)? If I'm not much mistaken, all that's really required for the solution above to work reasonably well is that it also have access to the velocity and acceleration capabilities of its host--related and potentially useful values, I feel.

However, if you don't want to do so, perhaps consider allowing your AIs to overshoot: once they've passed their target position, have them stop moving, but design the motion of the hosts in such a way that they retain momentum, slowing via friction. This does mean that a fast-moving body will likely overshoot significantly--but that's expected if it doesn't slow down before arriving, I believe.

[ThemsAllTook]

Last time I coded something like this, I used a tolerance value for the AI to say "I'm close enough, I can stop moving now". It took a little bit of tuning to get it right so they wouldn't just spin in circles trying to land exactly on their target (or on the other end, stop way short), but worked fine once I found the right value.

[oahda]

I'd use a tolerance value as suggested by a couple of people before me, combined with an actual calculation to figure out when to slow down based on current velocity, distance to target and deäccelaration speed (it would only need to be done once unless conditions change along the way, like obstacles or a new target emerging).

[epcc]

Check out PID controllers.
https://en.wikipedia.org/wiki/PID_controller