Asteroids Screenshot

I've had a few emails wondering on the progress of the little Asteroids game. To be honest, there isn't much to see at the moment; there's only a couple scenes: the main menu with instructions on how to play and the game scene where all the action takes place. A hearty thanks goes out to Ari Feldman for creating his SpriteLib graphics. I would hate to think just how bad the visuals of this clone would be without his work.

There's audio including some background music from a great site: Shockwave-Sound. I'm not very good at taking screenshots (at least not interesting ones), and there's a lot I'd like to add to this clone. Actually, each day it turns out to be less and less of a clone as I change the input scheme. In fact, I actually enjoy playing it while programming it - always the mark of something good to come. :-)



If there's one thing that this prototype of a game has done, it's shown the shortcomings of the engine I need to work on, where the engine shines (the actual game itself is very, very little code), and how much of a dream Smalltalk is to work with. I don't think - outside of work - I've even touched C/C++ in about 3 months. I think that, in and of itself, is a testament to just how good and complete Dolphin Smalltalk is.

Next I'll be adding a particle system to the mix and some simple particle emitters. That should add a whole extra layer of visuals to the engine very easily. As for the game, I need a nice starfield moving in the background, some shields still, and currently there's no way to die. The ship doesn't actually collide with the asteroids yet.

I'll post more screenshots later as more features are added. I'm hoping soon to actually have something downloadable for people to try on their machines.

Adding More Functionality

Work has been occupying most of my time of late, but over Christmas I've had some time off and been able to add more support for a few things.

At the end of the day, I very much want to not make use of Microsoft's D3DX library. While it is useful, Microsoft reenabled "DLL hell" with it, meaning that any user of an end-game would need a specific version of the DLL installed on their machine. In order to get rid of this library, I need to implement fonts and textures myself.

For bitmapped fonts, I'm making use of the Bitmap Font Generator. It's very good, and free. Just download it, create some bitmapped fonts with it and away you go. The code is almost exactly the same, and in many ways it's easier. To parse the .FNT file, I'm currently using Vassili's regular expression parser (ported by Chris Uppal). This has a few known issues with Dolphin, but I'm not using it for anything but simple expressions. In the end, I'll actually write my own parser, but for now, it works great.

Some nice benefits to having my own bitmapped font system is being able to calculate width, height, kerning, and render text in a meriad of ways (left, right, centered, boxed, etc), all very easily. It will also be significantly faster once I get batched rendering of quads in place, as right now each letter is rendering a single quad at a time. Inefficient, but very little text is ever actually rendered in a 2D game.

I haven't yet worked out my own texture loading and surface creation, but it's on my list of things to do. Microsoft's D3DX library supports an entire host of image formats. Most likely whatever I do will only support BMP and TGA files, but that's plenty. Perhaps PNG as well, but I don't want to rely on a 3rd party library for image loading.

XACT is a dream on the Xbox 360, but the PC version is behind the 360. This and other frustrations make it less than ideal for my game engine. So, I'm stripping it out. In its place I've been using the BASS Audio Library. It's a simple, and very well written audio library. It's shareware, and I'm sure many users of my engine won't want to purchase it, but it is free to use in non-commercial applications.

As for my previous post on the resource management, I've been putting together my prototype game for the engine (an Asteroids clone) and it was obvious very quickly that the current method of resource management would not scale at all; I knew that from the start, but I was hoping it would scale a little, but now it's apparent that it doesn't.

Tejon had a good idea, though, that I built on a little. I think there are a few kinks to work out still, but overall it's pretty good. In the GameResource class is a class instance variable that holds all the resources that have been loaded of that type. There is a class method #get: that will return the resource if it's already been loaded, or load it fresh and add it to the lookup table for that class.

It's definitely a lot more scaleable (as it's very much like every other resource system in existence). The kinks that need worked through? Currently each resource type's load method is #load:usingLocator:. I'd rather not pass the #get: method a FileLocator as well. My current solution is to set a locator in the GameEngine that all resources will use. So far I like this a lot. But what about resources that will be loaded from packfiles or memory? In theory I could create a subclass of FileLocator that searches packfiles for a resource (at least this is my current thinking). I need to think on this some more.

More to come soon...