wraitii

I'll try and get some smaller instructions in the repo and I'll ping you

Indeed something to be discussed. That being said, my intention here is more the former than the latter. I hadn't really considered it, but I think I could maybe set up a branch system to have variants of the mod, so you can use the provided infrastructure for other things. Alternatively, you could just setup forks that implement entire redesigns.

I do plan to have some screen on the landing page if you've activated the mod, but that'll only be for signed versions of the mod, which I expect to lag behind the 'fastest' stuff. It's going to be a little awkward, unfortunately, but less so than having to actually apply patches or something Not doable for this release either, though yes that would be a nice feature.

Hello everyone, LINK: https://gitlab.com/0ad/0ad-community-mod-a26 Following recent & less recent discussions on the forum, the team has a proposal on how to improve balancing that seems viable in the short term. This post will explain the 'what' and 'why'. What We will make a copy of the files relevant to balancing (templates, civ data, techs, ...) as of A26's release, and create a new repository on Gitlab. This repository will be bundled as a 'A26 community balance' mod, and regularly signed & uploaded on mod.io by the 0 A.D. team. The mod will also be easily downloadable directly from gitlab. Community members will be granted commit access to this repository, on a voluntary basis, by 0 A.D. team members. This commit access is subject to the expected rules, such as not trying to mess everyone's work and generally behave productively. More generally, the mod will be public and anyone can easily make PRs using GitHub/gitlab's interface, and people with commit access will be able to merge PRs. This mod can then evolve on its own after A26's release, independently of 0 A.D.'s work towards A27. Why We agree with you that balancing is a sore point for 0 A.D. The issue is complex, and the team lacks time to fix it. Previous efforts, such as the balancing PM or the balancing subforum, did not work well enough. Furthermore, we receive a lot of feedback from the community on gameplay and would like to give the community a more hands-on approach. There are far more players than team members, and we hope that having more people with commit access will speed things up. We understand that Phabricator is a little unwieldy. Using a better known tool will also make it easier for people to make changes. We cannot currently give commit access to the whole SVN repo, nor can we easily split the 0 A.D. mod to make balancing its own repository. Making more regular releases seems unrealistic at the moment. Migration to gitlab is also a work in progress. Therefore, we think this is an easy way to make strides forward while not increasing the workload of the team too much. By making it a mod that can easily be downloaded, and that's provided by the 0 A.D. team, we can somewhat ensure that the mod will be played, and thus a better product. This also relieves the team of some of the pressure of balancing the release right away, since we know unbalanced units (which are somewhat inevitably discovered after release) can be fixed. What happens with A27? This balance mod's scope will not follow potential engine changes in A27, and may not be immediately portable when the time to release comes around. Our hope is that, by comparing the mod with A26, the 0 A.D. team can understand the direction that things should go in and port relevant changes in a coherent manner. This will almost necessarily lead to some changes not being ported, or to some work being necessary to do so. To summarise: we'll give you the keys to the car to make A26 a more fun game. By the time A27 comes, we can hopefully use your work (and our own) as a good template for a better game out of the box. If this experiment is a success, we may reproduce it after A27, but time will tell. --- The repository will be shared around the A26 actual release, to make sure the files are indeed those from A26. In the meantime, feel free to share feedback on the idea and indicate what you'd consider a fitting role for yourself.

Not really, could well be a bug. Might be fixable in JS though since I think that's what decides decay.

Note that changing the cavalry to use its own pathfinder size would be much slower, but changing the pushing logic is cheaper and perhaps doable. On chokepoints specifically though, the 'bogging down' mechanic in A26 should help, potentially significantly.

It's improved the same as the infantry, but cavalry doesn't take more 'space' than infantry despite the larger mesh size. That remains future work for now.

The overlap is to enable more crowd-like movement, which improves performance and pathing in general. However, A25 had some workarounds that could lead to significant overlap. The RC / A26 should be much better in that respect, though you'll still get significant overlap in some situations, particularly for cavalry. Left is A26, right is the older A25 setting. I sort of agree that counting enemies should be done by selecting their units though.

