This article is intended to give the reader a look inside the making of a small game using Blitz Basic or Blitz 3D. Santa Blitz was my entry to maDenathorn's BlitzCoder Xmas Compo 2002 (not official I believe). I'm quite pleased with how it turned out considering how little time I was able to devote to creating it.

The Challenge
maDenathorn posted the basic competition rules on November 17th, 2002. Summarized, the guidelines amounted to:

Create a game that has a Christmas theme to it. There will be no limitations in the competition, except that all entries must:
1) Use 2D Graphics
2) Be original (No Xmas pong please)
3) Be FUN To play
Deadline: 1100 hrs, 12/25/2002 (UK)

Fun! And as a plus he offered Blitz3D or its equivalent value from Amazon.com to the first place winner. Idigicon later offered to pitch in a bunch of KoolDog games, so no one went away empty-handed.

The Schedule
Although the competition was announced on November 17th I was facing a lot of pressing work and personal deadlines at that time so I wasn't even sure I'd be able to enter. I made the decision to go ahead the day before my wife and I went on a house-hunting trip to Oregon/Washington :) we currently live in California. Even so, I really only got some basic planning done in the early stages, while most of the real work didn't happen until mid- to late- December. Here's a rough look at what happened when:

11/25/2002 - Project begun. I did some basic planning and a couple of images while at the hotel in Oregon. I also cobbled together the basic framework for the game: main loop, start-up, shut-down, etc. I knew I'd have to shelve it for a few more weeks though.

12/13/2002 - I finally got to really start work on the project on the weekend of the 13th. I created most of the basic graphics, though they would be edited later on. I also coded the movement for Santa's sleigh and the reindeer. I added in the snow effect and kludged together the background scrolling effect. As an afterthought I added code to allow the player to control Santa using a digital joystick.

12/14/2002 - I dropped in a basic main menu with some placeholder graphics and added in the necessary code to run it. I also did some behind the scenes work with object creation - sharing objects across sections of the game (in game, menu, etc.)

12/15/2002 - Spent ages finding and editing photos of houses and trees for the scrolling terrain. Then I quickly coded up a random level generator and the code for scrolling the terrain as the user flew over it.

12/21/2002 - Finally back after the work week I was able to add present dropping code and scoring. I also went back and added in speed limiting - courtesy of Morduun's article on frame limiting.

12/22/2002 - Added logic for level advancement, lives, winning and losing, etc. I also modified the speed limiter to calculate and maintain average FPS data.

12/23/2002 - Spent some time creating graphics and code for a new menu system with help, etc. Added in code for enemies. I was going to have Santa and the deer have a fiery crash when they collided with the enemy but my wife suggested that collisions should just reduce the number of available presents to drop - brilliant idea. It made the game less violent and more playable.

12/24/2002 - Spent the day recording and editing audio and coding in the hooks for it into the game. By this time my code was getting really kludgy and I even considered abandoning the contest. I also rigged up a kludgy splash screen with my 'company' logo - very bad coding here :). Finally I added the credits screen. And submitted the entry. At this point I was calling it v0.7. Still have stuff I want to add.

Not the best example of time use in the world but I managed (just) to get it done by the deadline and (barely) complete enough to make a good showing in the contest. In retrospect I would have tried to devote a few hours a night to it rather than marathon weekend coding sessions. I think the overall results would have been better. You spend a lot of time re-learning when you take a week-long break from your code.

The Design
Coming up with the design for Santa Blitz was quite simple. The contest's primary concern was that entries have a Christmas theme and be original - anything else (except 3D) was fair game. A colleague of mine (he's actually the president of NDL, makers of the NetImmerse game engine) once showed me a 3D game they'd cobbled together for the PocketPC platform - in which you played Santa flying over a small town dropping presents on the houses below.

I thought that was a pretty good concept so I brainstormed about it for a while. I pictured the deer and Santa's sleigh gliding gracefully over winter terrain and a starry sky filled with blowing snowflakes, thinking about how it would look in 2D. Cool, but it needs a point. How about pre-Christmas time trials to whip Santa and the team into shape before the big day? That sounded good because it gave an achievable goal: dropping a certain number of presents within a certain time.

With just Santa gliding over the rooftops it might be a little too easy to just stay at the same height and work out the present dropping timing and you've won the game. Well. The US media are always talking on Christmas Eve about how NORAD (scary folks with costal radars and nuclear bombers) is tracking Santa, so I figured they might send up a few interceptors to see about the time trials as well. And, of course, *that* activity might attract the attention of the friendly alien observers on the dark side of the moon - who've been working all these years to make sure we don't blow ourselves up (yeah, or something like that).

