Incorrect default walk speed?

[alre]

the unrealistic scale of units and speed is nowere coded in the game engine. You can make a mod like that defining a whole new set of unit templates and models, that have realistic values and whatsoever. 0AD will keep having its absurd scale, because it works perfectly fine for us.

[Stan`]

There seem to be one use of the scale modifier though, as it can be set on a map level using triggers. eg. you could make units slightly slower on a snowy map

EDIT: Actually you can already do that by affecting UnitMotion/Walkspeed with techs...

[ChronA]

On 20/11/2021 at 4:34 PM, artoo said:

The reason I think it would be better to have the engine run on real life values is, you can accurately balance this. Could be a separate little project, I think it is a lot easier to balance everything against true scale first, like you calibrate a balance, once this is done, it should and hopefully scales.

Easier to use real values than doing wild guesses in a scaled model.

I actually agree with this sentiment. There are a lot of things in 0 AD that could be improved, or at least made more unique, with greater realism.

However I don't see why anyone would take special umbrage with miss-scaled walk speeds specifically. Distance and time relationships must be inconsistent with reality in a game like this in order for it to be playable.  In the real world humans are basically tiny little fleas compared to some of the structures they build and they are positively microscopic compared to the distances they travel in the course of their daily affairs. So to even have actors visible on screen you need to massively inflate them relative to the features of their environments. Likewise with projectiles, you need to massively foreshorten typical engagement distances and inflate and slow the projectile models just to be able to see who is shooting who with what. But the distance dilations for combat are still not even within an order of magnitude of the dilations to the environment.

Thus inconsistent space/time scaling is basically unavoidable if you want to have a functioning RTS. Therefore it seems to me that what you are really asking for is that each of those relationships gets its own unique standard of measurement so it will conform to reality. But is this really helpful? Why do I actually want to know the walk speed of my units? Well for me there is only one overriding reason: I want to know how long it will take them to do things in the game. E.g. how many seconds will it take a spearman to close the attack range of a slinger (and thus how much damage is he expected to take during that transit). This is easy to calculate right now. Under your proposed system not so much, because the spearman's speed may be listed as 1.5 m/s and the slinger's range may be 300 m, but 300 projectile m / 1.5 walk speed m/s != 200 s...

But lets even suppose coding and mod compatibility were non factors, and the dev team decided to rebase all distances consistently in the engine so that the human actors would be in their proper scale (i.e. 1.5 to 1.8 meters tall instead of 4.5).  (And for the record, if coding and mod compatibility were non factors, I agree that this would be a good move because it would stop all the people making stupid mistakes like setting the projectile gravity wrong!) 

But if we did this, even then would we ever want to give our units their real-world walk speed of 1.5 m/s? I don't think so. Waiting for people to leisurely saunter to a destination is boring. And if you are the omnipotent god who ordered them to go there, anything less than a resolute power walk or sustainable jog implies that they don't respect your authority! There's a reason Doom Guy's default walk speed is 2.5X faster than Usain Bolt's fastest sprint...

So uh... it seems from your posts like you have some ambition or interest with respect to the Pyrogenesis engine and 0 AD's asset library. What I am trying to say with my word vomit is that wonky distance and velocity scaling seems like an odd thing to be a deal breaker. Maybe you should give some more thought to what you want to do, and maybe even give us a hint so we can provide more helpful insights.

[artoo]

35 minutes ago, ChronA said:

Maybe you should give some more thought to what you want to do, and maybe even give us a hint so we can provide more helpful insights.

My thought is, that is amazing to witness some comments here, documenting they don't get the simple mathematical concept of factorization.

I am saying, the engine can and is being configured with default values. So far so good.

But actually using a scaled speed as default value is in my view uhm suboptimal.

Hence any project using the engine will have to use the hardcoded 3.6 scale, hard coded in atlas for defaults, the rest comes from templates. So if my project used a different scaling, my team would run into problems, apart that I would want my team work against real defaults.

Its easier to eg research the avg walk speed of a horse and put the value in the template, instead of working with scaled speed.

Ideally, you scale everything at a certain ratio, atm, afaik, the engine uses different scaling multipliers for different things, some is scaled, some is not or differently scaled.

It is an approach the devs took, which is fine, but the engine is not really customization in terms of default settings with this appraoch. This would be a non issue, if real values were used, and the scaling multiplier gives you the speed you need in scale.

 

I was just thinking, there is also competition in open source RTS engines, and this may sound like trivial issue, but a tendency would be atm to recommend say spring engine.

 

Example.

0AD sets walk speed at 7 m/s, I doubt all balancers are aware this is actually a scaled speed at a factor 3.6, ie m/s to km/h.

 

So a default avg walk speed is 1.9 m/s x 3.6 = ~7 m/s

Difference is, walk speed is based on a real life reference point, no guessing required.

Balancing team would simply not have to care for scaling, they look up real measured values and put it in the template. Can then be fine tuned as desired.

[alre]

in 0AD there is no single unit that walks at 7 m/s. overwriting that default value is very simple and I would recommend - for easier balancing - fully specifying all units statistics in your template tree, without relying on any default whatsoever. That's what we do anyway. I wouldn't even know if that 7 value is actually the default, @Stan` said here that is only used for generating the example template.

You are missing a lot, and you think it's our fault. It's not, take some time to understand the game better, and its balance, or feel free to make your own mod and see how that plays.

[artoo]

8 minutes ago, alre said:

You are missing a lot, and you think it's our fault. It's not, take some time to understand the game better, and its balance, or feel free to make your own mod and see how that plays.

Look at the ActorViewer.cpp, you will find a hardcoded default walk and run speed of 7 and 12 respectively. Set it to unscaled default and have a scale multiplier. Nothing changes, just the default for walkspeed in the templates, ie 1.9 to 2.5 m/s for 0AD.

 

Look, I am long enough in the open source development, this is neither trashing nor somehow picking on the great work of an engine. This is about improvement, about customization of the engine, but it seems you are set to oppose this. Such little improvement could decide a teams choice for an RTS engine, just saying.

Edited November 22, 2021 by artoo

[artoo]

4 hours ago, Stan` said:

There seem to be one use of the scale modifier though, as it can be set on a map level using triggers. eg. you could make units slightly slower on a snowy map

A scale multiplier becomes ever more important if you implement more physics, like eg mass.

[Stan`]

