In a tile-grid where movement in any of 8 directions takes exactly the same amount of turns (chess-board style rules), can I prevent diagonal movement from showing more new tiles than orthogonal movement?

For example: You are the red box in the image below. The green cells are presently visible to you (square field of view). You can move a distance of one tile in any of the eight directions.

If you move north-east, you will explore 13 new tiles (shown in blue). If you instead move south, you will only explore 7 new tiles (shown in purple).

How can I make traveling in each direction equally favorable for exploration?

This is a fundamental flaw with the design of a game like this. You need to either not allow diagonal movement or switch to something like a hex grid which doesn't have this problem.
–
Tetrad♦Apr 21 '14 at 15:37

1

@Tetrad You're not wrong about it being a flaw, but you probably don't realize how prevalent it is in games like this.
–
Mr. SmithApr 21 '14 at 16:41

7

In any game where orthogonal and diagonal movement are equally quick, there will always be some things diagonal movement is better for than orthogonal movement and vice versa. It's just not solvable - if you plug one hole another opens.
–
PatashuApr 21 '14 at 23:53

3

Not quite a whole answer, but is it possible in your game to make a diagonal move take longer than an orthogonal one as proportional to the diagonal length? Second, you can have a mixed solution where movement uses the diamond pattern and view distance uses the square one?
–
ValityApr 22 '14 at 14:44

2

Another not-quite-an-answer: Orthogonal moves behave as they do now, but diagonal moves cause the light source to become "fuzzy" -- it doesn't reveal all the 13 squares that have just come into range, but only 7 (or so) of them, randomly determined.
–
SnowbodyApr 22 '14 at 16:50

Interesting; I've never considered a diamond field-of-view. However, there is an issue with this view too; it's a terrible idea to travel diagonal now, because if you spot an enemy while traveling diagonal, it will be significantly closer to you than if you had been traveling orthogonal.
–
Mr. SmithApr 21 '14 at 14:07

Since you are using a grid and know which direction the user is proceeding there is nothing constraining you from adapting the prior answer and using a different fields of view depending on the direction.

For example you could extended the field to include the corners when you travel in cardinal directions and shrink it down two squares on each end in your diagonal cases so that each uncovers 9 squares.

Another alternative depending on how your lighting works would be to use a better circle approximation with antialiasing, to partially reveal some of the squares.

That is an interesting compromise; if you travel diagonally, not all of the cells that would normally have been visible be visible. You can either wait a turn (to have those cells explored) or continue moving.
–
Mr. SmithApr 21 '14 at 16:44

Dungeons and Dragons 3.5 (pen-and-paper RPG) has a solution used for both movement and grid-based radius calculations: diagonal movement costs 1.5 what orthogonal costs. Since the diagonal of a unit square is approximately 1.414, 1.5 is pretty close.

Because D&D 3.5 only supports integer movement, the way this is actually calculated is that orthogonal movement costs "one square." Your first diagonal movement also only costs "one square," but the second diagonal costs "two squares." You alternate one and two squares for each diagonal move. Implementing this movement rule within your game will handle several problems with diagonal movement.

As this diagram shows, this movement rule creates a reasonable approximation of circles and also is not off by more than 1 when compared to the true distance (when within 15 units of the start).

If your vision/exploration radius is also calculated in this way, diagonal movement and diagonal discoveries will be about as close or far as orthogonal ones.

Exactly what I wanted to suggest. Although it's worth noting this strategy falls over in terms of restricting movement if the character can only move one space per turn (which appears to be the case from the question's diagram?). You could "remember" if they are on odd/even diagonals between turns, although this may be confusing/frustrating to the player. Regardless, this works well for the issue of visibility.
–
Alexis BeingessnerApr 22 '14 at 5:46

5

@AlexisBeingessner, true. And the questioner did indicate that he wanted chess-king-like movement, but I figure that since this is a computer game development site, I would point out a good game-play solution. If this is more of a riddle or a pure math question, I would expect it on another site. If this is for a rogue-like game, some of them already support varying movement speeds.
–
DaneApr 22 '14 at 11:02

Most Roguelike games appear to be turn-based, but actually have a time component, so if you move diagonally, other objects will have more time to react before you get to do another move.
–
KosApr 28 '14 at 12:26

