Finally, I managed to release my 3d action game “Radial Blitz” on iTunes yesterday. I encountered many obstacles along the way, but am quite happy with the result. In the coming months I will be exploring all the technical details of the game, from the graphics, to the world simulation, to the UI layer. In this article I’ll start with a bit of history and a general overview of the technology used.
Starting with WebGL
The origins of this game lie in a puzzle game I attempted earlier. It was an animated jigsaw puzzle using 3d scenes for the pictures. I was quite happy with the game, but very upset with the technology. I had chosen WebGL and JavaScriptt to produce a web game. The problem is those technologies were extremely slow, and had horrible compatibility across devices. The situation doesn’t actually appear to be much better today.
I didn’t really feel motivated to just port the game to a new platform, but one of the puzzles still appealed to me. It was a flight through an endless tunnel. I enjoyed just watching it and felt there must be a way to get a game out of it. That was the origin of Radial Blitz.
Moving on to Fuse
I wrote an article about my bad experience with JavaScript and WebGL. This article lead to a contact with a startup company in Oslo, Norway, now called Fusetools. I decided I’d try their new technology with my new game.
They offered a C# derived language that integrated 3d drawing and could target multiple devices. Eventually the 3d aspect of the toolset became more of an internal feature as the product became more focused on higher level app development. The changes made for an interesting ride, one where I ended up becoming one of their programmers. I now work on their high-level user interface layer, from layout to animation.
I did a port of the tunnel drawing from the puzzle game and started adding features. I was uncertain at first how the game mechanics would work. I tried many different things. Some were cut from the game, others were changed, and some secondary concepts can still be found in the game now.
I involved play testers once I had a working prototype. This helped me get an idea of what the game should really be like. As the idea solidified I worked more on my own, doing very limited tests with other testers.
Graphics
Originally the game used only procedurally generated objects: mainly the tunnel and the spheres floating in it. I used textures from GameTextures.com to give it a more polished look. Once the tunnel had some nice visuals the little spheres started feeling out-of-place — too simple by comparison.
Since I’d never worked with real 3d models before I thought it’d be a good experience. I wasn’t planning on doing anything too advanced, so decided to try out Blender on my own. The shock of that interface quickly convinced me I’d need somebody with actual experience here. My budget was quite tight, but I managed to find an excellent designer who did several models for the game.
This would also be the first time I produced a real 3d graphics engine. It had an actual pipeline, with various lighting modes and quality settings. Now when I play a AAA game I tend to just sit back and marvel at their graphics. I can truly appreciate how spectacularly difficult it is to produce the visuals they have.
Details coming
A lot of interesting technical challenges came out of this game. I learned many things and would like to share some of that. The game itself may not appeal to everybody, but I think there’s a lot of useful concepts within it worth exploring.
