iDevGames

Win-Win Game Development

Experience is the difference between a project taking months or days. With the first version of the engine finished, it was time to make a game with real gameplay. I had spent years learning the mechanics of game architecture without going past a simple game like Pong. At around the same time I had created the Java game engine I was working part-time in television production. One of the projects was a hockey related mascot animation. This project fell through and went very wrong. It was one of those things that seem right at the time but was not meant to be.

With a significant number of the 3D models already created and some of the animation already done, it made sense to salvage this project and turn it into a game. Using animals eliminates the sexism and racial problems that often occur in modern games so this was a win-win situation for me. The animation was improved and set outdoors and a polar bear was made to accompany the elk. The intro was animated and rendered. At this point it was around summer 2003, and I had created the basic treatment for the game that would become WildLands Hockey. Things were stating to take shape: all the final goals were planned and documented. Gameplay was fleshed out along with look and feel.

Gameplay Design

The second version of my engine, which now included network support, was completed a month before the uDevGames Contest deadline, along with a simple Pong game. Thus, the final stage of game design and development for WildLands Hockey began. Game character graphics were created with animated cycles for the skating elk and head turns for the bear. The idea was to keep this game small as my web space was rapidly being used up.

Some size experimentation was done with the characters and puck to see what looked and felt right. The character graphics were rendered in Lightwave 3D with a sprite plug-in. The time clock and game timer were first, then the goalies were added and their motion created, which would simulate inertia and momentum. They only move on one axis and their motion was the basis for all the other character motion. The goalie motion was later changed to be based on the player motion. This simplified things and allowed for less data to be transmitted in a network game. With the goalie done it was on to the puck. At this point I decided to start with the in-game sound design as I would be in those locations of the code. So, puck related sounds were edited and prepped. Various sample rates were used to get the best sound and size ratio; as most of the sounds were low quality it was somewhat of a challenge to get them to sound halfway decent.

If you do not know much about the importance of sound then take a tip from those in film. Sound is essential — people tolerate bad picture but not bad sound. Do the best with what you have but never skimp on sound. The great sound on the C64 and Amiga is part of what makes these systems so legendary. The sound systems in my first and second engines were also spatial and velocity based. This further enhances player experience by simulating the audio environment. Fast actions trigger louder sounds, and sounds play through stereo speakers on the side of the screen where they occur.

The puck actions were mapped temporarily to the keyboard to create and fine tune its motion boundaries and reaction in the game. Interactions with the boards, goalie, and net were finished along with most of the gameplay states. This made sense here as the puck is the focal point of the game. Its actions drive the states.

With the puck completed, the players were last. I approached this with multi-player in mind initially, as I wanted to triage the seemingly more complex parts first so that the 2004 contest would not be missed. Player motion was designed and implemented first, then player interaction with the boards and other places on the rink. Puck and player interaction was done, then stick and puck interaction. I spent a good portion of time making all these simple details work the way I felt they should. I wanted it to feel right. These simple little details combine into the complex gameplay that can either be fun and interesting or tedious and boring. Later beta testing with complete strangers would determine if I had something worth playing. Shooting was then added, and lastly player-to-player collision.

With the multi-player game completed, the client server network game state system from version two of the engine was updated, adjusted, and tested to work with WildLands Hockey. The nice part about code reuse is that not only do you avoid the tedium of doing something over but you know that it will work. The network gameplay required some minor adjustment and went quite smoothly. It is not perfect but some things were just beyond my capabilities.

What Went Right

Text communication

Given the need to communicate with text and numbers, fonts and localization can be an issue when your game is meant for worldwide distribution. A system was required to handle generating and displaying text in the game. In keeping with the sports theme a matrix system was designed. This allowed me to program text and numerals on the fly and display them without having to worry about fonts, cross-platform text or other languages. The matrix system is based on the kind you see at a hockey arena (or used to). I had spent two years in TV working at hockey games so I had more than enough time to study this and create my own version. I even put in crawls and scrolls like you see in the credits screen.

Intro animation

Experimentations began as to what codec would provide the best quality and least amount of size with full screen playback ability on most systems. Animation can really suffer from the wrong kind of compression — all of the beautiful time-consuming details can be wiped out or blurred beyond comprehension with the wrong compressor or settings. After much experimentation QuickTime H261 (similar to MPEG1) was used, as it was the best for all requirements.

Beta testing and adjustments

I called on friends, family and whoever to get the network and other alpha testing done. Some minor tweaks and bug fixes later, I submitted it to the REALbasic games list for beta testing. The general consensus was that the game was way too hard to play. One of the developers on the list informed me that developers usually find their own games too easy to play. He said you should make the game far too easy for yourself to make it accessible for your perspective players. I took this advice and made the AI easier but also adjustable to keep it harder for advanced players. I also made the players skate faster and their sticks bigger to make getting the puck easier. With some other issues fixed and time running out things were not perfect but I was pleased with them. There comes a point when you need to just release your art, as it is never really done. Also, while the input of beta testers is invaluable you probably will not be able to get all the requests in. The best is to compromise on those large changes that may not be feasible.

What Went Wrong

Major architecture change required

Before starting the original development, I went out for lunch with a friend and former coworker who is also a programmer. His background is in networks and security, mostly on Unix. When I told him about the game I going to do he asked if I was going to have a network multi-player mode. Up to this point I never even thought about something like that. I had never done network programming before, even though I was a network admin in my time in the IT work force, and knew what it was all about. Out of ignorance I said I would make things multi-player over the network — how hard could it be right?! With his network programming background and some of his help I could get up to speed and do what needed to be done fairly quickly. This was early Fall 2003, when it became apparent that a version two of the engine would need to be created for full network game play. The game would not be completed for the uDevGames 2003 Contest. I had more than enough experience as a programmer working on large projects to know this. I had not entered yet so it was not a problem; things could wait until next year.

Impossible architecture

The sprite surface control in REALbasic was not designed for network multi play. In fact some said that creating a real-time 2D network game like this just could not be done. I was already too far into it to listen to that — it had to work. I came up with a multi-threaded model that would work around this. However, in order for things to work across all platforms I needed to use an experimental version of REALbasic. At this time Real Software was redoing the whole thread model across REALbasic. This, along with some other issues and projects that needed to be finished, placed my second version of the engine and WildLands Hockey on the back burner for some months, until the newer version allowed me to finish it.

Lack of resources for network multiplayer design

If game programming is a black art then network game development is a 33rd degree black art shrouded in the deepest of mysteries. Finding information on it proved to be very hard. Most books simply show you how to set up a socket and send packets back and forth. Network game development is so much more than that. I got help from Aaron on the network communication system, which is an extended UDP socket that would fulfill all the communication requirements for a game. The work developing an interface menu and internal game system to connect two hosts was also a big job. There was much to think about. My solution was to look at other games and pick what I liked and what was also simple and feasible for a person with small resources. At this time my head was really starting to hurt with all the intricacies of network game design; single local game design really looked very simple now in comparison.

In late summer of 2004 everything was ready with the new version of REALbasic and so was I. It was back to version two of the engine to create at least a basic working network engine for 2D games. The latest version of REALbasic also had the bonus of a remote debugger, making things much easier. I looked at all the resources I could on network game design and what I could not find was done by trial and error. By the end of September 2004 I had a working network game that was like Pong running in version two of the engine. Network connection, sync, packet loss, lag, prediction and all the other network related issues I had faced were mostly solved. I placed this engine on the web with its complete docs and a basic network game programming theory paper I wrote, in the hopes that it may be useful to someone else facing the huge proposition of creating a network real-time game. In retrospect if I had known the work involved I may have never tried this. Ignorance is probably responsible for more things out there that we could imagine.

Audio

The sound designer dropped out with no work completed. This is to be expected when your project does not pay and paying work comes in. I decided to do the sound design myself. This is why there are no sound design credits and some gaps where the sound designer credits were to be. I spent a great deal of time scouring the web and elsewhere for free and royalty-free sound effects. I managed to get an adequate selection of lower to medium quality sound effects that would suffice for the game and intro.

Player pixel level collision

Pixel level collision was too sensitive for player-to-player collision and felt wrong. I came up with a distance-based system that makes the game player interaction less touchy and more real.

AI and game play design

The AI for single player mode was the last thing to be created. AI is not my cup of tea and some design flaws reared their ugly heads. I had spent so much time on the multi-player mode that not much forethought went in to the single player mode. I was able to crank something out with a few kludges that was actually better than I had expected it to be but far from perfect.

Late feature additions and polish issues.

With the audio designer dropping out my work load became much greater than I had planned. Thus some of the polish suffered. I was not able to get an in-game user controls section and it was a late add in the start up screen. As well I never had the time to make a better user guide in the game, or at least an HTML file, as opposed to just text.

Reflecting on Game and Contest

The WildLands Hockey project was a big learning experience that put all my skills and years of experience to the test. I wanted to finish a commercial grade game (circa 1990) before I hit 30. I didn’t quite make it, though I was close. Many of the game’s features and design were made for me. I wanted to make things the way I would like them to be. There are such things as cool features not getting in the way of the game. So many games are created with glitz first, but to me the worst of all is making it so real it gets in the way of the gameplay. Some examples of this are the game intro. Sure I worked really hard on this, but it will only play the first time the game is played; after that you must select it from the menu. An intro is cool the first few times, but after fifty it can get irritating when you just want to play. Mine also has a click to allow you to exit it. This common courtesy I feel goes a long way to providing an environment that a player will want to return to.

WildLands Hockey is client server based; each frame in the gameplay is stored in a state that can be transmitted in a packet for network play. This same design can allow for replays very easily. While this is a cool real feature I felt it just hinders gameplay. I worked for two years in TV for a local hockey team and most of that time I ran VTR and did replays so I am sympathetic to this cause. However, while real players and officials need that time, computers and computer players do not, so it can appear to just get in the way especially when the game is only three minutes stop time. You don’t want to spend more time on extras than on gameplay. If people want reality then they can get their skates on instead of playing my game. I feel game developers need to offer their players more fun than reality.

I hope the simplicity of this game will appeal to people even where hockey is not played — this is one chance you take when your game may have a more regional appeal. I certainly learned a lot about myself and game development on this project. Somewhere along the way this project did become work. It is something I am proud of and something bigger than myself that I can leave behind for others. Who knows, maybe this game will some day end up in a Mac or PC emulator similar to the C64 collection I have that reminds me of the many of hours of entertainment I had back in the 80’s and provides inspiration for today.

Conclusion

After being around since the VIC-20 and working in IT, including networks, database admin, and as a member of a few large and small development teams, I have seen a lot over the past many years. I’m beginning to feel like a dinosaur. I’m losing interest in much of modern computing as I look back on the golden age with increasing fondness. This was probably obvious as my game was not much different than what you would have found in an arcade many years ago. In all this time I have never even tried any 3D programming due to a lack of interest, but as that is where it all seems to be going I’ll either have to get with it or do something else. I may eventually do more games and maybe salvage my Java engine to the mobile world, but who knows what the future holds. For years I have wanted to finish a larger game project and now that it is completed it is a bittersweet accomplishment. Some of the magic is lost once the mystery is gone.