How about, rather than having a fixed viewing range, have the player's visibility area depend upon what direction the player was facing, as well as perhaps the direction the player faced in the last few turns (a player who was moving north might be able to immediately take a step south, but might take a few turns to get maximum viewing distance in that direction). A player who heads north out of a narrow corridor into a large room and continues traveling north would have limited visibility east and west, and probably should. When the player stops moving, one could have the system automatically "explore" unseen areas that are within the player's present sight radius, but while the player is actively moving the field-of-view should be more confined.

As an alternative to a more complex field of view (which as discussed above adds its own problems because of the constraints of a grid-based layout) you could try to emulate the effect of movement in a game that isn't based on a discreet grid. Where free movement is possible a diagonal move of one unit would be exactly that, not the ~1.41 units of movement seen with a square grid.

While you can't force single unit movement without losing your descreet grid (which would change your game design pretty significantly) perhaps you could keep track of the extra movement taken and drop moves later: track the extra 0.41s and once they total more then 1.00 have that unit skip a move. Or the other way around: consider diagonal to be normal, add up the 0.41s for each horizontal or vertical move, and give extra move credit once that is greater than 1 (or 1.41 for a diagonal move).

You would need to be careful how you present this to your players in a way that makes it look both smooth and fair. In a multi-human-player scenario such changes could become something the players take advantage of strategically - this may be a problem, or there may be a natural way to mix this in with the game mechanic (perhaps allow the players to store a small amount of "unused move credit" that they can use to react quickly at a later time and have the extra 0.41s of move feed into (or take out from) that pool.

This would work best if player control entities moved move than one unit each turn. For example three movement points might be used as three horzontal moves, or two diagonal ones with 0.16 left in the pool for later. Once that hits 1.00 the player gets a "free" hor/very move and at 1.41 a free diagonal one. You could cap the extra at 1.5 for force it to be used or lost at that point to stop the player keeping this stored energy for ages or letting it build up.

Obviously this is a complication to your game rules that may be completely undesirable, and it would be impractical for a non-computerised game, but if you could make it work within your game's existing rules it would limit the exploration difference between movement directions without needing to abandon the grid format.

To have diagonal and orthogonal movement reveal approximately the same area, you need two things (each of which, alone, has already been suggested in another answer or comment):

Approximately circular view range:

On its own, this won't give exactly the same revealed area for both types of movement. For example, in the image above, orthogonal movement reveals 9 squares, while diagonal movement reveals 13. It's still better than the 13 / 7 ratio for the square view area in your example, though.

In fact, as the view radius grows, the ratio of revealed areas per diagonal / orthogonal step tends to √2 &approx; 1.414 for a circular area, while the same ratio for a square view area tends to 2.

Slower diagonal movement:

In real life, walking diagonally across a square field takes longer than walking along one of the sides. In fact, it takes about √2 &approx; 1.414 times longer. If you want movement in your game to feel realistic, you should make that happen in your game, too.

In practice, 3/2 = 1.5 is a pretty good approximation of √2. Thus, you can just make each orthogonal step take two time units, and make each diagonal step take three. With the example view area above, this yields 9/2 = 4.5 revealed squares per time unit for orthogonal movement, and 13/3 = 4.33 revealed squares per time unit for diagonal movement. Pretty close, eh?

Alternatively, if you want to stick to "1 step = 1 time unit" for orthogonal movement, you can use something like the D&D system Dane suggested and make every second diagonal step consume an extra turn. (If you do that, though, you do need to give every unit an explicit counter of how many diagonal steps they've taken; otherwise you may end up with exploits like, say, a E, NE, E, NE, ... movement sequence allowing a player to explore faster than intended.)

An easy way to prevent such exploits would be to say that a diagonal movement costs takes two ticks except when preceded by a move in the same direction which took two ticks.
–
supercatApr 25 '14 at 19:14

It would leave that sequence less efficient, but so what? Not all methods of exploration should be equally efficient. Actually, it might not be bad to have a time penalty for changes of orientation, with an exemption for cases where the move before or after was a double-charged diagonal.
–
supercatApr 25 '14 at 19:29

2

I did something similar a while back, and I solved it by having orthogonal movement cost two "ticks" per square, and diagonal movement cost three.
–
Mason WheelerApr 26 '14 at 0:35