pikuorguk

My game engine now has scrolling tilemaps in it. I have arbitrarily chosen each tile to be 32×32 pixels, and the maps to contain 256×256 tiles. This gives me a virtual display of 8192×8192 pixels to make tile-based games in. 8192×8192 pixels is a lot… just over 67million pixels. Storing that as a bitmap would require a bit more RAM than my PC has.

This is why tilemaps are good. Big game areas, not much RAM usage.

Drawing them is easy. Draw tiles in a bitmap, then have a 2D array that says where each tile goes. Each tile is numbered, starting at zero. Scrolling is easy too, you just draw a different part of the 2D array on the screen. This makes a slightly jerky scrolling tilemap though since the smallest unit you can scroll is one tile, rather than one pixel. To implement smooth pixel-based tilemap scrolling requires a little bit of thought.

Not much mind.

I did it by having an offscreen buffer that was two tiles larger in both axes than the screen, giving me a 1 tile wide border around the screen. Now, when scrolling, I copy that buffer onto the screen, adding or subtracting an offset to decide which part of the offscreen buffer to use. When the edge of the buffer is hit, I reset the screen back to the centre of the buffer, and redraw it using a different part of the tilemap.

Enough waffle, here’s some code:

    void TileMap::DrawMap(BITMAP *bitmap)
    {
        masked_blit (buffer, bitmap, scr_xoff, scr_yoff, 0, 0, buffer->w, buffer->h);
    }

    void TileMap::RenderMap()
    {
        for (int y = map_yoff; y < map_yoff + buf_theight; y++) {
            for (int x = map_xoff; x < map_xoff + buf_twidth; x++) {

                int xx = (tilemap[x][y] % (int)(tiles->w / tile_size)) * tile_size;
                int yy = (tilemap[x][y] / (int)(tiles->w / tile_size)) * tile_size;
                blit (tiles, buffer,
                    xx,
                    yy,
                    (x - map_xoff) * tile_size, (y - map_yoff) * tile_size,
                    tile_size, tile_size);
            }
        }
    }

    void TileMap::ScrollMap(int x, int y)
    {
        map_xoff = x / 32;
        map_yoff = y / 32;

        scr_xoff = x % 32;
        scr_yoff = y % 32;

        RenderMap();
    }

Note that the ScrollMap() function doesn’t test for wandering off the edge of the map, and it dumbly redraws the whole map every time. These are things I will change later.

For a video of it in action, click this link.

Originally published at Error_Success. Please leave any comments there.

I’ve made some more progress on my game engine since last time. I’ve been concentrating on the sprite subsystem, making it so I can have things moving around the screen. All of this is being controlled by the XML file, so most of the coding has been quite generic; creating “manager” classes and storing things in lists. And parsing XML… lots of XML parsing. It’s the type of coding you can spend hours on, but have little to show except a bunch of classes and a single sprite on the screen that does nothing at all.

Well in the spirit of learning something new, I decided it’d be good if my games could have sprites that followed patterns on the screen. This could be used in shooter games, or as the beginning of an AI in some sort of top-down car racing game. This post on the Shmup-Dev forum introduced me to Catmull-Rom splines, and after a few hours I had little test sprites making their way around the screen. With a bit of modification, I then made it so that I could have “chains” of sprites chasing each other around the screen, all glued to the same path.

So now I can have enemies enter the screen, fly around a bit and then disappear off the screen again.

I need to think up some way of timing the appearance of entities on the screen. Currently I use a frame counter, but it’s a bit of a hack at the moment.

I recorded a video that demonstrates it a bit better. http://www.vimeo.com/8015369

Originally published at Error_Success. Please leave any comments there.

I thought it about time I showed some sort of progress, so here’s a short video demonstrating the menu system my game engine has. The screens aren’t hard coded, the XML control file defines what screens the game has, how they link up and so on. Even the menu options and their actions are defined in the XML file too.

Now I’m making sprites work, which should make a more interesting video.

The video was captured using CamStudio, which is a neat OpenSource screen capture program. I was going to use Fraps like everyone else does, but it doesn’t seem to record Allegro games.

For reasons I don’t understand, embedding the video here doesn’t work. Instead you will need to click this link to see the video.

Originally published at Error_Success. Please leave any comments there.