7 minutes ago, artoo said:

Look at the ActorViewer.cpp, you will find a hardcoded default walk and run speed of 7 and 12 respectively. Set it to unscaled default and have a scale multiplier. Nothing changes, just the default for walkspeed in the templates, ie 1.9 to 2.5 m/s for 0AD.

This of course if the unit doesn't have a walkspeed. Else it reads the template...

speed  = cmpUnitMotion->GetWalkSpeed().ToFloat();

 

8 minutes ago, artoo said:

Look, I am long enough in the open source development, this is neither trashing nor somehow picking on the great work of an engine. This is about improvement, about customization of the engine, but it seems you are set to oppose this. Such little improvement could decide a teams choice for an RTS engine, just saying.

As you saw the patch isn't complicated. It would only be used for modders though.

3 minutes ago, artoo said:

A scale multiplier becomes ever more important if you implement more physics, like eg mass.

Not sure it would work well on a 2D pathfinder, also performance might be pretty bad no?

 

[artoo]

12 minutes ago, Stan` said:

Not sure it would work well on a 2D pathfinder, also performance might be pretty bad no?

I am just saying, if you develop the engine further, and you add mass to the equation for example, you probably want to have the scaling multiplier stored somewhere, and not calculate it over and over again from the speed or so, apart from bad coding practice it would be. You very likely gonna need it the more complex the engine gets.

 

Would already be interesting to test some formation stuff with accurate speeds, unscaled, just for some fun testing to have a real values based reference point to compare against. Same for pathfinding etc.

 

Point being, if my super secret realism aimed project used a different scaling, the artists would probably pull their hair out why the walk and run animations seem 0AD public mod scaled in Atlas.

 

Edited November 22, 2021 by artoo

[Stan`]

