[Suggestion] Movement Calculation

When the movement cost 2 the logical step is that diagonal move cost 3 (instead of 2.8)

Or make it cost 2.8.  Display Movement Points as whole integers (i.e. trim fractions), but calculate real movement.  If everything takes at least 1 to move along, then any remainder at the end are useless.

The problem is that doing something like this makes diagonal tiles "safer" than horizontal/vertical tiles.  While it adds to technical realism slightly, I'm not sure the gameplay impact is worth it.  It's far easier to think of distance not as "the space between Point A and Point B" but as "how long it takes me to get from Point A to Point B".

Hexagon Debate: Activate

"The problem is that doing something like this makes diagonal tiles "safer" than horizontal/vertical tiles.  While it adds to technical realism slightly, I'm not sure the gameplay impact is worth it."

It should be safer, it is a longer distance.  Take these two scenarios (say movement cost is 2 per tile, and your army has a movement speed of 6.):

************************************************************************************************

Scenario 1:  You plan to march toward your enemy which is 18 tiles directly north of your city.  The total distance should be sqrt(648)=25.45, or approximately 26 movement points.  So it takes 5 turns to get to the city.

Scenario 2: You plan to march toward your enemy which is 18 tiles directly northwest of your city.  In this scenario, it only takes the army 3 turns to reach the city.

************************************************************************************************

That is a whopping 2 turn difference if distances were accurate.  As it is now, each scenario takes equal amount of time.

That extra 2 turns adds up in a game of large magnitude.  If you were the defender in Scenario 1, I would definitely want those 2 extra turns so that I could reinforce my city.  As for the attacker, I'd want the diagonal tiles to equal horizontal tiles.  

As for the Hexagon idea, wouldn't we all love that but it isn't going to happen.

Why don't they use hex ? Is it so hard to code with them ?

You can just expand the number of mouvement points : instead of getting 1 or 2 points just get 10 or 20 points.

If it needs 10 points to move one square orthogonaly, it costs you 14 points to go diagonnaly.

TatertotEatalot - I'm not saying that "realistically" the diagonal squares shouldn't be safer; I'm saying that from a gameplay standpoint: what does that add, other than complexity?  I tend to be all for making games realistic (I prefer sims to games, I guess), but at the end f the day, complexity for its own sake tends to do poorly.

It basically comes down to: squares, hexes, or real coordinates.  Hexes make it look "hard", real coordinates tend to make it "hard" (for AI, too, potentially).  Squares are the most approachable for casual gamers, and are 'close enough" to work properly.  That is, they make a difference in any given fight, but over the long-haul, the lack of complexity won't hinder strategies from being used.

If it were to cost 2 * sqrt(2) to travel diagonally, why should it cost 2 + 2 * sqrt(2) to travel two squares horizontally and one square vertically and not 2 * sqrt(5)?

Any decision that's made -- save real coordinates, which are incompatible with the game as currently conceived -- will be 'unrealistic' and to some extent arbitrary. 1-square-same-cost is the best option because of its simplicity: it avoids the problem of fractional -- radical, really -- movement points.

But gameplay-wise it add problems, like that city that is at "3 turns from you" when it should be 5 turns !

Isn't it a real strategic problem ?

If there is a graphical representation of the tiles you can travel to, then there won't be any calculation to do. And travel paths would be more realistics.

The same problem was in civ and ? We learned to play with it, but it doesn't make it a good design decision.

Seriously ... 3 turns instead of 5 turns in a strategic game IS a gameplay problem.

I can build a unit that moves three squares/turn in nine turns, and a unit that moves two squares/turn in five turns. The enemy city is nine squares away, six horizontal/vertical, three diagonal. It isn't immediately obvious which choice is the better option. That is a problem that isn't solved by any graphical system.

There's also this problem, which I flagged in the last post: it artificially inflates the value of units which have a number of movement points equal to some multiple of sqrt(2) or n + some multiple of sqrt(2). Other units -- especially those with a number of movement points close but not equal to some multiple of sqrt(2) -- are forced to waste movement points to move diagonally, making them substantially slower than they should be given  the absolute difference in movement points between them and units with some multiple of sqrt(2) or n + some multiple of sqrt(2) movement points.

Furthermore, given that the only significant basis for the gripe is 'realism' the system proposed isn't any more realistic given that it still doesn't accurately represent distance between squares separated by both horizontal/vertical and diagonal squares.

The speed at which your units travel the map is one of the most important problem in a strategic game. It's a matter of "how fast can I reach my ennemy". And it's really strange to be able to travel the whole map diagonaly and orthogonaly at the same speed.

And that's an often debated problem in TBS, like Strand says :

The lost points of movement is a real problem, and that's why an hexagon map is better. It would get rid of the "3 squares horizontal, 6 squares vertical" problem.

Oh sure. The hex/square debate is fine. I thought you were arguing in favor of the bizarre pythagoran-based system proposed by the OP. I don't think the problem is as bad as it's made out to be, but I don't think there're any real problems with a hex system. Cheers.

Agreed. I think at this point it's a "non-issue".

While i don't mind the unrealistic square based system, if you are looking for an example of a system that manages to do a non grid-like system work, then just look at the Total War series (the new ones). Click on your units and it is immediately very obvious wether you can reach your intended target this turn. Thus you don't need to mentally do you own calculations. And this allows for more realistic pythagoras theorem calculations.

In fact, even if WoM uses a simple square grid system, the movement range of the selected unit still ought to be highlighted clearly.

Civilization 4 also has the ability to see if you can reach a target and how long it would take before moving as well.  It would take no time at all for the user to calculate how far he would be able to move, that would be just plain dumb.  As for the 'bizarre pythagoran-based system' being hard to implement, give me a break.  

It does not have to be a system where it is in multiples of sqrt(2).  If you don't have the distance to travel somewhere, you don't get the travel there.  This is already implemented.  I believe right now if you have 5 movement speed, you can only travel 1 forest square.  BUT if you had 6, you can move twice through the forest.  So the wasted movement system is already in the game.  Just made a new game.  The way it is right now, even if you have 1 movement point left, you can travel where ever you want even if the movement cost exceeds 1 movement.

Only reason I don't suggest a hex system is because they probably already have it looked into a square tile based system.  But I do remember a post by Frogboy saying that he would not release this game if it wasn't the best fantasy TBS game out there if I remember correctly.  Maybe a hex system would be worth the while even it if drives back the release date a bit.  

Also, don't think this should be a high priority in any means.  But can have a relative impact of it's own in the game itself.  

In the end, it just depends on what the devs want

I haven't had much real experience with Hex Maps, although in atleast the simulation of RL or real time strategy maps, at the very least, Hex Maps really seem to be the way to go. I haven't seen hex-maps since I was dabbling in war-strategy board-games like Battle Cry. 

While fighting in an easily two dimensional landscape, like Civ 4, where everything is turn-based... Im okay with box-like checkerboards. However ... in a battle promised to be possible to play-out in real time ... I would want something a bit more complex. In all actuality I wanted a non-grid battlemap, where you could only clump units close enough that it did not disrupt their elbow room, or zone of control, and units went so many steps each turn.

With squares .... "real time" battle option seems far less likely. I would rather at-least have hex-maps for this case, although in my case I would prefer an UNgridded battlemap.

I mean square-maps have been proven to work on the World-Map, but battlemaps? Thats a whole different story, looking at a much more specific area.