iDevGames

Another interesting thing to note is that my target audience for Pirate Isle was much younger than those I normally develop for. One goal for Pirate Isle was that it would be fun and appropriate for gamers of all ages, and this resulted in a number of technical and game design considerations. I tried to keep the number of individual controls down to a minimum (the gamer only has four buttons to control Slash fully: left, right, jump, action) and the default configuration is set up so that two children can control Slash at once.

Not only did I choose a different target audience and genre of game to make, I also decided to explore different technologies with which to make the game. The entirety of Adventures on Pirate Isle is defined in a number of XML files which are then interpreted by the executable to display the game, much like how your web browser interpreted the HTML of this document in order to render this web page. The engine I created for Pirate Isle utilizes XML to provide structure and easy parsing of the game objects, but without some kind of scripting language it is nothing more than a file format to store definitions. For the brains behind the brawn, Pirate Isle uses Lua.

Yo ho ho, and a bottle of rum!

pirate_isle_2.jpg

Slash against the octopus

I found Lua to be simple to incorporate, easy to learn, and quite powerful in its own right. I had no experience with scripting languages before writing Pirate Isle, so the first thing I did was research the various languages. As normally happens, this particular topic of discussion had already been flushed out on the iDevGames forum. What excited me about Lua as opposed to the other scripting languages is its small footprint. Incorporating Lua into my project was a snap, and it handled running on Mac OS 9, Mac OS X, and Windows beautifully. Lua is also a simple, easy to read language, perfect for allowing interested parties to modify the game to their liking.

Even though Lua is as cool as it is, it is still an interpreted language. This means it lacks what games need most often, performance. My initial tests with Lua showed that it was too slow and cumbersome to have it handle every aspect of the game (such as storing and rendering the sprites). After some more tweaking and brainstorming, I ended up with what is best compared to a car and its driver. The car in this case is an OpenGL engine written in C—clean, fast, quick to respond and handles all the brunt work of going from here to there. Lua then fulfilled the role of the driver. Lua tells the car where and when to go, but leaves the specifics of how the car travels along the road and bounces against the rocks to the car. This approach improved performance dramatically.

That’s great, but now that Lua has been “demoted” to just being the driver I ran into another problem. How should all these scripts be structured, and what API needed to be developed in order to place the least amount of burden on the scripting language?

Hello XML

Using XML allowed me to define separate sprite objects, each with its own initialization, update, and event Lua scripts for unlimited customization. Once this was in place, I had a quick and easy framework for adding new, unique sprites to the game. This was also extremely useful for quick prototyping of new sprite animations, as well as doing quick fixes since modifications to the script did not require a recompile, and in many instances didn’t even require the game to be reloaded!

Avast ye ZBrushers!

pirate_isle_zbrush.jpg

ZBrush in action

I found out quite quickly that making a platformer is hard. I enjoy switching between genres when choosing games to make, and I must admit that the amount of work it takes to make a decent platformer is far beyond what I originally anticipated. If the sheer number of assets were not daunting enough, the intricacies of level design and the pressure to balance it just right are enormous. When I first developed the idea for Pirate Isle, my thoughts were to use pixel art in order to recapture some of the “retro” gaming experience. An example of this can be seen in the first color version of Slash in the image at the top of this postmortem. However, after about two weeks of some serious sprite creation and animation framing, I realized that at my current rate of graphic creation I would never make the deadline in time. Also, my pixel renditions of Slash didn’t have the “cute and cuddly” feeling that I was going for (as my lovely wife so pragmatically put it the pixel version looks like a “drowned rat”).

It was too late in the contest by this time to redo many of the hand-crafted game items I had already made, and Steve was already working on some hand-drawn enemy sprites, so I was forced to make some tough decisions. I settled on using the hand drawn objects I had already created (for instance, the fruit power ups, the tombstones, etc) and the hand drawn sprites Steve was making, and I would use a rendering package to create the backgrounds. In steps ZBrush!

ZBrush has got to be the finest character creation tool I’ve used yet (beating out such packages as Carrara Studio, for example). My good luck in the 2002 uDevGames Contest nabbed me a copy of ZBrush, and utilizing it for Pirate Isle helped give the game some character. I used ZBrush when creating the “tiki” statues, the jackal statue at the end of each level, and the “big-boss” octopus at the end of the sixth level. Using ZBrush for this purpose was incredibly simple and an enormous time saver. ZBrush allows you to start with a simple geometric object (I used a sphere when creating the octopus and a cylinder when creating the tiki statues) or you can use their unique modeling technique known as ZSpheres (ZSpheres are the 3D modeler’s equivalent of the little 2D mannequin most artists use to get proportions and posture right. I used ZSpheres when creating the jackal statue). Once you have your basic object, you can then mold and sculpt that object in a very intuitive manner, allowing for the creation of eyes, nose, mouth, and other facial characteristics in a matter of minutes.

In the end, the mixed-and-matched nature of Pirate Isles graphics hurt it more than helped. Poor planning in the beginning and my underestimation of the amount of art work required to make a good platformer caused Pirate Isle to suffer more than it should have. The experience was not a waste however, since I had a blast learning how to create “pixel art,” as well as spending more time with ZBrush.

Clear sailing ahead!

pirate_isle_3.jpg

Game Map Screen

Building upon past experience

Although the uDevGames Contests are only three short months long, I always try hard to make sure I code with an eye for the future. In some cases this “future planning” results in some wasted time, but in all too many cases it results in saving even more time. Adventures on Pirate Isle uses the same engine code that I wrote for The Belt last year, and it is even an evolution of the base code I wrote for Imp Fodder in the very first uDevGames Contest. Reusing this code allowed me not to worry about the average stuff such as how to open a window, or take over the fullscreen properly, or develop an architecture for my animation…you get the picture.

Utilizing a Scripting Language

We’ll be revisiting scripting languages in the “What went wrong” stuff below, but using a scripting language had many advantages. It allowed for quick bug changes, provided for much more stable code (when there is a problem with a script it simply displays an error and doesn’t crash the entire program), and it allows for artists and gamers to easily modify the game to their liking. All in all using Lua saved me both time and effort.

Non-tile Based, Polygonal Collision Detection

Although this may be a little noticed feature, Pirate Isle was not based on tile like most traditional platformers. All of the objects in Pirate Isle could be an arbitrary size, and all of them could have an arbitrary polygon as their collision boundary. This allowed for Pirate Isle to develop a non-tiled, more natural look, although the added complexity in the collision detection routines required some last minute fine-tuning for it to work on older computers.

An Enthusiastic Musician

