All Activity
- Past hour
-
Ok, I see why you want exponential decay, it’s not that you want a fixed minimum capture time (hard cut-off), but a diminishing return, to softly increase capture times for faster cases. That can also be done with no need to split the capture in linear and exponential parts, you just need a formula that modifies your capture rate to have this exponential behavior, but capture behaves linear all the way. Maybe this is what you meant by “not visible”, it’s just that in your original description that wouldn’t have been possible. This took me a bit because capacitor equations are not that appropriate for this, but what would work is R=r*(1-D/(1+e^((C-r)/S)), where R is your corrected rate, r is the rate as it is right now, D what percentage you want it to decrease for larger rates, C the rate that would indicate what is normal and what is fast, and S how sharp the correction is (more or less, the width around C where it mostly happens, for then to stabilise according to D). Then, for D=0.5, C=300, and S=100 (I’d fix it at C/3), you get these values (with C fixed, D and S can be tweaked to get different things): r=100 -> R=94 r=200 -> R=173 r=300 -> R=225 (the function scales nicely, if C=3000 and S=1000, then r=3000 -> R=2250) r=400 -> R=254 r=500 -> R=280 r=600 -> R=314 (stabilising at 50%, which can also be changed). I know that some people are scared of (simple) equations, but again, no one does the math, one gets an intuition, and what is good about this is that it does what you want, while keeping what one sees linear.
-
wowgetoffyourcellphone started following andrewtlong
- Today
-
Unusual high sniping activity of very few players
amjid replied to ffm2's topic in Gameplay Discussion
This looks more like input optimization (macros, scroll binding, high polling rate) rather than just raw APM. Small hardware tweaks can make a big difference in micro, especially in RTS gameplay. -
amjid joined the community
-
Good catch, I'm suprised you could notice it from replay at x2 speed. I took the video while developing and there was a math flaw at the time. The formula I went for in the end is simpler using root degrees to also avoid any asymptote, which make it very safe if you input low values. Again, check https://gitea.wildfiregames.com/0ad/0ad/pulls/8892 if you want to go into details. The new capture regeneration system reward garrisoning stronger units. Would be a shame to remove it now with this. Also still don't think putting a hard cap is any good compared to diminishing return.
-
The rate cap I propose should be after accounting for regeneration, if that's possible. The only effect should be to stop captures faster than a certain minimum time (given, of course, by the total capture points divided by this effective rate cap). But in your video it is visible, and it should be, that's the point. It goes from 4000 to 2000 points between 0:13 and 0:25, average of 167 points per sec, and then from 2000 to 400 between that and 0:39, average of 114 points per sec, which is 32% slower, and could be frustrating when one had an early estimation on how much it would take.
-
I don't like it that much either, but given that we do want to nerf specifically the faster captures, maybe this could be the lesser of evils. Somewhat, we cannot fix it with current balancing tool without impacting the normal capture, so maybe introducing a new one is necessary. I've set rather safe values for the PR, that should have noticeable impact only for the worse cases.
-
I was referring to the fortress. I agree that more points would be good. On the last point, I don't recommend adding an additional point of complication to a mechanic that is already complicated, as you mention in your OP. I agree with the other stuff, especially the need to nerf the high volume capturing scenario and not the small volume. To clear up some confusion about the nerfs that I introduced ahead of R28: by increasing the default regen rate, we essentially increase the number of units needed to achieve the "high volume" capturing scenario. At the same time, you are punished less for having an empty CC, giving you time to garrison it. I don't say that its perfect, but its better now, and in my games I see people go for siege more often.
-
Gitea: Issues without a Milestone
Atrik replied to Obelix's topic in Game Development & Technical Discussion
Probably something to do per-case. Backlogging seems to be worse case to me. Maybe if the issue seems important we could add arbitrary milestones. Also I don't know if it's somewhat impolite but maybe assigning members that have skillset and bear interest in the area that the issue touches, could nudge some to pick up the issue. -
Gitea: Issues without a Theme label
Obelix posted a topic in Game Development & Technical Discussion
Like some people might have noticed I worked on some janitor tasks in the last weeks. Now every open Issue has a Type label (some 35 closed ones are still lacking: current state), a Priority label (some 24 closed ones are still lacking: current state) and countless tickets have gotten a Theme label. As of today we have 112 open and 181 closed Issues lacking a Theme label (current state). I probably opened everyone of them, but have no more clue on how to label the last ones. Therefore I call for support! I you have the corresponding user rights on our bug tracker, please consider working on before mentioned list - and when opening a new Issue, please remember to use at least the three important label categories and a milestone. Why is this label important? If bug reports arise on the forums, it's not always possible to check on Gitea for the existance of already opened Issues by using the search function. We have no semantic search function, so it's sometimes just luck to find something if the words are matching. Then the search by Theme labels really helps. But if tickets haven't such label, we might open duplicate Issues which leads to problems in the future like redundant work etc. -
Currently we have 97 Issues without a Milestone listed on Gitea. The oldest one has been opened 4 years ago, but it seems to me that new Issues without a Milestone increased since the migration from Trac to Gitea. Shall all Issues without a Milestone be backlogged? If yes, I'd proceed.
-
Thanks to everybody who voted and participated. I think the trend was already identifiable by the vote so I went ahead and made the PR. Current key changes (might be amended by balancing members). Make some techs add capture points to associated building. Sentries add +50% to towers Professional Garrison add +100% to forts Add +500 base capture points to CC and +1000 capture point to Forts. Colonies almost unchanged. Support diminishing capture rates for CC and Forts See https://gitea.wildfiregames.com/0ad/0ad/pulls/8892
-
Here are the results of applying a exponential decay of 1.5 above 100 capture/turn. Before : Screencast+from+2026-04-25+15-51-09.webm After: Screencast+from+2026-04-25+15-56-10.webm Maybe the current decay is too sever or the threshold too low. But here the fort with 20 champs do resist a bit longer to theses 150 legionaries as the defender would probably expect.
-
I agree that it introduce a technicality and that's something to avoid. But it's much less so confusing then a full hard cap on capture rate. Especially given that the regeneration would be applied afterward so a hard cap on the rate would just create a artificial point where defenses are strong enough to defend whatever. The exponential decay is, in that regard, far less likely to introduce counter-intuitive behavior. Still a technicality, but one subtle enough for players to never encounter any confusion moment even if they don't know about it. I also agree that generally you want linear rates wherever you can fit them, instead of exponential one, because exponential effects are so hard for humans to comprehend. But here "exponential decay" doesn't result in a "exponential" visible effect. Instead it aims at making capture rates more intuitive by making the faster captures actually slower, therefore likely more intuitive for the defender, and barely less intuitive, for the attacker.
-
Yes, I understood you the first time, I think. What you say is, given a Fortress, you would call normal capture the time an appropriate army would take to capture it, and fast capture the time a huge army would take to capture it... that is, after a certain army size (or quality of troops, or Fortress HP, whatever), you want to cap capture time. That's why in your example you trigger exponential decay after some point because the decay rate is too large. It would work, it’s somewhat equivalent to a capture slots cap, but I think it'd be confusing and frustrating for players to be confronted with a capture slowdown midway the process. That’s why I said, instead of doing that, just cap the rate, and enjoy a linear behavior all along. In your example, “if you are capturing a CC with a total of 500 pts per sec”, just cap that to, say, 300 pts per sec, or whatever that results in a capture time similar to the linear+exponential decay case. Setting a maximum capture rate is a less complicated technicality than combining linear and exponential decay, and it’s a nice and simple way of fixing a minimum capture time. That’s what I meant with a slower linear decay being able to do what you want: nerf fast capturing, leaving alone normal capturing. Good to know!
-
In any case, I would PR for what this poll gets us. There haven't been any reason given for the poll proposals to be rendered invalid. The result of 1. would make capturing more difficult then my own taste but whatever...
-
As a starting point, it seems fine to me. Still, I think that in some normal circumstances, capturing is still a bit too quick/easy. Maybe 1000 points are enough. We’d need to test it.
-
Every turn, a structure losing over 200 pts would resist better to the remaining capture pts it is meant to lose. This would be clearly aiming at making capturing faster less then a certain amount of time, much harder, without making any changes to normal capture difficulty. In other words, nerf fast capturing, without impacting at all normal capturing. And without introducing a complicated technicality players would need to be aware of. Already indirectly the case, since capture speed is increased by how much a structure has lowered hp.
-
But what would be the effect of this? What's the difference of having a linear decay followed by an exponential decay, with a slower linear decay that results in the same capture time? There would be a difference only if actual (not total) capture points have an effect on some other stat. If the idea is that it would be noticeable on structures with a lot of capture points, then just give them more capture points (for the linear decay to catch up with the linear+exponential decay), unless I'm missing something. Something else I don’t know how it works is the effect of siege engines on capture points, which they should have to make their use make some sense besides destroying things. Since an army made only of soldiers or only or engines should have a very difficult time taking on a Fortress, I’d say that engines should increase the soldiers’ effect on capture points (not by proximity, but when actually taking part of capture), that way a mixed army would be more efficient.
-
Glad you're not thinking +1000 capture points isn't too much. We can go over some calculations for the CC that has a base of 2500 pts, we are increasing it to 3500. So a 40% buff. Without accounting for any regeneration, a 5 second capture would be increased by 2 second or 10 turns. In comparison the existing buff you provided of +25pts/sec would provide on the same scenario ~125 pts. So a 5% buff. On the same scenario this would provide 0.25sec so about 1 turn. So this +1000 pts addition is 10x more effective on fast capture scenarios then regeneration, and the break even point happens after 40sec. A minimum of +2 sec in worse case still gives a bit more room for the defender to react. I see a lot of ideas. But most of them increase the difficulty of capturing across all scenarios. Ideally, we would mostly impact the "worse" scenarios where capture happens just too fast. A suggestion that I'll be willing to implement is to have diminishing effectiveness of capturing over a certain rate. For example, if you are capturing a CC with a total of 500 pts per sec (~125 Romans with Marian reform), the CC lose the first 200 pts normally, but the last 300 pts strength are nerfed by exponential decay. Seems like a solution that could makes minimal changes, introduce little new technicalities and impact precisely the "worse" cases. Basically you could define in the template that capturing faster then Xsecs get exponentially harder.
-
We would need to evaluate only the best case (all techs, best units, etc) to work back from a minimum capture time. Other reference cases can be used for better calibration, like, if all are archers, how much time should it take, and so on, but just a very few cases should suffice to have some control on capture time, I just don't know the formulas. And can't the number of units capturing a building be just fixed? Same as the number of units working a field.
-
Yordan changed their profile photo
-
One could consider a system where capture points and garrison capacity scale with population. That said, it would likely introduce additional complexity. Even if feasible, it might be preferable to tune fixed values around reasonably standardized scenarios. That could work, although there are additional variables to consider. Capture time will always depend on the size and composition of the army. Are we talking about basic or elite units? Melee or ranged? Are heroes involved? Yes, that seems like a relatively simple solution to implement. As for collisions, they already exist. As shown in the video, when no formation is active, many units are unable to capture and instead try to find alternative paths. I think a certain degree of overlapping is actually beneficial for battles (though not for capturing), otherwise unit behavior can become somewhat clunky. It’s probably a matter of fine-tuning the parameters under specific circumstances.
-
"Another potential solution" is the opening of my text, and it’s perfectly clear to any English speaker that it’s meant as an additional idea. It doesn’t replace anything, it literally says “another.” It could have been “instead,” but it isn’t. You seem to enjoy these little internet arguments, don’t you? lol The Roman Army Camp can hold 20 units. Strangely enough, when you destroy it, an additional capacity of 30 units appears.
-
Exactly. "Isn’t 20 soldiers too few for a fortress?" is not the correct approach, but "which percentage of your max population is 20 soldiers"? Then it's not a small garrison. Just increasing it doesn’t seem right. What is worse, if one increases the pop cap, leaving the garrison caps fixed, all considerations of what is big or small are out the window… unless collisions are used. This always fixes the max amount of units trying to take a building. It also helps in fixing capture points, after a decision is taken on how little time capture should take (it cannot be that it’s not known if 5 seconds will become maybe 5.5 or 6 seconds, things should be calculated the other way around, first deciding an acceptable minimum capture time, and working backwards). And it applies for buildings that don’t have any of the mentioned Fortress or Tower defensive techs. If there’s a formation exploit, then I guess better if that’s solved, instead of collisions removed. If I understand correctly what’s happening from the videos, couldn't formations be temporarily disabled when units are taking on any of those tasks? Whatever needed since collisions does seem a step in the right direction. Collisions seem necessary, but maybe not sufficient, thus: I agree with 1. because of the regeneration problem pointed out, but disagree on how to exactly implement 2. because it doesn't seem very common that a given tech does more than one thing. On the other hand, someone said recently "the two techs for towers for greater range and more default arrows" "are also too expensive to be viable during the period of the game when towers matter", so I'd remove the Arrow Shooters tech and give that range increase to the Stone Tower for free, because, if I understand correctly, with no techs both it and the Sentry Tower have the same range (10 to 60 m, even when it’s taller). If Sentry and Professional Garrisons are not interesting enough, I’d make them do more of what they already do. Regarding increasing capture points +50% to Towers and +100% to Fortresses, I’d either give this for free, or have a mutual tech that gives +50% to both towers and forts, and from the start give forts for free whatever is needed to complete the +100% wanted.
- Yesterday
-
You should usually have to raze a fortress to the ground, rather than capture it. While that may not be historically accurate, it makes sense given the style of RTS, rather than something like Total War.
-
If I recall correctly, Roman Army Camp used to be able to hold 40 soldiers. Granted, when the collision issue (or just the formations exploit) is fixed, a full Fortress will be almost impossible to capture at full health, which might be a good thing lol.
-
From this initial post you made, it doesn’t come across as an additional idea but rather as a solution to the problem of buildings being too easy to capture. That is: instead of increasing capture resistance, allowing more units to garrison inside. That’s why I responded the way I did. What I mean is that, from a gameplay perspective, it seems much more interesting to improve the capture points of buildings and be able to keep more units outside, actively engaged in combat. If you garrison 40 or 50 units out of an army of 150, the enemy will most likely be able to wipe out the remaining forces due to overwhelming numerical superiority. I’m not opposed to increasing the garrison capacity of forts/CCs or other important buildings per se. But when it’s proposed as a solution to the issue of rapid capture, I think it’s better to directly strengthen capture resistance instead. As for the historical aspects, I understand them, but this is a game and, as such, it relies on certain abstractions.
-
Latest Topics
