Inferno - Game Project Blog


Aug 29, 2008
Me and ESN are teaming up to work on a project entry for the RIOTdigital competition, of which the game idea has actually been banging around my head since the start of the last competition, but didn't get much work done on it. This will be my first game and programming project, so this will be quite a learning experience, so to do something a bit different than the norm, I am going to do most of the development out in the open, doing various posts when I have time for what I have implemented for that day, posts for some of the technical decisions that I make for the design and such, and, also, once I get a bit further along with the code, putting it up on github for the entire world to see.


The game takes place within a haunted mansion, with the main character being somewhat of a dopey kind of chap, who is a walking disaster waiting to happen. Who after being a bit too clumsy and knocking over a lit candle, now has to run away from the inferno that he has created. The inhabitants of this particular haunted house are none too happy with this development, and will do everything they can to prevent him escaping. The tagline for this game is: Flee fire, dodge monsters, and solve puzzles. It's kind of a survival horror puzzler game, there is no direct way to attack the enemies, your only recourse is to set parts of the game world on fire, hoping to get them caught in the blaze, and this is also how you will solve the game's puzzles, the total design of which I haven't quite worked out yet, but will consist of places where you can start fires, with various different types of objects catching fire. The types of objects that you would find in an old, derelict wooden mansion. Things like curtains, cobwebs, rope, books, probably others, will be implemented into the design of the puzzles. There will also be collectible keys and switches and other standard puzzle fair that will be used for bonus collectibles scattered throughout the level that, if you are fast enough, you might get the chance to get. The reason for this is you are in a burning building, as time progresses, more and more of the level will be burned away, taking the collectibles with it. So you have to act fast to get them, and it will provide incentive to replay levels, trying to grab all the secrets as fast as you can.


There are 3 enemies planned for the game, each with different characteristics and ways of coping with them.


These enemies are slug or wormlike monstrosities with a nice mouth of shiny teeth that kind of hop/lumber slowly along, but that can lunge at you trying to grab a piece. They are slow enemies, but their lunges can offer a surprising amount of speed that you have to duck and slide under, as they are quite spiny and can hurt just by touching you. They can be quite dangerous if you aren't careful, and they make a nice whisperly cry for brains.


These enemies are small, very fast, puffball like creatures, that spin along the game world very quickly and do hops to try to latch onto our poor protagonists head, reversing controls or other such effects, that can be annoying, and deadly when combined with fire and enemies. They are quite fast, but that is also their weakness, once they start jumping, they only move along a predetermined path, being so fast and lightweight. They are more annoying than anything, but can be quite deadly if they affect you at the most inopportune of times.


These enemies are a modification of the classic charging creature type, I envision them as sort of a bull-like humanoid, who charge you, but who you can hop over if you time it right, but watch out, as they also lunge their heads upward trying to get you, too late and you might have a few more holes than you remember. This tendency is a part of their weakness, losing sight in front of them, and having a tendency to crash into objects if the jump is timed right.

I haven't done much of the coding, starting coding about a week ago coding my skeleton of the game, so there isn't much to show at this point, mostly game ideas and ideas for how to implement them in code. I haven't done much c++ programming at all, so this is very much a learning experience. I'm hoping to be done enough with it for the RIOTdigital competition, but we will see how things progress. Over the next couple of posts, I'll be going through some of the technical details for how I am designing it, partially to help me sort out my own thoughts, but may be boring to the nonprogrammers who aren't interested in that sort of stuff.

Technical Post #1: 2011/05/22

Now for some of the technical details of what I have accomplished so far, and how I plan on architecting this thing, as it will be somewhat intensive, as the game world is not static, so there is a need for many calculations for every frame, for how the fire will spread, ai for the enemies, motion for all the interactive objects, etc... The game itself is programmed in c++ using sdl for the backend, and the sdl_image and sdl_mixer libraries. I have a cmake build system all up and running, which makes building pretty easy, and should theoretically be able to be ported easily enough to mac osx or windows, but I don't run either platform, so that will have to wait until later. I've been able to build for both linux pc and the pandora, which should make testing a bit easier.