Dori Eggan is the wife of a relatively new friend of mine, Nate. Dori and Nate both came from my home state of Ohio, and Dori happens to have started a career as an educator in music. I approached her to see if she would be interested in experimenting in the world of game music, and I found she was quite enthusiastic about creating some original content for Pirate Isle. This panned out well, considering this was her first foray into the digital music realm and Pirate Isle scored sixth in the Sound and Music category. I sure next year she’ll be bursting with ideas and pent up talent, so watch out!

A Cool Artist

While I did 95% of the artwork for Pirate Isle, all of the creative genius which provided for the enemy sprites came from Steven. For his day job Steve does the cool art for many of Freeverse’s titles, but sometimes drawing monkeys for a living can get repetitive. When Steve let me know he’d be interested in redrawing a few sprites for Pirate Isle I was ecstatic, and would have been a fool to say no to such a talented artist. The various enemies Slash encounters are one of my favorite parts of the game, and thanks to Steve they didn’t disappoint!

Good Vocal Talent

Finding vocal talent for a game is challenging, especially for a freeware title being developed in under three months! So when the time came to create voice-overs for Slash my wife and I both sat down and recorded our voices. Needless to say her voice-overs were an order of magnitude better than mine, and thanks to her Slash has a voice instead of just little text bubbles. Some extra work could have gone into the sound processing of the vocals (to help reduce some of the static and such), but all in all I was pleased with the results.

Anyone want a peanut?

pirate_isle_4.jpg

Battleboard Screen

Interpreted Languages are Slow

Here is where we admit that scripting languages have their faults. First and foremost is performance. Lua is also deficient in that it does not have a C API for separate compilation and later loading of these pre-compiled chunks. Now, before I get a ton of emails saying that luac can input a Lua script and output the compiled version, note that this is not what is needed in this instance. The whole point of XML encapsulated Lua code is that it becomes simple for gamers to modify the game. This means that pre-compilation or running the scripts through a conversion tool is not ideal. What I really needed was a lua_compilestring() and lua_runcompiledstring(), but even after digging into the Lua library code myself I was unable figure out a good way of doing this. In the end, I was able to simulate pre-compilation by having my C code encapsulate all of the scripts in their own unique function. This reduced my script compilations from 60-200 lines of code to a single line of code. This managed to get the game to run well on 400MHz machines.

Lack of Audio Input

When my powerbook died late last year, I was forced to upgrade to a “Windtunnel” G4. This was nice development-wise, but one small speed-bump is that regular old microphones don’t work with this computer. I’m no audiophile, but apparently you need a special kind of microphone that I didn’t have the money for in order to use the audio input jack. I ended up borrowing my mother’s DV camera and recorded sounds and voice that way, but this turned out to be incredibly cumbersome. My disappointment in spending a little over $2,000 for a new computer and not being able to use a regular old microphone was profound.

HID Manager Woes

HID manager is actually a simple API to use. In a few days I developed a nice wrapper for it, had it integrated into my game, and was running Slash around with my little Gravis Gamepad. Unfortunately, it was something as simple as keyboard input that seemed to give HID manager all kinds of trouble. Yes, I understand all keyboards are evil since keyboard rollover is in their hardware, but for some odd reason HID manager itself was missing some key combinations which regular Carbon events were getting fine. My particular example is with the arrow keys. When I was gathering events with Carbon events, using the left, right, and up arrow keys in conjunction with the space bar worked flawlessly. When I switched to HID manager only, this key combination no longer worked. So although keyboard rollover still effects the Carbon events code, there must be some other bug in HID manager which caused that oddity in behavior. In the end I used a hybrid system of Carbon events for keyboard and HID manager for other input, and that seemed to work best.

Limited by the Design

As I mentioned earlier, I underestimated the amount of work that a platformer needs. My original plan for Pirate Isle was to release the uDevGames version with three separate worlds having different scenery and enemies, and each world with 5-7 individual levels. As you can see, I only got one world with six levels completed, and by then there was not enough time left to consider making an entire new world.

Hoist Anchor!

This year for uDevGames I wanted to explore new areas of game development, experiment with different art techniques, and ultimately just have a fun time creating a game that children of all ages could play with their parents. It is doubly satisfying hearing from others that “the sugar glider hero is very cool” or that “Slash is so cute,” because coming up with a good hero character and portraying that character well to the audience is probably the hardest thing to do in any medium, be it movies, literature, or games. Although my willingness to explore new areas resulted in somewhat of a “melting pot” of graphical styles, I had fun doing it and feel that I’ve gained much from the experience.

• Genre: Platformer
• Developer: Rocco Bowling
• Url: http://homepage.mac.com/felinegames/
• Team size: 1
• Released date: June 20, 2003
• Project length: 3 months

• Development hardware: “Wind Tunnel” PowerMac G4

What Went Right

NeHe and Cocoa

Learning OpenGL and Cocoa in three months is no easy task! The first step was reading my uDevGames 2002 prize, ‘Building Cocoa Applications.’ This is a great book; after reading about 200 pages and building the project with the book, I had a solid understanding of what Objective-C was, and the incredible powers of object oriented programming.

Next was learning OpenGL, which seemed twice as intimidating and complex. Actually, it turned out to be the best thing to happen to this project. Using the tutorials from NeHe, I was able to learn the basics of OpenGL in only a few days. OpenGL allowed me to get a visual start to GL Golf very quickly. Using a height map made in Photoshop, I could create decent quality levels very fast.

A Good Math Background

Having already completed trigonometry and algebra three, along with taking calculus, helped tremendously. When you go down to each line of code, everything is just a bunch of numbers, and most are very simple, but some of them are complex enough to give you a headache. After digging through about 10 different collision detection tutorials, I found one that made sense. After a few weeks of coding, I had collision detection and response implemented, but as I found out later on several occasions, the tutorials had some very big errors. For example, it gave the incorrect equation for finding where a ray and triangle intersect, which caused the detection not to work at all. So to make a long story short, keep taking higher-level math courses, because that’s what programming is all about.

iChat and iDevGames.com

Without the help of the iDevGames community there is no way I would have finished this game. Whether it was something as simple as asking how to convert a char array to NSString, or asking how to get smooth shading implemented, someone was always there. Thanks to everyone that helped!

What Went Wrong

My Stupidity

Often programmers do something wrong, but it still works anyway. This happened to me, and it was such a big mistake that it cost me an 80 percent slowdown. Luckily it was something as simple as calling GL_Begin(TRIANGLES) about 4,000 times each frame, when I really only needed it about 10 times. This alone multiplied my frames per second by five, making the game playable on almost all Macs.

