# How do I make a isometric movement?

0 Favourites
• 4 posts
• could please someone explain me how can i make a isometric movement. (2D Game, maybe like a top down game)

I would like to make a rpg with my friend using these isometric sprites ( http://kenney.nl/assets/isometric-buildings ) , but we don't know how to do the movement.

Thank you.

• ## Try Construct 3

Develop games in your browser. Powerful, performant & highly capable.

Construct 3 users don't see these ads

If I understand, it sounds like you might be interested in how to get 8 direction movement, but properly transformed for an isometric perspective; such that if a player holds the left and down keys, their character will walk at an appropriately shallow diagonal, rather than a perfect 45 degree diagonal.

Model world / Display world

One approach is to have two worlds.

A "Model" world, which is invisible to the player.

And a "Display" world, which is what the player sees.

(Prepare to see those colors a lot. Sorry in advance...)

The key is that the Model world is a flat 2D straight-top-down representation of your game world. And the Display world is the isometric view of your game world.

We build the 2D Model world first.

We then make a "renderer" (using events) which looks at all the objects in the Model world, and creates their Display world versions, positioning them to create an isometric view.

All of the game logic, (character movement, collisions, projectiles), will be handled in the Model world where movement and collisions are simple, as everything can be done with the standard 2D features already built in to Construct 2.

For each 2D object in the Model world, our renderer will create an isometric version, and use some math to convert its 2D world coords to isometric world coords.

Example

As a practical example, let's say there's a playable character with the "8 Direction" Behavior in our Model world. When the player presses the Move-Right key for one second, and then the Move-Down key for one second, the Model character moves rightward in the Model world, from pixel-coord (0,0) to (100,0), and then moves downwards to (100,100).

Remember though, the Model world is invisible to the player.

So the renderer takes that Model character and makes an isometric Display version of the character move rightward from pixel-coord (0,0) to (100,0), and then downward to (100,50).

Notice that the Model character is at (100,100) but the isometric character is at (100,50). Converting from 2D Model coords to isometric Display coords is one of the jobs the renderer will do.

In this case we are just dividing the Y coord by 2, and leaving the X coord alone.

Essentially, to create the Display world, we are just squishing the Y axis of the Model world to half it's normal height.

Thus, in the Model world, a 400 x 400 pixel patch of dirt in a field of grass, would be represented as a 400 x 200 pixel patch in the Display world.

So far so good, but what we just created is sometimes called an "Oblique" perspective, which is not quite the same as the more traditional "isometric" perspective.

Oblique vs Isometric

Imagine a camera pointing straight down at a treasure map, on the map the compass rose's North to South axis is oriented vertically in the camera view.

If we lower the camera's elevation angle from 90 degrees (straight down), to 30 degrees (shallow downward diagonal), we get the oblique view described above.

In this oblique perspective, a cube shaped building would have its southern edge (not a corner) closest to the camera.

To get a traditional isometric projection, we'd also then need to rotate the map 45 degrees, so that the camera is looking diagonally across the compass rose, such that (for example) the rose's North-West to South-East axis is oriented vertically in the camera view.

In this isometric perspective, a cube shaped building would have its south-eastern corner closest to the camera.

The math for converting from the Model world's 2D coords to the Display world's isometric coords is a bit trickier than the simpler oblique view, but still just some trigonometry.

Edit view (Model) vs Runtime view (Display)

So one problem you may have noticed is that with this Model-world/Display-world approach, when building your levels, you'll be editing the Model world, not the Display world.

Editing the Model world means arranging a bunch of 2D placeholder rectangles in the Construct layout editor, knowing that the "renderer" will turn it into a nice isometric view that you can't see while editing.

There is a workaround though, which can allow you to build your world directly using the isometric assets. Essentially, you would have to make a reverse-renderer, which will take an the isometric assets and their coordinates, and convert that to a Model world. After that the game would run normally off the Model.

If you're familiar with the concept of a Model-View-Controller, that's loosely what you would have with this Display-to-Model-to-Display setup.

Depth sorting

Finally, there's the issue of making sure things in the Display world are depth sorted correctly, so that a distant object doesn't overlap a nearer object.