Category: Game Design

Tiled Maps in Games 2

Well I’m still apparently on vacation time. Hopefully it gets better before it gets worse since I’m going to be traveling for the next three weeks. If I get ambitious maybe I’ll write a post in advance and figure out how the scheduler works.

This time I’m continuing the series on Wang tiles in games. For those of you who are counting this is part 10.  and for those of you who can’t count – talk to your technology service provider about an upgrade. The first part of the series can be found here.

According to the outline this post is going to be devoted to terminology.

Tile

A small colored region, generally, although not always, rectangular.

Examples:

Tile Set

A group of tiles where each tile appears only once. Typically this is how tiles are stored in game resources.

Examples: the example tiles from Tile, Low Frequency Feature, and High Frequency Feature could each compose a tile set.

Tile Map

An array of tiles. Each tile may appear multiple times and may be adjacent to copies of itself.

Examples:

Low Frequency Feature

Features that occur only a few times per tile. For differentiation purposes we’ll say that low frequency features can be counted easily

Examples:

 

High Frequency Feature

Features that occur more times than can be easily counted on a tile.

Examples:

 

Seamless Tiles

Tiles that when placed adjacent to each other have no easily distinguished boarder.

Example:

 

I think this is all the terminology we’ll need for this discussion. If you notice something missing feel free to leave a comment.

Which brings us to the second topic of the day. What are the problems with tile maps? I’m mostly going to talk about one reason: tile maps almost always look like a bunch of tiles (or are incredibly boring). Sometimes the clearly tiled look is a good thing. For example in a tactics or strategy game like Civ, or if you’re trying to evoke the aesthetic of a classic system they are great.

So, what makes a tile map always look like a bunch of tiles? The succinct answer is, “low frequency features”. The human brain is adept at finding patterns (even in cases where there aren’t any).  Low frequency features can be counted and grouped almost subconsciously, allowing anyone to identify when tiles are being used. This is true for both seamless and seamed tiles. The grass and stone tiles from Malwrath are all seamless, so the edges between like tiles are hard to find, but they have low frequency features and make it easy to see that tiles are being used.

The obvious solution to this is to use only high frequency features in the tiles. In fact lets take this idea to the extreme and use the ultimate high frequency tile.

Obviously a certain amount of features are needed to provide visual interest. While it is impossible to identify the edge of the monochrome tile or even that it is a tile it is incredibly dull. Features also allow the player to note that the character is moving. Without some form of terrain or reference, it just looks like the character is flailing around on screen. Thus tiles with only high frequency features will never have an organic feel to them. The dirt tile from Malwrath has only high frequency features and it looks a unnatural; even Mars doesn’t have dirt like that. Also included: an instance of human susceptibility to optical illusions – or an Martian rodent… take your pick.

http://livrespensadores.net/wp-content/uploads/2013/07/mars-rodent-orig-rover-composite1.jpg

 

Stay tuned (subscribed?) for next time when I’ll talk about a way around the low frequency feature problem.

Tiled Maps In Games

This is the first in a multipart series on Wang tiles. The current sequence of topics covers a wide range: the Background of tiled maps, Terminology, Aperiodic tiling, Wang tiles, how to make your own Wang tiles, and how to procedurally generate a Wang tile map. And (if I get really ambitious) how to generate Wang tiles procedurally from a larger texture. Of course, all of this is subject to change since I haven’t written any of the articles yet.

Anyway, onward to our first topic: the background of tiled maps.

What are tile maps?

A tile map is a picture created by placing sub regions (a.k.a. “tiles”) at fixed intervals to form a grid. Good examples would be tiled floors, a checker board, tessellation artwork, the board from Settlers of Catan and the world map from any game in the Civilization series.

A tiled floor
A Chess Board
Free Civ World Map

How are tile maps used in games?

