wraitii

This is an idea I've had for a while now (couple of years maybe?)... Original text in spoiler: Proposal below: Our civilisations are currently supposed to be balanced. Picking a random civilisation should, on average, give you a fair chance to win assuming equal skill. Since we now have 13 civilisations, that means we need to balance 78 matchups. This is a considerable amount, particularly since we actually have limited manpower, particularly for gameplay purposes. In my opinion, we only have 2 ways to balance so many matchups: Effectively reduce the # of civs (e.g Celt, Greek, Roman, Kushites), by making the different "sub-civs" very similar. This precludes adding too many different groups, or we have to add "trash" civs. Effectively make all civs very similar. We can't get AoE2 level of variety because our tech tree/unit tree is much too small. So we're reduced to making them all basically equivalent. I like neither of these options. My proposal is to split our civilisations into groups, and only balance inside a given group. What I mean is that any matchup inside a group should give you a fair chance of winning - but matchups across groups (say, below, Roman vs Kushites) could be terribly unbalanced - or could not be. Romans might have one unit or one strategy that Kushites can't counter for example. Below is a Group List (proposal with some quick reasoning). My criteria are, to some extent, chronological and geographical. I am also picking what I think would be interesting matchups. Superpower Group - the 3 largest empires in the relevant timeframe Macedonians - Under Alexander the Great, circa 330 BC, they conquered most of what I will call the then "civilised" world. Obvious pick. Aechemenid Persians - While Cyrus II is technically out of our date range, he's in the game files, and it makes fine gameplay to have Macedonians and Persians in the same group since they did fight. Mauryas - Under Chandragupta, became one of the largest empires — period — back then. These 3 together also form a continuum of Greek-Indian empires and are historically somewhat tied. I think they make up an interesting group. Mediterranean Civs - More naval oriented Romans - Since we are pre-marian, this is the Rome of the punic wars. Stronger in terms of naval power than we might think, not yet mingling with the gauls up North too much. Carthaginians - Foil to the Romans at the time, we need them in the same group for historical play reasons. The question is "who next?". I think we might put Athens, a strong naval city state, but they did not really wage war on each other too much. Alternatively, Iberians were conquered by Rome by 100BC, so they could be put here. I'm having a hard time putting Athens somewhere more relevant, because as a strongly Naval civilisation they would be easily unbalanced against "land-based" greek civs, and they're historically not really relevant against anyone but these same greek states. Athens/Iberians Aegean Civs - more land-based civilisations perhaps. Spartans - land-based, which makes them good to fight the two other successor states. Seleucids - Successor state in the region, that mingled with Ptolemy Ptolemaic Egyptians - likewise. Celtic Civs I'm grouping these here because they were relatively similar, and thus would be relatively easier to balance. To be honest, we could perhaps move them all alongside the "Rome" group, particularly if we put Iberians there. The trouble is that they didn't really fight many of the other civilisations from our time-range. We could also dispatch one celtic civ in each other group, for variety, but that throws historical realism somewhat out the window and might complicate balancing. Gauls Ibers Britons Unbalanced Civs - those that aren't in a group (yet/ever?) Kushites ---- The advantages of this are: We need to balance fewer matchups. With easier balance, we can make civs more diverse, possibly more historically accurate. Currently, and particularly in A24, we've made civs very similar as balancing is hard. It makes it possible to highlight some different matchups. It also makes it possible to add more civilisations - we don't need to consider the overall balance. As such, a Mesoamerican group can easily be added, like wise for Asian civs. The drawbacks, obviously, are that MP users would have a reduced # of picks, and that it needs some development to support.

Not to discourage you but the chances that we commit something that changes gameplay in such a way is low at the moment. In my opinion, these need a physics manager that handles collisions in c++, something that we will also need for unit pushing.

That's the hard part...

It appears to me some people enjoy the game, so I would not say this is an absolute fact. One can also create an almost perfect AoE 2 clone, which is a good game, purely by editing templates. Now, regardless of what the team will decide on balancing, I would like to say that borg has worked hard on his mod to make something that (it seems) people like, and that is a valuable achievement, which we should all recognise and applaud.

