wraitii

This has been the case for a while, and I've internally already suggested changing it, but I'm making a formal complain here : the way we gather wood from trees is really annoying. This is a collusion of various factors, so I'm just going to lay them all down: Trees tend to be all over the place and forests not large enough, which is annoying to place good dropsites. Trees can be worked on by up to 8 workers, which is imo far too much (should be like 3). Forests are either too sparse (units get inside and start bumping into each other) or not enough. Trees imo don't have enough wood individually. Returning with 10 wood is annoying because of all the above factors, this would be better if wood was gathered in batches of 20/30 by default. But iirc we don't have different carrying capacity for different resources. So we should: change our RMs to generate better forests and fewer stragglers across the board reduce the max number of workers per tree from 8 to 3/4 make sure Rms place wood in sane way (hard to do though) bump wood on all trees a little bit, even if that means having fewer per forests (not incompatible with the above) if possible, increase carrying capacity for wood only (might not be necessary if all of the above implemented). Edit: to clarify what I want: I'm asking for general input in view of actually making a patch on this.

Have to say I agree… It also feels extremely game mechanic-y and not like something natural and rewarding.

AH, we read the same link I've found it remarkably interesting, particularly how many ideas they tried and ended giving up, particularly since a few of them we've had too. I really like how they intended to do capturing by having buildings become disabled when below 20%, and then whoever repaired them would gain control. I feel like that's far less intrusive, more realistic, and just better than our current system overall…

I definitely agree that we need some kind of system like that, but it's actually tricky to do correctly… Perhaps we could show which existing building the new building would be connected-with when you place a foundation?

This doesn't really add much complexity, all you need to know is that farms are only good if you keep them busy, so you need to try and keep them busy and keeping them not-busy is more rewarding.

Could you state why here? This is the topic for it after all

Hm, as I understood it, D227 is a go. You've had 3 explicit OKs in the ticket, I'm adding mine here. Getting 5 people to agree on anything is already a miracle so imo you should go right ahead with that feature.

