-
Who's Online 6 Members, 0 Anonymous, 269 Guests (See full list)
-
Topics
-
Posts
-
My experience: 1100-1200 players: I can win against them. Most of them are slow and have a disastrous micro. Some are just fake rated, and most of them quit without resigning. But I know good players at this level. 1300 players: I'm probably able to beat them, with hard fights, they usually play TGs (like me), which make them way better in growing a city and a army. 1400, 1500: never played 1v1 against them, but it's a very variable rating. I saw some 1400 players which are worse than 1300 or 1250 players (the same for 1500 players), probably of a "rating farm" (winning only against 1100-1200). I'll end this part here. I'm not considering rushes because I think they turn any of these ratings into mere decoration. 1600 players: they are strong, and can easily destroy me lol 1700+: the same as 1600 Just a note: I'm between 1200 and 1300 (by the time, I'm 1300 at lobby), and this is just my experience. Rushes can kill me easily. I think this is the best way to understand these rating levels. Final: The problem are, as I said, the "rating farmers" - they host games that are only in their side, using maps that they can play without even watching (blind) - but, anyways, they don't play TGs and they don't pass the 1600 rating. That's is a truth, as 0 A.D. lobby is not a lichess.org lol
-
By real_tabasco_sauce · Posted
As an alternative, perhaps we could add a capture defense boost (technically a capture attack addition or a multiplier) for specific buildings, like the CC and fort. Also, we could change the default hero contribution to capture point regeneration (currently +1, which is negligible). -
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 adjust 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.
-
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.
-
