Click&Point A* Algorithme and ES

I’m working on a click and point game and so far I can do some kind of “follow mouse pointer”, that means where I point with the mouse there the player looks (kind a 2.5D click and point) and if I hit “w” it moves where it looks.

But I want of course improve this, I have a tile based grid where I have tiles with speed factor 1 and those with 0 (walls for example). As well tiles which can switch (doors) between 0 and 1. Of course I could have tiles with speed factor 0.5 (water). And what I want is to click somewhere and the player moves on (A* algo or the like to find the way to the wished point). It should be breakable at any time (new click somewhere else). But I do not know exactly how I can achieve that with ES. My player/hero do have a position and a looking direction and a model and stuff. If I would use the cinematic (that do have way points) then I do not know how to properly integrate this in ES. Or shall I use some kind a library, like libgdx-ai or the like?

A one thing more, my tiles, doors, items, furniture are as well entities with position/rotation and model as a) it is just convenient to make it that way and b) it is possible to change on the fly tiles and the like (when you solve a task some hidden stuff can appear or something can disappear and so on. So it gives me plenty of flex. Even my control system was that way extremely simple :smile:

I hope, my description is not too abstract/vague…
Did anybody something similar and can push me into the right direction?

I would hope so! :smile:

As to the other, before I write a whole essay on path finding and so on… which parts are you unclear on exactly? Just the “how to move the player” part? It seems like you might already have the A* part that builds the path… so you just need to know what to do with the path?

So yes the moving part is the one I struggle with.

I guess to calculate the way points I can manage I found a useful link which explains that

And I guess I can use either libgdx-ai or similar.

In the past I used jMEs cinematic but that was not ES based and there I hacked my self anyway in a corner, not with the cinematics in specific but overal :smile:

So I thought of sort of a way points arry component sticked to the player entity. And a walk the path system. But not sure. Could that work? The cinematics of jME were nice as they just did it for me but I guess not a good idea.

Yeah, if you already have a grid then A* is pretty easy to code… even from scratch. Actually, for something that’s UI interactive in 2D you can probably use straight djikstra or an exhaustive breadth first search. (After all, that’s basically all A* if you remove the distance to end heuristic.)

Anyway, if you have a path then yeah, attach it to the player and have a system that walks objects along a path if they have a path attached. Can even use it for NPCs later. Let the AI pick a path and let the walk system walk it.

Ok then I go with a way point component where the way points are one stack where I can pop them. That way it should be even pretty easy to exchange a route with another while travelling. So when the player click somewhere else the player can change its route all the time. Cool.
Seems now pretty clear :smile:

Ok now another problem in this topic. I have now a FollowWayPointsAppState and WayPoints component. The FollowWayPointAppState follows now the way points in the WayPoints component and pop the WayPoint if the controlled entity reach that WayPoint. So far so clear to me.

But I have a ControlAppState where my hero do for example look in the direction where the mouspointer is pointing to. I want this to be able to inspect a room be turn around with a light, it also looks more vivid. But if mye hero is on the way to a target position and the FollowWayPointsAppState tooks over control, I do not want that my hero looking in the direct of the mouse but in the direction of the next way point.

So I wonder how I shall do this. Shall I have a Control component which tags my hero as long as there is not WayPoints component and as soon I add the WayPoints component I remove that tagging Control component? In may opinion this is a bad solution as the FollowWayPointsAppState should add the Control component after the hero reached the destination how can that system know if it should re-add the control component. Because after reacht the target I want the hero looking into the direction of my mouse pointer again. As well I want to abort a path by clicking somewhere else, that would as well not work with this Control component tag Idea I outline here.

I hope my lengthy description was more or less clear. Is there something easy I could do but do not see? I think as I somehow now do not think in terms of an ES :frowning:

EDIT: Maybe I should not just use a tagging component but some kind of a state component which just says: “Hey currently you are under foreign control”. Would that be the proper solution for this?

Off the top of my head…

Have a component that says which way the player should look.

While walking the waypoints set this component for the path.

The stuff that handles the mouse movement can see if the player is walking waypoints by looking for that path component and if the player is not walking waypoints can set this ‘look’ component themselves.

You could have lots of reasons to want to set where the player is looking. As soon as that becomes a game level logic issue then it should be expressed in a component, I think.

Hmmm thanks.

But now more problems pop up. The way point component is currently a stack of Vector3f. My FollowWayPointsAppState do then have to poll all entities with WayPoints and Position and Direction (I had that Direction component exactly to make my hero look in that direction), Because if I want it fluid move the FollowWayPointsAppState should only do part of the way (tpf and speed releated actuall). But if I do this I get once triggered for the changed/added entity with a WayPoints component but only one time. So how is the proper way for this? Poll all entities as long it has way points? That lead to the next problem, because if I do it like you say “look if the way points components still have way points or is already empty” the FollowWayPointsAppState still geht triggered even if there is no work for it. That isEmpty on WayPoints would solve my Contorl problem indeed, but keeps the FollowWayPointsAppState busy.

Or is this something I have to life with anyway for this kind of problem?

Hope you understand what I mean?

EDIT: Another negative thing is that the ControlAppState needs to know about the WayPoints component to see if it is “on the way” (isEmtpy() == false) or not (isEmpty() == true).

I’m trying to figure out where this is empty thing came from as I don’t think I mentioned anything like that.

An entity has a path… it is handled by the waypoint walker thing.

An entity doesn’t have a path… it isn’t being handled by the waypoint walker thing.

Ok. I see. I guess I make my self unclear and I think too far (as usual).

=> Direction component
=> WayPoints component

I think we get nearer :smile: How does the ControlAppState know that it is walking along side a path? By query if there is a WayPoints component? ed.get(e.getId(), WayPoints.class) != null? That sounds like some kind of an anti pattern to me, but proof me wrong :smile: Maybe that is exactly how I should do it…

EDIT: aha and it has to know WayPoints anyway as the ControlAppState will produce that component, when I click somewhere. So seems like a good idea. At least one I could implement easily.

You can query this… or you can use a WatchedEntity.

The player is a special case where you want to potentially watch single components about a thing that doesn’t go out of scope. Thus, WatchedEntity which lets you keep the entity even if it doesn’t have the component you want… and you can still do applyChanges() just like a set.

Probably everywhere you have a player-specific system in your UI you could be using WatchedEntity.

That sounds like a very good idea. I will have a closer look to this WatchedEntity as it seems to solve many problems I have with that single hero thing. I know you mentioned it already, but I was too shy to try :wink:

Many thanks for your suggestions.