3 minutes ago, artoo said:

Point being, if my super secret realism aimed project used a different scaling, the artists would probably pull their hair out why the walk and run animations seem 0AD public mod scaled in Atlas.

Well it wouldn't because it uses the template values? Or am I misunderstanding something? The 7 and the 12 are only when you don't have template and you tick the move options, which you do not usually. Most people test things using the play button in atlas anyway.

4 minutes ago, artoo said:

Would already be interesting to test some formation stuff with accurate speeds, unscaled, just for some fun testing to have a real values based reference point to compare against. Same for pathfinding etc.

Well you can do that with my patch ^^

5 minutes ago, artoo said:

I am just saying, if you develop the engine further, and you add mass to the equation for example, you probably want to have the scaling multiplier stored somewhere, and not calculate it over and over again from the speed or so, apart from bad coding practice it would be. You very likely gonna need it the more complex the engine gets.

Well what the engine needs right now is more threading and maybe stop supporting ARB shaders which might be older than some of 0AD players :X

 

[artoo]

10 minutes ago, Stan` said:

Well it wouldn't because it uses the template values? Or am I misunderstanding something? The 7 and the 12 are only when you don't have template and you tick the move options, which you do not usually. Most people test things using the play button in atlas anyway.

I haven't had enough time to go in greater detail with atlas code, but if no template value is found, it uses the hardcoded defaults. Would be odd in a differently scaled project? You are the master artist to say. I could find out when precisely the default is used, but I think its more of an issue for artists if the default is used by Atlas, their walk and run animations would not fit set scaling?

 

Another use case of a scale multiplier, Atlas, could come from template too.

 

27 minutes ago, Stan` said:

As you saw the patch isn't complicated. It would only be used for modders though.

Right, its a little patch with great effect that should be upstream, addressing little hurdles that may or may not prevent adoption of the engine for other projects. In return, if the engine gets more adopted, you probably get more patches enhancing the engine.

 

Edited November 22, 2021 by artoo

[Stan`]

21 minutes ago, artoo said:

Right, its a little patch with great effect that should be upstream, addressing little hurdles that may or may not prevent adoption of the engine for other projects. In return, if the engine gets more adopted, you probably get more patches enhancing the engine.

Maybe, although my mileage has been in the other direction so far

22 minutes ago, artoo said:

I haven't had enough time to go in greater detail with atlas code, but if no template value is found, it uses the hardcoded defaults. Would be odd in a differently scaled project? You are the master artist to say. I could find out when precisely the default is used, but I think its more of an issue for artists if the default is used by Atlas, their walk and run animations would not fit set scaling?

Well testing template interactions, in this case walking, without actual templates is kinda dumb anyway ^^,  The only reason I use the actor viewer is to check whether the anims are in sync with the template anyway. If not I adjust the animations until it fits. But I always have a backing template. The only case where I don't care is for idle anims.

I don't really use the feature that makes the unit run anyway ^^ with or without template.

30 minutes ago, artoo said:

Another use case of a scale multiplier, Atlas, could come from template too.

Same code in Atlas than in the game Components are shared between the two. The only problem with atlas is it uses a different GUI.

31 minutes ago, artoo said:

Right, its a little patch with great effect that should be upstream, addressing little hurdles that may or may not prevent adoption of the engine for other projects. In return, if the engine gets more adopted, you probably get more patches enhancing the engine.

Well first one needs to evaluate the impact, and make sure it doesn't break something else unintentionally ^^"

[Stan`]

Just checked for fun with a dude box.

 

Set a speed of five it already slow, 1.9 might be terrible. Pathfinder is having some trouble also, maybe grid is too big.

 

 

dude_box.pyromod

[artoo]

23 minutes ago, Stan` said:

Set a speed of five it already slow, 1.9 might be terrible. Pathfinder is having some trouble also, maybe grid is too big.

With patched cmpUnitMotion?

[Stan`]

No need to patch anything you can either set the walkspeed directly in the template

