jonbho

I initially planned to have only 3 levels, but turning that into 9 looked more sensible: completing a level is a positive reward for the player, and thus it will help us provide them with a better experience. So let’s get started trying to generate nine levels with varied graphics and progressive difficulty.

Both variety and progression are very important to providing a satisfying game experience. Let’s start with the graphics which are the easiest here, thanks to Dan Cook’s Tyrian graphics. I initially planned on having three “worlds”, thus three main sets of graphics, and three levels in each world with progressing difficulty. But given the Tyrian graphics easily allow more variety, I have decided on having 9 different looks, one for each level.

Level graphics

Having a look at the Tyrian graphics, I saw some interesting things for level background graphics. Have a look at this piece (shown at 4x size):

The piece above can be broken down in tiles of 24×28 pixels, and the cool thing is that the piece above comprise all possible combinations of sand and grass. Thus, if we create a grid, and we randomly assign a type of terrain to each grid corner (sand or grass), we can then find the right tile to paint in each cell, looking at the terrain type for the corners.

Actually, it’s not true, the tiles above are missing two cases (grass and sand in pairs in opposite corners of the cell), but those are easy enough to prepare by hand.

So what did I do? I extracted these graphics by hand using Paint.NET, and saved as separate 32bpp BMP images for each tile: 16 tiles per combination of two terrain types. Fortunately the Tyrian graphics have several of these cases… so I did this for 9 different combinations, choosing the ones I liked the most. There were several combinations I really liked, but they didn’t respond to the same pattern. I had to keep things simple, so I only used tilesets that could processed in the same way.

Once I had this, I needed to write some code to generate the random terrain types for grid corners, and then the tiles for each grid cell. I don’t want to store the whole level, so I made the code generate the background by pieces. I have a piece that can contain about two screenfuls of data (less would do too), and the whole level is mapped on top of this in a repeated fashion – this structure is called a “ring buffer”.

Have a look at the code that does this (in game.cpp):

As you can see, the code is not complex, although the underlying arithmetics can be a bit tricky to wrap your head around. The tiles are ordered in the textures list such that the right one is picked.

If you are doing these changes by hand, which is actually the best way to follow along the one-week-game project, please note that you have to change the value of MAX_TEXTURES in core.cpp to 256 or so, or the textures won’t fit and you will see a lot of white blocks!

The result is pretty nice for what we have been able to invest, look how this looks with the tile set above and a couple other nicer tilesets:

Level progression

But the most important part is the actual challenges the player has to confront as they progress through the game. We prepared some logic yesterday which can generate level content according to some parameters, while always allowing the player to overcome the challenges. What I have done is prepared a different set of values for these parameters, and the right set is selected by a g_current_level variable that is set at the beginning of the level.

Here is the code that holds this information, and the content-generation using these parameters:

While we don’t have menus implemented, I’ve just made the keys 1-9 take you to the start of each level.

And here is how the levels look now (some of them gorgeous, if you ask me, thanks to the awesome Tyrian graphics):

Spacecrash: Day 4 of 7 from Jon Beltran de Heredia on Vimeo.

You can download the whole package of source and resources in its current state, for you to play around: sc-day-4.zip.

Recap

I am behind compared to what I expected to have today. Here are the main limitations:

• Gameplay and gameplay difficulty are not adjusted for an engaging experience and progression.
• More enemy behavior and variety is needed. At the very least proper sizes for obstacles and enemies!
• Graphics and sound effects need a lot of work

I don’t want to change the schedule as a matter of principle for this project. If I go deeper into these areas, I may miss other critical areas, such as menus/UI or deployment. So I will work on menus tomorrow, and prepare an installer on Saturday. If I can make some time apart from this, I will put in some work in these areas. Since it probably won’t be enough time, on Sunday we’ll have a complete game, only with mediocre effects, gameplay and progression – so I will plan for a couple more days next week working on these two areas. It’s definitely not the worst budget blow-up I’ve been through!

And if you want to be notified when new articles to help you become a games developer are ready, just fill in the form below: