I spent yesterday doing a whole bunch of things that weren't working on Brixtar. I needed a bit of a break to do important things, like realise that the Mozilla Thunderbird logo is actually a postal delivery bird and not, as I had originally thought, an envelope in a bad punk rocker wig.

Not a wig
Thanks to everyone who has played Brixtar, and thanks again for all the feedback I've got. Part of the reason I need a new journal entry is as another repository for your feedback - multiple pages of comments get weird especially when I post replies due to the unconventional nature of the journal commenting system.

This week my plan is to fix up Brixtar and to improve the underlying game library in preparation for the MAGIC game contest (in only four days time!). Since I'm experimenting with the whole "game in a week" policy it would be a loss if I weren't to join in with a game of my own. Thankfully there's a big overlap between Brixtar fixes and general library improvements.

Here's a list of what I'd like to get done, and a rough guide of the order I need to do it in:

Mac OS X Brixtar Port

I still need to port Brixtar to Mac OS X. I've been porting code regularly between platforms, so I know nearly everything works already. The only code I need to sort out is the Carbon specific functions for specifying where the writable game directory is kept; I'm using Ravuya's PropaneFS code as a basis for this as my Carbon knowledge is basically nil, so I assume it'll work well. I have yet to test it however.

I also need to figure out how to get PhysicsFS to read files within a Mac OS X application file. It's good karma to bundle everything up into a single package for Mac OS X, but unfortunately PhysicsFS seems to by default not read inside the application file. I may need to add in some extra platform specific code to fix this.

Mouse/Joystick Support

A common request is for mouse support for Brixtar, and I agree that it would be a better method for paddle control. I've got stubs in the input module just waiting for me to add in mouse and joystick control. I haven't played around with SDL's mouse and joystick support, but I'm assuming it'll be pretty easy to get running.

Annoying multiball bug in Vista

The report of a hang-up with multiball in Vista troubles me, as I suspect it might be a flaw with the signal code within my architecture. Every ball has its own set of signal connections which are used for timer updates; it needs to record which signals it has connected to so it can disconnect when it is destroyed. However this requires some moderately complex memory management under the hood to store the lists of signals and slots, and I suspect this might be the cause of the hang-up. I've been plagued with memory leaks in this code and I suspect I haven't caught them all.

This might be a lot harder to fix, given that I don't have a copy of Vista to do the tests. I may have to kindly request help from Vista owners to try out different debug version and send me the log files, making this a slow problem to solve. But it'll have to be done if I want to ensure that my game library will work on Vista

Paddle collision and other small gameplay fixes

There's an issue with the ball seeming like it should collide with the paddle but it doesn't. This needs fixing. There's also small problems with timing and powerups that may need fixing too.

Sound effects

I might leave the music for Brixtar, but it does need sound effects. I'll put in some basic beeps for the game, and tie a function key to sound on and off.

Graphics internals overhall

No-one reported this as a bug, but I know the internals of my engine so I know it's there. There's a nasty problem with the creation of sprites in my current graphics architecture; a sprite has what I suspect to be an O(N2) algorithm time for changing the depth. This is due to a naive sorting algorithm being run to position the sprites in the right order in the internal list. At start-up, this translates to O(N3), which is nasty; it's only not a bad problem in Brixtar because there isn't a large number of sprites, but you can see it slowing down the game for a split second if you spawn lots of balls at once.

I'll need to fix this, and at the same time I'd like to try storing the sprites in a vertex buffer object to see if that gives me any rendering speed up. It mightn't have much effect in Brixtar as there's only one texture used, but it may make a difference in more complicated games.

Menu System

Brixtar would be better with a menu. I've got a good menu in the partially completed code for Ice Slider, but the code is very messy and specific to that app. I'd like to make a general module for menus so I can reuse it in all my games, or at least the arcade like ones that I'll be making for the next few months.

Animation System

Finally, if I have the time (and I suspect I won't) I'd like to start working on code to make animated character sprites easy to implement. I've got a very specific style of character that I'd like to use in my games based on a kind of paper doll system; 2D sprites made up of individual components. I've done some simple tests on paper and Inkscape and in the very basic case I think they'd work very well:


Concept art from a yet unnamed Castlevania-style platformer

This is some early experimental concept art for a game idea I had late last year; the characters are in a style that I think would work very well in a lots of my game ideas. Eventually I'd like to use them in a story-based platformer game I've got floating around in my head, but I suspect the style will work in nearly everything I'd like to do.