Tile maps are primarily used for both world and level maps in games. Of course, with current games that frequently depends on how strict of a definition is being used for a tile… Can a repeating 3D space be called a tile? Does drawing a repeating texture on the surface of a 3D object count? In any case, many games use tiled maps, and nearly all games for the good old NES and SNES used them.

Why use tile maps in games?

Since my cursory search of the Internet provided no resources on why tile maps were originally adopted in games, I get to speculate wildly (hehe). The most likely reason that tile maps were originally used is actually rather blase: resources were extremely limited. Let’s start with storage space. Tile maps allow a much larger space to be rendered than could be stored by a system if it was a single image. For example, let’s consider the Nintendo Entertainment System which has 2 kB of on-board ram and a game everyone should be familiar with The Legend of Zelda which clocked in at < 100 kB.  If the world map in The Legend of Zelda was stored as a single 24 bit RGB image it would occupy 23,000 kB (world 16 x 8 screens and each screen is 256 x 240 pixels) of memory. It’s clear that some form of image compression needed to be used to create larger worlds on the NES. One of these compression methods was the use of a tile map to build the world.

Other resource limitations to consider are money and time. Specifically, even paying a lowly artist to draw all of these images would become incredibly expensive and be a massive time sink. Let’s just look at what it would cost if the artist was paid per screen of images drawn. If the tile set used occupies approximately one screen you could reduce the cost of the art by 99% and use it to make the game mechanics better – or increase your profit! That number is if you estimate that there are ~38 unique tiles in the over world map and a screen is 14 x 10 tiles. Of course, you can also reduce the number of unique tile drawings required by just changing the tile color.

It’s also possible that the use of tiles provide some additional benefits at the hardware rendering level. But, since I’m not familiar enough with the hardware and graphics implementation in these systems, I’ll stop my speculation with the obvious advantages I mentioned above.

 

I think this is enough for now stay tuned next time where I’ll discuss the terminology and shortcomings of tiled maps.

Platformer Update 4

This week’s accomplishments are mostly of the bug crushing variety. I reduced the likelihood that the ‘no more jumping for you error’ occurs. I’m not convinced it’s completely resolved. What exactly is this error you ask, well let’s start with a screen shot (finally) of physics body debug render. The player is represented by the small square on top of the circle on the bottom about 1/3 of the way in from the left side.

Since jumping is conditional on having something to jump off of at present, the circle fixture checks to see if it has contact points near it’s bottom. if yes then jumping is allowed if not no jumping for you. At various times during testing the player stopped responding to jump commands while appearing to be grounded visibly and with in a few thousandths when the numbers were reported. The cause of this phenomenon is it seems that when Box2D contacts are reported to a libgdx box2d contact listener only the most recent contact point is retained.  So if the player is contacted from the side, by let’s say a box propelled by an explosion, the circle would record a side contact and decide it was hovering making jumping impossible. The solution I used was to shrink the size of the circle ever so slightly, so that the box now projects out past the sides of the circle slightly. This has eliminated current instances of this issue, but I’m not convinced all cases have been eliminated.

In other news Rho_Bot stopped by long enough to find a problem with the explosion system. Basically too many explosions (to put a number to “too many” somewhere 3-4 range) in rapid succession caused the program to hang while the physics calculations were completed. This was solved by limiting rocket ROF which was planned anyway.

Platformer Update 2

Last week I mentioned screenshots for the platformer, and everyone here to see those will be disappointed, because instead of spending time adding content and updating graphics I decided to reorganize how level data is organized. Why exactly did I do this?

Because I could.

Also levels were defined in a combination of *.xml and *.json and I wanted to standardize it a bit. Now all level data is stored in a single *.json file. I also wanted to move level loading instructions into their own class. Previously level’s loaded themselves; however, the level class was getting long and moving the loading functionality seemed to be a logical way to split up the class.

So not  a very exciting week when viewed from the easily demonstrated progress dimension, but streamlining level files and improving class compartmentalization should make things smoother going forward.