• Developer: Kevin Dromereski
• Genre: Arcade
• Team Members: 1
• Development Tools: REALbasic, MBS plug-in
• Animation & Graphics: Lightwave 3D 7.5, Photoshop
• Video & Sound: Sony Vegas, Digital Media Workshop, SoundEdit
• Hardware: 12” iBook G3 800MHz, Custom-built Dual 1.8GHz PC (Windows XP)

Nevertheless, I did succeed in making a fun racing game. Hopefully this postmortem will shed some light on the development process, what went right and what went wrong.

Tools

I used many tools to create BitRacer. For programming I used Xcode to program Objective-C, C++ and Python, making use of FTGL, FreeType, ODE, and OpenAL. To create the user interface I used Interface Builder. To create the 3D graphics I used Blender and Wings3D. To create the 2D graphics I used my own drawing program, as yet unnamed. To edit sounds I used Cacophony by Richard Bannister.

What Went Right

Polish

One of my aims was to make BitRacer immediately and easily playable, and I think I achieved what I set out to do. I used most of the last week of development time during uDevGames to work on the polish of my game. That is, the menus, options, help files and all that is peripheral to the gameplay. Spending this time on polish was a good decision, for polishing a game takes longer than you think. Now, having done so, I can really appreciate the difference it makes.

You never fully realize how important polish is until it is done. Often it seems inefficient to waste time on menus or help files, when you could spend valuable time on gameplay. Especially when you realize that polish takes far longer and it is not so fun. Yet when people play your game, few bother to read the read-me, or check the help, they just play it. If it doesn’t work or is unintuitive, they don’t have time.

An unpolished game will, simply by virtue of being unpolished, score lower when users rate it in all the other categories, and visa-versa. The link is stark when you look at the uDevGames 2003 results; the top three best overall games are identical to the top three games for polish. In identical order! Possibly it is the way in which people rate games in terms of irritation instead of enjoyment.

UI and IB

A more technical aspect of polish: Apple has a superb Interface Builder (IB) that is very easy to use. Every Cocoa programmer will use it for almost all aspects of their interfaces. But it is limited to the rather un-gamelike blue of Aqua.

One of the best technical ideas in BitRacer was the use of IB to create my interface using OpenGL. In Quartz Apple has a superbly powerful compositing engine, and it allows a developer to simply interweave OpenGL contexts, pictures and standard user interface controls. I used this to allow me to graphically put together my interfaces whilst also using OpenGL to provide a classier look and feel.

SCREENSHOT HERE

In the screen-shot above you can see how I used graphics and text as standard Cocoa objects, while at the same time using my own OpenGL menu items. I used the tool-tip field in Interface Builder to create text, buttons, checkboxes and radio buttons.

Retro Graphics

Or just half-baked graphics? Indeed, I was both criticized and applauded for my graphics. Unfortunately, I could not avoid the use of cuboids due to the physics, and so I spent many hours racking my brain, asking myself “How can you make a bunch of plain cubes look good?” I did not initially want to use retro graphics, however they were a good solution. Looking back, I now like them much more, the solid color against the dark background is a striking and different look. I like the way it gives BitRacer a distinguishable look, and their Tron-eqsue feel.

The Blender Track Editor

Initially I created levels that hard-coded into the code, but after that became implausible I used a text data file. However, neither of these methods came close to providing the ability to create decent 3D tracks. Again I was constrained by the physics. Instead of being able to use a 3D program to create sweeping curves, banks and rolls, I had to use imagination to create fun levels out of cuboids. No 3D program was going to let me export a list of cubes, who wants to model with cubes, right?

Fortunately I knew about Blender, a powerful free 3D program. One of Blender’s many attributes is its use of Python to allow scripts to access and alter its scenes and objects. I could use a script to output my cuboid information based on the objects in Blender. After hacking around I was able to use Blender to create 3D tracks out of cubes. I could now create and edit tracks in 3D, and using more of Blender’s abilities, I was able to position a tree of waypoints and checkpoints for the AI to race around.

What Went Wrong

ODE (Open Dynamics Engine)

Physics is extremely hard to get right. I have written my own physics engines, notably the one behind SillyBalls. For BitRacer I decided it would be better to use a “real” physics engine, for which the only genuine option for free use on the Mac is ODE.

Using ODE and creating physics took up a vast amount of time whist working on BitRacer. The myriad of interdependent variables and options are extremely confusing. For example, I would change the geometry slightly and the steering would also change!

That aside, ODE worked great, except that it provides few robust collision primitives. This meant that although I could construct objects from arbitrary meshes, the collisions with the meshes were very temperamental. Cuboids were the sole useful collision primitive that I could successfully get to work, the result of which is my use of only cuboids. I did not foresee this constraint—initially putting together ODE was deceptively easy.

Unfortunately this constraint molded almost every aspect of the game. It forced me to think of alternative solutions, like using Blender for generating tracks or a Tron like look. While these solutions weren’t necessarily bad they were very time consuming.

The racer is a good example of the problems I had from using ODE. Many people complained that it stuck on walls or bounced oddly. Above you can see what the racer really looks like for collisions.

Bug Testing

I own a dual PowerMac G4 450MHz computer, and had assumed this would be a good baseline; “If it works well for me then it should work well for everyone else,” was what I thought. Of course my clever use of multithreading and buffered physics worked beautifully, for me.

It wasn’t until I tested it on the last day of the competition that I realized my folly. Single processor machines had thread timing issues—BitRacer would run like treacle because the physics thread was starved of CPU processing. I then scrambled for the next three days into the voting period to make it playable even on a single PowerMac G5 2GHz. Oh foolish me, to ever underestimate the need for testing.

Distractions

Ah yes. The weeks off doing this or that, having to spend most of my time at work. Oh the wasted time, I should have spent every waking moment working on BitRacer!

Conclusion

There are many things done and many more things remaining. After the intensity of uDevGames, like most entrants, it is time for a break. I am very happy with how BitRacer turned out; leaving it as a learning resource makes it worthwhile as is.

However, excluding the ever-present possibility of BitRacer 2, I am planning to make at least a multiplayer update to BitRacer, with hopefully LAN play. I realize, yet again, that these are big goals, but it would be fun.

• Genre:
• Developer:
• Url:
• Team size: 1
• Released date:
• Project length:
• Development hardware:
• Critical applications:

Bio

Will Thimbleby has been writing Mac games since Tracktor Beam. Since then he was a runner up in uDevGames 2001 with SillyBalls. In real life he is a PhD student working on fancy calculators, and programs MacSword, a bible study program, in his spare time.

Drunk with this new-found power, I made the rather sudden (even, perhaps, presumptuous) move to enter uDevGames 2003. Excitedly I began to think up ideas, draw graphics, and make music simultaneously, and with no real order or plan. This was probably my first mistake. In the grand scheme of things, I hoped to create a platform game I had an idea for a while ago.

Because I had no real experience or reference to anything at all, I was just making things up and improving as I went along. If you have the patience, then this kind of self-taught approach to learning how to make games is probably the best path for a beginner. The way I see it, if you base everything you do on your own first impulses and ideas, you are virtually guaranteed to have a somewhat original game. And then you can go back and improve upon bits and pieces that need tidying up. That was my basic philosophy for making Druid. Too bad I never got around to the tidying up part. :)

Music Creation

Oddly enough, Druid’s music was not only the first thing I started doing, and the thing I ended up most happy with, but also the only thing I used a PC for; the music was done completely with FruityLoops on Windows 98. (Lucky me, I get the music producer with a professional recording studio in his backyard for a dad. Boy did I take advantage of that!)

I had a reasonable amount of experience with music-making already, and I put it to use. I really tried to give each music track a distinct “feel,” so that you could recognize which tile set it belonged to automatically. You can make a catchy tune, but if it doesn’t have instruments and a melody to fit the environment of the game, it’s wasted in my opinion.

So, I tried to pick instruments and sound effects which suited each environment. For the Forest music track, I used a sample of a female singer, slowed it down, and voilà , instant Druidical hum. I used a lot of tribal-sounding drums and other instruments, and tried to keep it reasonably simple. I think the end result for that piece was quite good; it had a nice feel to it while remaining not too overpowering or attention-grabbing (it is, after all, background music). I followed a similar pattern for the other two sound tracks, using quasi-environmental instruments, and using excessive Fruity filters to get that echo-y, cave-like sound for the Cave track (which I believe only appears on one level).

The music creation wasn’t really coordinated with the rest of the project. I basically just worked on it when coding and drawing graphics was getting boring. Even so, I think it suits the style of the individual levels quite well and did a lot to help the overall feel of the game.

Graphic Creation

All the level graphics and sprites were done with AppleWorks 6, which I find invaluable for such hand-drawn pixel graphics. For the characters I did on the main menu (which aren’t really that good, I just needed something to put in the menu background) I used Flash 5, then did finishing touches (fire on the arrow of the red Druid, etc.) with Photoshop 6.

Like my code, my graphics drawing was really a learn-as-I-go experience. It took me ages to start off—I tried to draw a decent-looking rock about 20 times before it looked okay. I drew a lot of inspiration for my graphics by playing some good old Atari ST platform games, with cute-looking, excessively colorful graphics. After some experimentation, I was onto the right train of thought, which was basically drawing the outlines of objects, filling them in with a solid color, then subtly shading around the edges. I think it gave the game a cute, quasi-cartoony appearance, which was what I was after.

Animation I find to be the trickiest part of drawing graphics. After a lot of experimentation, I ended up drawing the animation of the Druid running in Flash 5, by overlaying each image as semitransparent layer, then using that as a guide for drawing each individual frame in AppleWorks. I’m not sure if this is the best method, though. I would really like to learn a bit more about animation.

Of course, drawing decent graphics by hand took me a long time, and I was quickly running out of time and patience. So, unfortunately, I began to get lazy, and ended up merely changing the color of the sky and tinting in order to create differing tile sets, and I only ended up making one Druid sprite.

Coding

I of course began Druid with very little knowledge of programming, and because of this the basis for my game was highly unstructured. Druid was built on this rather unstable foundation, and suffered greatly in terms of speed and stability. It also made it very difficult to expand and customize, so in a way it also slowed down the project and damaged polish.

Now that I have proper knowledge of how programming operates and how a game should be written, I will not make the same mistakes again when I re-write Druid from scratch, nor if I make another game.

Ideally, for next year’s competition I’d like to team up with someone who knows a good deal about programming with something like Cocoa, and then just make game assets (graphics and music). There is only so much that you can physically do in the time limit. I really doubt I could develop a good code in something other than TNT Basic and still make quality graphics and sound within those time restrictions.

What Went Right

Music & Graphics

I’m really happy with the music I made for the game. I think that it gave Druid a really good environmental feel. However, it did considerably add to the file size (about 6MB).