Realistically, I think those would help with pure balance efforts, but: We aren't giving commit access to balancers on SVN, and it's unlikely that the switch to git would help much on its own (not even mentioning that git is rather complex to use). Giving access to just the balance data requires splitting the 0 A.D. mod from the public mod, & then actually using svn or git for it. All of this is work. Stan has plans for a gitlab migration, but progress is slow for lack of time. Splitting the 0 A.D. and public mod is also work and will lead to interesting problems of synchronisation and things like that. It's entirely possible that it will actually make development slower overall. --- The only real option I see now is to make an official copy of the relevant parts of the public mod after A26, and then let players modify that mod while distributing it. But only assume A26 compatibility. Then nearing the end of the A26 cycle, look where that mod is, and bring back the relevant changes. This of course assumes that the engine hasn't changed substantially in-between, which may or may not be a fair bet.

Anyone is free to give their time to set this up. It's just writing. No one in the currently active dev team or forum members at large seems to be up for it, unfortunately. I think the problem is actually that balance should be more accessible to the developers. We don't really know what we need to do at any given time because few of us actually have the time (or indeed the motivation) to play the game. I don't think a direction is 'needed', nor do I think this project is likely to die soon. There are several active & semi-active developers, and we have renewed somewhat regular releases compared to years past. People care, and so long as one person cares, the project isn't dead. Now to discuss some finer points There is one thing that must be understood: there is no 'deciding' what people do in 0 A.D. You literally cannot force them to do something else. Even if there was a 'decider', their decision power with regards to the 'majority of work' is zero. The 'balance' problem isn't that we don't have a decider, it's that we have no-one actually working on it. Stan is currently working a potential GitHub migration. I think he doesn't have enough time for it though. Help there would likely be much appreciated. But you should expect to be doing most of the effort in reaching out & getting told what to do. I think it would be a great way to help the project if you're up for it, but it's not going to be easy. - 0 A.D. used to have a 'decision maker' to a large extent on gameplay decisions. They day he left was one of those 'almost killed the project' days. Yet it endured. No solutions are risk-free, and no solutions are perfect. But a hard reality, that I cannot stress enough, is that someone taking their time and effort to get anything actually committed is worth more than any endless discussion on the forums.

Alright, time to bring out the salt. Absurd statement. All of those complaints are possibly contradictory. If anything the fact that there is always one unit that's OP, but it's not the same unit, proves that we do do balance changes. Formations & naval combat aren't a feature of competitor RTS games either, so why pretend it should be here. 'Expected polish'? Did you somehow pay for 0 A.D.? Look, this can be rephrased pretty easily as 'People come to the forums, dunk on the team with their brilliant ideas that are definitely gonna fix everything, then whine months later when their miraculous solution™ hasn't been adopted when in reality they have done 0 effective work for the project'. We don't need you. No one cares about you. You're just some random human complaining on the internet right now. Your contributions to the project are nil. You don't have a phabricator account, you've never posted on Trac, you've never actually contributed anything beyond forum posts, which have obviously not succeeded at doing anything or you wouldn't be complaining right now. You've been here for 4 years. If nothing has changed, perhaps you should look inwards: your current efforts are insufficient to help move forward 0 A.D., and playing a self-aggrandising card to the dev team achieves nothing (though you did get a good rant out of me, I do love these). Your first post in the forums was "What can I do to help?". My answer is simple. Start actually helping, or GTFO. Wish I could enshrine that sentence.

A good community manager is something we've been lacking indeed.

An option with respect to that is letting people download mods from mod.io, not the host, but fetch the list of mods from the host. It's essentially the same thing but you don't need to trust the host so much. That feature I think we only miss for lack of trying. --- Now with that being said: I think one thing that gets forgotten in this discussion a little is that the project is still given as an alpha. The snail pace is sort of OK. It's actually less idle now than 3 years ago, for example. Should it 'die' in number of players, well it can just be rebooted later with a different visions since the objectors will have moved on. This is a different ballpark entirely to commercial endeavours, which must succeed. We can fail time and time again and it doesn't really matter.