Lack of Motivation

This is the biggest problem plaguing independent programmers today, and I’m no exception. If I programmed 20 hours a week every week of the contest, there’s no doubt in my mind that my game would have been twice as good. I had spurts of time where I programmed 20 hours in two days, and then times where it took me three weeks to get 20 hours of work in. I don’t know any good ways to fix this; you just have to do it, and when you see new results the urge to program will come back.

The Forum

I spent way too much time reading the forums while developing GL Golf. This was both a good and a bad thing. While I received much needed help from forum members, I also drained lots of time there. For some reason I would check the forums as often as I compiled my game, which ate up valuable developing time.

Tools

My primary IDE for GL Golf was Project Builder, with a little help from METAL Basic. I used METAL to reformat my Meshworks animated models to a nice useable text file. I used Meshworks to make the golf club (which will be changed shortly), and Photoshop 7 to do all the other graphic work. I also used Photoshop to make the levels. While it was hard to actually make a hole, one could be created in 10-20 minutes. My development system was a Quicksilver 733MHz G4 with a Geforce2 MX card. This was a good machine to use, because it was an average system, which kept my system requirments low.

Summary

Overall GL Golf was a great experience, and the uDevGames 2003 Contest made it all the better. I now have the knowledge to program a high quality 3D game, and I plan on doing so for the next uDevGames contest. I plan on continuing development on GL Golf, and within the next few months I hope to have a shareware version finished. I am already looking forward to uDevGames 2004, so get ready for another great game!

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

• Critical applications:

What Went Right

Early Planning, or “The List”

By choosing an update to a classic game, a lot of the hardest work was already done. Since Ladybug was a maze game, I had a genre that was proven to work. In addition, I had already worked on an unreleased maze game, so I knew most of the programming challenges that would confront me. With that in mind I grabbed a fresh yellow legal pad and started planning. I wrote down every game play feature I thought I would need. I planned out the interface. I wrote out several classes and how they would work. Whenever I would think of something new, I would add it to the to-do list. If I knew I wouldn’t have time to do the programming or art for a feature (such as terrain multi-texturing, or multiple level designs), then it didn’t even get written down.

As the three months went on, the list grew and shrank, but it always remained a roadmap for what I had done and what I still had to do. I could see which features would need to be implemented next, and which could wait until the end in case they needed to be cut. It wasn’t a strict schedule or design document, but it did its job. I was kept sane as the list kept the project organized. My brain could focus on the task at hand instead of the overall picture. In the end the vast majority of features made it into the final game, leaving a few to serve as the basis for a post-uDevGames update.

Cocoa or OpenGL

Apple has done their homework—Mac OS X is a dream to use and to program for. I knew before I even started work on Gaichu that I would be using Cocoa and OpenGL to realize it. OpenGL was a no-brainer, as there is no other alternative on Mac OS X for 3D. However, I had never done anything more than a few simple tests with it. Cocoa worried me as well. I had programmed several full projects using Carbon for both classic Mac OS as well as Mac OS X, but my only Cocoa programs had been those same OpenGL tests.

After the three months I can say that I shouldn’t have been worried at all. Obj-C is a beautiful language and Cocoa is a beautiful API. The Cocoa development docs are a great resource, and what can’t be found there can easily be found on-line (CocoaDev is a favorite). OpenGL is very easy to use and puts the old QuickDraw API to shame. And needless to say, the on-line resources for OpenGL are vast. Anybody who still isn’t using Cocoa or OpenGL needs to get with the times and discover the greatness of these two APIs.

Listening to Early Feedback

I knew from the beginning that since I was working alone I was going to need feedback from as many outside sources as possible. I tried hanging out in the iDevGames chat room as often as I could, and I had a Gaichu feedback thread in the forum within the first three weeks of the contest.

The early feedback was invaluable as my “testers” caught several bugs that I wouldn’t have caught otherwise. I thought that my first attempt at player movement code was more than adequate, but because of feedback I ended up re-writing that piece of code more than three times. And I must conclude that player movement in the final version is vastly superior to the earlier versions.

Listen to your testers. When you’re playing your game four hours a day, every day for months, you start to lose perspective. Just because you think a certain feature is adequate, or that the difficulty is right on, that doesn’t mean that the rest of the gaming public will as well.

What Went Wrong

Inconsistent Art Focus

If there’s one thing that I hate more than anything else in shareware games it’s amateurish artwork. I used to believe that artwork wasn’t what made a game great, but it’s hard to have fun playing a game when the artwork makes your eyes bleed. In the not-making-your-eyes-bleed category, I think Gaichu does pretty well, however I still wasn’t satisfied with its artwork.

Gaichu lacks a consistent art focus. Since I was doing all the artwork myself, I thought that I wouldn’t need to do extensive sketches and tests for each piece of art. I thought that I could just make each piece as necessary and in the end it would work out since they would all be made by the same person. It didn’t turn out that way. Most of the artwork was redone not once, but multiple times. Some pieces like the title-screen were slapped together at the last minute.

Gaichu badly needed an art director with a unified vision for what the game should have looked like. Gaichu’s final artwork isn’t bad. In fact, there’s a lot I like about it. However, it’s not as good as it could have been, and that’s something I will be striving to fix in the near future.

The One-Man-Band

When you’re making a game by yourself, you have to wear a lot of hats. Sometimes you’re the producer, sometimes you’re the programmer, sometimes you’re the sound guy. Unfortunately, at times certain hats get more of a preference than others. For Gaichu it was definitely the programmer hat that took up most of the time. When presented with both a programming and an art task, the programming often took precedence. Art and sound assets took a back seat and didn’t receive as much attention as they deserved.

Regrettably, there’s not much that can be done to remedy this. There are really only three possibilities. You can extend the deadline to give you more time, you can hire one or more persons to assist you, or you can overextend yourself and work even harder for longer hours. For the uDevGames Contest, number two is the only real choice; unfortunately I have a phobia of letting other people help me on projects such as this. A partner or two on a later project might be something I want to explore.

Not Enough Early Feedback

Above I said that early feedback was one of the things that went right, however it’s also something that went wrong. Browsing the forums shows that a few of the games seemed to monopolize most of the forum members’ time. Some games reached multi-page threads almost immediately, while others died out without constant developer bumping. When you’re a developer starved for feedback, you start begging for comments and suggestions.

As the voting was winding down I received several comments that the game was too hard, that the enemies were too fast. That’s a great comment that can be used to improve the game, but it came too late in the contest to work on it. Next year I’m going to lock several testers in my basement and force them to give comments and suggestions.

Conclusion

