wraitii

I feel like CCs should only be able to make a basic spearman or swordsman, and everything else should be in the barracks, with the barracks possibly producing a level-2 version of the basic unit by default (or treat the CC version as a level 0 weaker unit or something).

Quick meta-input: It's largely true that we haven't changed gameplay significantly since forever. The main cause of this is that not a great deal of people on the team actually play the game, and the few that do seem largely content with the breakneck speed and the current mechanics. There is a metagame, and it's a relatively simple one since it's rather poorly balanced on the whole. Furthermore, many devs feel that changing something now is useless since we're still in Alpha. Now this is something on which I could complain at length, but it's there. Personally, I believe we're a little too hung up on Age of Empires - and my personal preference would be for a complete switch to a production/consumption system over the "one shot" AoE like system of gathering resources. Each unit would consume some resources, each unit would produce some, and houses would give you manpower instead of raising the pop cap (which would then be soft-capped). On the whole it'd make eco more interesting. I also generally agree that the game goes way too fast in the early stages and that units are inherently too cheap, but that is definitely a matter of personal preference - and many would argue that AoE 2 goes way too slow. We've also had weird effects at play, such as the big unit speed and very large vision ranges, making our maps feel extremely small. Relatedly, our counters are crap - that's because we have far too few units per civilisations, and made some braindead decisions such as the pierce/hack attack we chose. But to go back to my first point: even perfect mods won't be played much, since the team doesn't play much, and that means that imperfect mods (such as my trade changes) have basically 0 chance of convincing anybody.

The fundamental problem is that our civilisations don't have enough units, on the whole, since not all of them have a basic spearman or a basic swordsman (and it gets worse when you consider champions).

You still should reduce the water waviness Regarding the lag, it's not "normal", but it's to be expected for such a map. Sadly our engine is currently not very optimised for rendering a lot of objects, since it doesn't use a technique called instancing. This means that beyond a certain number of objects, even powerful laptops will start lagging. Furthermore, the gameplay itself is not as fast as it could be and on a large map with a lot of objects and 5 AI player, lag is currently qui unavoidable.

I'd rather replace them with an EntityMap (we need good insertion speed, good lookup, good erase, and good iteration speed) but that means treating local entities separately (and I'd like to get D8 committed first). Some more profiling on the aspect, using a 3AI replay. Since there's no formations being used, we can check the calls to MT_UPDATE_MOTION_FORMATION and the number of entities called to get a rough estimate of "raw overhead per entity". We can complete with Update_Final to the visual actor, since only moving units do something there. Motion formation takes about 50µs, for 270 entities, i.e. around 0.2µs per entity. Final update takes 400-700, with 550µs as a median, for over 2450 entities. Raw overhead would be around 0.2µs again. What this tells us is that with around 5K entities (quite possible depending on map/mapsize) we can expect a raw broadcast-message overhead, per turn, around 2ms, possibly more. And I'm not counting the overhead from looking up handles and such. This isn't huge, obviously, but it's there. And well, 60 FPS means 17ms at most per frame. Now we cheat a little, but even if we aim to keep turns below 40/50ms, this is still at least 4/5% edit: obviously that means little since it's computer-dependant, but I'm on a 2015 2.7Ghz intel i5

Some more random profiling (as usual, take percentages as indicative more than actual): RangeManger::UpdateVisibility() seems quite slow. It's basically 100% the call to ComputeLOSVisibility, but in an unexpected way: 60% is ComputeLosVisibility(entity_id_t, player_id_t) calling ComponentManager::LookupEntityHandle() because that triggers an std::map find call, which is as usual horrible. The remaining 40% are the ComputeLOSVisibility call itself (which is not inlined whereas the first one is). Maybe we could avoid that handle lookup. For the actual ComputeLOSVisibility call, it seems to be mostly virtual function calls that are costly (and here I do mean the fact that they're virtual). RangeManager::PerformQuery() i about 40-50% GetInRange calls, most of the cost there is inserting (as expected). I do believe that could be skipped by iterating the original arrays directly. I don't see any special hotspots in the chess themselves, though the vector comparisons do seem slower, but honestly the assembly code is a little hard to read there :P. It seems to me like the slowest part is the check for min range, but I can't guarantee it. Also a bit of overhead in UpdateVisibilityData from the loop there at the beginning, and probably some overhead on function calls to UpdateVisilbilty and PerformQuery in general. Nothing too awful though. And I confirm general slowness in BroadCastMessage from using the map and calling the virtual HandleMessage functions. I'm certain the map is slow, I'm less sure about the function calls.

