I have a component based architecture game engine with different subsystems, which do different things. Now I have the boiler plate partly finished, and I think about the next things to do.

I have an object in my scene manager. This object needs to be moved automatically. Now I think about a system with the task to manage all waypoints. This system needs to have two arrays, one with the waypoints, and one save each connection to another waypoint. If this object need to move, I send a message to the ai system, which set the new destination waypoint, and then the ai system sends a message to the pathfinding system (is this a seperate system or combined with the position system, or with the ai system?) which calcs the way to the waypoint, and if finished sends a message to the position system, which moves the object at the right speed.

Now I would like to hear other opinions. Is this a good way? How do other people do this? I think this is a common term in game programming, so there are quite much ways to do this. Maybe this way is a little bit overcomplicated, are there simpler ways?

Thank you

Dominik

Yes, using a routing component like that is fairly common.

Routing between two points may need to pass through portals (doors, bridges, ramps, etc.) might require gating so actors don't walk on each other or consider the route blocked just because the portal is in use by another actor. Each actor can route between the segments and queue up for the gate to become available if needed.

Also routing between short waypoints can make it easier to decide if the path segment is temporarily blocked or if a full reroute is required; if the path is blocked by another actor you can just stop and wait for a moment, but if the path is blocked by a more permanent thing you might need to completely reroute around the barrier.

Routing in games where everything is an open field and few objects are movingis an easy problem. Routing in games with tight spaces, with many moving objects, or with gates and doors and other portals, it can be very tricky to look like organic movement.

Ok, the way I described it is ok, but a little bit overcomplicated because of my system design.

I think this is ok, on the first view, I don't like the idea to rearrange this design, because I need much time, to think about which component based architecture I take, maybe it was not the best decision

Dominik

To me I'm going to say the same thing I end up having to tell myself day to day just looking at what you wrote: you're overthinking this.

You seem to be looking for the "ideal design" when the only real way to learn that is to practice, to see what works in different situations and come up with a design that you feel fits the requirements of what your game logic will need to do.

The truth is these forums and no other place on the internet has golden advice for game design, each game is different and how you can approach it has both a thousand ways that are right, wrong, mediocre or anywhere in between. We can give you advice like ideas about how to solve a problem but we can't really tell you the ideal way to design a game.

I also think you're overthinking the logic here a bit, is there something -flawed- with what you're suggesting to do?

Leaving on that note, I'll point out the obvious: take the simplest route, if you don't need to split everything into 50 systems, don't do it, you can always do it later. There's really nothing "wrong" with putting the pathfinding right into the ai component other than it may get convuluted after awhile or you may feel the code is being shared a lot and would be better accessed somewhere else. Frob gave you examples of things the AI might need to accomplish in order to move between areas, your design may vary based off that.

Thank you very much. No, I don't think there is something wrong with my systems design, and right, I need much more practice.

Thank you

Dominik