What I have gotten working so far is a nice skeleton of classes and functions, which will help aid me in putting the parts where they should be and everything. I have input management working, a working state manager that I could add states to, a main loop that calls functions into the state manager which passes it along to the state, and initialization and cleanup functions to start up and close everything down. I will have the states broken up into 5 different modules, each one handling a specific task, such as display, sound, input, and logic, and a core class that handles data that must be shared between each of these modules and handle the running of the functions to each class. Each module will have it's own set of data that are specific to that module, and which none of the other modules need to know about, but as far as the actual running of the processes go, I am implementing what I have seen described as data oriented programming/design.

The basic idea behind this programming paradigm are as follows:

Separate the data from each of the objects, have data split up and grouped into sequential blocks of memory, with which batch processing can be used to handle the state changes of all of the objects, rather than having a separate class for each type of object, like tiles or each type of enemy, or whatever. This helps with the massive amounts of world updating that I will need to do, rather than doing a ton of function calls and going into and out of each object in the level to update it's state, having steps, like a run AI step for the enemies, which will run a batch process, little more than a for loop, through all of the data specific to that type of enemy, which will be stored with all of the other data in a vector. So AI specific to each enemy will be run, with a base enemy class with virtual functions and the enemies inheriting from this, to run their AI on their subset of the global data, which for the ai will be the properties, the position, and the physics related data. Each of which is stored in separate vectors. AI will do little more than updating the accelerations, velocities, and various properties of the enemy. Moving and handling collision detection is another batch processing step, going through all of the data, moving according to the acceleration, velocity, direction, etc... the positions of all the interactive objects. It doesn't care whether it is an enemy, the player, a falling box, whatever, it just handles it's own step easily and efficiently, with sequential data so the cpu can do prefetching all of the data and reduce cache misses.

Rendering is handled by the display module, with which it has it's own data, such as all the images needed to be drawn in the world, again, the rendering step doesn't care how the enemy is moving or anything, just the state of it's position, direction, and animation state. Sound similar sort of deal, storing the sounds and everything else within it's own class, since the rest of the modules could care less about accessing this information.

The fire is a bit more involved, but I'll still try to make as general as possible, with each type of object having specific burn properties such as burn time, fire resistance, flame direction, etc... I am still trying to think about how to handle the burn physics, but as far as tiles I am thinking I will do just simple calculations with a tile affecting the adjacent tiles, so the fire can spread from a central location, with fire travelling along the floor being a separate calculation, and this which can hurt the player and enemies. As I said, I'm still thinking about how to do this, as this is a big part of the game, so once I get my prototype done I'll be doing lots of testing with the fire physics to make it work well enough.

There is going to be a lot of motion on the screen, so I'm trying to find what I can to reduce the amount of drawing, but there will still be a lot, as the tiles will be practically changing every frame when on fire, and the enemies and other things. The aesthetic of the game is actually grayscale, with an additional lighting step being done after the drawing, by modifying the color of the pixels around the fire to be orange or whatever, so trying to find good ways to draw that, using an optimized circle drawing algorithm or something. I think it will add something to the graphics and feel of the game, and hopefully won't cost too much performance to do it.

I am planning on using XML to store my game data, such as the enemies and their properties, the tiles and the tilemaps, sounds generated, etc... I'm planning on using PugiXML, which seems like a good, fast performing xml parser, and which I may just store that data always in memory, but not sure, depends on the size. I picked up some ideas from the Tiled map editor, which gave me the idea to use xml, and to store the tilemap data in base64, with compression probably provided by zlib or fastlz or something. Still working out that whole stuff, but I plan on having all the data for a chapter, which has a set of enemies, their properties such as size, speed, sprites, etc, tile sets and maps, objects, etc... All contained within this chapter, so I can add new chapters to the game with different kinds of enemies and tilemaps, etc... Still thinking about this stuff though, I might break it up, but it seems convenient to store the stuff in memory, but we'll see how it affects memory usage of the game.

I think that's about all for now, hopefully was a bit informative, and do point out if I am making any glaring mistakes. :) . I'm sure I will make many.
Last edited by a moderator:
Well, Esn just did an update on what he has been working on, which is the brainless enemy, with an awesome animated png showing a few frames of what I think is the moving motion. Pretty dang nice, gives me motivation to keep working today, trying to work on the physics of the general motion, and also some of the other functions within the logic module. Tough to orient right, with as few calls as possible and as few branches. And just how to work out the whole acceleration and velocities of the objects. Things having the capability to slide, so to speak, etc...

The Brainless Enemy:

It's actually the brainless enemy that was in the initial post, which are kind of like slug/worm like blob things, with a big mouth full of teeth. :)