So, we've got a good goal and some believable (well, for a video game :P) enemies and that's about all we need. I think the design for uncomplicated games should be kept simple - I wrote mine up in couple of paragraphs, included below. You can see how the game changed while I was coding it - many things were simplified or removed and even the name changed early on during development, as I wrote this several weeks before doing much actual work on the game .

Santa's Run

Drive Santa's sleigh and drop presents into chimneys. Run is timed and various numbers of packages must be dropped (depending upon level) accurately to advance to the next stage. For added interest, Santa must avoid the might of the US Air Force, who believes he might be a terrorist in a private plane. F15 fighters and surface to air missile installations will begin to crop up in greater numbers as Santa approaches America's heartland. He might also meet a UFO or two.

Game will scroll right to left. Parallax scrolling if possible with three levels of background scenes. Front layer will consist of target houses and chimneys. Static background. Snow effect plane will cover graphics overlay (snow will probably be white dots to save time - need speed tests. Control of the sleigh will be sluggish - rudolph guides and other deer and the sleigh follow more slowly. Santa can move up or down and speed up or slow down - within level-specific limits. Houses could be considered collidable targets for the sleigh. Packages obey gravity (possibly modified to improve playability).

May be as many houses as desired. Could have various types of levels - from rural to light urban. Level starts empty and such then scrolls into playable level. Level ending is empty as well. Music should be something christmasy or maybe just sleighbells jingling in a loop.

One idea is a 'stealth' mode that lets Santa avoid detection by children. Not sure how this would work - and it would have to work in conjunction with attacking planes and SAMs as well.

These simple guidelines gave me enough to go on as I built the game, but gave me the flexibility to make changes for playability and speed of development. For example, I nixed the idea of air defense sites early on - to make the game a bit easier and a bit less violent. For more involved projects (though I've yet to complete one) I firmly believe in using a detailed design document to keep you on track.

The Art
Tools Used: Clip art, photos, Macromedia FireWorks MX, Wacom Graphire

I was under no misconception that Santa Blitz would be my magnum opus. I knew I'd only be able to spend a couple of weeks putting it together so I needed to come up with 'good enough' graphics for the game - quick to make but decent enough to be believable. The first thing I did was develop a list of items I needed. These included Santa's sleigh and the reindeer, UFO and jet enemies, houses and terrain, a bitmap font and game icons, menu images, and miscellaneous background images (moon, stars, snow, etc.)

I could have pixeled everything but this time I wanted to try something new. Instead of drawing everything by hand I opened Microsoft Word and started browsing Christmas clip art. In the MS library I found many of the components I needed. I was able to easily browse the vector files and pull the ones I wanted into my painting application (at a large size), edit them, and scale them down to game size.

The best example is the reindeer. I found a nice looking sample in the clip art library and brought it into FireWorks. I needed two animation frames for each of three positions (up, level, and down) and I needed a Rudolph. First I rotated the clip art image into the horizontal position (it was tilted a bit) and edited out the rest of the image using the marquee to delete large sections and the eraser tool for detail work.

Then, I copied the image for my second frame, leaving the first frame as it was. On the second frame I used the marquee to grab and delete the front and hind legs and paste them into rotated positions - to give the impression of galloping. Then I used the eyedropper and paint tools to rejoin the legs so they looked natural. I used the same process to reposition the antlers a bit as well. Then I used the paint tools and dodge/burn tools to edit and shade the sprite to my liking. After that I copied both frames and rotated them to create up and down positions. Finally, I scaled the images down to the size I wanted for the game. For Rudolph I just copied all of the frames and added a single pixel with a glow over the nose of each frame.

The most time-consuming graphics in the game were the houses and terrain. For these I used photos of real houses (collected during that recent house-hunting trip) and edited them to look snowy. The one with the car in the driveway is actually the house my wife and I will be moving into this January :). To do this I scaled all of the images to about twice the size they would be in the game (and scaled them to match each other) then painted over the top of them using progressively lighter shades of grey. For the blank terrain I simply cut trees from various images, scaled them, and made them snowy. I also took care to make sure that all of the house and terrain sprites would tile properly. Finally, I scaled them all down to game size.

While the graphics in Santa Blitz aren't exactly up to commercial game standards they work pretty well for a small competition entry and they were quick to put together. I spent maybe 10-12 hours during the whole process - and the result was not too disappointing. I highly recommend the clip art process to non-artists, just make sure whatever you use is royalty-free to avoid legal issues.

The Audio
Tools Used: Windows Tools, Cool Edit Pro (demo)

There was no audio in Santa Blitz until the day I submitted the game for judging. This was a mistake. I recommend planning and implementing audio in your games from the start. As it was, I was rushed and it wasn't as smooth as it could have been. I don't know much about sound and have very little experience making samples and integrating them into a game engine, but I plan to learn a great deal about it over the next few months. A game without audio (or good) audio is only half as good as it could be.

That said, I'm happy with the way the game's sound turned out. Most of the game audio was drawn from the few megs of samples I've downloaded from the Internet over the past year (all public domain I believe/hope). It was really just a trial and error process. Once I found a sound I wanted to use in a particular location I loaded it into Cool Edit and massaged it until it sounded right. Santa's voice (my father-in-law), sleigh bell loop, and the Whining Dog Games sound logo were all recorded by my wife and edited by me.

One piece of advice is to try to keep your sound files as short as possible - tenths of a second if you can. Longer sounds (besides using more memory) take longer to play back, possibly playing past the end of the event (collision, etc.) which spawned them and taking up channels you may need to play back new events. If you don't want sounds cutting off and spluttering then use short samples. The other piece of advice is to get a good tool if you can. I plan to buy Cool Edit as soon as possible. The day I submitted my entry was the first time I had ever used it but I think I'm hooked for life.

Get into audio - it'll make your good games even better. I was only able to spend about six hours recording, editing, and coding in the audio for Santa Blitz, but I now wish I had invested twelve.

The Code
Tools Used: BlitzBasic, of course (well, Blitz 3D)

Okay, Santa Blitz is not the most complex piece of code I've ever written nor is it the most elegant - but it is the first decently playable and complete game I've ever made. I've finished small projects before but never a well-architected game from start to finish. There's a lot to learn still and I look forward to my next project. The sections below give a look at the major code sections and some notes on what and why.

Note: Some of the samples below are in pseudocode to avoid making this article too long. You can download the actual code below.

Framework
Santa Blitz started with a basic framework and I've learned that this is the best way for me to progress - it gives a skeleton for me to hang bits of my code on and keeps me organized. I don't know if it's the absolute best way but it works for me. Here's a look at the framework.

That's it really. It's very simple and it keeps things organized - at least for me. We'll deal with the key function groups and some other core parts of the code in the following sections

Application Management
I chose to group all of the core application management code in one place. It's kind of nice because if you want need to work with the startup/shutdown code or the menus or other system-level functionality you know to look here. I called the file game.bb and here's a look at the functions it includes:

The game management routines, broken down in this way, let me do things like bump the level from any point in my code. For instance, if the correct number of packages are delivered (as discovered during the update phase) we can call EndLevel() and this will check goals and move us to the next level. Similarly, if we no longer have enough packages to complete the level, calling EndLevel() will remove a life and restart on the same level - or end the game if out of lives.

Game Objects
I used types to hold much of the game data - player objects, snow and star collections, particles for collisions, and so on. The types get declared in the types.bb file, instanced in the vars.bb file, and then initialized in the game.bb file. Initialization essentially creates all of objects with placeholder values - to be filled in when needed. Better object creation and destruction could have been had with a bit more work - but this was at least functional. Below is an example of a game type (snow):

I used an array for this - and I guess I could have just used a collection, but that's the way I started going with it so I stuck with it.

Game Loop
The main game loop is quite simple. First we call Morduun's frame limiter to get a movement factor. Then we draw the screen, get and process user input, and update all of the game objects. The code is below:

Drawing & Updating
Drawing and update functions are each placed in their own file with the main function - DrawScreen and UpdateGame() - at the top. Sub-functions such as DrawSnow() and UpdateSnow() are called by the main function. This breaks up the code for readability and makes it easier to debug - for me, anyway. If I know a certain routine is working then I never have to look at it again. I often write the code in place and then bust it out into its own function later when it's completed.

Conclusion
Designing, architecting, and coding a game (even a small one) is a long and difficult process - too long to discuss fully in a single article - but it's not an impossible mission. This is really my first original start-to-finish game project but completing it has helped build my confidence and I'm ready to face that long list of game ideas I've been avoiding for so long. I hope those of you who have finished games before will keep churning them out and those who haven't will keep at it until you do.

Thanks again to maDenathorn for hosting the competition and to all of the entrants for their games (I'm still trying to beat TheCaffeineKid's game - tough one). Looking forward to the next competition.

- Michael (mearrin69)
You can download the game and full source by clicking HERE (2.3Mb).