In the end, Gaichu did pretty well; 5th place in Polish, and 10th Overall, is nothing to sneeze at in a competition involving 43 games. Of course, the best prize is that after years of programming and attempting to make games, I’ve actually made one. When someone asks me what I do and I respond, “I make games,” I no longer secretly think, “Liar!” In that regard, uDevGames 2003 was huge success.

Screenshot 1: One of the earliest Gaichu playables, about two weeks into development.

Screenshot 2: Gaichu now with player-rotatable walls that block enemy movement.

Screenshot 3: An early interface test. The colored squares represent poison, letters, and bonus pickups.

Screenshot 4: Gaichu is starting to resemble a real game with improved graphics.

Screenshot 5: Gaichu v1.1, the final version released before the end of the contest. Chu, the ladybug girl, was added at the last minute and not finished in time.

Gaichu

• Number of Developers: 1
• Length of Development: 3 months
• Development Hardware: 867MHz G4 (1.1GB RAM/GeForce2MX 32MB), 350MHz G3 (448MB RAM/Rage128 16MB)
• Critical Applications: ProjectBuilder, InterfaceBuilder, Photoshop, Hash Animation Master, UVMapper, Peak DV, Melody Assistant, OpenGL Profiler, Shark

• Project Size: 48 code files, 9,833 lines of code, 100MB of art and sound assets

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.

1. 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

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

What Went Right

The Idea

Three months is still a very short time, so I knew I had to come up with a very simple idea and stick to it in order to finish before the deadline. Sokoban came to my mind, which I really love. I decided to create a game with rules of similar simplicity but as many possibilities for complex and mind-challenging puzzles. Since it was clear from the beginning that the game would be 3-dimensional, the decision to implement a user interaction scheme similar to Kula-World was quite obvious.

kiki03.gif

When discussing this plan with my friend Rolf, we came up with several ideas for different game items and mechanics. Most of them were just copies or simple alterations of ideas we knew from other games. But there was one exception: the idea of an unusual physics with a subjective gravity, a gravity that has no fixed orientation in space, but one that is bound to the player and changes with its orientation. Letting the game take place in the nano world was a good solution for explaining the altered physics. But it could also be used as an excuse for simple graphics and other glitches that might appear. Altogether I was very happy that I quickly found a simple but appealing idea with some originality in it. Highly motivated, I began to evaluate which tools I would use.

The Tools

kiki04.gif

I knew I wanted to reuse some of the code I wrote for my previous project, mainly some basic vector, matrix, quaternion, and projection utilities. I also wanted to avoid long compile times and do some rapid prototyping in Python. After evaluating some systems to bridge between C++ and Python, I chose SWIG, which I can highly recommend. I’ve never written a program with sound output before, so I tried the _SDL_mixer_ library, because I already appreciated the well-done SDL framework. There was no need to look for other solutions, since the sound system I hacked together in a few hours worked perfectly for me and I felt no reason to touch it again, despite its probably quite naive implementation. Compliments and thanks to the author for this very nice library.

The shareware program Amadeus II was my choice for simple sound editing tasks. After trying some free modelers, I found that Wings3d is the best solution for me because of its stability and ease of use. I feel that the time I spent with these evaluations (approximately a week) was worth it, since I found a couple of free but very good libraries and tools that enabled me to be quite productive.

Planning

kiki05.gif

Since I was the only person on this project, I felt no need for a formalized design and project plan. Nevertheless, I knew I had to focus on a small set of predefined features and estimate the time needed for their implementation. The rough project plan I sketched has been a good approximation. Despite some unforeseeable problems, I managed to finish the game in time and without any stress. When looking back, I think that defining the scope and features of the game beforehand has been of even more importance. The first playable version of the game was finished quite fast and I have very often been tempted to add more features. With a few exceptions, the feature list prevented me from doing this and enabled me to concentrate on improvements instead.

Scripting

If somebody would ask me: “What is the one best thing you have learned by doing this project?” I would surely answer: “Discovering the power of scripting in general and the coupling of C++ and Python especially.” The time I saved by being able to test the various aspects of the program and change its parameters in real time, without having to recompile it, was simply invaluable. Thanks to SWIG, I could easily export almost all the C++ classes and methods to the python interpreter running inside the game. This not only eliminated the need for implementing a level editor, but also helped a lot in many different situations. The last time I programmed in Python was years ago. I am amazed at how mature this language and the accompanying libraries (modules) became in the meantime. Many compliments go to the people who developed it!

What Went Wrong

kiki06.gif

Design

The player movement turned out to be much more complicated than planned. But instead of redesigning the whole mechanism to fit the unforeseen needs in an early stage, I hacked around the initial structure and soon got quite a mess. This introduced some runtime bugs which were very hard to find (or still unsolved), mainly because I have problems understanding my own code now. But the worst thing is that the whole system virtually isn’t extensible anymore. If I had changed the design early enough, possible additions like moving sideways or jumping backwards would have been much easier to integrate. I honestly think this is the only thing that really went wrong. But let me try to summarize some things that have been ‘sub-optimal.’

Shadows

As mentioned above, I lost my focus sometimes and implemented features that hadn’t been planned. This wasn’t a problem as long as they improved the game, but on one occasion it was a real waste of time, since I didn’t use any of the code I created for days. This was when I tried to implement shadows. After I got the first version of the shadow system working, I realized that shadows were absolutely not fitting into the overall design of the game. Instead of adding some ‘realism’ to the world, they just made it look confusingly complex. Additionally, a proper implementation would have been very time consuming since I didn’t anticipate the clash with the quite heavily used transparency.

Lighting

kiki07.gif

When I compiled and ran the game the first time on Jaguar, the lighting was broken. This has been very annoying, since the optical appeal of the game completely depends on the lighting instead of texturing. After some days of debugging I came to the conclusion that there must be a bug in the OpenGL implementation of the new Jaguar release and asked for help in Apple’s OpenGL mailing list. After getting no immediate reply, I obsessively tried to find a workaround myself. Eventually I found one, but the frustrating process of finding it almost drained all my motivation. Looking back, I should have asked for help earlier while anticipating some time for its arrival, since a nice person sent me another workaround later.

Conclusion

I learned a lot while making this game. I surely will continue to use the C++/SWIG/Python combination in future projects but I will probably drop the inclusion of the frameworks inside the application bundle. I will also try to improve my design capabilities and refactor more mercilessly in the future. Asking for feedback in the iDevGames forum has been a good idea and I hope to exchange more experiences on the web and in mailing lists. I am planning to port the game to Linux and Windows with my friend Znek in the next months and I will certainly take part in the next competition, if I have time then. There is already an idea for the next game growing in my head. I had a lot of fun developing the game and taking part in the competition. I am quite proud of the work I have done and it makes me happy that some people like the game as well and provided me with valuable feedback. I would like to thank the organizers, participants, and sponsors of the uDevGames Contest, the people playing, voting and providing feedback for the games, and the many people programming, documenting and maintaining Open Source programs and libraries.