@smiley Yeah this has been an area of interest for me for a long while. @Mercury On my end anyways, the problem has mostly been about convincing myself that: The changes are correct and won't crash/OOS in odd ways The changes are actually faster. One difficulty is that profiling this type of change is difficult, since they tend to change the game determinism. So you kind of have to get a feel for it. In the particular case of your suggestion, maybe it's straightforward with a replay, but it would still need to be shown. Changes for the sake of change are bad for 0 A.D., particularly 'optimisations' which tend to make things more complex. What I'm saying is that 'conceptually faster' might be 'totally irrelevant' or even not actually faster -> only hard, cold numbers matter. In the case of my 'sparse vector + dense vector' approach of D3186, the performance degrades over game time and I haven't been sure that it's certainly better than just an unordered_map or things like that. There are slightly less brute-force approach that might make those cases better, but slower in other situations. It's tricky is what I'm saying. The problem is that you can't be _that_ agnostic about the actual storage location. Getting more performance at this point generally means thinking about it, at least. -- A few other things: ComponentManager::QueryInterface is mostly used by JS code, where I think its performance cost is largely dwarfed by the performance cost of C++ <-> JS interop. The C++ code usually goes through the component cache. I am not sure getEntitiesWithInterface is used all that much, I think most JS code that does something similar actually goes through the Range Manager. -- Finally, a quick overview of some things that can definitely be optimised still: Posting (global) messages is probably slower than it needs to be because of the std::map iteration. That's mostly what my diff above set out to fix, but we might gain from using specific structures for that instead. Memory layout of components is fragmented (using new), and we would gain from denser layout. I do not know if we should favour putting components of the same entity together or components of the same type together. We can probably gain by having more dynamic message subscriptions. The game already allows dynamic global subscriptions, but not dynamic local subscriptions. The fact that we support several component types per interface slows everything down and prevents a number of optimisations, by basically adding a layer of indirection. We only use that feature for UnitMotion vs UnitMotionFlying, and to be honest I am not sure it's a good thing to support. But I also haven't really been able to convince myself of that, and tear the feature out. I think an approach here would be to split unit motion into a 'navigation' component that mostly has the current unitMotion interface, and more specific components 'WalkMotion', 'FlyingMotion' etc. that handle the nitty-gritty of moving. But that sounds kind of complicated, and would probably only be a benefit if we remove the component-interface split.

This sounds a little like what I've done with D3186. I need to get around to profiling that better.

Eh, not much, but you're really not missing out. There's been very few threads in the past few years, and mostly internal drama.