<?xml version="1.0" encoding="utf-8"?>
<Entity parent="template_unit">
  <UnitMotion>
    <WalkSpeed>1.9</WalkSpeed>
  </UnitMotion>
  <VisualActor>
    <Actor>dude_box.xml</Actor>
  </VisualActor>
</Entity>

or do

<?xml version="1.0" encoding="utf-8"?>
<Entity parent="template_unit">
  <UnitMotion>
    <WalkSpeed op="mul">0.21111</WalkSpeed>
  </UnitMotion>
  <VisualActor>
    <Actor>dude_box.xml</Actor>
  </VisualActor>
</Entity>

It's exactly the same as adding an extra multiplier. 0.21 * 9 is about 1.9

 

[BreakfastBurrito_007]

At least there is no miles/hour, just thinking of all the frustration that system has caused for people who deal with units.

[artoo]

3 minutes ago, Stan` said:

It's exactly the same as adding an extra multiplier. 0.21 * 9 is about 1.9

I'd make the scale multiplier configurable in some template, and to be on absolute safe side, no hardcoded defaults for atlas.

 

Doc might read on scale multiplier: "Do not touch unless you know what you are doing." 

[Stan`]

1 minute ago, artoo said:

I'd make the scale multiplier configurable in some template, and to be on absolute safe side, no hardcoded defaults for atlas.

 

Doc might read on scale multiplier: "Do not touch unless you know what you are doing." 

It's configurable in all templates, you can put it in template_unit, or in any bottom template as shown in the diff I posted earlier. 

You don't even need to have a dedicated parameter as long as every moving thing inherits from the same base template. That's what inheritance is for. In the example above instead of having a tag called ScaleMultiplier, it's just the attribute of walkspeed. and I can make every template inherit from that one.

 

[artoo]

2 minutes ago, Stan` said:

You don't even need to have a dedicated parameter as long as every moving thing inherits from the same base template. That's what inheritance is for. In the example above instead of having a tag called ScaleMultiplier, it's just the attribute of walkspeed. and I can make every template inherit from that one.

 Yes, I know, just thinking it may come in useful in terms of coding, but this works fine too, sure.

[Freagarach]

12 hours ago, Stan` said:

Set a speed of five it already slow, 1.9 might be terrible.

That is merely because you're used to our current speeds.

Look at my army of boxes (with Hercule in the lead).

[Freagarach]

20 hours ago, artoo said:

if you develop the engine further, and you add mass to the equation for example

Please do! I only have it in JS for the moment. ^^

(I'm a big fan of realistic 'known' values (like strength of a person), balanced by changing 'unknown' ones (like morale).)

[artoo]

22 minutes ago, Freagarach said:

(I'm a big fan of realistic 'known' values (like strength of a person), balanced by changing 'unknown' ones (like morale).)

Like morale is a given percentage of strength? Or like wounded decreases efficiency?

 

Atm, I am evaluating the engine, what's doable ...

[Stan`]

11 hours ago, artoo said:

Atm, I am evaluating the engine, what's doable ...

A lot is doable actually. @Freagarach has a mod with a lot of new features and Hyrule Conquest completely changed the way the game is played as well. I'm really looking forward to seeing their A25 version.

[wowgetoffyourcellphone]

12 hours ago, Freagarach said:

(I'm a big fan of realistic 'known' values (like strength of a person), balanced by changing 'unknown' ones (like morale).

As long as it's on a per battalion basis, then yeah. Managing the morale of 300 individual soldiers sounds like a nightmare. 

 

[chrstgtr]

On 20/11/2021 at 4:34 PM, artoo said:

The reason I think it would be better to have the engine run on real life values is, you can accurately balance this. Could be a separate little project, I think it is a lot easier to balance everything against true scale first, like you calibrate a balance, once this is done, it should and hopefully scales.

Easier to use real values than doing wild guesses in a scaled model.

Do you also propose that we wait several days for units to walk across a map to meet the enemy? Or better, that we wait 18+ years to raise a solider? 

Games are extrapolations. The unit measurements might as well not be denoted in real life units. Sometimes you just have to roll with what is obviously not real life.