• Genre: 3d puzzle
• Developer: Thorsten Kohnhorst
• Url: http://kiki.sourceforge.net/
• Team size: 1
• Released date: November 15, 2002
• Project length: 3 months
• Development hardware: Cube 450MHz G4 and iBook 500MHz G3

• Critical applications: Apple’s Development Tools, Python, SDL, Wings3d, SWIG

astrosquid02.gif

Game screen

A few years later the young man had become quite an advanced programmer and had just developed a new sprite engine he called the Lost Minds Sprite Engine, or LMEngine for short. It used OpenGL to draw 2D sprites with full real-time scaling and blending at good speeds, and he was quite proud of it. To test it he had made a small game, a Tetris clone aptly named LMTetris Demo, and released it as freeware, but now he needed something a little bigger to make a first real release with the LMEngine. He found the old source of the side-scroller and thought that maybe, just maybe he could make something out of this.

The Development

Of course, the old source was quite poorly written classic code, using CopyBits for graphics and with more loose ends than working routines. So whipping it up to shape was more than a challenge; it included fixing bugs, Carbonizing it, and replacing all the GWorld code with the new LMEngine graphics routines. However, it all somehow fell into place and everything progressed nicely. Until one day, when all that was left to make were the levels and some additional sprites. As I was now working alone, with mere moral support from Derek, I simply got tired of the game. With every new sprite graphic added and every new level created it felt harder and harder to continue. But I told myself that this game was too good to just give up on now that I had come this far, so I pressed on, and eventually finished it. This resulted in the first release of the game only having eight levels. I knew this was too little, but I just couldn’t bring myself to make any more.

astrosquid03.jpg

Game screen

After the initial release I got quite a lot of positive response, which gave me the energy to add another eight levels to the 1.1 release of AstroSquid.

As for the more technical aspects of the development, there were a couple of different tools and libraries involved. The first and most important was of course the LMEngine, which is a set of routines to handle 2D graphic sprites. It was used for all the graphics in the game, from the menus and text, to the game interface and actual game sprites. The actual drawing part of the engine uses OpenGL calls, but the engine also has a lot of routines to manage the sprites along with a couple of special routines to, for example, go into fullscreen mode. The LMEngine also has routines to save/load entire scenes of sprites from files, something I found very useful as it meant I could store, for example, menus, interfaces, and backgrounds, and then load them in one call instead of hardcoding things like menu graphics.

The other two libraries I used in the project were MIDIWorld by Derek Smith, which uses QuickTime to play music files, and a sound library I had made earlier to play multichannel stereo-panning sound.

What Went Wrong

Using Legacy Code

The first thing that went wrong should be obvious to most people. The fact that I tried to be smart and renovate old, poorly written code. Even though this might make things easier in the beginning, it always lands you in trouble later on.

I think I would have been much better off if I had started an all new project, with better structure and integration of the LMEngine to begin with. At least it would have saved me many hours of going through pages of old code, just to figure out what it was actually doing to my poor sprites.

Poor Planning

The second thing that went wrong was poor planning. As I never intended the project to get this big and serious I started out with very vague plans of what I was going to make. I think this was one of the main reasons for me losing interest and almost giving up on the game at some points. Had I instead carefully planned what levels, features, etc. I wanted in the game it might have been easier to make steady progress, and thereby keep up my interest. Which is, I think, one of the hardest and most important things when making a game alone.

astrosquid04.jpg

Game screen

Leave the Music to Musicians

The third thing I can think that went wrong must have been the music. As I’m not good enough to do the music myself I asked a friend to do it. In doing this I was all too unclear on what I wanted, how much of it, and when I wanted it. This then stalled the progress, as I felt I had to wait for the music to move on and then when I finally got something I just put it in, even though I wasn’t really happy with it, just to get it over with. I should have been much more precise about what I wanted, and what the deadline was. However, it all worked out for the better as new and improved music was later made and included in the 1.1 release of AstroSquid, making me much more content with the game.

Quality Assurance

The fourth thing that went wrong is a real classic—insufficient testing. Happy that I had finally finished the game and removed enough bugs to make it run on my computer, I was itching to release it. This resulted in quite an unstable 1.0 and quite a few bug-fixes and long programming sessions after the release. I won’t go into any details, but there are a lot of things that can go wrong with DrawSprockets and OpenGL.

What Went Right

The Engine

Now for the bright side. The first thing that went right was actually the work before the actual project was started. The LMEngine and the other libraries performed very well and needed very little maintenance during the development, the exception being the fullscreen code in the LMEngine, which caused me some grief. But apart from that the LMEngine worked very well and the pretty graphics that it made possible are one of the keys to the relative success of the game.

Time-saving Editors

The second thing that went right was during development. I decided quite early on to make several editors (for sprite scenes, sprite resources, and of course for the actual levels). Though this was a lot of work, it really made things easier later on. I also kept on adding features and improving these editors along the way.

astrosquid05.jpg

Main menu

A Polished Interface

Third, I think that the menus and interface in the game turned out quite nicely. Not only do they look quite good, but they also give more feeling to the game and make it seem more solid. I don’t think you should underestimate the significance of good looking, easy-to-use menus and interface, even for small games like AstroSquid.

Debugging Procedures

Fourth, during the development I added an extensive set of debugging tools to the code. This is also something I can really recommend: routines to output a debug file or something similar when things go wrong. This is also very good to have when testing an application, instead of getting an e-mail that just says “it won’t launch,” you could instead get detailed information about the things you are interested in at once.

Good Early Community Feedback

Last of the big things that went right I must mention the release of the game. Even though there were bugs and problems with the release I got a lot of coverage on various websites and good ratings by (some) users. This really helped to motivate me into fixing bugs and releasing a 1.1 version.

Summary

The uDevGames 2002 Contest has, to me, mostly been a way to promote this game and of course try to win some of the prizes. As this game is shareware and I’m just a poor student, I’m interested in making money so that I might buy a pizza or a beer once in a while. However, I’m still young and rather idealistic, so I fully agree with the sharing idea of the competition. The development of the game actually started a little before I had heard of the competition, but when I did hear of it I thought it was a great opportunity and registered at once.

