Speed scaling

[Dacyn]

I use accelerated mode exclusively when playing because I hate waiting around for units to move.

why shouldn't we just increase the speed of movement, then?

[autolycus]

I don't know why you dislike the idea so much; you should try it first. I use accelerated mode exclusively when playing because I hate waiting around for units to move. I hold down shift so I can enjoy the animations for combat and healing. I consider myself a target audience for this change.

I think my reasons for disliking the idea are quite explicit. I'm open to the change, but I have also got detailed reservations prior to testing it. (A door need not be fully open to allow movement.) If I'm wrong, I will gladly take my lumps. But as Dacyn says, why not just make everything faster for people like you?

I don't mean that in a disrespectful way - do you remember games like Archon and Adept? The pieces moved with very amusing animations which varied in speed depending on whether they were golems (veeeeery sloooooow) or phoenixes (hang on, what was that flash?) and you could scale up the overall speed average. You could accomplish this with a speed slider so that each player could tailor his environment to himself, instead of just accelerated speed and normal. After all, each of us has a different machine, so we can't really calibrate from each other's experience.

If one of the aims is indeed to act as a cue for terrain speed, then the existing animations, no matter how you vary the speed, aren't as accurate. If I want to see how fast in strategic terms a unit moves, I would still rely on calculation and the move-radius highlighting.

I appreciate the developers' flexibility in implementing the change though. I will try it out when I can. Thanks, Dave, for explicitly stating the difficulty level(not much, I understand?) of coding the change.

[Dave]

I appreciate the developers' flexibility in implementing the change though. I will try it out when I can. Thanks, Dave, for explicitly stating the difficulty level(not much, I understand?) of coding the change.

Just to make it clear exactly how easy it was, there was the following line:

Code: Select all

	const int nsteps = disp.turbo() ? 3 : 10;

and it was changed to this:

Code: Select all

	const int nsteps = disp.turbo() ? 3 : 10*u.movement_cost(map,terrain);

And that was it...

Of course, there will likely be refinements that people come up with that may require more complex coding...

David

[autolycus]

Correct me if I'm wrong, but does this mean that if a value is set by a user preference slider, you could use that value to speed up or slow down the base speed for this just by multiplying, and it wouldn't be difficult to code? Need not be a slider, could just be a radio-button selection (like slow, normal, fast, very fast).

[Dave]

Correct me if I'm wrong, but does this mean that if a value is set by a user preference slider, you could use that value to speed up or slow down the base speed for this just by multiplying, and it wouldn't be difficult to code? Need not be a slider, could just be a radio-button selection (like slow, normal, fast, very fast).

Sure, but where will it end? People will want speed controls for movement, attacks, healing, etc etc.

Anything that requires GUI controls is immensely more complicated than anything that doesn't.

In fact, this is a long-running feature request that no coder has ever wanted to do....

David

[autolycus]

Sure, but where will it end? People will want speed controls for movement, attacks, healing, etc etc.

Rationally, it ends where you and your team want it to end. However, one thing which tends to drive what people want is the existence of interface elements or preference controls which are seen in other games; most people don't suggest lots of things never seen before.
So, for example, separate sliders for FX and music volume (instead of just one volume control) have become 'standard' in most games, including BfW. Most games also have a general speed control, which can be a keypress input during the game (e.g. < to slow down and > to speed up), or a preference panel thing. Games generally don't implement separate speed controls for many different classes of animation, so you're quite safe!

[Dave]

Sure, but where will it end? People will want speed controls for movement, attacks, healing, etc etc.

Rationally, it ends where you and your team want it to end. However, one thing which tends to drive what people want is the existence of interface elements or preference controls which are seen in other games; most people don't suggest lots of things never seen before.

Well, personally where I want it to end is pretty much where it's at now

I hate preference options with a passion, and dislike implementing any that are unnecessary.

Also people suggest things from other games, and if we accepted all suggestions, we'd end up with the union of all features of all other games -- which would be insane.

