[AoM-like pathfinding/movement]

Hmm, that paper is about units with linear and rotational momentum, which I don't think is a good model for most units in our game

Sorry! I was thinking about something like that, but I can't find the URL.

Yeah, I think it'll be necessary to make pathfinding asynchronous - a unit requests a path on one simulation turn, and doesn't get the result until the next turn (or even later), so the engine can schedule the computations to spread the load. But it may be okay for each pathfinding operation to be uninterruptible (it rarely takes more than a millisecond with the current not-very-optimised code) so that only batches of multiple pathfinding requests have to be split across frames, which should simplify things.

It's quick, but in the map you use you never have to check a lot of tiles. If you plan for huge maps with a lot of units pathfinding a lot where you will encounter A* worst case (when used with the Manhattan distance), then it could become a problem.

[AoM-like pathfinding/movement]

An Age of Empires developer explained how they handled the problem of group movement, if you want to look at it:

Coordinated Unit Movement : http://gamecareerguide.com/features/19990122/movement_01.htm

Implementing Coordinated Movement : http://gamecareerguide.com/features/199901...ementing_01.htm

Yeah, currently I have it so that both units stop and try to find a new path simultaneously. That doesn't work well when one unit comes from the east and one from the west, and they collide and both decide to head around the north of the other unit, so they both move north and hit each other again, then both decide to head around the south of the other unit, and repeat many times. I guess simply telling one unit (based on some arbitrary priority) to wait for ~1 second before computing a new path would help with that.

According to litterature there are two main ways to solve this. The first is named "Steering behaviors", which is what you want here, and the other one is about crowd simulations, wich is out of scope and still an area of research. Note that it is also possible to cheat and allow units to cross each other.

Steering Behaviors For Autonomous Characters : http://www.red3d.com/cwr/steer/gdc99/

Currently it keeps the old long-range path, and recomputes a new short-range path to the next waypoint (avoiding the new obstable). I don't think that's great, though - it might get stuck weirdly if e.g. someone builds a long wall in its path. Need to make the code more robust when paths become invalid or the unit gets stuck, without allowing one unit to eat up an unfair amount of CPU time, but I'm not sure how to do that properly - it'll probably needs lot of testing and tweaking.

If the new short-range path fails (rare), then you can always ask for a new path. Concerning CPU cycles, it's possible to give the pathfinding code a budget each frame, and ask him to continue the computations the next frame if it's not finished. There are a lot of possible optimisations too but I guess they should only be performed if pathfinding takes too much time.

[[Review] Patch for ticket #251 - parser does not ignore comments.]

Hello!

This is my first patch for 0 A.D, I hope I made it right. The related ticket is here: http://trac.wildfiregames.com/ticket/251

The only thing I did is modify the parser so it does not treat values of 'typeRest'.

Thanks for the review and for opensourcing this great game.