Like anyone working on an indie game, one part that is often neglected is level editing tool. Coders like to focus on the game mechanic and framework and will opt for some hardcoded level with minimal assets. While that may work for a while, it is short sighted.

Taking control of the Content

A better approach would be start working on tools and tools integration even before writing any code. Working on a 2D game like platformer or a side scroller, one of the first things you need is a decent level editor and to setup a content pipeline for game level data.

One possible solution would be to roll your own full featured editor. This would require a substantial amount of time and resources, and divert the focus for the game to tools. In my experience, this is not very practical if your goal is to get going quickly and work on the actual game.A much quicker solution would be to leverage existing editing tools to create the game levels.

One such tool is the Flash IDE (Flash CS4/CS5) – it has powerful editing features and is very easy to use. In a recent game project I managed to save time by using it to build my own levels. Since Flash is commonly used to build levels for nearly a decade, many developers found ways to customize it to their needs.

The Content Pipeline

To borrow a phrase fro the Microsoft XNA docs, the content pipeline is a set of processes applied when a game that includes art assets is built. The process starts with an art asset in its original form as a file, and continues to its transformation as data that can be retrieved and used within the game. The goal is to have it set up so that artists and designers can place, modify and preview game assets quickly and easily. In the case of a small scale 2D game you’d want to make it as simple as possible.

While different platforms use different asset types, I will focus on the ones that are common in 2D games for mobile and web platforms. These feature heavy usage of bitmap assets for characters, background and game elements, and some form of descriptive data file (like XML) for levels.

Design Time vs. Run Time

The pipeline itself is processed at design time and ends at run time, when the game loads a level with its related assets.  Larger game platforms often use asset processing to create highly optimized versions of the assets for runtime based on the design time assets.  In the case of simple 2D  game, and in order to simplify, the graphical assets that are used in design time are the same one used at run-time –  this will do just  fine for most cases.

In this process, we first arrange the bitmap assets used in a specific level and import them into the editor as library items. Then the level is created by placing instances of these items in the editor, and gets saved to an intermediate format. To prepare for runtime, the level is exported to an  XML level file that contains references to the game assets. Finally when the game loads, it reads the level file and graphical assets to populate the game level.

In addition, round tripping between runtime and design time is made possible, so that a designer can instantly modify the level in the editor and preview the changes in the game.

More to come

In Part 2, I will walk trough the  actual steps for building and exporting a game level and handling different game assets.