As for the near future my studies are taking more and more time from my programming and I doubt I will get much done the next few months. I do, however, have another game in development and ideas for at least two more when I get the time. AstroSquid is, at least for me, a finished chapter and I strongly doubt that I will ever make a sequel to it, but then again, you never know.

• Genre: Space shooter
• Developer: Lost Minds
• Url: http://www.lostminds.com
• Team size: 1
• Released date: August 31, 2002
• Project length: 5 months
• Development hardware: G3 400MHz

• Critical applications: FutureBasic, Adobe Photoshop, Infini-D, ResEdit, Reason, SoundEffects

When the uDevGames 2002 Contest was announced I told myself that I didn’t have time to write a full game in three months, but a voice in my head kept telling me to try. After three days of internal debate I caved in and began to work on Black Cube. My goals were to develop it using only inexpensive or free tools, to learn OpenGL, and to deliver a completely finished game by the deadline (I didn’t want players to think, “That was a fun demo, it’ll be really nice once he finishes it.”). Also, the knowledge that I would never have to work on it again after three months was a powerful incentive to keep pounding away at it. I kept telling myself, “Just think, once you finish this you can go back to playing Warcraft III…”

What Went Right

blackcube03.gif

Clear Goals and Scope Control

I only had three months to write a game from scratch, and in my spare time. Given that my last game took me six years (off and on) to complete, clearly some changes in my work habits would be needed. On the plus side, I have many years of professional software development to draw on now. On the minus side, I now have a family and a demanding job, and not a whole lot of spare time—I needed a plan.

Given that time was not on my side, the number one factor to my success in finishing Black Cube before the deadline was scope control. I have many game ideas (don’t we all?), but fortunately one of them was this puzzle game. The graphics were simple enough that I expected good performance on any machine capable of running OpenGL and Mac OS X, so very little time would be needed for performance tuning. Likewise, the sounds could be quite simple provided they were appealing enough. Granted, I did not know OpenGL yet, and hadn’t yet used Apple’s development tools, but this game seemed like a good project to learn those on.

During the actual programming of Black Cube, I kept my eyes firmly on my goal of delivering a complete game. This helped me cut the right features as the deadline approached. For example, I originally imagined a background story to the game, involving a stellar cartography mission. Mapping the pockets of “dark matter” would allow ships to pass safely through the area of space represented by the board. But as time grew short I concentrated solely on the puzzle element, because without that I had nothing. I can’t say enough how important clear goals and scope control were to this effort. Whenever things went wrong I reviewed the ultimate goals of the project and adjusted my plans.

blackcube04.gif

The 3D Rules

Deriving the new rules was interesting. An important principle of the original 2D game was reversibility: if you fired a ray in reverse, it would travel the same path as the original ray, but backwards. Most of the 3D rules can be derived from the 2D rules and this principle. The hardest rule to come up with was the 3D corner rule, and even after I had the flash of inspiration that the ray should split in two, I didn’t quite believe that it solved the problem (thankfully my friend John McIntosh understood the rule immediately and convinced me that it worked!)

My biggest fear until the game was finally completed was that the new rules would be too complicated to be fun. Each player has to decide that for themselves, but I enjoy playing the game and I’ve heard from some other players that they like it as well. The rules are rich enough to yield some interesting bounces that are difficult to interpret.

iDevGames

Aside from creating the uDevGames contest, iDevGames offers many useful resources for Mac game developers. In particular, all of Black Cube’s sounds were provided by iDevGames, as was most of the code I used to load and play sounds. Two weeks before the contest deadline Black Cube had no sound, and only a week before the deadline it did.

Good Tester

One asset that I had less control over was the quality of the feedback from people testing the game. Fortunately the friend who had helped me figure out some of the rules for Black Cube took a shine to it and played it a lot. He sent me several pages of useful feedback. He even figured that the deflection rules allow the ray to bounce around the board infinitely! To my knowledge this has never been seen in an actual game, but thanks to his warning I made sure the code handles it gracefully (basically, a ray is “absorbed” if it travels for too long). I also got some useful comments from people who didn’t play the game as much, and it all helped the final game immensely.

blackcube05.gif

Game screen

What Went Wrong

Time Constraints

As strange as it sounds, the lack of time I had each day to work on Black Cube wasn’t always a bad thing. Rather than jumping in and coding each day, I was forced to think about what I was going to do. During my driving commute to work each day I would mentally design changes to the code, and sometimes I’d realize that my first approach wasn’t going to work even before I’d written anything.

However, the short deadline did force me to cut certain features out. Some examples: the game is not localized for languages other than English, and is not designed to make localization easy. It relies heavily on color and may be unplayable by color-blind people. High scores are not saved. And last but not least, I had to drop plans for a Mac Classic version early on.

Perhaps the worst problem with the game as it currently stands is that it is a CPU hog. One of the reasons is that it polls for events (using the function WaitNextEvent) rather than using Carbon Events. If this were a full-screen game perhaps no one would have noticed, but early in the project I converted it into a windowed app for various reasons. I did get a couple of complaints from players about CPU usage and I may address it in a future update.

Limited Artistic Talent

My artistic skills are limited, and so are my tools. To model the game arrows I used graph paper and typed polygon coordinates into the code by hand. This was adequate for a puzzle game with simple screen elements, but in the future I’m going to have to invest some time and possibly money in order to make the game art more interesting.

My other artistic failure was Black Cube’s icon. It wasn’t incredibly bad, but it looked like it was drawn by an amateur. Fortunately a passing graphic designer named Jesse Holden took pity on me. After playing the first release of Black Cube he asked me if he could make me a better icon. I really like what he made and feel that it helps makes a good first impression when someone is about to play my game for the first time.

blackcube06.gif

Design concept

Looking forward, it is clear to me that the kinds of games I write in the future will be limited unless I start to involve someone else to help with the art assets. That’s a big decision for me to make because I get a lot of flexibility by working alone. If I don’t like how a game is turning out, for instance, I can make big changes without consulting anybody. Conversely, when my professional job becomes especially stressful I sometimes have to cut back on my programming hobby.

Reliance on Third-Party Code

I relied on sample code to get two parts of the game up and running quickly: Apple’s OpenGL setup code, and iDevGames’s “Core Audio Test” example for my sound code. In both cases there were problems introduced by the sample code that I almost didn’t have time to resolve. For the OpenGL code, Apple’s full-screen example does not allocate a sufficient depth buffer for most 3D applications. I spent over a week trying to figure that one out before I finally got help from someone on Apple’s OpenGL mailing list.