So, for example, separate sliders for FX and music volume (instead of just one volume control) have become 'standard' in most games, including BfW. Most games also have a general speed control, which can be a keypress input during the game (e.g. < to slow down and > to speed up), or a preference panel thing. Games generally don't implement separate speed controls for many different classes of animation, so you're quite safe!

We've already had several people suggest seperate sliders for each different class of animation....

David

[autolycus]

Well, personally where I want it to end is pretty much where it's at now

I hate preference options with a passion, and dislike implementing any that are unnecessary.

Also people suggest things from other games, and if we accepted all suggestions, we'd end up with the union of all features of all other games -- which would be insane.

I understand. But what I was suggesting was that features which players tend to find necessary are actually the intersection of all features, or something statistically similar. This is true of most software types.

Of course, I think we'd all be pretty upset if Wesnoth started gravitating towards the mean. Nevertheless, some features - like tunable control over the general speed of the game - are quite common and useful because of the many different computer setups we all have.

Currently, you've got zoom (in/out/reset) which helps those who need a clearer (to them) perspective. Having a speed (slow/normal/fast/veryfast) might help those who want to tune the game to their systems. As it is, the sound and display are tunable but not the speed...

[Dave]

like tunable control over the general speed of the game - are quite common and useful because of the many different computer setups we all have.

I don't think these are common in turn-based games. IIRC no version of Civilization has had such an option.

David

[dms]

Hi, I'm a new player. I recently downloaded 0.8.1

First, great game. I'm really enjoying it.

This might not count for much since I havent tried the prevoius movement style, but I think this feature is good. It just feels right. I think it makes sense to see fx a unit that moves slowly on water actually moving slowly on water.

I think it's more about 'feel' and less about providing information. When I want information I look at the movement radius or move the mouse around and look at what path the footprints take.

[scott]

I think it's good, but aren't the fast units also supposed to move faster? The total time for any unit to move its full distance = x seconds, so faster units move 1 grassland space in x/a seconds and slower units move x/b seconds, where a = fast unit's movement and b = slow unit's movement.
Anyway, I thought this was the original intention.

[Elvish_Pillager]

I think it's good, but aren't the fast units also supposed to move faster? The total time for any unit to move its full distance = x seconds, so faster units move 1 grassland space in x/a seconds and slower units move x/b seconds, where a = fast unit's movement and b = slow unit's movement.
Anyway, I thought this was the original intention.

Yes, it WAS my original suggestion. Then somebody suggested the terrain-feature, and I added it to my suggestion. The actual change is good, but not what I suggested; it just supports my suggestion.

[scott]

It's halfway there - it just needs a division step now

Just to make it clear exactly how easy it was, there was the following line:

Code: Select all

	const int nsteps = disp.turbo() ? 3 : 10;

and it was changed to this:

Code: Select all

	const int nsteps = disp.turbo() ? 3 : 10*u.movement_cost(map,terrain);

So wouldn't this pseudo code pseudo-work?

Code: Select all

	const int nsteps = disp.turbo() ? 3 : 10*u.movement_cost(map,terrain) / (UNIT MAX MOVEMENT);

[Dave]

So wouldn't this pseudo code pseudo-work?

Code: Select all

	const int nsteps = disp.turbo() ? 3 : 10*u.movement_cost(map,terrain) / (UNIT MAX MOVEMENT);

Yes, in fact the following code would do it:

Code: Select all

const int nsteps = disp.turbo() ? 3 : (50*u.movement_cost(map,terrain)) / u.total_movement();

Constant changed from 10 to 50 to make units with 5 movement move the same speed as they did before.

But....we're not sure if this is what we want. We could try it though I guess.

David

[scott]

So this will make gryphons travel 9 spaces of grassland in the same amount of time as an elvish fighter traveling 5 spaces in grassland...

I'll compile it and post a mac OS X binary for those that are interested.

http://www.cis.rit.edu/~slk8779/wesnoth/