Likewise, I think I did quite well in terms of graphics for a first shot. Several people have commented that they like the colorful world and cute Druids.

Weather Effects

Weather Effects gave my game a much-needed depth and feel for environment. Although I desperately wanted to make animated levels and parallax scrolling, this was not possible at a decent speed with TNT Basic. Without the weather effects, the levels would have simply been a completely flat plain.

TNT Basic

TNT Basic allowed me to create a reasonable game with virtually no experience, in two months! This is something I don’t think many other (if any) game-building apps for Mac can do, at least not with that level of ease.

What Went Wrong

Speed

The speed of Druid is really terrible. It usually only goes at about 10-15 FPS on my Power Mac G4 (it does run a bit faster in Mac OS 9 and with weather effects off). This is largely due to my poorly-structured, inefficient code, but it also has to do with TNT Basic’s restrictions in terms of the number of sprites on-screen.

Polish

Druid didn’t turn out particularly polished at all. I’m embarrassed at my horrid, pointless renditions of Druidical characters on the main menu, people have complained that the menu system is awful (and it is), and the randomly-flashing text impossible to see. This is largely due to the fact that Druid was only half-finished when the due date arrived for uDevGames 2003. When I re-write it, I vow to keep polish and overall interface smoothness firmly in mind.

TNT Basic

TNT Basic, while being remarkably powerful considering its ease of use, does have its restrictions. I’m particularly disappointed at being unable to do parallax scrolling or animated levels, as I mentioned earlier.

Conclusion

Overall, I’m very pleased with my first attempt at serious game-making, especially the game assets (graphics and music).

Participating in uDevGames couldn’t have been a more interesting and rewarding experience. It gave me an incentive to learn programming and graphics very quickly, which I did. And I even ended up coming in 4th for originality, and winning prizes!

Working with TNT Basic was also a good move. It introduced me to programming very quickly and easily, and let me program a basic game quickly enough for me to still have time to make graphics and music.

I’m very much looking forward to uDevGames 2004. I intend to use proper art tools and techniques to hopefully produce a more visually stunning title next year. And with my experience in programming, I won’t make the same coding mistakes again, for a faster, more stable game, with more polish. It will also leave more time for improving the game and assets, instead of spending most of my time learning what to do by trial-and-error.

I’m going to continue working on Druid, of course. I’ll finally finish the game I originally intended it to be…

• Developer: Miles de la Hunty
• Genre: Platform
• Site:
• Team Size: 1
• Project Length: 4.5 months
• Development Hardware: Power Mac G4, Windows 98 PC
• Critical Applications: TNT Basic, AppleWorks 6, FruityLoops 4 (PC)

I even went out and bought a book on Greek Mythology to help me better understand the nature of my game. I also imported the Japanese version of Ikaruga for my Dreamcast. This was essentially my design document. I tried to stay true to as many elements of it as possible—minus the whole 3D background thing going on, though it was considered in the initial phase.

The Tools

Coding

My choice of IDE was Apple’s Xcode. Once again, a wonderful environment to work in. And combined with my powerhouse of a Dual 2GHz G5, I was able to compile my source over and over again in mere seconds. This is great for fixing things up and recompiling.

Game Assets

I used Painter 8 to paint the background images, a most wonderful program. I also borrowed my dad’s graphics tablet. The first level is done entirely in charcoal except the water, which is oil painting. It is such a natural tool, almost as easy and a lot more powerful than traditional media. For those interested in what is to come next, I will touch up the ending of level one, and start doing level two entirely in thick oils.

Contrary to popular belief, all the entities in Icarus are in fact models. Most of them are 3D models and all of them are done in LightWave 7. While it is not the easiest tool in the world, once you get over the learning curve, it is amazing what you can do. Also, while using it for this project I learned a lot of new things you can do in it.

What Went Right

Leveraging Source Code

The project weighed in at 7,000 lines of base code. When thinking about my idea and what I wanted to do fresh off of Microbian: Fighter, I knew I wanted to do an Ikaruga clone, and since I couldn’t get a hand on Unity at that time, I knew I had HUGE stockpile of already done code. Basing off the Microbian: Fighter engine gave me the following things:

• Robust collision detection
• Completed physics
• Advanced particle system
• Color-based system (this actually stems all the way back to the BOB2 days)
• Resource handling

Right from the start I didn’t have to worry about adding all those standard features needed in almost every game. I could focus on what needed to get done. Of course I was going from a universe type game to a vertical scroller. This allowed me to make many optimizations to speed things up. I also needed to get some solid texturing code in there, and that is where Holmes Futrell was a life saver. I borrowed his GLTexture class and this made it a cinch to load textures and apply them as needed. Overall, I got to work mostly on my content and less on just making it work.

Working with a Professional Musician

Miyaka Cochrane is a wonderful musician. His most notable music comes from Raptor — Air Superiority Fighter and Argonaut 2149. He also created over 20 minutes of music for Microbian: Fighter. I appreciate him very much for donating his musical talent to Icarus. He is also planning on doing two more songs specifically for Icarus after the contest is over.

High-quality 3D Models

I don’t know how Lee did all the models for Microbian: Fighter. Somehow he managed to color all those models using his little text-based applications. That blows my mind. I personally couldn’t do it—I’m a much more visual person. I like my GUIs and mouse so I added a vertex painting ability to my standard model viewing application, and with the click of a button, I was able to color my model in bright vivid colors with little to no effort. While the painter isn’t perfect, it was possibly the only way I could get any models done. Let this be a note: custom built tools are unmatched in productivity.

What Went Wrong

Distractions of the Ancients

I chose a lousy time to get addicted to a game. Roughly three days after I decided to enter uDevGames, my friend James introduced me to a new map/gameplay style in Warcraft 3 called Defense of the Ancient. This game ended up consuming 1-2 hours a night throughout the entire contest. In fact I was playing it right before I started writing this postmortem! Beware other developers: they will try to suck up your time with great games.

Poor Time Management

Not only was this newfound addiction taking up my time, I was also still in school. I was in a compiler class, which also required a good deal of programming. Writing multiple thousand line programs for different causes can really tear your brain in so many ways. There was much more stress than what is really healthy. Not only this, but I often fell into procrastination. I would postpone working on my compilers project until the last three days it was due, and this caused me to lose three solid days of work instead of only losing two hours a day over two weeks. Time management is something every developer needs to learn. All of this leads to the biggest thing that went wrong.

It was way too short!

The thing can be beaten in about 65 seconds if you are good. My original plan was for about three minutes of solid gameplay. The main reason this fell through was because I hand painted the levels. Offloading that work to an artist could have significantly reduced the workload. But as it was, I was painting the level, especially the town area, and just did not have the time to do good work and have a lengthy level done in three months. Not only did it take a long time to do my background in the style that I chose, I also found out that many gamers found this new style strange and not common in traditional games, so the graphics were not well accepted. I feel if I had more time, I could have provided more details and thus make it more liked.

Issues with Audio

The final explosion was nearly impossible to tune. In my design document, Ikaruga, the final boss exploding was supposed to bring the framerate to about 10fps. I found this near impossible to precisely gauge. Being on a G5 is a blessing and a curse for game developers.

The Future

In my ReadMe I made a promise to my fans that I would complete this game if I won a spot in uDevGames. Things that I will be adding include the nuclear homing special weapon, as per my design document, and another level or two, each between 4-5 minutes in length. Also, I plan on adding at least two more bad guys, one more boss, and of course, more patterns and evil chaining schemes. I will not be making this game shareware, because I feel by winning in uDevGames, I have received enough payment to continue releasing this game as freeware.

• Developer: Brian Ramagli
• Title Artist: Jill Hogno
• Genre: Vertical Shoot’em-up
• Site: www.hkasoftware.com
• Team Size: 1
• Release Date: November, 06, 2004
• Project Length: 2 Months and 3 weeks
• Development Hardware: Dual 2GHz G5 (1.5GB RAM, Radeon 9600)
• Critical Applications: Xcode, Lightwave, Painter

Project Aims

To avoid comparison with the big Pro Evolution Soccer or FIFA series, I wanted my game to be strongly arcade. I also wanted to develop a game that both a child and an adult could find fun to play.

Design

At the beginning the design was very poor. Of course, I produced a lot of ideas for the game, but I knew that developing even a simple soccer game in three months would be very hard for me. Consequently, I decided to first develop a simple game and then add additional features as time permitted. So I simply designed an objects tree, thinking of the C++ classes I would have used and keeping the game concept in my mind.

What Went Right

Math

Coding a 3D game usually requires a lot of math, trigonometry and physics formulas, and Feathered Soccer made no exception. Moving the ball realistically, moving characters, and checking collisions are some examples of where math is essential in this project. However, I love this subject, and when I started coding I had just completed a first year Computer Science course at college that included one physics and two math exams, so producing the needed formulas wasn’t a big problem.

Happy Coding

Even if I had to fight against some bad technical bugs during this project, they didn’t take much time to discover and fix. Their presence was due mainly to the little time I had to complete the project. Because of this, and of course because of being a big (and bad) programmer sloth, my code isn’t very good in regards to maintenance. However I had the code clear in my mind at every stage of the project, so I could fix the bugs with little pain.

Using Strong Tools and APIs

It could seem an obvious thing, but it’s not: choosing strong and proven tools like Xcode and strong and proven APIs like OpenGL and SDL really helped my development. You can of course use and be fascinated by a new tool, however it’s not a good thing if, having only three months to develop a game, you also have to beta-test the tools you use.

What Went Wrong

Artificial Intelligence

Well, I’m coding a soccer game and everything’s going fine, so where is the tricky part? That part is Artificial Intelligence (AI). It took me a long time to produce a not-so-stupid AI and I found the teammates’ AI expecially difficult. When the player controls a character, all the other characters of his team should move in a meaningful way. The first experiment I made resulted in very unintelligent AI. It was clear to me that I had underestimated the problem. So I spent a lot of time on this, thinking of a better solution, playing other soccer games and, at coding time, using a try-and-fix approach. In the end it seems that because of a fear of making AI that was too easy, I made AI that, according to user feedback, is too difficult. So the moral of the story is “In medio stat virtus,” as the Romans used to say, which means, “Virtue stands in the middle.”

Sound

I added sound at the end of the project, which means I had very little time to find and implement it. I was in trouble trying to find some good royalty-free sound effects and background music so I decided to buy a copy of iLife ’04 and produce my own music with GarageBand. Then I found some nice effects and bought them. There were also some problems from a technical point of view. I tried to use SDL_mixer to add sound, but for some reason, probably due mainly to me, I wasn’t successful in doing this in even a simple way. Because time was running out, I decided to go platform-specific for this contest and I encapsulated some Cocoa code into my C++. I found the Apple documentation on this topic very clear. Then I noticed that the game slowed down while playing a sound effect, so I modified my Cocoa code to be multithreaded. Finally everything worked and I am very proud of my encapsulated Cocoa code. I will, of course, have to change it if I decide to port the game to other platforms.

