Adventures in Game Programming

Inspired by the great video game primer written by Cecil I thought I'd share some of my experiences with hobbyist game programming. This isn't an instructional manual on how to program games or a large project, but hopefully it will give some insight. This first entry may be a little dry as I introduce what I'm going to be working on, if so you have my apologies. In terms of technical know-how this blog is going to assume you understand some basic programming techniques now and then, but even if you don't you should still be able to follow along.

Introduction

So first things first, who am I and what are my qualifications? Well, I'm a programmer (not a progamer), but not one in the game's industry. I've been programming side project games on and off for quite a while now and have really started to invest a fair bit of time into it. With my most recent project I thought it might be fun to also talk about different aspects of what I'm working on.

I hope to write a few blogs in this series and in each entry I want to dig into a different aspect of my game and all the little tricks and tips I've used to make it play well. I am by no means an expert, nor do I mean to imply things I say are the only way to do things, it's simply the way I've picked and why.

Choosing the Right Project

The game I'm going to be talking about was intentionally kept very straightforward and very small in scope. As anyone who's started a programming project will tell you, your biggest enemy is aiming too high. In this case I've decided to make a retro platformer in the style of Castlevania and Ghost & Goblins. Sure platformers are a dime a dozen, but I'm OK with that; I'm making it for myself, not to become the next Notch or Pixel. Given that I have my full time job and art takes me an extremely long amount of time to product (more on that later), I thought a simpler project that I can finish in a reasonable amount of time would be great.

It's amazingly easy to take simple ideas and get them bogged down in that one hard part everything relies on. Even worse, with more experimental game ideas you can easily get stuck with a prototype that just isn't fun.

A pretty far along prototype. I really like the setup for this game, but I had trouble designing content and explaining the concept to people. Essentially it's a game about time travel where the player character travels back in time, but you go through everything in chronological order. It is functional, but it doesn't have anything that really makes it stick as a game. Art is placeholder art from Biolab disaster

Even if the game is fun, you can really get stuck on implementation details, the simpler you can keep your first few projects, the better off you are going to be. Platformers are great in this regard. Your enemy AI is going to be very simplistic, you often don't even need a true pathfinding algorithm, and you can get by with much simpler collision detection. Don't mistake that for thinking platformers are simplistic or straightforward, there's a world of difference between Bubsy and games like Super Meat Boy.

This is another prototype I really like. A tactical battle RPG type thing. The concept sounds simple, but a tactical RPG demands strong AI which started to become a huge time sink. I decided with this one to shelve it for the time being. Plus I need to go back and implement fog of war to make the game fun. It does have a nice A* implemented I may talk about at some point.

The Tech

So now that I've decided on my project, the next step is deciding what tech to use. Normally this is where you may debate the differences between C++, C#/XNA, or countless other languages, but my case is different. I've been working a lot lately with a nice HTML5 engine called ImpactJS, so I'll be using that. Javascript isn't really a language I'd recommend to new programmers, nor would I say it's a particularly good environment for game development. The reason I choose it is simple: my work has recently required me to start doing some javascript programming and I wanted to get more comfortable with it. In that respect ImpactJS has been great for me, it has taken some of the load off what I need to program for my game, and I feel very comfortable in javascript now.

When you use a pre-built engine its functionality can range from incredibly basic to pretty robust. In the case of ImpactJS I get quite a lot, it has a built in level editor, collision detection algorithms, decent animation & font support, asset management, input handling, and a structured game loop that I can just plug into. The engine also exposes object oriented functionality and module support for javascript which is handy. It's far from perfect, and as you'll see using such a robust system can have a lot of limitations, but it works and that's what matters. There is also one kicker that makes me feel good about using it: being javascript the code is exposed for modification.

So now that I have my engine it's time to get started...

Screens & Overlays

Right out of the gate I decide to tackle the issue of screens first. A lot of the time this is something you may put off until after having a working prototype, but in this case I know I'm going full steam ahead so there's no sense in delaying it. In cases where I do try to tackle the issue later on, it's much more of a pain to retrofit than to do it up front.

So what is the screen problem? Well quite simply, the highest level state machine for my system. Pretty much every game is going to have at least two states: the menu/start screen and the game screen. Being able to switch between the different screens without issue isn't terribly difficult, but I do need to have something there.

For my simple platformer I can break the screens down into the following short list:

Starting Menu Screen
Option Menu Screen
Game Screen
Credits/Ending Screen

Next I come up with what I need the screens to do:

Render
Run logic/frame (update)
Initialize the screen
Uninitialize the screen to remove key bindings and such.
Animate transitions between screens.

I punt on that last one for now. With such a limited # of transitions I don't need a system in place for transition animations, I can handle that on a case by case basis.

So now it's time to hash out a quick interface that's going to give me what I need. Being javascript, I don't formalize it as an interface, there's not enough logic for that to be necessary. A simple set of functions for each implemented screen will do: initialize, destroy, draw, and update. Each screen initializes the key bindings it needs in initialize, removes them in destroy, and uses draw & update to render the screen and update its state. I add a global method to allow screens to tell the system to load another screen. It's not an idealistic architecture, but it's functional and gets the job done.

The next step is implementing what I call overlays. In this case my overlays are going to be the pause menu and any other information that appears over a screen rather than as a screen. Overlays are very compact as well, they have an identical interface to a screen with one notable difference. Instead of using a global function to close itself, I take advantage of one of the best parts of javascript: functions are treated like objects. That means the object creating the overlay can pass the overlay the function to close itself. No need for a more complicated event handling system or other mechanism. When the overlay is ready to be closed it just calls its own function and it's all taken care of.

Here you can see the game screen with an overlay indicating that the player has died and the can restart. You might thing the sprite died from an enemy, but it's really just from embarrassment over how he looks.

Now that I've whipped up my starting screens and overlays I'm ready to focus almost exclusively on the game itself. At this point my structure is as follows:

A main game loop provided by the engine.
A menu screen with options for New Game, Continue (not functional), and Option Menu
An option menu with options for volume control.
A game screen.
A menu overlay for the game screen with support for pausing the game.
A death notification for the game screen with support for retrying. I won't be using lives for this game.

Conclusion (for now)

Not bad for the first few hours of programming. As you may guess by the last screenshot, I have a little more done at this point, but I'm going to end this blog here. Next time I hope to get into the camera as well as some basic enemy stuff like how I made my "medusa heads".

If you've read this far, thank you! I know menus and overlays aren't the most exciting part of game development, nor was this description particularly involved, but I wanted to get it out of the way first. Next time I will be providing more code examples and specific algorithms. If you are so inclined I'd appreciated any feedback on how to improve this blog or topics you'd like to hear about.

Adventures in Game Programming

Completed

Ongoing

Upcoming