Hey guys, I have a change (D1871) that could significantly reduce the number of units stuck (and improve pathfinding behaviour overall) because of the use of 2 different pathfinders in 0 A.D. The change feels good to me and Itms agrees, but it needs to be tested (a lot). I'm asking for help on this: if people could try this differential and report how things felt. I'm wondering most if there are cases where units get 'stuck' walking (which generally doesn't happen in svn). In general, this will make unit movement more permissive (they can get closer to trees and other structures). Thanks for the help

It just means I enjoy coding for coding's sake. I've mostly worked on 'engine' things lately (pathfinding optimisations, code cleanups, things like that) because that's fun to me. Whether I was optimising an RTS or another type of game is not very relevant. I do have my own opinions on where I believe 0 A.D. should go as a game, some strong, other less so, but for me personally there are higher priorities right now and so I am not debating gameplay or playing much.

That's not related to the state or quality of the game (and thus not a proper argument). I enjoy working on 0 A.D. regardless of whether I play it. It could have become a fishing game at this point for all I care.

Just had this idea, and I think it's good, so I wanted to share this... Current situation As you may know, the AI is currently designed to ultimately be run in an asynchronous manner, in the background, over possibly n turns. A reference is this interview of @quantumstate for example, but it's also quite obvious from the architecture. The Idea was that thus the AI wouldn't be blocking for the simulation even if it was slow. Based on the fact it currently runs once per 8 in-game turn (about 1.5 seconds in SP, about 4 seconds in MP), we can assume that this is a reasonable time-frame for such a threaded AI. To support this, the AI receives a copy of the simulation state, through AI Proxy components on most entities and AI Interface. Consequences This is nice in theory - I've never questioned it and I don't think anyone questioned it in the past few years. However it has several significant drawbacks: The AI wouldn't be able to be run more than once every n turns (n=8 right now). That makes it basically impossible-by-design to micro efficiently, for example. Note that our synchronous AI can, but that's not how it should work (and it doesn't leverage that). Copying the simulation state is slow. AIProxy listens to most messages, all entities have one. It can easily take up several ms per turn (in fact I had a diff for that which I didn't keep as it was kinda broken.). Copying the simulation state is error prone. We have to do it manually. Techs in particular were a real pain to handle. Mitigations for multiple AIs (the common-API) are a mess. Copying the simulation state is greedy and custom. If the AI wants new information, we have to add it to its state. If it doesn't care about some information that we've added, we've payed the price anyways. The above flaws are all fundamental to the design. The second and first can be mitigated, but at great cost, and only up to a point. Proposed Change The biggest change is simple conceptually: we run the AI synchronously. It fixes all the fundamental design flaws above: we can run it every turn if we want to. This fixes point 1. we no longer need a copy of the whole simulation state. This fixes points 2/3/4. The AI can call into the Engine directly (using QueryInterface or something similar) - in a read-only manner. This can be by setting a flag or by copying only that relevant bit of data it's asking for. If the AI remains in its own context, we can use structured clones. The problem of this design is that if the AI wants to do something slow (and it does sometimes), it will lag. There is a solution. We let the AI run specific computations asynchronously, over a specific number of turns, using an interface similar to worker threads. Then if the computation isn't done, we block, otherwise we return the result and process it synchronously and deterministically. For these computations only, we copy whatever state is necessary. What I hope this achieves A speed-up of several ms per turn on both SP and MP. A much simpler AI interface (basically no interface). Still the ability to run longer computations asynchronously.

Fixed by https://code.wildfiregames.com/D1856

This appears to be a rounding issue, we're off-by-one. The walking speed is computed correctly everywhere, but unitMotion moves by one 'comma' more than should be possible. That doesn't always happen though, and I don't think the run multiplier code is related... But it's the one related change we did recently . Odd.

Do you have a replay showcasing this?

This exposes us to dangling pointers, as the component pointed-to may very well be deleted at some point (particularly for components referring to other entities). Now 0 A.D. doesn't actually change an entity's templates (i.e. its components) at runtime right now, so we could take some liberties with components of the same entity, but that's probably not something we want to do from a design point of view. Then again, changing components at runtime might be too difficult to ever implement. What we could maybe do is a component cache on the JS side to avoid going back to c++ everytime, but that's also scary for mostly the same reason. At the moment, we have bigger performance concerns imo.

It would make the code much easier to understand though :p

Hey, What you've noticed is accurate, and somewhat known (mostly by me I guess): The rendering is draw-call bound and slow, the pathfinder can be slow, and the Javascript main loop is very slow (we use it for most gameplay stuff, which is why it's slow). Unfortunately, profiling spider monkey accurately is very difficult. There are few tools, and almost none that can be integrated with an existing profiler. What you'd see in OSX's instruments and I assume VTune are memory addresses, which are actually JIT-ed code and/or spider monkey code (mostly the former). With a lot of hard work, using JIT debug output and the trace logger, one might create debug symbol-like structures to document these, but it seems not super useful. What we did in the past (and probably will in the future) for profiling JS was using our internal profiling, which does have an overhead but can give you an idea of what's going on. _Overall_, though, we've already optimised most obvious bottlenecks. The remaining bottlenecks are not trivial to fix, and JS is somewhat of a lost cause.