Fighting Against Time: Mid-Project Changes

One of the worst enemies in this project was time, so there are a lot of features I would like to add which are not present in the current (1.0) version of the game. Choosing what to implement and what leave for later versions was very hard. I tried to think of what is really necessary in an arcade 3D soccer game and what is not. I only wanted my game to be polished and fun to play, even if this would have meant the lack of some features. I list here some of the features I didn’t implement.

• No bonuses — If you played the game, you may have noticed that tackles aren’t punished and that, even if the game has a strong arcade/cartoon inspiration, it hasn’t any kind of hyper-speed or other bonuses, which would have also changed the gameplay experience positively.
• No two-player game
• No configurable options
• No replay
• More teams and competitions

Of course this is only a small selection of the things I didn’t add because of time.

Risk Management

Choosing the API and the Game to Develop

Even though I had experience with 2D games, considering that I had never developed a 3D game before, choosing OpenGL as the main API was a brave decision and a big risk. However I really wanted to do something I would find fun and a 3D soccer game fit the bill. In real life, with a boss who wants a good game developed in three months, I would probably take another route.

Conclusion

One thing I learned from the development of this game is that I should pick a project that is possible for me to complete in the given time with less pain. However, it’s also important for a person to pick a project which he/she likes and enjoys developing. As a matter of fact, I also had a confirmation of human will power: I really wanted to have something playable for November 6th and I had it. If I could suggest something to a person who wants to conduct a big project I would say this: choose something you really like and trust yourself.

• Critical applications: Xcode, GraphicConverter X, GarageBand, Cinema 4D CE, Art of Illusion, The Logo Creator 3
• Development hardware: PowerBook G4 867MHz (384MB RAM)
• Url: www.bluepixysw.com/
• APIs: SDL 1.2.7, OpenGL, Cocoa (only for sound)
• Project length: 3 months

Snowball had a dual purpose. First, it was meant to be a successful entry in uDevGames 2004 in order to win recognition in a wider arena than just my peers. Second, it was meant as a proof of concept for an isometric engine for future game development. The intended customer for Snowball was the average voter attracted to uDevGames.

Details

Schedule

The scheduled development timeline included having a basic foundational engine in place by September 10th. This was to take advantage of a two-week break from my teaching job. After that I planned to begin beta testing and add features and stages weekly until November 6th. In reality, the basic engine wasn’t in place until October 19th, more than a month late.

Source Code

The source code consisted of 2,220 lines of code used from my previous projects and 10,138 new lines of code. In addition, the following libraries were utilized: SDL, SDL_mixer, OpenGL, libPNG, and zlib.

Compatibility

The finished application bundle is roughly 3.3MB in size and should be compatible with Apple computers running Mac OS X 10.0. It requires a video card with at least 8MB VRAM (like an ATI Rage 128) and a G3 500 MHz processor or better. The only known compatibility issues are with the Windows version of the game and have to do with resolution switching.

Tools

The primary development tool used was Apple’s Xcode 1.5. For the PC version, DevC++ 4.9.8 was used. Corel’s Painter 8.1 and Adobe’s Photoshop CS were used for creating content along with an Intuos 2 Wacom Tablet. Apple’s GarageBand was used for composing the music.

Credits

The writer of this postmortem, Aaron Sullivan, designed and programmed the game. Amy Sullivan, his wife, constructed the in-game stages and recorded sound effects. Sean Sullivan, his brother, composed the music.

Of note were contributions from outside this team including Eric Wing and Josh Abernathy, who helped test and fix an important bug in SDL involving mouse coordinates.

Carlos Camacho and the staff at iDevGames provided the contest under much duress and Snowball would not have been created without the motivation of this particular contest. Feedback from several members of iDevGames’ forum was also of great benefit as was feedback from family and friends and voters that took the time to reply by email.

What Went Right

Origin

Before uDevGames 2004, I contemplated creating a computer role-playing game (CRPG) and I decided on an isometric view in order to capitalize on having rich illustrated artwork rather than stale jaggy 3D models. As the beginning of the contest approached, I realized that a CRPG was a far too ambitious project to complete in three months, but I could develop a part of the larger CRPG game with a smaller entry. The isometric graphics engine now became the focus.

I had used OpenGL to develop two 2D games: an unfinished uDevGames 2004 entry, Bugganauts, and Space Barrage, my first finished game in decades. I had never used OpenGL for its more common purpose, a 3D game. I had a quick tech demonstration that I worked on as a proof of concept, but now I needed an idea for a small game using the isometric view.

The choice was between a 3D version of Bugganauts, involving lots of alien shooting and hostage rescuing, or a cutesy puzzle game like an old favorite of mine, Adventures of Lolo. Well, I was really leaning towards Bugganauts, until I thought that I could maybe make the small game into a part of the larger CRPG. The setting for the CRPG was to be a snow covered world. I thought about snowballs and a puzzle game and how you could use the ball rolling up snow and enlarging. I had never seen this in a game before and that spark of originality sold me on it.

Graphics

The basic premise for the game was simple, and I expected that most of the work would be in creating the graphics engine. This was okay, because that was one of the two primary goals. I despise aliasing (jagged edges rendered on the edges of objects, especially prevalent in 3D games) and after great success with using glAArg¹ to polish Space Barrage, I became somewhat obsessed with removing as much aliasing as possible from this game. While this took time from other aspects of the game, I learned the most from this part of the development.

Spending so much time on the graphics delayed my beta testing by more than a month, however! I include this under “what went right” because I waited till very near the deadline (a day or two?) to reveal Space Barrage. Even a month late is a big improvement over my last attempt.

Workflow

I had a reasonably efficient workflow that included posting updates for whoever would read my blogs at uDevGames and visit my personal web site about progress on Snowball. I made an effort to keep these updates from becoming a distraction.

I kept the web page very simple with an easy process for adding screen shots. I had a couple of long winded blogs, but I used them as a way to process what was going right and wrong and to think through what the next goal needed to be. It kept me accountable to a public audience (even if it was just an illusionary one) that would know if I was sticking to the goals rather than going off on a time consuming tangent.

STL

I finally embraced the STL (C++‘s Standard Template Library.) I made it a point in Space Barrage to simply avoid dynamic memory all together in order to sidestep time consuming memory leaks, because I knew I could easily derail in such a short time span. In this project, I dug into the STL. One investment I made was buying the book ‘Accelerated C++’ by Koenig and Moo. I highly recommend it to beginning programmers and anyone who isn’t acquainted with using the STL and likes to use sample code and tutorials.

At first I found using some of the STL conventions cumbersome, feeling a bit like wading through Java-type convolutions to perform simple actions. After working with it a bit, I learned to really enjoy the peace of mind that comes from avoiding the responsibility of plugging memory leaks. I didn’t get in too deep, really, just some vectors, strings, and maps, but I’ll never look back.

Code Reuse

Reusing some code from Space Barrage and the unfinished Bugganauts gave me a boost at the start. I relied on SDL for window and graphics setup and a custom PNG texture loader that I think is mostly code by Keith Bauer (a.k.a. One Sad Cookie). I used code I had set up for music and sounds (though the sound effects never made it in) that relied on SDL_mixer.

Cross-platform

Using these cross-platform libraries made the port to Windows very easy. I’ve found that developing on two platforms really helps refine your code. One platform catches some errors that the other might not.

What Went Wrong

Time

The obvious and probably most common problem in software development is difficulty predicting the length of time parts of a project require. This is especially true for inexperienced programmers. When one has never programmed a 3D game, how is one to estimate the length of time it will take to complete a 3D game engine? One guesses.

Design Document

My work schedule was very full at the start of the contest, but I anticipated a two week break and worked on a design document and engine ideas in the spare moments in between teaching classes. I carried a growing stack of papers covered in cartoon sketches, schematics, and formulas. I never took the time to formally compile it into a design document and although you’d think that was a bad thing, it wasn’t that bad.

From working on Space Barrage for the 21 Day Later Contest I knew that a tight schedule meant I’d be keeping it mulling around in my brain at all times anyway. I did eventually keep a list of tasks to complete as I approached the end. So, for a longer term project, especially one with more than one programmer, I would say that not having a detailed design document was something that went very wrong. For this short term project, however, my stack of papers was enough for this single programmer to stay reasonably on track.

Schedule

That said, my schedule went way off track. I was determined to get a playable out to the public as soon as possible to avoid the problems I had with Space Barrage, but I released it a month late.

I had time to clearly identify the areas that needed to be improved in order for the game to do well in the contest, but I ran out of time to implement the changes. Some of the problems identified were:

• The WASD keyboard controls were just right for some, but unnatural for others. Custom keyboard options were needed.
• One unexpected discovery is that some players found the learning curve too easy and gave up before it became challenging.
• Mouse control was something I didn’t plan until I realized there was a simple and effective way to implement it. The mouse control made it much easier for inexperienced gamers to play compared to the keyboard control, but led to some confusion as well.
• People were much more inclined to play through if they knew the total number of stages but the game never gives them a hint.
• Everyone wanted a way to continue if they stopped playing and came back to the game later.
• Snowball’s music soothed some and got on the nerves of others as it constantly repeated for hours with no interruption, if you played that long.

Bugs

There was a serious bug discovered when running on Mac OS X 10.2 that inverted the mouse coordinates read by the game. It happened in the middle of the voting, so anyone with that OS version would not be able to play. As a quick remedy I forced the game to start in full screen mode where the bug did not appear. This bothers many in the Mac community, but my hope is that it enabled more people to play. Several days of correspondence led to fixing the bug in SDL that was causing the problem.

Windows PC

Because Sean, my music composer, had issues with getting his PC hardware/software working correctly I had to deal with the possibility that he’d be unable to provide a soundtrack. I spent time with Amy composing some music in GarageBand. It was temporary and would need much more refining before release. Fortunately, Sean agreed to work at our office and used GarageBand to create some excellent original compositions in a matter of three days near the deadline.

Time Again

Overall, I spent too much time making sure I fulfilled the one goal of creating a new graphics engine and too little time making sure I fulfilled the goal of doing well in the contest. If I had compromised on some graphics issues, I very well might have had time to add more game features, get more early feedback and fix many of the interface and user experience issues.

Mid-project Changes

In the last three weeks or so it became apparent that many of the planned obstacles and game mechanics couldn’t be added in time. This was disappointing, but focusing on the various techniques involving the ice blocks turned out to give enough game play variety to satisfy the expected length for a small contest game.

In fact, I was very pleased that just one element could be stretched so far and it helped me to accept that this project was worth continuing beyond the contest.

Conclusions

Fun

Overall, I’m satisfied with the state of the game that was completed during the voting period. Because I delegated stage design to my wife, there was plenty of content for players to explore even if the amount of variety was low. The team members had fun working on it and I know that many people had fun playing it.

Some things that I learned