The problems in the sound code were easily fixed, but since I added sound last I would not have had time to fix any significant problems. It also meant that much of the beta testing did not test the sound code. That was an unnecessary risk, but I did have the fallback plan of releasing Black Cube without any sound.

Lesson learned: leave adequate time to incorporate third-party frameworks and code, and put them in the code early so that they get the same amount of testing as the rest of the game.

Final Thoughts

I am very pleased with Black Cube. Although it is not a game that appeals to everyone (“not twitchy enough” was a comment I heard), the people who like it seem to like it a lot. And of course it feels good to have written a game again, after so many years. I am indebted to Carlos Camacho and iDevGames for the incentive and helpful resources that pushed me to develop this game.

• Genre: Puzzle
• Developer: Matt Diamond
• Url: http://www.mindthecube.com/Black_Cube.html
• Team size: 1
• Released date: November 12, 2002
• Project length: 3 months
• Development hardware: PowerMac G4 400MHz

• Critical applications: Apple ProjectBuilder (v.2.0, April 2002 beta), Spark ME by TC WORKS, Pencil and graph paper

puzzle,OpenGL,3D,Carbon,ProjectBuilder

galder02.gif

Game screen

The player can at any given time only choose to remove a cluster of stones, and the same reaction always comes. Therefore, I started out thinking about the shape of the game board, and what kinds of moves could be added to give gameplay more dimensions. Being able to spin the rings to sort the stones came out as pretty obvious, and for a start, that was it. The other moves (collapsing and collecting) did not appear until the game was half done. Also, in the earliest plan, the Nexus didn’t exist. One could click anywhere to remove stones, even more like the Collapse form. However, when I recognized that there would be no space to draw the stones in the innermost ring, I had to cut that space off from the board space, and then and there its function became obvious—every cut would originate from there. The scoring system was there from the beginning, as well as the metaphor for the game: magic and arcana. Actual gameplay evolved heavily during development.

Learning the Toolbox

Making a puzzle game was something of an obvious choice. As I come from OpenGL with GLUT, I have for the longest time possible avoided learning the Mac Toolbox. Therefore, I wanted to avoid any complex interfacings with the system software (and boy, did I have to learn everything from the beginning!). However, it didn’t work out that way; Galder proved to be as dependent on the Toolbox as anything. Mind you, this is my first completed project, and my experience is from Allegro and the Standard C Libraries, and some simple demo coding, so having to sift through Inside Macintosh was the horror of horrors for a start—especially when discovering that QuickDraw doesn’t support rotated CopyBits(). Furthermore, I wanted to create the kind of game you play during breaks, just firing it up for a quick spin (pun… not intended), but one which is still somewhat addictive. I need to say that the addiction level came out weaker than I intended, but still it’s very quick-playable indeed.

The Plan

As for planning, the whole of it fit on an A5 paper jotted down on my way to work one morning.

galder03.jpg

Game screen

However, more than 50% of that planning was related to a feature that didn’t even make it into the code at any point. So, “failing to plan” did not, for once, turn into “planning to fail”, but that was only thanks to me having enormous amounts of time that summer. The only design document was my log book, which also turned into a simple diary. Usually, a thing such as this is influenced by a lot of people. Galder, however, was almost exclusively shown to and influenced by my fiance (and, of course, her little brother. You have software you think is bug free? Hand it over to an eight-year-old and it’ll break in no time!).

The Tools

Galder was built using the regular tools: compiler, image editing program, ResEdit, and some kind of sound editing program (the sounds weren’t made by me). As for doing things right and wrong, Galder developed fairly smoothly, keeping in mind that it was built without any plan or foresight, and with little knowledge of the Mac Toolbox.

What Went Wrong

Lack of Planning

If Galder had been more thoroughly planned, and had carried a technical specification, it might have come out a bit better, and could have been developed much faster. For instance, had I planned for multiple boards, I might have also planned for multiple high score lists.

galder04.jpg Game screen

Poor API Knowledge

If I had worked with the Toolbox¹ before, I might have been able to make my Toolbox code more efficient. Right now, as you can see if you look through the source code, there is a lot of redundant code, especially around the code for dialogs. The Preferences dialog grew enormous, simply because adding a working checkbox for a setting took around fifteen lines. By just building a few 10-minute test applications before plugging them into Galder, and by knowing what code parts need to use dialogs, I could have saved a lot of time and a lot of code.

No Backup

At one point, I used a hammer to fix my PowerBook G3. I tell you, never trust hardware. It is only by way of a miracle that Galder was finished. (I was amazed when I dropped the PowerBook onto the floor one morning and it actually fixed a problem with the keyboard.) I thought that the power supply to the PowerBook had finally given up, and thus I tried to rip out the hard drive to insert it into another Mac (which doesn’t work, I can tell you now). After severely damaging some parts that are still missing from the PowerBook, I used the hammer to straighten out some metal plates and reinsert everything that I could fit just to give the PowerBook a decent burial, but it magically turned on and hasn’t flunked since then. I had a backup, but not at the time of the hardware problem.

To summarize: plan your code and application specification. If there’s something you’re not sure how to do, then build test applications and make sure you know how to do things, and then plug them in. And above all, back up. Just put a .zip up on your web site every once in a while.

Overall, a good number of things went right, and can be attributed to proper code architecture and the keeping of a log.

What Went Right

Good Code Architecture

galder05.gif Design Sketch

The keywords here are: isolating parts of the code, keeping the Main.cpp slim (so that as much code as possible is isolated), using constants for anything that needs to be in many places (i.e. no numbers anywhere in the code, except for maybe a zero or one), and avoiding locking down specifications. The Galder board, for instance, was vectorized until the next-to-last build or something like that—up until then I could adjust the number of hours and rings, radius, nexus size, board position and such, by adjusting a set of constants. I still can, but it would require me to redraw the backdrop image.

Keeping a Log

By keeping a log I could look back to old solutions to problems, and check what I had tried to do about a problem before. Also, discussing the problem with one’s self eases the problem solving. It’s when you speak them out loud that you hear when something is wrong, and by writing instead of talking you don’t need to be embarrassed in front of your neighbors.

Coder’s Life

This is all about giving yourself what you need. I had the best conditions for programming this summer. Working as a subway toll booth assistant on weekend nights, I could work completely undisturbed for long hours (there are very few customers that don’t have subway passes at those hours). Therefore, if what you need is the company of a penguin, check the classified ads. I found not having access to the Internet from the subway actually helped. Thus, when I bonked into a problem, I could either do nothing for four hours and then check the Internet upon returning home, use the four hours to try to solve the problem, or fix other things in the code. Choosing between programming and staring at an empty ticket hall is an easy one.

Commenting Code