Berries are a staple of AOE (to the point that AOE 3 joked on it), where they occupy the niche between collecting treasures/sheep and being able to farm because you have enough wood. This is a little irrelevant in 0 A.D. because our starting resources and units would allow us to have enough wood from the get-go to make farms (and we don't even have hunting). So I'd rather we just go into farms directly. Furthermore, berries made lore sense in AOE ½ because you start in the prehistoric/dark age, basically as hunter-gatherers. That's not really the case in 0 A.D. But mostly I find them annoying because they're bloody hard to see

Disagreed. The meta-play here would be capturing the animals before the enemy does it, and then keeping control of the animals. This wouldn't be entirely unlike the relics or the sheep of AoE, as wow said. And it would be a completely different thing from farming. If we added mechanic such as shepherds having to guide the sheep instead of capturing them a-la AOE, and we allowed laming the shepherd and/or the sheep, we could even have an interesting, high skill-ceiling early gameplay just based on capturing the sheep. It shouldn't be a huge food income but give you a definite edge as the game drags on, making it worth it but not absolutely terrible if you don't do well. Obviously this is only worth it if we seriously slow down the early game. Regarding corrals, I'm really not a fan of how they are implemented now because they just seem to be extraordinarily "game mechanic"-y. Anyhow, I think hunting is not working properly and probably never will, and I think berries are a bad idea given our usual starts and we should either reduce the starting resources and the starting pop or remove berries from our RM.

I'm all for removing stupid features, and could name a few (corral, imo capturing, I'd do away with anything that's not some type of farms for food, tbh…) , but I feel like you're getting it wrong on citizen soldiers. First: the point of citizen soldier is, first and foremost, the historical goodie. If we were to remove something, it should be the women, not the fact that military units can gather. I'd like to add that departing from the classic RTS formula isn't necessarily a bad thing, AoM had military units that could make buildings and that was a refreshing change. Your point about resource explosion is a little silly. Units can either gather OR attack, and that doesn't change from other RTS, so I don't see why it'd explode any more than another game. It's the fact that we start games with a farcical number of units and fast gather rates, as well as units being fast to recruit, that leads to apparent "explosiveness". Now, your calculation makes it sound like attacking is not worth it. But the math could be inverted rather simply if we lower gather rates and raise unit costs (including training time). If your attack takes 10 guys away from your eco (let's say for 120 food/minute, which would be far less than we get now, admittedly) and you manage to kill 3 enemy units (let's say each cost 50 food), then you're coming out on top by attacking. Other things must be factored in (buildings efficiency, how easy it is to garrison in 0 A.D. - imo by far the poorest design choice), but it's nothing structurally broken like you make it seem. Likewise, progress from weak to strong units has nothing to do with citizen soldiers and everything to do with how we (haven't) implemented technologies correctly.

Feel like there's absolutely no point having that in-game, but I would be okay with it for scenarios and whatnot however. Edit: that or the complete opposite of the above: I think it would be interesting to remove all other sources of food but farms, with mimo's changes in that patch, and offer a few different types of farms good at a few different things. For example a slow but steady gold source farm (say, peppers?), a fast-but-needs-a-ton-of-space-and-hard-to-defend type of farm (wheat?) and a slower-but-takes-less-space-and-you-can-have-several-villagers-per-farm type of farm (potato or whatever else ). edit: ah wait I forgot we don't have gold as a resource, nevermind that one then

Yeah that's a real issue for 0 A.D. (I find bushes can be particularly easy to miss), but imo not really the one described above.

This isn't a real problem, to an extent. Sufficiently skilled players will not get into mosh-pit engagements, because that's not really efficient, and will hotkey/select their units by types to micro them even if they don't know where exactly they are. Targeting the enemy unit can take more than 100ms since you'll need to think about it anyways. This is obvious when you see AoE 2 expert players. It's also always easier to count your units by selecting them all and seeing the number the game gives you than trying to count them (likewise with health and health bars). If your games has formation fighting, it's basically irrelevant because you don't need to recognise units instantly, it's not a MOBA. Finally, comparing still images is ignoring animations entirely, which are a key component of recognising units at a glance. I think I remember the original thread that was written about recognising things, and it was more about buildings looking too different across civilisations than it was about units. 0 A.D. also has a problem with seeing units/entities at all, not specifically differentiating them, as they tend to blend in the terrain too much.

I'm pretty sure that's just because that unit reacted to being attacked or something, because the simulation has no concept of direction and/or rotation for units (I say direction because there's no easy way to know what you're pointing towards currently). I don't think that's actually a huge issue, since it could probably reasonably be added, but then you need to change the combat system entirely. Which also is in the realm of possibility, in itself. Ships are a different matter…

Regarding territories, I feel like at least two things should be considered: -forbidding farms inside territories (or possibly dividing their efficiency considerable) -Actually using the concept of provinces from the original design, where the map was divided in provinces and you could conquer those in a largely predetermined way to acquire their resources. This feels limiting, but now that I think of it it's actually probably a much better way to handle this. That being said, it kind of implies larger maps, as do a lot of other things.

This is kind of not true, though. 0 A.D. has constraints that we are extremely unlikely to budge on, such as using Javascript for most things, which makes performance a much more real issue. I'm not saying dynamic LOS is impossible, but assuming perf is just a matter of better coding will end up being wrong more often than not in our case.

I feel like if something doesn't really fit (territories) it would be better to just flat out take it out. No while I do see that you're going for an overall vision/guideline, I'd just like to point out that this isn't enough for really anything. Or, to put it another way, don't expect the team to budge unless you get into the technical nitty-gritty (I don't mean code here, but detailed explanations of how things would work). Still, your direction seems interesting, so do go ahead

I'd like to see some more details on something that's not Athenians and see how you'd make it work. Overall I agree with your analysis of the troubles with 0 A.D., but I don't think you provide answers to all of it (e.g. territories don't really seem that much more useful in your proposal). Women seem like they'd be less useful on the whole and their presence becomes questionable imo. I'd suggest perhaps women are the population providers instead of houses or something. Gathering bataillons just seem like a PITA, too. I could actually like endurance as a gameplay feature provided running is only useful in a very specific "short-range outmanoeuvre to get a flanking bonus" case, which will be tricky to get right. Additionally, directionality with units with no turn radius and no concepts of "engagement" is a relatively dodgy thing. We could add those, but that has larger consequences on combat which you haven't gone into.

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.