1. A game’s difficulty curve is one of the most important ways to keep a player playing. If the target audience has a wide range of skill levels, there had better be options that allow them to play how they want right away. I had comments that there was no challenge to the game or that there were far too many “easy” stages. In smoothing out the difficulty curve and forcing people to play through the “learning” stages I had turned off the less casual gamers.
2. Players want to know how far away the conclusion (or the next goal) is. Players who did not know the number of stages either gave up, or lost interest early on. As soon as I told players the number of stages, they would play to the end.
3. I can’t stand aliasing. Many casual gamers have not learned to ignore aliasing and I’ve even heard one person say, “Did you see all the rats?” referring to the crawling pixels on an aliased line. The amount of work and time I had to invest to help remove “the rats,” however, seemed to be worth it. I still get a big reaction from many players when they rotate the stage for the first time. Many simply expect it to stay flat because of the style of the imagery.
4. Sound effects make a big difference with people’s response to the music and the game overall. There are sound effects recorded for Snowball but getting them in the game was one of those tasks that kept sliding off the priority list. The impact of the player’s actions and the level of immersion felt by the player is greatly reduced in this soundless game compared to, say, Space Barrage. Also, there are comments from players about loving the music, but many could not stand the unbroken repetition of the single track during game play, no matter how good the music might be.

Conclusion

Snowball was meant to be a contest winner and an engine test for another game. In part it has succeeded but I’ve really grown to believe that Rollo the Snowball has a much bigger exciting life ahead of him.

My plan is to bring this game to a commercial level of development. In the coming months, I’ll be using all the brilliant feedback from the participants in this contest and taking the time to add all the fun features that were so painful to cut from this abbreviated version. This time, the goal will be to finish a game worthy of a player’s hard earned cash.

¹ Developed by arekkusu

• Genre: Puzzle
• Developer: Aaron Sullivan
• Url: http://homepage.mac.com/aaronsullivan/projects/snowball.html
• Team size: 3
• Released date: October 19, 2004
• Project length: 4 months
• Development hardware: Powermac G4 Dual 1GHz, Wacom tablet
• Critical applications: XCode, Adobe Photoshop, Garageband

The Gravediggers Toolshed
h4. Coding Tools
We use Runtime Revolution to build the user interface for our iGame3D game-making software. The engine with the scripting language, OpenGL drawing, etc., is linked to RR via the plugin “iGame3D Pro external” that we are developing. We spent most of the time in this app arranging levels, making models and writing the scripts. Here is a screenshot of the Revolution/iGame3D working environment in action:

However, we did not use CodeWarrior to build the game itself. We are using it to develop both the Mac OS X and Windows versions of the iGame3D plugin and the Windows version of the iGame3D Player.

The source code for the Mac OS X version of the iGame3D Player was done in XCode. The Dead Days application is a special version of our iGame3D Player. This needs some explanation: games in the iGame3D engine are actually written in our custom scripting language inside the Runtime Revolution environment with the plugin. The iGame3D Player application can run these games. Just copy the game files into the player application package and the game is done. It would have been enough to just release the game code (written in our cryptic scripting language) since that’s what actually makes up the game, but it wouldn’t be very useful to anyone. So we decided to release the source code of the player application itself! The source code for Dead Days is nearly the same as the original iGame3D Player source code. It has some little changes for licensing reasons. Check out the ReadMe that comes with the source code for more information about this.

The simple text editor that comes with Mac OS X was used to create the ReadMe files for the game and the source code. Smultron was used for text operations like “Find and replace” on the game scripts.
h4. Game Assets
We used Sound Studio to record and edit the zombie growls and screams. By the way, those have been pitched down, these are not our natural voices. The background music for the training level was played on a keyboard and recorded with Sound Studio. The sounds came in through an eMac’s built-in microphone. We edited some royalty-free sound effects from the web in Sound Studio as well, like the gun shot and the punch.

We made the background music tracks, except for the one in the training level, in Apple’s GarageBand using some of the built-in loops and our own melodies. QuickTime Pro was used to convert the sounds into an AIFF format that Ogg Drop X could handle correctly. iTunes was used to convert the music to MP3. To compress the huge AIFF audio files into the OGG Vorbis format we used Ogg Drop X.

GraphicConverter was used to convert images into the PNG format. We also created the alpha channels for some images in it. We used Photoshop to do lots of the textures, and images. We used Cinema 4D to reduce the number of polys on the zombie model. The original zombie model was created a year ago in Lightwave by the multi-talented Charles Goran.
h3. Tripping up in the Valley of Shadow
Obviously entering the contest only a few days before the deadline made the process a real rush. We did not have time to test the game on many machines so there was some bug-fixing during the public voting period. There were also issues with the camera that we did not notice until players brought the problem to our attention.

We mistakenly assumed that Mac OS X 10.3 “Panther” was already the standard Mac operating system, especially with the OpenGL updates and bug fixes that shipped with it last summer. Almost immediately after releasing the game we received requests from people who wanted to play “Dead Days” on Mac OS X 10.2.x. After some re-coding and testing about two days into the voting period the game was built to be compatible with Mac OS X 10.2.x.

The newer version of “Dead Days” also had trouble for nearly the whole voting period due to an issue of using the .sit archive format. Certain versions of the StuffIt Expander corrupted the application package on some gamers’ machines, causing it not to run at all. With six days of the public voting left we released the game again using Panther’s .zip format which seemed to fix the startup issues.

Getting adequate feedback was almost as tough as making the game itself. We had about a thousand downloads before the first complaint came in and about three thousand downloads before we received feedback that actually pointed us in a possible direction to fixing the problem.

In the tunnel vision rush to make a playable game some of the essential non-game elements get overlooked. We did not expect the public to go looking for an “Options” screen to change the keyboard settings, screen resolution and mouse sensitivity. We also didn’t think they would skip the training level and proceed to mash every key on the keyboard trying to figure out the game. These instances revealed a missing link in our engine that we surely need to work on. Our custom scripting language allows us to check the state of specified keys, but changing these keys would require a change in the script files which are neatly hidden inside the application bundle. An easier way to configure the keyboard controls and changing the screen resolution in the game is now high on the to-do list.

The current iGame3D editor, which is still in production, has not been tested to see if it could efficiently make a game from the ground up. Several bugs or cumbersome user interface actions in the editor also cost us some time in the rush to complete the game.
h3. Return of The Living Dev
The eight to nine days and nights that “Dead Days” was in development, Tobi finally had absolutely no other obligations to tend to. Life was reduced to game development, food and a little bit of sleep. Bill managed to tear himself away from iGame3D development, survive each day of child care and pull through the graveyard shift until dawn to edit the levels and add textures.

The goal of iGame3D finally proved itself for us, we didn’t have to start coding from scratch. For “Dead Days” the only C coding neccessary was the fixing of bugs that the development of this game revealed in the iGame3D engine. With very few quick fixes to the source we were then allowed to concentrate on the creation of the actual content and gameplay.

We benefit from the fact that we have already been working together on iGame3D and related projects for nearly three years. We are well aware of each other’s abilities and use this knowledge to efficiently delegate responsibilities, to prevent production pipeline bottlenecks.

Because of different time zones, it is common that we meet up on the internet and discuss plans, changes, and production just before one of us passes out. Although some problems arise from this, for “Dead Days” it acted to our advantange in that when either of us woke up there were always cool new textures, levels, models, and music to check out. The iGame3D Team worked like a twenty-four hour assembly line.

The process of creating a game was an intense test for the iGame3D engine and its user interface. The process revealed some bugs and showed us which parts are functioning well already and which parts still need work.
h3. Reflections in the Wisdom Pool
It was an honor to have taken part in this unique contest. Once again uDevGames openly challenged us to create and release a game to the Macintosh gaming community. It’s great to have uDevGames as an annual event and we hope that it continues successfully for many years. In our opinion, everyone who was able to create a game in this 3 months is a winner. After this contest the team will continue their work on the iGame3D engine and application. The success of this year’s entry is a confirmation for us that iGame3D is going to succeed and sets our expectations that much higher for what comes next.
h3. Le culte des Ghoules
h4. Tobias Opfermann
This 20 year old German programmer started towards a career in game development when he began to create his first applications with the card-based programming environment Hypercard in 1996. With that he produced a tool for the Mac Game “Damage Incorporated” (Marathon engine) that helped in making levels, which in turn was used to produce a custom add-on scenario called “Year of the Tiger” in 1999, together with other fans of Damage Incorporated.

After this, the C language in CodeWarrior 5 was where he experimented with very simple database programming and later a freeware OpenTransport chat application called “P.I.N.C.”

Using REALbasic he introduced the world to the “Oni Savegame Editor” in 2000. This program was widely used among Oni game fans, gained a feature story on the German TV station NBC Giga, and continues to receive positive feeback from Oni players four years later.
h4. “GL Thrill”
After the migration to Mac OS X in early 2001 he entered his first game into that year’s uDevGames contest. The contest provided a challenging call to step up his experience of game development and he found much to learn at the iDevGames forum. Stepping ahead of his background in HyperCard, MetaCard and RealBasic, Tobi’s 3D first person shooter, “GL Thrill,” placed eighth in that year’s contest using C and OpenGL.

In 2004 Tobi graduated high school and has since split his time giving back to his community, both at his employment in a care home and with his personal dedication to the iGame3D project.
h4. William Griffin
What smells like New Jersey and makes games? You have to a sense of humor if you are going to make games with Bill Griffin. This 34-year-old New Jersey father of one quotes himself as saying, “Writing about myself in the third person is freaky.” That’s the kind of guy he is.

After a combination of 13 years toiling in the graphic arts, entertainment, video and tech support industries, Bill came to the conclusion that he had taken his two years of community college as far as it seemed likely to go. Those years of clocking infinite over-time gave him the opportunity to attend the annual design technologies exhibition SIGGRAPH on three occassions and to take two excursions to E3, the annual Electronic Entertainment Expo, looking for a door into the world of game design.

Bill recalls one of these high tech events with an embarassed grin, “I spilled beer all over my pants at the Apple/Newtek boat party, damn!” The 2001 E3 event, however, is especially remembered for a very encouraging conversation with an important games marketing manager from a big name company that left Bill Griffin convinced that it was time to put away the old things and to take up his lifelong goal of being a game developer.
h3. Team iGame3D
In early 2002 Tobi posted a demo of the game engine he was producing with the skills he had cultivated while making “GL Thrill.” Bill responded to this by offering his willingness to take on whatever non-programming job was necessary to make a game happen in this engine, and a game design team was born.

That spring and summer they used the engine to create a level builder and player called “T3DEdit.” Thirty-five custom scripting commands that were needed to produce a first person strategic target shooter with exploding ants were added to the engine during the uDevGames 2002 three month development cycle.

With most of their time focused on creating a tool that would continue to be relevant in the future, attention afforded to the absolute needs of making an amazing game capable of winning the contest was sacrificed and their entry “Antack” placed sixteenth in a very competitive uDevgames that year. Much to their surprise “Antack” would attract over eighty thousand people to download the game within the next twelve months.

