Leaderboard

I think the main problem is that players will probably expect to get some feedback from the GUI when issuing commands while paused. E.g. if you click to train a dozen units, you'd expect to see your resource counters go down, so you can tell when you've spent all resources. We don't currently have a good way to implement that - your commands don't get executed until the next simulation turn (so they'll never get executed while the game is paused), and the GUI just reflects the current simulation state, so we can't update the resource counters while paused. I'm not sure how we could cleanly fix that, and it's easier to just prevent the player issuing commands while paused. But there's no technical problem other than the GUI - you can open the console (F9) and enter Engine.SetSimRate(0) to pause the game and close the console and issue some commands then Engine.SetSimRate(1) to resume, to see what the behaviour is like.

Chris Priestman has put together a beautiful piece about us at Indie Statik. He really gets what 0 A.D. is all about, and it shows: Plus, we’ve been featured in OMG!Ubuntu! and the prominent German-language website Golem.de. Some more shout-outs, including YouTube videos, can be found on our campaign updates page. Check it out! Please feel free to share more places 0 A.D. has been covered, and help spread the word to further outlets.

Ok, so i have some understanding of the code by now. I have inserted my code to create a NavMesh from a given grid - but have not increased the density to 4x4 cells per tile yet. Don't want to change too much code without really understanding everything. I have struggled a bit with the all-too-easily-overflowing fixed datatype but still converted all of my code to use them. I also had to remove all of the C++11 code :-( My beloved range-based for loops :-( Visualizing the walkability of the map (in m_Grid) you can imagine how those tiles can be joined to form larger cells (suboptimal coloring based on the cell-id): Conserving all flags this reduced the number of cells on this map from 65536 to some 7000. Ignoring the construction_obstruction flag (which is irrelevant for pathfinding) only 5854 cells are necessary to cover the map This suggests a speedup of between 3 (median size of a NavCell) and 11 (average size of a NavCell). The really interesting comparison would use 4x4 cells per tile to begin with though. The size of the areas without change would not decrease so the NavCells can stay just as large as they are right now (we only have to add some smaller ones near the borders), so I expect the difference to be more noticeable then. Pathfinding does not work yet, so there is no direct comparison of speeds at this time :-( To allow future camparisons I have already visualized a small benchmark of the old pathfinding though. Thought I'd share it with you in case you are interested: The plot shows the time it took to calculate a path (in ms) in dependence of its final length (in game units). You can clearly see the constant 10ms efford for any path to an unreachable goal due to the algorithm basically searching all of the walkable space. There is another line near 1ms probably due to starting positions that are either unreachable or on an island (test map was peloponnesian wars). ------ I have to admit that I am a bit less optimistic seeing these numbers. From the delay of ingame orders I imagined the pathfinding to be worse than it actually is and I had hoped for a higher median cell size. Still I am looking forward to the timings of my algorithm - especially when adding the denser grid as I know that the grid based A* scales really bad with increasing grid density.