Monday, January 7, 2008

Turn-based movement

The combination of new baby and two-year-old continue to take most of my time and sleep.

I've been thinking about simultaneous movement versus “I go/you go” systems in turn-based games. I've got a Roguelike game I work on from time to time. It is currently a simple I-go-you-go system. Everyone is in a big list, and each unit moves in turn, without being able to move into any square occupied by another unit.

This comes up short in a couple of ways. If you have a line of units all trying to move through a hallway, the order in which they take their turns will determine how closely packed they can be. Because of this, it is harder for the player to predict how units will behave. Predictability is important for my game.

This kind of sequential movement also means that each unit sees the world at a slightly different point in time. Again, this affects predictability.

There are ways in which you can alter the movement order to try and prevent collisions. For instance, if a unit tries to move and discovers that its desired location is occupied by someone who hasn't moved yet, the moving unit could adjust its position in the turn order so that it waits until the blocking unit has moved. (You'd have to ensure that dependency loops were handled somehow.) This might be good enough.

A really expensive way to solve this would be to do pathfinding for all units simultaneously. The state vector would consist of everyone's positions. There would be a lot of edges in this graph, so it probably isn't an option.

No comments: