Half point for movement cost

[Noyga]

IMO there is not need to use float numbers.

For example, if you want an unit with 8 moves, with movement_cost=1.5 on mountains, just make a unit with 16 moves with movement_cost*2 on all terrains and movement_cost=3 on mountains.

[zookeeper]

IMO there is not need to use float numbers.

For example, if you want an unit with 8 moves, with movement_cost=1.5 on mountains, just make a unit with 16 moves with movement_cost*2 on all terrains and movement_cost=3 on mountains.

Extremely ackward.

[Darth Fool]

IMO there is not need to use float numbers.

For example, if you want an unit with 8 moves, with movement_cost=1.5 on mountains, just make a unit with 16 moves with movement_cost*2 on all terrains and movement_cost=3 on mountains.

Extremely ackward.

Extremely Awkward? Awkward, maybe, but certainly not extremely so. In fact, I think that the alternative is at least as awkward. The only issue that would make the above solution seamless would be the inclusion of a switch that tells the movement animation that the slowdown in animation because of the movement cost should be weighted by a factor of 2 or whatever. If that was done, then I think that this would be the ideal solution. Somebody who wants to distinguish between a movement rate of 1.4 and 1.5 really ought to be able to live with multiplying the movement rates by 10.

Consider the alternative. Implementing floating points not only requires it to be maintained, it will require explanation of what goes on with those pesky numbers after the decimal. Heck, it even takes up more screen real estate: "1.3" requires more space than "13", not to mention the translation issues.

[Rhuvaen]

I think a movement of X implies that the unit can move X hexes in best terrain. Just multiplying costs and movement by ten fools the player into thinking 'this is a really fast unit'. That much should be obvious.

I don't think this is about 0.1 destinctions in move costs, but having halves (0.5) steps would make the movement system that much more flexible.

[zookeeper]

Consider the alternative. Implementing floating points not only requires it to be maintained, it will require explanation of what goes on with those pesky numbers after the decimal. Heck, it even takes up more screen real estate: "1.3" requires more space than "13", not to mention the translation issues.

The floating point notation doesn't have to be used when no floats are used so no mainline unit would ever show any decimals in their MP's, so I wouldn't worry much about space and such.

[Viliam]

Let's weigh the costs and benefits of introducing fractional movement points:

Benefits:
It is possible to make a custom campaign where some units can have 1.5 MP in some terrain, without having to double all numbers.

Costs:
Almost every part of code related to movement points must be modified. Also all future code related to movement points must be aware of this.



Is it really worth to make the whole program more complicated on different places, only to allow units in one custom campaign have 1.5 MP movement? (Unless someone would want to use this is mainline campaigns too, but so far it did not seem necessary.) Changing the MP system from integers to fractions does not seem like a big change, but it is a relatively big change. Not big in sense "write a long code", but rather in "write a lot of little code in many places; do not forget any".

To compare, it would probably be much easier to add code: "for selected units, show animation twice faster, and always display MPs and MP costs divided by two". -- It would require writing one function "return movement points of this unit as string", using it in 2 or 3 places (status table, help, advancement menu), and speeding up animation (which could be useful for other purposes too, e.g. for units having too many MPs).

[Eleazar]

I guess it needs to be decided first if there's actually a problem with the current terrain speeds. Frankly it does bother me that no terrain has an slowing effect less drastic that cutting the speed in half. But i don't find a X.5 move rate very elegant either.

If if was decided that more flexability of movement rates was needed, IMHO the most straightforward fix would be to change the numbers for ALL units. The standard minimum movement rate becomes 2mp per hex and all units get double their current move points. The resulting values should be small enough to easily remember, and there are no fractions to worry about.

[irrevenant]

If if was decided that more flexability of movement rates was needed, IMHO the most straightforward fix would be to change the numbers for ALL units. The standard minimum movement rate becomes 2mp per hex and all units get double their current move points. The resulting values should be small enough to easily remember, and there are no fractions to worry about.

Agreed, except I suggest keeping the minimum rate 1 mp and reserving it for roads only (ie. plains are 2mp) since (a) a base of 1 is more intuitive and (b) it makes roads have an actual in-game impact rather than being merely decorative.

Edit:
Make that roads and castle.

[deserter]

If if was decided that more flexability of movement rates was needed, IMHO the most straightforward fix would be to change the numbers for ALL units. The standard minimum movement rate becomes 2mp per hex and all units get double their current move points. The resulting values should be small enough to easily remember, and there are no fractions to worry about.

Agreed, except I suggest keeping the minimum rate 1 mp and reserving it for roads only (ie. plains are 2mp) since (a) a base of 1 is more intuitive and (b) it makes roads have an actual in-game impact rather than being merely decorative.

Edit:
Make that roads and castle.

I'm not so sure about this.
Think about a horseman with 8 MP. Now that would become 16 MP and the crazy horse would be able to run across 16 hexes! Is there really such a big difference on grassland and road? I don't think so.
There just doesn't seem to be any solution to make the roads only a little bit faster than grassland. Except for the fractionals, but, well, I don't much favor that solution.
Roads are fine as they are.

[Darth Fool]

Agreed, except I suggest keeping the minimum rate 1 mp and reserving it for roads only (ie. plains are 2mp) since (a) a base of 1 is more intuitive and (b) it makes roads have an actual in-game impact rather than being merely decorative.

Edit:
Make that roads and castle.

I'm not so sure about this.
Think about a horseman with 8 MP. Now that would become 16 MP and the crazy horse would be able to run across 16 hexes! Is there really such a big difference on grassland and road? I don't think so.
There just doesn't seem to be any solution to make the roads only a little bit faster than grassland. Except for the fractionals, but, well, I don't much favor that solution.
Roads are fine as they are.

Fine, make horses have identical move on roads and grassland, 2mp. Roads would only improve the movement of unmounted units.

[Eleazar]

Fine, make horses have identical move on roads and grassland, 2mp. Roads would only improve the movement of unmounted units.

Then a foot unit with 5 MP on open ground, could suddenly outrun horse if given a road.

• The disadvantage to making castles as fast as roads, is that it makes castle invasion that much easier.

• it certainly would be nice if elves could tranvers a cave hex using .5 fewer current MPs.

• faster roads could add some additional strategy to maps, but any map with roads would have to be reassessed, so some levels don't suddenly become super-easy.