What you're seeing there is just the polygons used for rendering. However we do have a "terrain tile" system, which are the same size as every ground-rectangle you see above. Pathfinding takes places on a 4x more precise "pathfinding grid", which has 16 squares per terrain tile.

Erh, my patches might improve stuffs a bit the whole concept remains fundamentally flawed in my opinion.

I think implementing a Vulcan backend is a good idea, and it could support windows, linux and OSX (through MoltenVK). I'm not extremely up to date on the details of the renderer, but in principle we will need to keep an OGL renderer too so that older hardware is supported. My main question is if there are libraries that could allow us to implement a single low-ish level renderer and that takes care of switching to OGL, Vulkan, Metal or DX.

The pathfinder threading is safe because computing paths is a pure operation (by design) and all paths are computed in between turns in both the threaded and the non-threaded version of the game. If you compute paths in the background while also running other Simulation operations, then things might get weird. The problem is that the Pathfinder Grid isn't actually copied to make it 100%, structurally thread-safe. IMO that's not a huge issue but we need to be careful.

"Ridiculously complex" is a bit of an overstatement. None of the code is super easy but there's nothing too unexpected - except for unitMotion maybe. The pathfinder is actually 5 components: The obstruction manager handles collisions (for unitMotion - not the pathfinder proper) and rasterising static obstacles (like buildings and terrain) and keeping track of units. UnitMotion handles the actual movement logic. It's terribly written at the moment (buggy, unclear and inefficient at actually moving sanely…) and I have a patch (I think it's D13) fixing it. On top of that, we need to change the architecture to a Data-oriented design - I may or may not have a patch for this, can't recall, but I've definitely done it somewhere. The hierarchical pathfinder handles accessibility (and could be used to handle high-level pathfinding, but it's not really much faster). It creates big "regions" and connects them. That's where flood-fill comes in. I have a patch (D53 I think) that improves its performance. The "long-range pathfinder", AKA the A* JPS pathfinder, is pretty well optimised (aka making it much faster would take too much work). It can create a path from navcell A to navcell B using the rasterised map of the obstruction manager - so no unit avoidance here. The "short-range pathfinder", aka the vertex pathfinder, aka a graph pathfinder, is used to walk around units. It's triggered by unitMotion when getting stuck in some special circumstances. It creates on-demand an exact map of all units and A* on that. Nothing is threaded right now but two things are 'easily' threaded: the long and short paths computations. These are currently done between turns, and could be parallelised. Doing it _super_ safely would mean rewriting some stuff, doing it kinda dangerously is very easy and I have a patch for it on Phabricator somewhere. I also have (this one indeed very WIP) patch for unit-pushing, which removes most of the need for the short-range pathfinder (it's still useful to keep around for stuff such as finding your way around a resource). The short-range pathfinder might be optimised for the common-is case of several units close together since we could reuse the graphs across computations if those are in the same region - but it's not trivial to do correctly. The other patches are pretty much finished and ready to merge, they just need some review and some more testing.

It's not all it takes I also need to get my 0 A.D. groove on and I haven't got it back yet :/ . Anyways I think I have a 200$ amazon gift card lying around somewhere so don't worry.

Well technically it's because I'm using a custom setup so I can't bundle the game - why am I using a custom setup? Because my SSD is too small.

I do have a custom setup using brew for most libraries, but I still use the script for some because it doesn't work otherwise. It's also a super-hack and brew is very much not nice if you're aiming at using the same versions across multiple computers as it's not always possible to access a specific version.

Can you provide a GitHub repo?

This is an open question for @Itms

Haven't really been able to notice so, which isn't that surprising, moving from 38 to 45. 45 onwards will have spectre mitigations which will slow it down but maybe other gains here and there.