My code running a Lua script

Well, this is a bit fun! One of the main points of my game environment is that I should be able to easily modify entity behaviour without having to hard code anything into the environment itself. After a bit of thought, the programming language Lua seemed to be the best idea.

I was completely amazed at how easy it was to add this to my own software. After compiling it up, a surprisingly small amount of code is required to get the basics working. It was harder working out how to extract the Lua script from the zipfile I am using.

The screenshot illustrates a very simple Lua script that does nothing more than contain a function called “think” which looks like this

– Basic test
function think(xpos, ypos)

print (”xpos = ” .. xpos .. ” ypos = ” .. ypos)
x = xpos
y = ypos
return x, y
end

So it takes in two parameters, prints them out, then returns them back to the host C++ application. So my C++ application calls the function in Lua, that prints out the values it received, and then returns them. If you look in the debugger you can see it all works

Now to work out how to expose data and functions in the C++ application so that Lua can use them. I need things like “getPlayerPosition” and so on.

Originally published at Error_Success. Please leave any comments there.

For the curious I have spent the past week (off and on) making a pause button work. Yes, after a week of coding I have managed to allow the player to press the ‘P’ key and see a little “The game is paused, press P to unpause, Q to Quit” box appear on the screen. Not only that, but the player can then actually press ‘P’ again and go back to watching a black screen with a red triangle on it (the “game”), or press ‘Q’ and go back to the main menu.

Which makes it sound like I’ve done bugger all really. And that’s the problem with measuring progress by things you create and can actually demonstrate to other people. You see, what I really achieved this week is

Read the rest of this entry »

Originally published at Error_Success. Please leave any comments there.

I’m working away on my un-named project, which is starting to take shape nicely. When it’s eventually finished it’ll be some sort of game engine-thing for making 2D style sprite based games – shooters, platformers, and so on. I have no idea what to call it though – a framework seems to be something like XNA where you have a collection of classes and libraries that can be bolted together and compiled up to make a program. An engine seems to be something similar, or the part of a game you get when all the assets and levels are stripped out – imagine Doom without its WAD files.

Read the rest of this entry »

Originally published at Error_Success. Please leave any comments there.

It’s my opinion, probably because I’ve written lots of database-driven apps, that all software can be reduced to a simple set of data structures, relations between the data structures, and the operations on those data structures.

Take, for example, this blog. There is a database table with the posts in, and then some PHP to turn that into readable HTML. Without the database, the site is worthless. The PHP, while important exists solely to display the data.

The same probably works for games too. Game objects have attributes, it makes sense to store game objects in collections for ease of management – put all the baddies in a collection, put all the bullets in a collection, collision test the baddies collection against the player, but don’t collision test the player against their own bullets. Level data contains attributes that are modified for each level. These also need storing in some sort of collection. Enemy AI is merely a type of attribute for each enemy type, and even the actual AI code should just modify known states for each sprite – ‘find player’ ‘move to player’ ’shoot at player’ and so on.

Don’t forget the game’s menu system and title screens. They’re just more data – “Display splash.png for 3 seconds, or until mouse pressed” “Display main menu until option chosen”.

So, because it’s easier than trying to debug homebrew Nintendo DS code without a debugger, I’m in the process of making a game environment that accepts an XML control file to set the game up. It won’t be predesigned for any particular style of game, but it will be designed for 2D sprite-based games.

It’s my aim that by writing an XML control file, some enemy AI in a scripting language and drawing the artwork my environment can then render the game. The ultimate aim is to have a reusable game rendering environment that lets me create games of a certain style in a less error-prone way.

I have a sample XML file created already, and am now using the excellent TinyXML to parse this and turn it into a set of C++ classes. After that I will reuse the sprite management stuff from my DS coding and expose basic sprite functions – “move_x”, “move_y”, “explode” etc to see if I can make a simple game of some sort.

I’m re-using a lot of code that I’ve used before. I had a basic sprite and screen management system on my DS, which has been ported to Allegro/C++ and some of the code I did in Processing has been used too. I think I’ll stick with Allegro now, it not only has excellent documentation, but it also works and is complete and so simple to use.

Robustly parsing XML is possibly more tedious than writing SQL though.

Originally published at Error_Success. Please leave any comments there.