Ran some tests looking at things. There was some memory dumbness recently, though I've been working on fixing them. Still need to figure out if we need to call Clean() in UpdateGrid in the beginning, I doubt it. It seems, from my profiling, that BroadCastMessage is slow on its own because of the cost of calling the functions. Those are virtual, obviously, so they may be expensive if we call them enough times. It'd be interesting to look into it more, this may be a false positive or the real cost is calling JS components, I'm unsure. (EDIT: now that I think of it, it's much more likely that the cost is the cache-miss from accessing the component itself in the map, since we're using a map.) Another virtual call that might be more costly than we expect: the TestShape filter from our obstruction filters, notably used in the pathfinder's TestLine Decomposing TestLine, the std::map find is quite slow in general, probably in large part because we have tons of shapes and very few actually interest us so we waste a lot of time getting them back (as expected). It might be better here to store shapes in the subdivisions directly.

Definitely graphics related. Are your drivers up to date?

Yeah, fixed too.

You're referring to the fact that units sometimes glide at the very end of their movement? If so yes it's a bug, and it's fixed/it will be fixed in my ongoing UnitMotion rewrite which will land whenever.

You're correct afaik. I think we could also use a sphere/elipsoid bounding box, which would probably be best for a building such as this.

I can confirm that I have the bug fixed on my end, I'm just waiting for a formal report from someone on Windows and *nix that it works and that nothing is obviously broken, and then I can commit it. I need to check for repackaging options. There might be an easy-isa option, or I'll need to repackage the whole thing.

Regarding code and bridges: I actually believe a walkable mesh would be far easier to do than changing terrain. Changing terrain sports a number of drawbacks which I am very reluctant to get into. A walkable mesh would imply a new component, and tight integration to the pathfinder, but in itself nothing there sounds impossible, and would in theory allow ships and units. Since we cache the obstruction maps, nothing there is insane so long as the update isn't too difficult. We could also add gates to their sides and stuff. It would be a little slower, but it wouldn't be by that much. However, the pathfinding problems of gates still apply: closed bridges currently would be seen as utterly impassable. The feature is also not really that interesting, since most bridges won't be high enough to let ships through. Have to agree with draw bridges there (though how realistic are those for the time period?). I generally don't see handling height as relevant, that would just add passability classes for a super special case which is annoying.

That is "normal", passable terrain is defined by the slope of the terrain and not the terrain texture - contrarily to most other RTS games (and to be honest maybe we should change it). In that case probably you are going over some impassable terrain with your wall.

Hm, the water settings you posted above are good. I notice some artifacts in the reflections though. What map-specific settings do you use? Water waviness? Water type? This map looks like it would benefit from much smaller waviness and water type "lake" or "clap".

Are you running the water on highest settings?

How about "Vox Populi"? Kind of fits the FLOSS world.

My chauvinism forces me to suggest Vercingétorix

Hm, you guys were right, the code was completely bonkers. I should have fixed it by now, let me know after the auto build if you find bugs New format if you want props to sync with a main actor: <animations> <animation file="infantry/general/inf_02.psa" name="Death" id="death1" speed="250"/> <animation file="infantry/general/inf_03.psa" name="Death" id="anotherdeath" speed="250"/> <!-- ... --> </animations> To clarify: -no need to use named variants, just put all your animations inside one <animations> block. -"name" now must refer to an animation type (e.g. "walk", "death", "idle"). -You can use frequencies as before. -"id" is now the parameter used to sync across props. If an animation has an ID, all props will try using an animation with the same name and ID. You may have several animations with the same ID. I'll try adding tests for this later because it's quite annoying to check manually.

Hey, thanks for your interest! This is planned, but it's not as easy as you'd think. That actually sounds like a pretty good idea. We've been thinking about this a little more, but I don't see big changes coming. We have been quite unable to figure out how to implement formations. Don't expect too much on that angle for now. This would be possible but there's a few limits: -size of the Javascript memory - some maps already run into this, I've been thinking about making it configurable for people that want more. -it would lag horribly. I don't think we can go realistically beyond 200/300 units because it would become unmanageable for the player.

I'm not sure what the procedure would be, but it would be interesting to give them 0 A.D. I remain unconvinced that machine learning can efficiently learn to play an RTS with current technology, but who knows.

Honestly I think for very easy we should put it at 0.1 or 0.2

Have to agree that some more player color would be nice. Suggestion (nb: don't necessarily do all 3) -color a band around the legs -color the tip of the tusks -paint something on the front. It also looks quite golden and not bronze to me but maybe I'm just seeing things The howdah also looks like it's quite far back? Is that historical?

As far as I remember they were indeed deprecated (I remember for Corsica Vs Sardinia running into that problem, but it made more sense for that particular map so I ignored it). The "biggest" problem with circle maps is that sometimes you need bigger maps to make them work compared to square, but I don't think that really warrants keeping them.

I would be interested in an economic mod that plays a little more like Anno. With the resource agnostic mod in, we could even add a little complexity.