Calum Mackervoy

2D game worlds are constructed of several different types of terrain, of grass and water and firey lava. Since time-immemorial, top-down 2D classics like Pokémon have stored such data in terrain maps, essentially an array of integers representing the game map. In a very simple example we can imagine building a tile set of black and white squares, like a chess board:

[
    0,1,0,1,0
    1,0,1,0,1
    0,1,0,1,0
    1,0,1,0,1
]

The array rendered, where 0 is white and 1 is black

Of course, in most games we would prefer not to have such harsh lines between each tile on our board. Often we want our terrain map to include several kinds of terrain and crucially to include some blending between each type of terrain:

[
    1,1,1,1,1,1,1,1,
    1,0,0,0,0,0,0,1,
    1,0,0,0,0,0,0,1,
    1,0,0,0,0,0,0,1,
    1,0,0,0,0,0,0,1,
    1,1,1,1,1,1,1,1
]

Obtaining such a result involves creating a tile set for each type of tile on the map, here we have water and grass. Instead of creating a single tile for grass and water that blends like the black and white of a chess board, we create many tiles for each tile type, blended with the different surrounding terrains. Take the example below:

In our game we will then select the tile to display based on the surrounding tiles. If the tiles to the right of this one are grass - but all other tiles are water, we will draw a version of the water with a grassy verge to the left, like in the tile highlighted below:

Another water tile is surrounded by water, so for this one we select the corresponding “full-water” tile:

Tile Maps in Godot

Whilst classic games such as the early Pokémon games were built from scratch, nowadays aspiring game developers can use an engine to get up to speed faster and leverage existing tools for common games development needs.

Godot is an open-source game engine for producing both 2D and 3D games, and using the TileMap node from the 2D engine we can draw 2D maps of terrains like the one above. Going into detail about how you can do this with a standard terrain set is not the purpose of this article, but suffice to say that it involves configuring essentially the process outlined in this article. The developer can create the appropriate terrain map PNGs, configure the map, and provide the array of terrains that define the pond:

[
    1,1,1,1,1,1,1,1,
    1,0,0,0,0,0,0,1,
    1,0,0,0,0,0,0,1,
    1,0,0,0,0,0,0,1,
    1,0,0,0,0,0,0,1,
    1,1,1,1,1,1,1,1
]

Then the engine does the heavy lifting: selecting the correct tile to display, etc, and the developer can get back to the fun stuff. If you’re looking for a tutorial on how to set this up, there is a concise one covering the use of tilemaps in a top-down 2D game available here. The Godot documentation also has a tutorial on Using TileMaps.

Blending with unknown tile types

I’m working on a game which is data-driven. Players are able to publish their own content, including for example map regions with custom tile types like lava or sand, not necessarily prepared in advance for the default levels. The tiles, downloaded from the web, aren’t known in advance and we therefore can’t prepare blended tilesets for every tile type in advance. We want to allow plauers to draw a new terrain like lava and drop it into their map at run-time, i.e. without modifying the game files or needing to consider how it blends with grass. We want to be able to do this without giving up on blending altogether, or accepting the harsh borders like a chess board.

The solution is fairly simple: we will place each tile type on its own layer, and we’ll prepare only one tile set for each terrain: blending the tile with transparent space:

Much like our previous example, but here the lava tile is blending with empty space.

By using a standard tileset layout like this, we can adapt a standard tileset configuration file (.tres), removing this workload from the creator. Representing the world data in JSON, the configuration of a new terrain type becomes trivial:

{
    // ...
    "terrainTypes": [
        {
            "data": "https://simpolis.gamescommons.com/assets/tileset/Water.tres",
            "name": "Water",
            "solidity": 0,
            "hot": 0
        },
        {
            "data": "https://simpolis.gamescommons.com/assets/tileset/Grass.tres",
            "name": "Grass",
            "solidity": 5,
            "hot": 1
        },
        {
            "tileset": "https://simpolis.gamescommons.com/images/7c8febe6-1484-4b23-91be-7b290234821e.png",
            "name": "Lava",
            "solidity": 0,
            "hot": 10
        },
    ],
    "terrainLayers": [
        [
            1,1,1,1,1,1,1,1,
            1,0,0,0,0,0,0,1,
            1,1,1,1,1,1,1,1,
            1,2,2,2,2,2,2,1,
            1,2,2,2,2,2,2,1,
            1,1,1,1,1,1,1,1
        ]
    ]
}

Accepting a tileset data-type, the player can upload their custom terrain set, with the appropriate data properties like hot, which can be used to control behaviour. The game parses this data and builds the necessary game assets, completing them and saving them for future use. Thus, the player is able to upload a custom terrain type like lava into their world, in a game which wasn’t built to understand what lava is:

Games Commons

The concept of building a game piloted by the data published by its’ own players is an exciting one. Done well, the game becomes limitless and even alive: evolving with the collective efforts of the players. A game built in common is a Games Commons, and while in this demonstration we have been principally concerned with straightforward graphical elements, the idea constitutes a novel approach to game design that has far-reaching implications.

If this article has piqued your interest and you’d like to hear more about the concepts covered or more broadly about the project - or if you’re interested by Godot and open-source games development - then don’t hesitate to get in touch!