wraitii

Difficulty modes (Alpha123 is right in that medium, hard and very hard use the same logic while easy is a little dumber and sandbox will never attack) -Sandbox: 50% of the resource actually gathered are added to the resource count (in effect, gathering is twice as slow) -Easy: 66% -Medium: 100% (normal speed) -Hard: 133% -Very Hard: 166%

Just to be clear, it works now? We don't have very good support of external screens yet, as we're using an older library. But we're working on improving that.

Hi raymond, Do you have a Retina computer? There is a known issue with those. I think playing in windowed mode fixes it. edit: this post might be of interest to you.

Thanks for reporting this, I will look into the issue and it will be fixed. Edit: beyond what Sanderd said, there still should be no errors in such a case. I had forgotten this was a naval map.

Hi Don, those questions are actually perfectly valid and are some things that I should improve someday. There is a do-nothing AI, which is the "base" in the common-api folders. In the common-api-v3, this is made slightly more complicated by the presence of a "shared script", ie something that does computations for all AIs (and which is basically compulsory at this point). Another "do nothing" AI is scaredybot, which you can check in the AI folder (it's declared as hidden in its data.json though), it uses the common-api-v1. I don't think you can write on in C++ now, so you have to do it in Javascript. However we're planning to move some things to C++ for performance, so there might be a day when this is possible.

Okay, self-replying for a more detailed explanation about how entity collections work. First, this all happens in shared.js, which is the core of the shared component. Shared.js stores a list of all entities in an associative array [key] = stuff, which is like an even more flexible and slower version of an std::map. There is also an entity collections of those entities. It also stores entity collections in 2 ways: as an array (somewhat similar to an std::vector), under the name _entityCollections, and as an associative array of arrays ([Key] = [vector]), under the name _EntityCollectionByDynProp. Now what happens when we run ApplyEntitiesDelta()? There are 2 cases: -If the message is "Create" or "Destroy", ie if an entity has been created or destroyed, we will loop over all entity collections (using _EntityCollections) and either add it if it fits, or remove it if it was present. -If we are dealing with a state change, we will loop over all entity collections that have registered for this state change. If for example the change is a change in position, we will access _EntityCollectionByDynProp[position] and we will loop over the array of entity collections. Same deal, we'll check if we need to add/remove. Now this doesn't sound too bad. However whenever we check if we need to remove an entity, we will have to check if the entity is listed in the collection. And the collections store their entities as an associative array. Thus we need to do something pretty similar to a "find" for an std::map. And we do this a lot. Same for state changes, as we need to know if we need to check wether to remove or add then entity. Put together, this gets way too slow. To complicate things further, we often iterate over entities of an entity collection. And iterating over an associative array in JS is really slow. Now the proper way to deal with this would be to realize that entity collections are reaaaally often created by filtering other entity collections. Thus there is a "natural" tree here, and we could use this property to speed things up. Something to keep in mind though is that an entity collection would not be fully defined by its children. At the most basic level, we have all entities. THen we have entities for each players, including gaia. Gaia is special-case, since it's basically mostly resources. However for players the enxt level of division is generally structures and units. And in units, support and the rest (which ban de further divided in infantry/cav/siege…) With a tree, when we receive a "Create" message, we'd start from the top and see if the entity can be added to that collection. However if we check starting with the "all entities" collection, that's always a yes. We should probably start at a lower level, like which player. Then we'll check children of that collection. Thus we would only check a little more than what we need, and not all entity collections. When we get a destroy message, the procedure would be somewhat similar. if the parent doesn't have it, the children won't either. State changes are a little trickier. The best guess is probably to register the first collection in a branch that needs this state change, and check its children if an update for the parent was required. This would also help with making Filters more hierarchical, because obviously it's better to check if the entity belongs to the right player first then do some more complex calculation than the opposite. I think this would help improve the efficiency of entity collection filtering in JS. It might not be much faster though, because JS sucks for looping over associative arrays and arrays in general. Needs some thinking. And it definitely needs a C++ architecture to be efficient, in my opinion. (if only because the entity collections themselves are inefficient). Edit: some more notes. ApplyEntitiesDelta also changes the entity in the _entities associative array. Which is also a fairly slow operation. This is about 100% similar to the issue with the range manager and its entity maps.

RedFox/Yves: porting the existing stuff to C++ is a little bit like shooting a bullet in our heads. BTW Redfox Length is never recomputed, it's actually done only once and the counter is incremented/decremtned. The check for "this.length === undefined" checks if the object has ever been initialized. Anyway as I've said the whole architecture needs to be rethought. Currently entity collections are a bit like std::map, only less efficient. We loop over then entities a lot (for filtering, with "ForEach" and we actually very rarely need to call a particular entity in those at all (for that we use a call to the "big" std::map which stores all entities). So an std::map is probably the worst thing you could do. Secondly, the use made of those is dumb: most entity collections are created by filtering from another one. We could thus see them as some sort of tree, which would help "ApplyENtitiesDelta" because we could, with much less work, eliminate entity collections that won't accept this entity. I don't think this last point is 100% clear, but I'll get back to it later (with some graphs and all), I don't have the time right now.

RedFox: that doesn't exist because it's an associative array. But performance is generally horrible. I've got a few ideas on how to improve on that, but it might be worth considering moving it to C++.

I'm pretty sure this is always the same old issue.

Very interesting graphs, and very interesting reports too. It seems to me Mythos made a really good decision when he contacted you.

Yes it is fairly strong for a beginner, but I can assure you it doesn't spawn unit. Check A14 again, the difficulty settings should be better (ie easy should be easier) and there will be a new sandbox mode where the AI won't attack.

quimkaos: what makes you think that? Aegis doesn't.

New-ish version, fixes a serious bug where the AI would assign all its worker to fields/ too many to wood and weird stuffs like that. Also, the attack plans now attack informations again, because it's less taxing for the pathfinder that way. ai.zip

I like the idea of the big oak. It probably fits the gaul more than some fancy menhir thing.

Season would need a new texture, a sort of "decal" that would be overlayed on the existing texture. It might be building-specific but could probably reuse the base texture UV. It could simulate snow covering, vegetation growing and decaying, dust in deserty maps, things like that. Having a day/night cycle means adding dynamic lighting to the game, which is a lot more work. Both would have to introduce big gameplay changes (night would emphasis LOS and stuffs like that, which is not too suited for an RTS in my opinion, at least 0 A.D. would require a ton of changes.) Seasons would slow units down in winter, stuffs like that, which is already less important.

Some profiling data of a few simulation functions in an aegis vs aegis game I've just run. Obviously this graph doesn't show ComputeShortPath which gets stupidly slow (27ms at times) when the AI starts to attack and pathfinds a ton of units individually (I'll change that). What I've found interesting here is that "Move" takes 2.5ms reliably in the mid-game (25th minute) as many units move, and execute active queries is even slower (6/7ms). Those curves are quite flat, which would indicate those values don't really change from turn to turn. Combined, this is about 10 ms per frame devoted only to these two fundamental functions. With optimizations to the queries (which are easy) and optimizations to "Move" (which might be impossible, I actually have no idea what this function is), we could cut it down to 2/3 ms, which is a serious improvement. (calculateTerritories is here because I wanted to see if it was slow… It's 1 ms at most, not too much but not completely negligible either).

Thanks a ton for this wiki page, Yves', I'm getting pretty cool graphs for AI profiling which is really helping me see what needs to be done and what doesn't.

Menhirs and Dolmens are anachronistic for the gauls as far as I know, it was an earlier people. It might still fit if they adopted the buildings in their own customs, but that is far from certain. I'm really not sure what to give the gauls though. They were master blacksmith/silversmith, but that's not really a building, and I don't know of anything particularly massive.

I agree that we need more separation. Imo one way to do this is to make some stuffs obviously for early-game and some others obviously for late-game. Another way would be to make some resources work well, but only if you follow a specific path or only if you're really focusing on those. I'm not too hot on Berry regeneration, to be honest. Berries to me are the hunter-gatherer stuff, really only for a small boost early one. Hunting is similar, it should be fast and worth it if you're dedicated to it. However hunting is kind of broken right now (animals are too fast, too strong, too scattered and rare). Farming and Herding should be two viable long-term solutions. However right now farming is far better. One way to change that: -Herding should definitely use the "trickle" effect, by having animals tasked to a farmstead (which can train those). This would take a limited amount of space (currently only the farmstead) thus be easy to defend, but it would be slow-ish (obviously techs would make it better). -Fields should take way more space (We should make them bigger and perhaps reduce the overlapping possibilities). We also need to find a way to push those away from the CC, but making them like twice bigger might just do that. Perhaps a bonus if around a farmstead. Thus farms would be faster than herding but more dangerous: you'd need to defend your workers, and it would start taking actual space. And farming would occupy many of your workers whereas herding wouldn't. (btw about the farm diminishing returns, perhaps it should be changed so that 2/3 is optimal rather than 1 to occupy more workers). I can see two ways to handle fishing, being inherently map-specific: -make it interesting after some techs (like ~farming, but it would take less space). A bit like it's now. -make it way more interesting than farming/herding, on par with hunting, and even better after some techs. This will put a huge emphasis on water gameplay. It's a choice. Note that fish importance is dependent on other factors too: if we make farming take up a lot of space, on very watery maps, it won't really be viable, thus players will have to fish. Limiting other resources availability in general makes fishing more important, thus naval gameplay too. Technology wise, I think the game should force a choice on you. If you start improving herding, you can only improve herding later on (start with a pair and make any subsquent tech require that first one), except perhaps for a few rare cases.

Now with 100% more player colors: (I'm way too lazy to do proper AI work so I keep retexturing this boat instead).

In my opinion anything keyboard-shortcutted could be made a tip. And a lot of little play tips. Currently imo our tips are a little descriptive, not really insightful. There's a lot of stuffs that is obvious if you just give a look at the GUI. For example, the catapult one: CATAPULTS - Ranged siege engines that are good against buildings. < Thanks Capt'n Obvious - May upgrade to flaming projectiles for extra effectiveness against buildings and units. < Where? - Expensive and slow. < A little obvious too, you can see that in the GUI - Pack up into carts for movement, and unpack into stationary engines for attack! < Well, duh. I mean you really can't do otherwise. In my opinion this tip is not really interesting. Now as far as I know we don't really have fancy stuffs for catapults, like being able to attack a given ground zone to kill trees or something. But if we had, that would be an interesting tip. What might be worth putting for example is stuff like "can't be garrisoned in X" or things like that, that are not obvious. Another example: BARRACKS - Trains all citizen-soldiers. < True. But they also train champions if unlocked at the fortress. Which is slightly more interesting. - Research military technologies to augment your armies. < Not completely true with the blacksmith. - Build multiple barracks to train masses of citizen-soldiers quickly. < A good tip even if it's kind of obvious, but the phrasing could be better imo (the sentence feels hard to read for me). - Build a barracks in a forward base in order to supply your assault with fresh troops. < Good tip. For the barracks, what could be added? Right now, perhaps stuffs like "Build one early on to be able to train citizen-soldiers while you phase up". But frankly those two tips aren't really all that useful. They're stuff you can just guess and that the GUI tells you, a basic tutorial would deal with this info really well. The last two tips for the barracks would fit better a "Having a strong army" tip. Now stuffs that aren't obvious, like "citizen-soldier vs champion" or the "garrisoning for more arrows" are well deserving of a tip. I'd add experience (and in particular how citizen-soldiers lose gathering efficiency as they experience), unit groups, perhaps a few general concepts like "Territory battle", some strategy explanations (rushing, booming, turtling, whatever), perhaps some specific information about technologies (for example recently I've learned that in the Iron Axe vs Wheelbarrow pair, you were probably better off with Wheelbarrow unless you always made sure to have small resource returning times for your workers.) Perhaps some specific tips for some maps. Perhaps a few gameplay points that aren't immediately obvious (swordsmen make better siege units than archers or pikemen, cavalry swordsmen will kill support units faster). We also need a tip that explains the difference between females and citizen-soldiers. We could even throw a few build-orders here and there. Real tips, you know.

Very good tutorial, you should also put in on the Wiki, we might have some proper resources there for artists at last

New version of the upcoming version, no real changelog this time either, still more rewriting and still more work about naval stuffs (this time it's fairly close to completion but weird issues make me unable to complete). I've fixed a few bugs in the attack plans that should make the AI slightly better at attacking though. Just replace the binaries/data/mods/public/simulation/ai/ folder with the one linked. (for sanderd: not a patch because imo this is easier for a folder) ai.zip

Okay, so since I wrote the animation tutorial on the wiki, I got the model in-game and tinkled around with animating (nothing really done for now ). I made the row a prop to the fisherman, which is currently a mauryan archer stripped bare. I figured it'd be easier to animate the model on its own later. So anyway here's an in-game screeny...

How do you get these graphs, btw, Yves? Is it possible to do some more specific stuffs? I don't really know how to handle the in-game profiler…