By the time that winter came to a close, Bill had used the “T3DEdit” application that was created for making Antack to explore several dozen directions of the engine’s abilities. First Antack evolved into a space combat simulation, then there was a castle building routine, which was followed by testing a 3D clone of the Tank level in the 1984 game TRON, there was a vampire rampage, a famous space tunnel run screen saver, the iGame3D dancing groupie screen saver, a test for tic tac toe, another for pong, a coin platformer example, survival horror concept, a ‘shoot down the 3D flying saucers’ design tutorial and an early concept for a racing game. These were among dozens of test levels that came out of the early editor.

The code and knowledge gained from making “Antack” was taken to the next logical step feature after feature to build the foundation for the 3D OpenGL game design environment that is now “iGame3D.”

Spring of 2003 brought that name change, removal of some parts of the scripting language, and a switch to Metacard, a powerful card-based development environment which finally gave Bill the ability to turn his ideas for iGame3D into living tools. Summer brought the last sad Macworld to Manhattan, where by pure luck Bill met Kevin Miller, President/Owner of Runtime Revolution, the company that had just acquired Metacard a week or two earlier. With iBook in hand and the very limited alpha version of iGame3D, Bill gave his first software engineering demonstration to a corporate executive.

Bill confesses, “It was ugly as sin, it had bugs, and I was having the time of my life making it.” Purchasing a Revolution license meant being free of the 10 line restrictions limiting the first Metacard Demo-based version of iGame3D. Bill set himself to the task of learning the transcript language by jumping head first into creating a full featured interface for a complex application based on external engine programming by Tobias Opfermann, that listed support for particles, several standard 3D formats for import and export, polygon drawing tools and commands, an expansion from an original 35 to 125 script commands, and a screen saver stand-alone, among its many abilities.

For the length of uDevgames 2003 Bill was lounging around the iDevGames internet chat room, between moments of developer inspiration and burn out, and found that sharing the creative process on an up-to-the-minute basis with nearly two dozen game developers was much less stressful and much more educational than focusing all his attentions on one game in the competition against them. At the end of that year’s contest Bill was the proud interface programmer of a fully operational iGame3D beta version with nine demo levels to present to the world.

Then Tobi sent him a barely functional example of a new version of the application with the plan: “Let’s make a new interface, one that is so easy people don’t need to read any documentation.”

A year later finds the team working on their sixth user interface revision for iGame3D, which has taken bold steps away from its dependance on using models from Meshwork and is now hosting its very own 3D format with self-contained animations, material shader properties, and bones, as well as other tricks up its file structure. Their 3D third person action adventure game “Dead Days” showcases the abilities of the new models along with improved OpenGL lighting, the addition of particle effects, and the effectiveness of the 3D modeler built into the engine. The team hopes that a version of iGame3D suitable for general public use will be ready at the end of Winter.

* Runtime Revolution with iGame3D Pro external
* Metrowerks CodeWarrior 8
* Apple Xcode 1.2
* Sound Studio 2.1.1
* Apple GarageBand
* Apple QuickTime 6
* Apple iTunes
* Ogg Drop X
* Apple TextEdit
* GraphicConverter
* PhotoShop
* Cinema 4D
* Smultron

My interest in space games dates back many years, when I played Elite for countless hours on a Sinclair Spectrum. In later years, I found myself enthralled by Frontier, the ‘sequel’ to Elite, and the vastly underrated plot-led combat sim Warhead. Both of those games more or less typify how I expect a space game to work: convincing physics, true 3D and immersive environments.

The thing that brought these old gaming memories back was a recent remake of Elite written by Giles Williams, the punningly-named Oolite. As much as I liked Giles’ game, I really wanted to see a space sim with more graphical realism and a sort of crude, industrial look. Also, where many space games revel in high-tech heads-up displays, I wanted to place the player directly in the cockpit, looking around at the clunky hardware as well as out at the stars.

I’m always reluctant to exactly copy existing games, so I began to think of ways to make my game stand out as I laid down the design for the gameplay. I decided that it would be most interesting to shy away from the usual ‘dogfights in space’ gameplay and go for something a little more unusual: a more passive kind of gameplay where you have to rescue asteroid miners from certain doom. No guns, no shields, just a chunky industrial space tug, a set of mining tools, and your flying skills to keep you alive. Having settled upon this cursory design, I began coding.

What Went Right

Starting from Scratch

One of the first decisions I made was to drop almost all the code I had ever written before. I had wanted to take this step for quite a while because I had become weary of working with the same rotten old code, which I first started writing several years ago. I used this code to make Super Phoenix and Yoink, and it works adequately as far as it goes, but it has deep seated design problems that I’ll probably never manage to eliminate. By starting afresh, I hoped that I would be able to create a clean, focused basis upon which to work, and that would help me to make a better game.

I also wanted to try several technologies which were new to me. My earlier games are still compatible with Mac OS 9, using the CFM runtime and the Carbon API. For Rescue, I thought I’d go a step further and build a Mac OS X only Mach-O game for the first time.

Using Standard Libraries

Having disposed of my own source code resources, I decided to replace it by utilising as much freely available, widely used source code as possible. I mainly wanted to avoid reinventing the wheel, but I also hoped to learn some new skills and techniques by delving into other people’s code.

I chose SDL as the foundation of my application. It has a good track record, it’s popular and as a bonus it’s abundantly cross platform. SDL also has an extensive selection of standard (and not-so-standard) additional libraries, and I picked two of the best respected – SDL_image and SDL_mixer – to handle image file loading and sound, respectively.

For my math and physics code, I decided to try WildMagic, a huge and rather complex C++ library. WildMagic had a large number of features which I didn’t really want to use, such as a built-in scene graph and an application framework similar to GLUT, but I was able to use the functionality I wanted (vectors, quaternions, matrices, intersections and so on) without picking up too much unwanted overhead.

I needed a way of loading 3D models, something which I haven’t even thought about since the last time I used QuickDraw3D. Because I had no experience in writing my own model loader, I decided to use the OBJ format loader written by Karl Berg, another member of the iDevGames’ forum. I found his loader particularly interesting because the example program supplied with it showed a spaceship model with attractive specular highlights and an illumination map.

For other data files, I decided to use TinyXML, a simple but effective XML library written in C++. I used it in the creation of my uDevGames 2003 entry, Yoink, so I was already satisfied that it was the right tool for the job.

Optimization

I wanted to make an infinitely large, densely populated asteroid field with a large visibility range. This was going to cause obvious problems in terms of the frame rate, so I had to use some tricks to keep things moving quickly.

I used simple cubic space partitioning to control the culling of invisible objects. Partitions which are outside the camera frustum are not drawn. I had considered using octrees instead of plain partitions, but I decided that it would be too complicated and not necessarily much faster. However, I did go on to use an octree routine to lay out asteroids in space partitions in a way which prevented two rocks from overlapping.

In addition to this, I needed to cull objects by distance. I was only able to render about a hundred asteroids before things started to get too slow, but this meant that either my visual range was very short or the asteroid field had to be very sparse. I dealt with this by reducing distant rocks to a silhouetted polygon on a billboard, and using fog and careful scaling to make the level-of-detail pop less noticeable. It wasn’t clever, but it allowed me to display several hundred asteroids instead of just a few.

Elsewhere, I used very few optimizations. Apart from having to make some minor changes to WildMagic to get a big speed increase, I didn’t do anything much to make things efficient, so the game wasn’t very fast or smooth on slower computers. Machines with old graphics cards such as the ATI Rage 128 were almost bearable, but most people weren’t able to tolerate the game at such a low frame rate, so I necessarily cut a lot of users with lesser machines out of my potential audience.

Teamwork

When I embarked upon the development of Rescue, two weeks after the start of the contest, I was really only using the contest as a chance to experiment in a formal setting. I didn’t even sign up for a several weeks. However, out of the blue I was contacted by a freelance musician, Mikko Tarmia. He said that he had seen Rescue and wanted to write music for the game. I was flattered that he liked what I had done and I really liked the sample pieces of music he showed me, so I was very keen to ask him to contribute.

It then struck me that my little game experiment was now much more serious. It wasn’t just my effort and reputation on the line, but Mikko’s too, so I felt that there was no way I could afford to let him down by slacking on my part of the deal. From that point, no matter what happened, I was determined that I would do my best to reach the end of the contest without quitting.

Later in the contest, I realized that, while I had nice spaceship and asteroid models, as well as pretty star and nebula textures, I was going to have a hard time adding textures to the 3D models. My modelling software, form-Z, is rather good at low-poly modelling, but is lacking in features for manual UV mapping. I could also see that I was going to be pushed for time if I concentrated too much on making textures. Having already formed a small team, I was much less reluctant to ask for extra help than I had been on previous projects. With this in mind, I asked my old friend Brian Smith, a skilled graphic designer and 3D model maker, to join the team and work on the textures.

I had never developed a game as part of a team before so all of this was a whole new experience for me. I’m pleased to say that I found the whole collaborative working process very smooth and easy to deal with. My teammates were both very professional and delivered high quality work right on time, and they were thankfully tolerant of my requests for changes and criticism! Mikko and Brian wrote their own accounts of their parts in the project, which you can read below.

What Went Wrong

Too ambitious

As was the case with Yoink in uDevGames 2003, I found that the game I had designed was much more complex and time consuming than I had imagined. I still find it difficult to perceive how long things will take at early stages of the project.

My failure to devise a schedule and stick to it meant that many features had to be omitted from the game, so much so that the resulting gameplay was nothing like what I originally envisaged. I had planned to make Rescue a much more innovative game, in which stealth and lateral thinking were your only weapons against a much more powerful enemy. Among some of the features I had to omit:

• Giant enemy battleships which would patrol the asteroids looking for mining installations to destroy. This would have been quite a significant part of the programming work, as it’s very difficult to make an effective AI which is fun to interact with. I expect that developing the AI would have required a lot of tweaking to get things just right.
• Tools such as limpet mines which could be deployed from the player’s ship to distract or delay the enemy. Also, I wanted the player’s ship to be able to pick up objects with its robot arm and carry them around. I mainly omitted these features not because they were difficult, but because they would have served no purpose without an enemy to defend against.
• A mothership which would drop the player off at the beginning of each stage and pick them up at the end. It would loiter in the background and act as a drop-off point for evacuated miners. I was very disappointed to have to leave the mothership out of the game, but Brian and myself agreed that there wasn’t enough time to build and texture another detailed spaceship model. In the end, I resorted to having the player accelerate into hyperspace instead, and this was at least an unusual approach to this particular sci-fi cliche.
• The most ambitious thing I had to omit was the planned character interaction and plot. I wanted to have a co-pilot character sitting in the other seat of the cockpit, and this animated character would act as in-game help, telling the player what to do next and explaining how to perform certain tasks. Beyond that, I had imagined that I could have a storyline played out in animated 3D cutscenes, using the same characters. Unfortunately, all of this had to go because it was the lowest priority of all. However, I wish I had been able to add some kind of in-game help in the absence of the co-pilot, since many players clearly had difficulty understanding how to dock the ship and how to get into hyperspace.

