Several months ago, I talked about the distinction between world space and screen space. As a recap, these are fundamental concepts that separate our game or simulation state from our drawn or rendered state. What gets drawn to the screen is not necessarily how things are laid out in the game’s actual (world) state. Check out the previous articles for more information.

The concept of tile picking involves a user hovering their mouse or some other input device over a tile in the game map. Usually the user is doing this in order to interact with the tile such as moving a unit to a location, placing an item on the tile, or inspecting the metadata of the tile. Fortunately for the developer, the process of picking is independent of the projection other than some simple math to do a conversion of coordinates.

Imagine that you are playing SimCity 2000, and you want to create a stretch of road from one location to another. The process involves the user hovering the starting tile, clicking the mouse, dragging the road to the end tile, and releasing the mouse. Tiles were picked out of the game map based on the mouse’s coordinates during game updates. Which space do we pick the tile from? Do we have to calculate if the mouse is contained within the projected tile or within the game’s world space coordinates?

Orthogonal

If the projection used in the game is orthogonal (think NES/SNES Zelda games), then the tile picking really is just a matter of answering the question, “Which tile contains the current mouse coordinate?” Answering the question is simple:

mousePosition = GetCurrentMousePosition();

worldX = floor(mousePosition.X / tileWidth);
worldY = floor(mousePosition.Y / tileHeight);

pickedTile = tiles[worldX][worldY];

To explain briefly, we get the position of the mouse (I use SDL which has a function to get the mouse position). We then convert the coordinates from screen space into world space. Finally we get the tile that is stored in our tile collection at the world space coordinates. We floor the coordinate conversion because landing in the middle of a tile will result in a partial index.

Reference the grid to the left. For the sake of discussion, let us assume that each grid contains 16 x 16 tiles. The top left most pixel is located in world space [0,0] and at screen space (0,0). The top right most pixel is located in world space [5, 0] and at screen space (80,0).

If the user moves the mouse to the screen space coordinate (25, 50), then the math to calculate the picked tile is as follows (using the aforementioned technique).

mousePosition = (25, 50);

worldX = floor(25 / 16) = 1;
worldY = floor(50 / 16) = 3;

pickedTile = tiles[1][3];

Performing that calculation, we get a result of the tile highlighted in blue. It is then up to you to do whatever you need with that tile. You can highlight it by changing its color, pass it on to some actor to recalculate its path, or place an object into the map at that tile’s position.… Read more

If you are not familiar with tile maps, please see the previous article in this series before reading this article.

Spaaaaaaace!

A space is simply some collection of points, vectors, shapes, and other objects that we use to store the state of our game or simulation. There are various kinds of spaces that can be employed during game development, but the two that I will focus on for this article are the concepts of world spaces and screen spaces. It is important to know the distinction and differences between these two spaces because it will make your game development journey much clearer and easier. Personally, it took me awhile before the concept of separating the spaces really “clicked” for me.

World Space

The most commonly understood space is the world space of the game. This is the space that contains the positions of all entities in the game. For example, if we have a 5 x 5 tile map where each tile is 16 x 16, we can represent that map (as discovered in the previous article) as a two dimensional array where [0, 0] is the first tile and [5, 5] is the last tile. Where these tiles are drawn on screen is of no importance when you generate the tile indices in the representative array. The underlying world of your game is represented by this array. The entities live their lives in this boring, mundane, grid-like existence.

All the game interactions and logic take place within this world space because of how extremely simple and efficient it is to perform calculations if we assume our game is as simple as an evenly laid out grid. But when we plays most tile based games, we notice immediately that what we interact with certainly is not as boring as the pictured world space to the left This should make sense to you after thinking about it for a little bit. Think of games like SimCity, Diablo II, or The Legend of Zelda. Even though each of these games has different views and projections, they can still be represented by a very simple tiled world space.

Screen Space

So what about those various projections then? If games that rely on tiles are nothing more than glorified arrays, how do games get those pseudo 3D effects complete with movement, collisions detection, and tile selections with the mouse? This is where the screen space comes in to play. The screen space is nothing more than a visual representation (via rendering) of the underlying world space in which our entities live.

Remember when I said that isometric and oblique projections share the same data structure? I said it because they do! The world space for both projections is identical. Only when you look at their screen spaces do things begin to diverge. By performing the previously discussed transforms to our world space, we can end up with a nice looking screen space in which the player will act and react. In fact, the player does not even know or care about the world space!… Read more