Inferno - Game Project Blog

[JDGBOLT]

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.

Synopsis
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.

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

Brainless
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.

Mindless
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.

Fearless
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. I will likely be putting in game design ideas here and there, intersparsed with the more technical details, of which it would be great to have feedback, as I have but one mind, and I have never programmed a game before.

 

[JDGBOLT]

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.

 

[Esn]

A first rough version of the Brainless:

Needs lots of cleaning up and so on, I just figured I'd post something here to prove that I'm doing something as well.

Assembled with the APNG Assembler

 

[Orion4874]

Pandora specific or cross-platform?

 

[Esn]

Potentially cross-platform; the main thing stopping it from being so is the intended resolution, I believe. There's definitely going to be a PC version, though.

 

[JDGBOLT]

The current targets are the pandora and pc/linux, as those are the platforms that I readily have access to, though pc/win and osx could potentially work, as it so far is just SDL with a Cmake build system. Potentially could be ported to other handhelds, only thing being the higher resolution graphics being used, and the fact that it will probably be fairly cpu intensive, as the world isn't static, so lots of updates have to happen every frame, which could get taxing on some of the handhelds. Also I only own the pandora, so not sure how well it will work with the other platforms, never built for them or anything. The graphics are planned to be using a 32x32 tile, other platforms probably would be able to display much less of the world if we did it on platforms with less resolution than 800x480. Not sure, we'll see after we finish it first.

 

[Esn]

I decided that I'd rather do the animation first in Pencil, and then do the painting in MyPaint after. That way I can get the animation working right before I fill it in to look nice, and Pencil is a lot better for that. I did the Brainless animation entirely in MyPaint, and you can see that it looks a little jerky.

That means I need to make Pencil talk with MyPaint. MyPaint uses the OpenRaster (.ora) format, so I need a program that can convert a consecutively-numbered series of PNG images (such as Pencil will produce) into a multi-layered .ora. The only one I found that works in Windows 2000 is GIMP 2.7.3, which JTGBOLT found for me here (the Pandora's version of GIMP is 2.6.x, which doesn't support .ora). Anyway, I tested it out, it worked, and I now have a working pipeline:

1. Open Microsoft Paint, make an image 2 pixels taller and wider than the intended resolution (64x32 in the case of "the Brainless", so image would be 66x34)
2. Make a 1px black box around the edge; everything inside the box is what I can work in
3. Use Irfanview to save it as a transparent PNG, choose white as the transparent colour.
4. Use Paint.NET to increase its size by 800% (I like making the original high-res)
5. On the Pandora, import that PNG into Pencil (Edit->Import PNG)
6. Create animation within that frame
7. Save animation
8. With PC version of Pencil, export animation as series of PNGs (Pandora version can't export)
9. Using GIMP 2.7.3, File->Open as layers, import the animation-PNGs, export as .ora
10. On the Pandora, open .ora with MyPaint, paint over the frames
11. Export individual layers as PNGs. Bring to PC, there you can do touch-ups, etc.