Scheduling

Another problem in common with last year’s project was the proper scheduling of the development process. I don’t particularly like to work to a fixed timeline, so I spent my first two months producing code and game assets with no regard to the deadline.

Much of the work was comparatively easy and quick to produce, since I had already written similar code for my other games. For example the time-based animation system and simple scene graph were quite elementary and didn’t take long at all. On the other hand, several essential elements ballooned out of control and ate up significant chunks of the development time and my patience. The collision detection system was an especially major source of wasted time.

I also spent a whole week doing nothing but trying to redesign the cockpit model. I had an existing cockpit model which appeared in early versions of the game, but I wanted to replace it with one that was much more immersive and full of equipment. This became a huge source of stress and annoyance because I simply could not get the result I had in my mind. In the end I had to compromise and revert to the version of the model which was closest to my original intent.

Collision Detection was Problematic

I chose to write my own collision detection system from the ground up instead of using a library such as ODE. This seems odd with hindsight, as I was trying to utilize third party code as much as possible, but I suppose I was afraid of its complexity. I have since discovered more about ODE through the experience of other developers, and it seems that it is indeed fraught with tricky problems. Maybe I made the right decision for that moment in time.

I designed a rather complex but crude mechanism which utilised WildMagic’s intersection routines to handle interactions between primitive spheres and capsules, groups of primitives, and rays. It took about two or three weeks to write because I kept deciding that I had made design mistakes and refactoring it. Even after all that hard work it still didn’t work properly, and many of the features were never used in the finished game because they weren’t reliable.

As it stands, my collision detection system is still too crude for my liking, and this shows in various places. For example, the requirement that all objects must be capsules forced all of the asteroids and buildings to be roughly capsule shaped. Unfortunately, you can sometimes still see weaknesses in the system when you get close to irregular objects while looking at the external view. This code will all need replacing in some future version.

A Lack of Refinement

While I managed to make good headway into the technical issues of making the asteroid field limitless and the spaceship fly the way I wanted, I didn’t pay enough attention to the little niceties that gamers expect. The title, end of level and game over screens are extremely lightweight in their presentation. There’s no in-game menu; everything is just ‘press a key to continue’ (and it doesn’t even tell you to do that!). Also, there are no in-game preferences and there’s no way of redefining the controls. I did manage to have an editable XML preferences file, but that’s probably too technical for ordinary gamers.

As I expected, I’ve had quite a lot of feedback asking for redefinable controls, so I have put this on my to-do list. Of course, I don’t intend that the game will continue to have a horrible in-game GUI — I shall also deal with this in time.

I did have a little success with the manual I wrote. The final version of the manual was illustrated and had detailed instructions to help novice pilots figure out how to land and escape into hyperspace. I know that many people won’t read the manual, but I’ve had positive feedback from those that did, so I’m happy that it wasn’t a waste of time.

Working with the Limitation of Other People’s Code

There were several occasions when I was forced to deal with problems that were not of my own making, but which came instead from the way the various libraries and other incorporated code worked.

The first thing which hampered my progress was a strange bug in CodeWarrior 8.3 which prevented SDL_image and SDL_mixer from being linked to my application. A little research revealed that the problem was caused by the underscore in the libraries’ names. I dealt with this quite easily by making my own versions which were renamed to remove the underscore.

The only thing which concerned me about this modification was compliance with the license. Since the SDL libraries were released under the LGPL, I didn’t want to fall afoul of the license’s rather complex wording. My modifications were extremely minor, so I simply asked Sam Lantinga, the author of both libraries, for permission to make the changes without getting embroiled in the licensing concerns. Much to my relief he gave his permission!

WildMagic also needed modifications, although it was less worrying to me because its license permits almost any modifications. The problem was that the programmer had inexplicably decided to use the memcpy() function as a means of implementing copy constructors and assignment operators for almost every class. For frequently used types like vectors and quaternions, the overhead of calling memcpy() all the time was substantial and showed up as a large blip in Shark profiles. At the time, I felt that Rescue wasn’t running fast enough on slower computers, so I tackled this by simply commenting out several of the most commonly used constructors and assignment operators and rebuilding the library. This increased the speed of the game by no less than 30 percent, so in the long run this was a great benefit!

Karl Berg’s OBJ loader was the other component that I changed, and again it was helpful that his license amounted to the freedom to make any changes. In its original state it was only able to support BMP textures and didn’t look for texture and material files in sensible places. I addressed these issues by adding support for SDL_image and adding a function to return the application bundle’s resources folder.

At some point I would like to make some more radical changes to Karl’s code. His coding style, essentially C with classes, doesn’t really marry well with my own, and there are some outstanding bugs I’d like to fix. I plan to strip down his code to the bare parsing routine and build it back up in a way which is more suitable for my purposes. I’d especially like to add features which allow code to examine the model geometry, as this would be useful for collision detection.

Last Minute Damage Control!

I saw this coming but I somehow didn’t manage to avoid it: I reached the uDevGames submission deadline and I still didn’t have any gameplay to speak of. You could fly the ship around, pick up miners and hyperspace to the next level, but there was no threat and nothing to force you to take any risks, so if you were a careful driver you’d be able to play the game forever.

About three hours before the deadline I took the drastic step of adding a simple time limit. This was something I really didn’t want to do because it made Rescue seem very similar to Asteroid Rally, Matt Diamond’s game from uDevGames 2003! At this late stage I saw it as the only way to turn my basic spaceship flight simulator into something like a proper game. Thankfully, it only took me a few minutes to implement the time limit itself and the ‘out of time’ game over screen. Once in place, the time limit did indeed have the desired effect, and it was now necessary for the player to rush from one mining installation to another to complete later levels in time, putting their ship at risk in the process. After a little tweaking of the difficulty level, I finally reached a stage where my game was fun and exciting for me to play, not just mildly interesting! Satisfied that the game was now just about acceptable, I packaged it up and submitted it just one hour before the deadline.

Tools

I used the Metrowerks CodeWarrior 8.3 IDE to write and build the game. However, in an attempt to make the source code more accessible to the community I’ve since made an Xcode project as well. This was a useful learning experience in itself!

The spaceship exterior and interior models, as well as the buildings and some of the asteroids, were built using form-Z, a highly accurate and complex modelling package I use for my commercial visualisation work.

Brian used Cinema 4D for UV mapping and texturing the models, as well as making some additional asteroids.

Carrara 3 was used to make the stars and sun. I had hoped to make better use of Carrara since it was one of the prizes I won in last year’s contest, but as it turned out I wasn’t able to learn its polygon modelling feature set in time to do something useful with it. I used Photoshop CS to make the font and various other graphics, while Brian used Photoshop 7 to work on the textures.

For audio, I used Reason, another prize won in uDevGames 2003, just once to make the first sound effect! Had Mikko not come on board to make the music and the rest of the sound effects I would have had an opportunity to put it to better use. Never mind, Yoink still needs music!

Summary

Now that that the contest is over, I can clearly see that I made many of the same mistakes as last year. I devised a game idea which appeared at first glance to be concise and manageable, but which with hindsight couldn’t possibly have fitted into the three month development period. Maybe if I had unlimited amounts of free time it might be possible, but when I have to fit all this hard work around a full time job and other obligations and interests, it’s can’t be done.

Still, even though the resultant game didn’t match my original vision, I’ve benefited in several ways. I’ve learnt a lot about several very interesting APIs. I’m now very interested in using the SDL libraries and WildMagic in future projects.

I’ve worked as part of a development team. I’m used to teamwork in my day job, but it’s a bit of a breakthrough for me to be able to share my personal creative work with other people. It has been enlightening to work with other people’s opinions and contributions in mind.

My objective of making a reasonably complete space game engine has finally been achieved. I (and others) can now build upon this project to make more sophisticated games. I now have another partly finished project to hang up on my web page!

Where shall I take Rescue now? I plan to add all of the features I was forced to omit before I go any further. Replacing my home-cooked physics with ODE, renovating the OBJ loader to suit my needs, building the enemy ship models, putting them into the game and giving them AI — all of those things are achievable now that the deadline has passed and I’m free to work at my own pace. It seems that Mikko and Brian are both interested in seeing the project completed, so it looks like I’ll be working hard on Rescue for the next few months.

Neil Carter

www.nether.org.uk

Making the Music and Sound

Mikko the Musician

I almost cancelled my intention to participate in this contest because I had a great deal of work with other projects going on. But then a big project was cancelled and I had some time again. I found Rescue, which is sort of a slow action game (I was actually looking for an action game), and contacted Neil.

After trying the early version of Rescue, I quickly had a vision of what the music would be like. Neil didn’t want it to be too modern in terms of its harmony, so I followed this rule. I’ve usually created this kind of stuff by using orchestral instruments only, but this time I wanted to add some electronic sounds to it. The ambient in-game track sounds electronic, but actually most of the sounds in it are “real” (low strings, choir). The main theme reappears in the action track too, to make the game audio more coherent.

I also promised to help Neil with sound effects, so I made them after the music was ready. I didn’t notice the rapid passage of time and was actually a bit rushed to finish them before the deadline!

I didn’t have any problems with this project. Communication was great and things worked out nicely. The only thing I got a little worried about was when Neil decided to change the purpose of certain music tracks to deal with changes in the gameplay. Fortunately the game developed in a way that meant we didn’t have to throw anything out. Just some of the sound effects I made have not been used in the game (yet).

Texturing the Models

Brian Creates the Eye Candy

I was happy to accept when Neil asked if I would like to produce textures for Rescue. Like Neil, I tend to start lots of projects but only finish a few and so the competition sounded like a good incentive.

The first step was to make sure we could transfer Neil’s models from form-Z to the 3D package I use, Cinema 4D, UV map them and then export the models as Wavefront .obj files which the object loader library could use. We soon discovered Cinema’s .obj file exporter reversed the surface normals. This was easily fixed by inverting the models’ normals before exporting. There also appeared to be a problem with the UV mapping in Rescue. By examining the UV data in Cinema 4D’s Structure Manager I discovered that the first UV coordinate was being zeroed when the models were opened by the object loader library. Neil and myself decided that this glitch should be worked around by editing the .obj model files (copying the first set of vt coordinates to the end of the UV list and then updating all references to it in the f polygon list) to save time hunting it down. Cinema 4D also didn’t export material files with the .obj model files and so manual file editing was required to construct them and link them to the model files.

The most time consuming part of my work was UV mapping the models. This was done in Cinema 4D with the freeware plug-in, UV Toolkit. The asteroids proved tricky to flatten as they had continuous surfaces. I decided to minimise variation in texture scale and shearing at the expense of creating seams. I also chose to stick to a single 512×512 texture for all the asteroids to save time and conserve VRAM. To change the texture scaling to fit the different sizes of asteroid I first mapped the larger asteroids to the full texture space and scaled down the smaller ones proportionately. However, this resulted in a very blurred texture on the large asteroids. I later realized that the object loader would tile the texture if the UV coordinates were outside the 0.0 to 1.0 range and so the smallest asteroids were assigned the full texture space with the larger ones scaled up, to a maximum of 4x for the biggest ones.

