Leaderboard

Hello all this is by far my favorite open source project so I decided to make an account here. I had an idea that I couldn't find already in the suggestions here. If you have played the RTS called company of heroes at one point you know by dragging the mouse while holding the right mouse button you can change the direction your units will be facing when they arrive at wherever you are sending them. I think if this isn't already in the works it would be a very useful feature so you can make sure your units arrive how you want them to. At times it is hard to preposition your units in battle without this feature. That is my suggestion! I hope to contribute on the programming side of things too once I get more familiar with the codebase as this would be my first time working on open source project.

Okay, the new version has been committed to SVN. Again, no real log changes, but tons of behind-the-door changes, so it needs testings, and I also need feedback: do you find it harder/easier than before? What should it do differently? Stuffs like that. Hopefully it's a little faster than it used to be, I'm not really sure. No naval support or savegame support as of yet.

Civ-Sol are your town guards and basic Cav is your explorer. Maybe some civs could have clubs/maces/axes, post some historic units that did and I'll add them.

Here is a recent forum thread about the Blender Guru "ancient civ" contest that Shadosk's mentioning. Bienvenue Shadosk / Romain !

I can't edit video, so i have a veeery long video of me painting this thing Took everyone's suggestions into account I think I did what I could, he definitely looks a lot less stiff! Thanks for the feedback guys background is a little new, could possibly be a bit too busy you know what, scratch that. It looks a bit dull

Looking good. To avoid the worst case of A*, you'll have to do some simple heuristics like described before. An iterative flood-fill method should be pretty fast and do the trick. Running some tests with my own A* setup on reasonably complex map layouts, a 48x48 (2304 tiles) can take around ~1500 iterations to cover the map, while a 512x512 (262144) can have over 88700 iterations per A* search query. If you can reduce the number of cells tenfold from a 256x256 map (~65k -> ~6k), you'd already cut down the number iterations by a huge amount, to somewhere around ~5000 for the whole map. Looks like a huge algorithmic victory to be gained regardless

Thanks for the writeup in this thread of the Aegis Bot. I am looking to help with this part of the development so it is really nice to see a well established ai. I have not contributed to any open source project so this will be my first time but I have worked with AI before, but never on an RTS. Don't expect much from me but I look forward to learning how the current AI works and hopefully I can start helping in some aspect. I have played against it a few times and it is going well I see!

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.