Jump to content


WFG Programming Team
  • Posts

  • Joined

  • Last visited

  • Days Won


wraitii last won the day on May 25

wraitii had the most liked content!


About wraitii

Profile Information

  • Gender

Recent Profile Visitors

4.387 profile views

wraitii's Achievements

Primus Pilus

Primus Pilus (7/14)




Community Answers

  1. I'll try and get some smaller instructions in the repo and I'll ping you
  2. 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.
  3. 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.
  4. Hello everyone, 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.
  5. Not really, could well be a bug. Might be fixable in JS though since I think that's what decides decay.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. A good community manager is something we've been lacking indeed.
  13. 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.
  14. @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.
  • Create New...