For the buildings and tug UV maps I found the best method was to break down the model’s surfaces based on the most suitable type of projection. For example, first I assigned UV coordinates to all the surfaces that could be mapped with flat projection, then all those that need cylindrical projection and so on. With all the elements mapped the largest surfaces were placed and scaled within the UV map. Finally the smaller elements were slotted into the remaining spaces. Much fine tuning of elements’ scales was required to optimize texture space usage. For most models the texture space assigned over its surface needed to remain constant. However the tug cockpit model was to be viewed from a fixed position so I skewed the scaling so that the surfaces nearer the viewer were allocated more texture space.

The textures themselves were based on reference images supplied by Neil (a photo of an asteroid, a shot of the Space Shuttle cockpit and so on) and discussions that occurred as the textures where developed. I took screen shots of the UV maps in Cinema 4D and opened them in Photoshop. All the textures were painted at twice their final target resolution. They were rendered using a mixture of filled and stroked selections and hand painting. Public domain photos from the web were overlaid on the painted texture to add detail to the metal, concrete and stone surfaces. I also placed blurred highlight lines along the model edges where I wanted emphasis.

Overall, given the limited time I had available to UV map and texture the models, I am pleased by the results. I would like to get involved in more game texturing in the future and am sure that what I have learned from this project will come in handy.

Brian Smith

www.steampunk.demon.co.uk

www.mikkotarmia.com

I knew at the beginning of the contest that this was a huge project to take on for a three month time frame. I did as much planning as I could ahead of time, and studied all of the technologies I thought I’d need. I wrote up a thorough design document, and showed it around to a bunch of other developers for feedback. When the contest start date finally came around, I felt pretty well prepared for what was ahead.

Development Tools

IDE

I used Project Builder as my IDE. Up until the contest, I’d been using-don’t laugh-MPW. I nearly ended up using MPW for the contest, but recent events convinced me that it was finally time to drop Mac OS 9 support, and move on to Mach-O. I’ve looked at Xcode, and I feel that it is rather bloated and unintuitive. While a bit older and no longer officially supported, Project Builder seemed a better choice to me, and it worked without a hitch.

Text editor

BBEdit was the most essential tool for me. I’ve been using it for code editing for years, and it’s the best text editor I’ve ever used, hands down. Syntax coloring, regular expression find and replace, and many other features make it a fantastic programming tool. In September, I upgraded to the newly released BBEdit 8.0. It had a feature that made my workflow much more efficient: single-window, multi-document editing. I had previously been minimizing each source file’s window to the dock—not a good solution when you have more than a dozen source files!

Graphics

I tried out several different image editing programs early on, and was having trouble finding one that suited my needs. I don’t own a copy of Photoshop, and didn’t have the money to spend on one. Eventually, Daniel Lurie recommended the GIMP (GNU Image Manipulation Program). I was initially turned off by it, as it ran in X11, but after using it for a while, I found that it really worked quite well. It served me well over the course of the contest, and I feel it gives even Photoshop a run for its money.

Audio

I used two programs for audio: Amadeus II and Reason. Amadeus II is a great little shareware audio editing program, and one of the few shareware programs I’ve actually registered. I had a bad experience with Audacity, and there didn’t seem to be anything else usable out there. Some sound effects were recorded, some were artificially created, some were copied from the original Water Tower (a fact of which I’m not proud—I wish I’d had time to redo them), and some were created in Reason. I wanted to write background music for the game, but unfortunately, due to lack of time and lack of musical talent, that didn’t happen.

Models

I looked at a few modeling programs, but they all seemed to have a rather steep learning curve, and I couldn’t be bothered to spend the time choosing one and learning to use it. None of them quite managed to fit my needs anyway. I ended up creating my own model format, and typing in most of the models by hand. For some of the more complex models, such as the deadly block, I wrote a small console application to generate them programatically. While far from an ideal solution, this at least allowed me to get the job done and move on.

What Went Right

Game Concept

Since I was building on a game concept I’d created the previous year, I didn’t have a whole lot of work to do here. Essentially, I just had to figure out how to make the transition from a 2D world to a 3D one. I had some crazy new ideas for game features, but a lot of them didn’t make it. By the end of the contest I had a game that was very similar to the original. While I would have liked to explore new concepts a little bit further, I feel the original gameplay survived the transition to 3D very well.

Code Structure

I had learned a lot about writing better code since the uDevGames Contest from the previous year. Working with another programmer helped me see new and better ways to write things, and after adopting what I feel are better coding practices, my coding has become more efficient. Toward the end of uDevGames 2003, the Water Tower source code had gotten to be such a mess that I could scarcely add a single new feature without causing three new bugs. Water Tower 3D was a completely different experience. The code remained clean and readable throughout the entire project, and was very flexible. Adding new features was almost always painless and easy. Keith Bauer, another programmer, looked over my code toward the end of the contest, and told me it was nicer and more readable than most other code he’d seen.

Animation

When I was planning the game before the start of the contest, I knew that character animation was going to be one of the bigger challenges. I did some research, asked some people who had done this sort of thing before, and came up with a system I thought would suit my needs. I wanted to get as much research as possible done before the contest started, and since animation seemed like such a large unknown, I spent most of the month of July working out how to do it. When the contest started in August, I was pretty satisfied with my animation system. When the time came to implement it in the game, it was up and running in a matter of about two days. The results were quite pleasing. During the course of the contest, I got many compliments on how well-animated my character was.

Asset Management

Managing assets for the game was a pretty smooth process. I had a directory full of human-readable ASCII files that were used for models, animations, and textures, as well as a separate directory for the texture images themselves. I could set up material properties for each texture, and change which texture is used on a model by changing a string in my model file. My model and texture loading code loaded all of the files in the directory at startup, so no additional loading code was needed when I added new models or textures.

What Went Wrong

Water

The biggest trouble I ran into during development came when I tried to implement water. I wanted a system where the water would flow more realistically, as opposed to a flat plane rising at a constant speed, as it was done in Water Tower. I started on the water system in September, thinking I could get it up and running in about a week.

A week passed, and it still wasn’t working, so I figured I’d give it another week, as it was a very important gameplay element. Another week went by, and another… Before I knew it, I had spent more than a month of development time doing almost nothing other than work on the water system. That’s a gigantic loss of time for a three month contest! Eventually, I realized that if I continued on the water system that way I had been, I wouldn’t have anything even close to releasable by the end of the contest. I cut my losses and implemented Water Tower-style water, and was done with it in an evening. To this day, it’s the thing I’m the most disappointed that I wasn’t able to do in the game.

Too Big a Project, Too Little Time

I knew from the start that this project was really asking a lot of myself in such a short time frame. With everything I wanted to do with the game, there was no way I could get completely finished in three months. I tried to prioritize the most important game features so that I could at least have a working, playable game by the end of the contest. I don’t feel that I did a very good job on this. Some fairly essential game features were still missing by the time voting started, and there were some other things I really could have done without that took a lot of time. I do feel that I’ve pushed my limits and done more than I could have imagined in the time given, but the project was still much too large to be appropriate for uDevGames.

The Character Model

Another big unknown was the character model. I had very little experience with any modeling program, and hadn’t ever modeled anything as complex as a human before. For the first half of the contest, I was using a white stick figure for the character. I would have liked to create a more realistic human model, but I didn’t even know where to begin. When I was showing the game around to coworkers one day, someone had a suggestion for at least a start: stick with the model I had, but give it colors to make it look like a character from the Atari 2600 era. The effect wasn’t too bad; a definite improvement. I spend some time proportioning the character to look less like a stick figure, and eventually decided the result was good enough for the contest. While not really satisfied, I was at least able call it “done enough” to move on to other things in the game.

Camera

There were some usability issues that I unfortunately never addressed. One problem, which seems to be inherent in any 3D game, was the camera. I put all of the responsibility of moving the camera on the player. While it’s nice to be able to control the camera, it’s not something most people want to have to worry about in the middle of the action. I had some ideas for how to make this nicer: I was going to have an invisible object that could be placed in the level editor that I called a “camera hint.” When the player walked over a camera hint, the camera would pan to a predetermined angle. Well-placed camera hints in a level could make it unnecessary for the player to adjust the camera at all. Add that to the long list of features that didn’t make it.

Levels

I wanted to have at least four different level sets finished by the end of the contest: Tutorial, Easy, Intermediate, and Advanced. Sadly, the levels you see in the contest version are none of those; they’re still placeholders. The difficulty is about at Intermediate level, which is also a problem…the game has a rather steep learning curve for beginners. I have to wonder how many people stuck with the game long enough to get the hang of it.

Conclusion

While I’m proud of what I’ve done with the game, I have to admit that it was simply too large of an undertaking for a contest of this scope. However, if it hadn’t been for the contest pushing me to finish, I probably would never have gotten anywhere near this far with the game. It would have been just another project on my this-would-be-cool-but-I’ll-never-get-around-to-it list. I’m planning to come up with a somewhat smaller project for the next uDevGames Contest. It would be nice to be finished by the deadline for once!

I was told by many developers that I was crazy for trying to do this alone. Many times when I felt overwhelmed, I considered looking for other team members to take some of the load off, but I stuck it out by myself to the end. The main reason I enter uDevGames is to learn new things; how can I learn if someone else does the work for me? This experience is invaluable. I feel that I’ve furthered my abilities as a programmer, an artist, a designer, and a musician. This is my goal. This is why I do what I do, and why I enjoy working alone.

A big thanks to iDevGames and all of its staff members for organizing this contest. It’s one of the best things in which I’ve ever participated. Thanks to the sponsors, for donating some great prizes to motivate developers to do better. And thanks to Apple, for creating this wonderful computing platform.

• Developer: Alex Diener
• Language: C
• APIs : Carbon, OpenGL, OpenAL, FreeType, Vorbis
• Source files: 71
• Lines of code: 17,110

BlitzMax is the new, next generation game programming language from Blitz Research. BlitzMax retains the BASIC roots of Blitz3D and BlitzPlus, but adds a ton of cool new features and abilities. BlitzMax is BASIC—with a few twists, including:

• Function pointers
• Fully dynamic arrays
• Inheritance and polymorphism
• ‘By reference’ function parameters
• Byte, Short, Int, Long, Float and Double numeric data types
• Array and string slicing
• Flexible ‘collection’ system for dealing with linked lists etc
• Low level pointer handling
• UTF-16 strings
• The ability to ‘Incbin’ binary data and access it as easily as if it were a regular file
• External language support for interfacing with C/C++/Objective-C or assembly code.

BlitzMax programs can be compiled for Mac OS X, Windows and Linux PC’s. The BlitzMax license is ‘all in one’—buy BlitzMax once and run your programs on all three platforms.

Related Link: BlitzMax

blitzmax,macosx,released