Oh, yes—commenting code is good. When building Galder, I learned so much during development that each time I returned to a code part I had knowledge that I wanted to use. I used comments as a notes system. I marked code parts that I wanted to revisit later. I developed a set of symbols for comments, for instance #O# marked a comment about possible optimization, #E# an operation that needed error checking, #P# for a possible problem, and so forth.

Conclusion

Galder was a good first try, I learned a lot from actually finishing a project. Fascinating enough, what I thought would be a few hours of finishing work evolved into over a month’s work. Since I failed to plan, I actually got to say, “Wait, maybe I’d like some sounds in this game!” So my advice to aspiring game developers is: Finish a game. Finish a Tetris clone and release it, and you’ll discover the true pest of things not going your way. They say, “90% of the time is spent in the last 10% of the project”—that is actually true.

¹ The Macintosh Toolbox was a set of resources, drivers, routines and APIs stored in the ROM of “Old World ROM” Apple Macintosh computers. See Macintosh Toolbox on Wikipedia for further information.

• Genre: Puzzle
• Developer: Ivan Milles
• Url: http://ivanmilles.mine.nu/oldgalder/
• Team size: 1
• Released date: November 15, 2002
• Project length: 4 months
• Development hardware: PowerBook G3 233MHz

• Critical applications: CodeWarrior, Adobe Photoshop 4, ResEdit

Tools

My development tool of choice is Metrowerks’ CodeWarrior 5.0. I noticed that Metrowerks was a sponsor of uDevGames so I crossed my fingers that I could win and get my hands on the latest version. For working on 3D models, Joe Strout’s Meshwork can’t be beat. It is great at creating optimized models and includes many features. Joe is also always improving Meshwork so if you are not familiar with it, take a look. Textures and other eye-candy were of course created in industry-standard Photoshop. Don Murta’s GLSee was also very helpful in converting the 3DMF files into OpenGL code. Long time Mac-first developer Pangea Software tools were also used: 3DMF Optimizer and 3DMF Mapper. The machine gun model was designed by David Drew and the sword texture was provided by Elizabeth Lim.

image2.jpg” alt=“GL Fighters”

What Went Right

Getting on the right track

The first version that I started was completely on the wrong track; I had been making every pose in Infini-D and then exporting it as a 3DMF, running it through 3DMF Optimizer and then loading it up in GLSee (which converted the 3DMF model into the C code) for drawing it, and had then copied that code into a function in my game. This was far too time consuming and pointless, and resulted in low-poly models that moved jerkily. Sometimes, developers need to look at the process and decide when the development needs to be turned on its head. It was a wise decision to change my workflow early on so that the game could be submitted on time.

Making my own animation program

I was used to making animations in Infini-D by defining key frames for various points in time, which the program moved smoothly between, so I designed my character animator on that principle. There is a separate model for every body part, and each of these body parts smoothly rotates to each pre-defined animation frame. Utilizing my own animation program instead of a third-party tool allowed me to easily add in the features I needed. After spending lots of time tweaking all the animations they ended looking like I wanted them to.

Beta testing. Lots of beta testing!

There is a computer lab at my school (all Macs of course) with a variety of modern computers, and a lot of interested classmates who were more than happy to have an excuse to play computer games between classes. This was very convenient for beta testing because the testers tried a lot of silly things that I would never have thought of, and found many bugs that I would never have found. The immediate feedback was also helpful in improving the game design.

Entering the uDevGames Contest

Around the time that the uDevGames Contest was announced, I had just started another project and was not actually going to do anything with GLFighters. The uDevGames Contest was exciting because I would have a vehicle to distribute my game and win some prizes, such as CodeWarrior, which I sorely need for my next project.

image3.jpg” alt=“GL Fighters”

The Eye-candy

I believe my game is an example of “programmer art” that is less terrible than the norm. All the models were created with Meshwork, textures created in Photoshop, converted to .TGA (Targa) with GraphicConverter, mapped onto the model with 3DMF Mapper, and then brought into the program by GLSee.

What Went Wrong

No planning

I had started with a very vague plan for a game that never actually became concrete. I just started with a guy running around on a platform, which became two guys, and then added various features such as changing backgrounds, multiple weapons, jetpacks, cloaking, multiple skins, first person view, AI, map editor, etc., which were all just random ideas from various sources jammed together. For example, I was once showing it to a friend and he just thought it would be nice if you could use two swords to fling people over your head with them, so I spent the next several hours making the animations and fixing the huge number of bugs that suddenly appear whenever I add anything new.

System requirements too high

I designed this game on a PowerMac G4 400MHz (it was powerful at the time!) which meant it was harder to know what needed optimization since it almost always ran at an acceptable speed. This will definitely be much harder now that I’ve got a PowerMac G4 733MHz with a GeForce3 and almost a gigabyte of RAM. Due to the high system requirements, many gamers could not run the game at acceptable speeds.

image4.jpg” alt=“GL Fighters”

Sloppy code

This was one of my first games in C++ so I was not yet aware of the wonders of #pragma mark - and descriptive function and variable names. Even now when I look at my code I can barely figure out what’s going on. I now group all functions by what they affect and put those great #pragma mark -’s between the groups. Also, I knew nothing about optimization so I used all sorts of unnecessarily slow commands like if sqrt(a&lt;sup&gt;2+b&lt;/sup&gt;2)&#38;<c instead of if a&lt;sup&gt;2+b&lt;/sup&gt;2&#38;<c^2, which does the exact same thing but runs much faster.

Working alone

It is much harder to be motivated when working alone; it is too easy just to take a break for a week or a month or two with no one to remind you that you have to keep going. Working alone also led to the game being released in an unfinished state. However, I’m now working with two artists and a programmer so adding new game assets or code has helped in my current development efforts.

uDevGames & the Future

Overall, it was a very rewarding experience and I was glad to see iDevGames pull it off. I’ll be interested to see the games that will be released in 2002. The number of prizes was also great and hopefully I can get a new version of CodeWarrior so I can work on Phantom Strike more effectively.

I am working on a new game called Phantom Strike. There are two artists and one other programmer helping me create this new first/third person shooter. So far, our progress has been very good. I don’t want to give away too much, but the game will (hopefully) be a bit like Halo but set in the near future of Earth.

• Developer: David Rosen
• Genre: Arcade
• Site: http://www.wolfire.com
• Team size: 1
• Released date: August 2001
• Project length: 2 months
• Development hardware: PowerMac G4 400MHz

• Critical applications: CodeWarrior, Meshwork, Photoshop, 3DMF tools by Pangea Software, GraphicConverter, GLSee