Spring RTS Engine

Lately there has been a fair bit of argument over how to balance different unit types in terms of what areas of land they can access - ie how steep a slope they can climb.

Its a difficult thing to balance using only hard limits of where a unit can and cannot go when there are so many maps with different averages on what a hills slope should be.
So i suggest a new tag slopeGrip <float 0-1>, which will affect how quickly a unit can climb slopes.

It will effectively act as a mulitplier on the speed calculated in CGroundMoveMath::SpeedMod.

I was thinking of changing:
float mod = 1 / (1 + slope * moveData.slopeMod);
to
float mod = 1 / (1 + slope * moveData.slopeMod/slopeGrip);

So all terrain units could have it set as 1,
kbots could have it at 0.8, tanks at 0.5 etc.

Or would it be better to have a logorithmic scaling as it nears the maxSlope? (making grip less of an issue on very shallow hills)

So all units could scale any face it would just take them ages? Thats the old method, the new is better we just need a logical standard.

Not neccesarily ages, just some a bit longer than other units.
The values i gave were just an example.

Wouldn't it be easier just to specify 'mod' plain and simple...

But the first part is true? Bad idea, it was weighed, it was measured, and it was found wanting.

Its allowing modders to better control how well units handle slopes, whether they decide that a unit 'takes ages' to get up a slope is up to them. To be honest i don't see any standard ever happening - there are far too many maps and mods to go and make them adhere to any standard. From my point of view its better to just have maps for specific mods. Had we planned ahead we could've had a standard but its too late now.

I thought that's what the badslope value is good for?

There isn't any tag called badSlope in the unitDefHandler (you sure that's what it's called?),
However the variable slopeMod is based on the maxSlope value and does increase a units climbing speed for a higher maxSlope. But it would be better if a units climbing speed was independent of the maxSlope for more flexibility.

Surly (or it looks to me) he's saying leave it as it is, but add in teh ability to have units not nesceserily go slow just cause there on a hill?? For instance, cars slow down on steep hills as they have to chage to a lower gear to get more taque, but legged things (IE Kbots) surly would not realy slow down partuly just because there on a slop, just like most people dont realy slow down jsut cause there going up stairs.

Of course it would still render some surfaces entirly unclimable right? Just chage the speed modifer to a seperate value? Thats what your suggesting?

aGorm

I am suggesting that with this addition it will be possible to have some units (say vehicles for arguments sake) be able to cross hills not too ineffeciently but still at a slower speed than other units (like kbots). Allowing the kbots to have a maneuverability advantage - both sets of units would still be able to cross the terrain at a reasonable pace. But the kbots would have the speed advantage while fighting on hills. Vehicles on the other hand would have the speed advantage on the flat parts. Currently if vehicles have a higher speed than kbots, but the kbots have a higher slope tolerance, and both are on a (steep) slope within their tolerances then the vehicle will still have its speed advantage.

moved to feature requests.

aGorm wrote:For instance, cars slow down on steep hills as they have to chage to a lower gear to get more taque, but legged things (IE Kbots) surly would not realy slow down partuly just because there on a slop, just like most people dont realy slow down jsut cause there going up stairs.
aGorm

Cars have to slow down because they are already running at max capacity, I see no reason other vehicles would be different. People don't sprint everywhere, we walk, and that leaves alot of extra power available to maintain that speed.

Yep, IRL kbots wouldn't behave much different than cars in terms of slope climbing, though they'd be able to navigate much rougher terrain (means debries and crap like that). Maybe kbot and veh speed could be equalized since kbots already offer less bang for the buck in direct combat.

No, thge reason humans slow down on hills is they get tired.... you can actully move up a hill just as fast, just it wears you out. Kbots on teh other hand would not get tired.

aGorm

Humans get tired because we need more power to move uphill and our energy reserves don't refill quickly enough. A kbot would slow down as well since it needs more power to move uphill at the same speed which it doesn't have unless its bipedal construction prevents its motor system from utilizing its full power (speed) on flat ground.

Thats true, however vehicles are more likely to waste energy by losing their grip and falling back a little. Kbots having a better grip in the first place don't waste all the energy they put into climbing the slope.

I doubt that, vehicles have about 10x more surface area in contact with the ground.

At least the tracked vehicles do.

Sorry if this is completely off, I haven't read the thread, I'm just making a guess based on what I think this is probably about.

I think you're complaining about how vehicles can sometimes climb slopes faster than kbots in AA? If not, ignore.

This is because vehicles move a lot faster than kbots. So you have a vehicle and a kbot both ascending a slope of 24. That's the most a vehicle can climb, but significantly less than a kbot can climb. So the kbot moves at roughly 75% of its max speed, while the tank moves at 50% of its max speed.

Let's just guess that the tank is a flash, for instance. It's moving at 2.6 normally (random number). The kbot moves at 1.7 normally (random again). The kbot therefore moves at a speed of 1.275 going up the slope, while the vehicle moves at a speed of 1.3. Increase the slope to 25, and that vehicle is going at speed of 0, while the kbot is going at 1.25, since the vehicle can't climb that at all.

Just random figures and guesses. I don't know if the kbot would be moving at 75% or the vehicle at 50%, I'm just throwing out a situation wherein you'd see the "problem" I think you might be talking about.

Yes, that's what it's about and I think he wants units to be MUCH slower at 100% slope climbing than 66% slope climbing. Probably needs to play on slopier maps