I think you have unreasonable expectations of how this would go. We did open a dialogue, we in fact opened a ton of it in the various PMs and forum threads. We asked people to send us changes, and we tried to merge as many of those as we could (this meant understanding the change, the justification for the change, the validity of the change, and then actually merging it). If what you mean buy "give responsibility" you mean commit access, this is something we haven't done because: it's an on/off switch right now and seemed potentially a little dangerous, but that may be too cautious an opinion. who we gave access to would become the de-facto balance dictator over all others. I fully expect that to go extremely well and cause no controversy whatsoever. As for the faster release cycle, I think it would be a worthwhile option to decouple the 0 A.D. mod, that we can provide via other means & update separately, from the 0 A.D. game, but we haven't gotten around to that just yet. Maybe an easy first option is to have an official 'patch' mod that we update rather more frequently than 0 A.D. itself, but it does introduce complexity if some features get changed and compatibility breaks. Ah, yes, but that's the catch: this is one of the things that we can do, since it doesn't affect gameplay. The fact that it hasn't been done must be put to a lack of interest on the part of people writing code for 0 A.D. (for my part, I have to say I'm more interested in other bits of the game. Here is the time for the usual FLOSS disclaimer: we are takers of good patches that introduce worthwhile functionality.

I think the game is more balanced than it was on A23 (or A24, don't recall), so I'd say it has been a local success. Yes, that is what I am saying we cannot do. There is no 'manager' in charge here. The simplest way to move change forward is therefore 'fait accompli'. Make a mod that basically the whole lobby uses, and it'll be straightforward to argue that it should be replace the 0 A.D. public mod. --- Specifically, combined with the above, a single vote to choose the 'mod' for the next alpha might be workable. --- I think that's rather unfair/incorrect. There has never been more development on the graphics side, and I substantially upgraded the pathfinding in these late alphas, not to mention the threading. It's just not something that's very visible to players, but as a game engine 0 A.D. has made strides.

The core issue is that for the most part, team members are people working on features, because people that care about balancing & gameplay are players, and players like to play. And people just don't have the time to play and work on the game. Ergo the team are feature-builders, and there is real vision for gameplay. Add to that that amongst the team, we have severe disagreements on how the game should play. There is deadlock there to a large extent. Then nothing really changes. The problem with the 'incremental changes' approach that we tried to take is that everything can be scrutinised, and it kind of precludes changing the 'long-term vision'. I think it worked well to locally balance the gameplay, but it has lead to increased uniformity and has not really made the gameplay more interesting. Another way is the 'split & regroup' approach, that was tried with balancing mods or to an extent wow's Delenda Est. That has the benefit that it can leverage a benevolent dictator and realise a vision. If there are enough players / traction, it could be considered for merging back as the 'main' 0 A.D. mod. But it might need us to provide more support to help good mods gain traction, and it would probably benefit from a split between more 'engine' files and more '0ad-specific' stuff. --- Finally, 'balancing' is trivial. Just make all civilisations have identical gameplay. That's not particularly interesting, but it would work. The question is generally not how to 'balance' but what game to make.

I completely disagree. What if a modder doesn't use the base template? What if we had hundreds of damage types against specific units, like Aoe2 does? That's just asking for a mess. Not to mention the possibility of technologies suddenly making units that were impervious to some damage actually take that damage. Except a resistance of 0 is 100% of damage taken, because the formula is exp(0), whereas exp(undefined) is Nan. So it's not like they're actually the same at all in Javascript. Maybe Resistance needs to be renamed again, but I've yet to see a convincing counter-argument to that diff. Right, let me add a bullet point: Healing rate is expressed as a % of health instead of a fixed HP rate (note that's also fairly arbitrary though. One can argue that more HP means you should be healed slower as a debuff. I just point out it's a trivial fix). --- Of course, there is an alternative option here. Have all units have the same HP, and change their armour. It comes out exactly the same, of course.

The idea of current armour is that +1 is always +X% (I don't remember what percentage exactly, maybe 10%), whether your base armour is 1 or 999 doesn't matter. There are three approaches for resistance, broadly: Raw numbers (AoE 2) -> has the drawback of being very prone to unexpected big changes from small deltas (e.g. a +1 tech can be anywhere from 0% to -50% damage in practice) Percentage points -> Add 10 percentage points of resistance. So if you had 80%, you now have 90%. The problem is likewise that a tech can have very different effects, but you sort of avoid the thresholding problem. AoM used a system like that IIRC. An exponential system like 0 A.D. uses, where + 1 armour is always +10% armour, no matter what the base armour level is. This is easy to reason about for techs, and easy to reason about for users. But it means you technically cannot have 100% resistance to some damage, though in practice the difference is limited. The main drawback is that the math is kind of unintuitive & raw points don't tell the whole picture.

I think it'd be more logical, gameplay-wise, to have units restricted to roads. Then you can just make those units fast. But that can't be implemented for now, because terrain only affects passability via height.

Global auras and technologies are the same tech and the fastest. Auras pay a small penalty from being tied to in-game entities, but I think it's negligible compared to the cost of the modifier. Player auras are just techs I think? Single-Entity-only modifiers are about as fast so long as you only consider one entity, but you pay the cost for every entity. Garrisoned auras is probably slightly slower but kind of negligible. -- Ranged auras are much slower than all of the above, for we need to compute every turn what has possibly changed. They also add single-entity-modifiers, so you pay the cost of those on top of the raw aura calculation.

My opinion: we need D3886 to make resistance opt-in rather than opt-out we need to normalise all resistances to 0 and adjust health accordingly. Any non-0 resistance must indicate a particular strength/weakness of the unit, and only that should be shown in the GUI (I join the opinion that '10% extra resistance against hack damage' is better than arbitrary levels) we need to allow negative resistance in templates (maybe we already do?), as bonus damage. I've grown rather sure over time that anything else is complete insanity. --- Also, it's called resistance because you can't have armour against status effects or capture, technically.