iDevGames

Last week’s news about Apple’s use of SproutCore triggered a lot of discussion about the future of rich Internet applications, run-time environments, and JavaScript frameworks. While SproutCore has been referred to as “Cocoa for the web,” its developer Charles Jolley says that the framework was “inspired by Cocoa,” not really a port of Cocoa. But what if someone ported not just Cocoa, but also an Objective-C runtime the runs entirely in JavaScript via a browser? Well, the developers at 280 North did just that.

• Related Link: Ars Technica article

Those new to developing on Mac OS X, or new to programming in general, can have a difficult time finding resources to aid them. Luckily there are some resources for those who need them.

Here are two resources for programming on the Mac.  The first is from MacZealots.com, called “Beginning Mac Development: A Solid Foundation”, it is a short article giving a series of steps and tips for those who want to learn to develop software for the Mac. The second is a free eBook called Become an Xcoder by Bert Altenburg, Alex Clarke, and Philippe Mougin, written for non-programmers. It is hosted on CocoaLab.com and has pdf versions in a variety of languages.  It is an excellent resource for new programmers. Links to these resources are below.

Related Links:
• Beginning Mac Development: A Solid Foundation
• Become an Xcoder

appleii.jpg

‘Choplifter’

When I tried to think of a game I could make that fitted that restraint, something based on an old memory of a 2D scrolling helicopter game came to mind. I later found out that this game was the Apple II classic “Choplifter.” My Dad told me that I played it a lot when I was three or four years old, and it had obviously left a mark in my mind.

With the idea starting to form, I began work. The first step was to make an OpenGL view in a window, and add player control. I used Cocoa and Project Builder, as I was already familiar with them, and within a day or two I had a simple Chopper sprite and basic (but very buggy) player controls, in a spunky metal window.

Then I decided that for this type of game I would need a level editor, so I started working on that. The level editor evolved alongside the game, and was hugely useful in the process.

early.jpg

Early Physics Testing

Continued Development

From there on in, it was a matter of refining and adding to what I had. I started adding collision detection, tanks, and eventually gunfire and explosions. Chopper evolved into something that I had never thought was possible when I had begun.

greyblue.jpg

Gotta Love that trippy grey-on-blue effect!

Graphics were slowly updated as I went. Usually I would put in placeholder graphics for a start, and change them when they annoyed me enough. Most graphics were overhauled at least a couple of times, if not more. Some graphics, such as the Chopper graphic, and the sky and ground, were updated or replaced at least half a dozen times.

An interesting decision I made about a month into development was to give the 3D effect. Chopper has a 2D engine. It’s all done with an orthographic projection so there is no z coordinate. As a graphical enhancement I decided to make it pseudo 3D. I added side walls to buildings, and depth to the grass. This made some of my earlier work redundant, such as angled tiles, and also made some things far more difficult for me later on. It may also have limited some gameplay elements, as it took a lot of my time to make things move properly. I believe it was worth it, though, as it added to the realism element of the graphics, and taught me a great deal.

While making Chopper I used “to-do” lists extensively. I would make a build, play it for a while, and write down any problems I found. I found this to be very useful in many ways. It was a good tool for finding what the player might see as a problem; it ironed out bugs, and there was a great feeling when I had an extensive list with all items crossed off. I also wrote down anything I thought might be added as an improvement to the game. Whenever I completed one task, I would build and run again, and write down anything I found wrong.

This part of the development process was always done on paper, as was any math that I had to do. I think a pencil and paper are invaluable.

What Went Right

I believe the most significant thing that went right was that I was a self-employed artist for the period, and as such was able to spend roughly 10 hours a day for the whole three months working on Chopper. Also, my girlfriend was overseas for six weeks of that time, and I probably worked about 15 hours a day over that period. Time was one of the constraints of the competition, and I had it in my favour.

explosions.jpg

Boom Boom

I was really pleased with how the particle effects turned out. I had played with the NeHe particle engine in the past, and this really helped with what I wanted to do. I found it quite amazing what a few sprites with different color/alpha/blend modes could look like, and saw potential for far greater effects using a similar technique.

Using Cocoa and Project Builder made the task a lot easier than it might otherwise have been. Cocoa is a very stable development library, and is well worth using despite its lack of cross-platform compatibility. Cocoa has taught me how to use classes and how to use them in a way that works well. I would have gotten lost in C++ and would have been more limited in METAL or other such options.

Despite the fact that I will probably never develop on such a limited machine again, I am glad that I used a G3 350MHz iMac to develop on. There were a few entries in uDevGames that as a result of being developed on higher-end machines run very poorly on low-end Macs, and could have been easily optimized to run much better. I was forced to optimize a lot throughout the process, just so I could continue to test it. This brings two benefits: one, I have learnt ways to optimize code, and two, Chopper can run reasonably well on a G3. I think a good way to develop games would be to code and build on a fast machine (aka G5), and test on the lower spec machine you are aiming for. I hope to do this in the future.

The iDevGames community and the uDevGames Contest were a tremendous help along the way. The combination of motivational and technical support has been amazing.

Another thing that went really right is that I got a great job as a result of developing Chopper. The experience and knowledge that I have gained have proved to be invaluable.

‘http://debug.jpg

Play Testing & Debugging

What I Would Do Differently Next Time

Instead of writing what went wrong, I thought it would be easier and more beneficial to say what I would do differently.

Number one on the list would have to be that I would do it all in 3D right from the start. As I mentioned earlier, pretend 3d in orthographic projection is a lot of work, and limits what you can do. This is going to mean that if I were to do Chopper 2 it would have to be a re-write.

hoverbuilding.jpg

Hmmm…. Floating Buildings?

I would plan more. When I started Chopper I had no idea what it was going to be like, only a very vague memory of Choplifter. If I had thought a little further ahead I could have structured better and saved myself a lot of headaches. Now that I have learnt more about my own capabilities and limitations I will be planning my next project a lot more carefully from the start.

Related to this, I would also refactor more. The code got very messy about halfway through when I changed the way map tiles were saved and loaded, and found I had to optimize. Instead of spending the day or three cleaning it all up and making it nicely structured, I just left it in a mess. The code turns into a dodgy DIY add-on spaghetti pile and it then takes a lot longer to add new features. Functions should also be shorter than I have made them, if anything just so it is easier to navigate through the code. The classes work well, but the functions within them need to be broken up into much smaller tasks.

I would write my own music and spend more time on sound effects. I spent about three days searching the net on a 56k modem for suitable music. It was a very frustrating process, and in the end the best I could find was less than satisfactory. A hired musician or music creating software is a must for decent music, and next time I will hopefully have the latter.

I would post less betas. I probably uploaded about 30 beta versions over the three month period, and although I received great support from people, many seemed to tire of it at the end. Fair enough too! Three or four betas would probably be a much better way to find out what needs fixing that I hadn’t already noticed while play-testing.

Conclusion

Chopper has been great fun to make. Most of all, it has been a great learning experience. If I had sat down before I began Chopper, and thought about what the best Choplifter clone I could make would be, I would not have imagined anything near the standard that Chopper turned out to be. I now feel I can do anything, and can’t wait to prove it!

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

• Critical applications:

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

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.

The second option was rejected after a long debate in iDevGames’ forum about whether or not the modern game player was tough enough for the kind of gameplay we grew up with 20 years ago. Option three was the one that I finally went for.

I knew that my choice would not appeal to a very large section of the game playing community. Pandering to the 3D high frame rate obsessed voter would have been an easier path to score votes, but I wanted to make a game that I would like to play. I wanted to make a game that requires some thinking to play and not something that you can just pick up, press fire and play.

I also suspected that, as my game would not have a story line, I would not be able to score maximum points in the voting. This was confirmed once a large chunk of the contest had elapsed. I fully respect the various issues that caused delays behind the scenes of the uDevGames 2004 Contest, but it is a bit demoralizing for a developer to find the scope of the project, i.e. the rules, going against them when clarification had been requested long before the contest started. Luckily by that time I had decided I was in the contest for the fun of taking part and not out to win otherwise there would have been one less game to vote for.

When it comes to game development I’m more interested in the logic side of the game (my other projects such as FlipSquare, Chromacell and Metamorphosis point to this) and less interested in the look and feel. I guess this is why I can’t get very enthused over the graphics stuff in FPS games even if I try. Industrial Revolution is a game that contains a lot of behind the scenes game logic.

Why Cocoa and Objective-C?

I briefly toyed with the idea of using C++ and SDL and making this a cross-platform game, however I was already working on yet another evolution of my Metamorphosis game using C++ and SDL so I wanted to do something different.

Ever since I first started developing on the Mac I’ve liked Cocoa and Objective-C, so that is what I decided to go with. I know there are some people out there who would not approve of my choices, but it was my entry and not theirs.

Organization

A very important component of any successful project is organization. In order to keep track of what I was doing and what I still had to do in the project, I used my Project Tracker application. The uDevGames Contest was a perfect chance for me to put Project Tracker through a proper test in a realistic environment. The diary function proved very useful in allowing me to keep my development blog up to date on the uDevGames site. Recording every new idea, class and feature and noting every change to the design as I went provided an easy way of checking back on what I had done. It also provided a very useful document for writing this postmortem.

Just over half way through development (September 20th to be precise) I was introduced to OmniGraffle by a fellow Mac developer who unfortunately failed to last the course in uDevGames 2004. Using a trial version of OminGraffle Professional, I produced a set of class diagrams so that I could get an overview of how everything fitted together. My intention was to publish these diagrams as part of the development blog but time did not permit this. The diagrams will be included in the source code released as part of the contest, however.

Priorities

At the very start of the contest I made the decision that I would not let the game rule me. I would do the development when I had spare time, and if the game failed to be completed in the three month window it would not be the end of the world. Taking this non-pressured approach ended up being more productive than trying to cram coding into every waking moment. I feel that knowing you have to get something potentially complex finished by a fixed deadline can sometimes lead to the ‘headless chicken’ effect where you spend the whole time sitting there thinking ‘I’ve got to do this! I’ve got to do this!’ instead of thinking about the actual project.

Most of the initial development took place during my lunch breaks at work. This meant that for the first couple of weeks I spent no more than about eight hours on the project. The first real long sessions of coding came about due to being stuck for hours on trains going to and from meetings.

Another opportunity for putting in some serious development time arose when I was away on holiday for a week. However, I again decided that a life in the real world was more important than the contest.

Even right up to the close of the contest I did not end up doing any of those “lack of sleep” coding sessions. However I must admit to losing more than a couple of hours around midnight on several occasions just playing the game and trying to claw back the money I spent on my railway!

Development Phases

Before I began coding I had an idea in my head of the distinct phases of development I planned to do. The plan was as follows:

• Get the basic Cocoa framework up and running (this used the initial steps I had previously written for the FlipSquare tutorial).
• Office screen — Text based display of player assets (such things as factories and trains).
• Map screen — Graphical display of player assets on a map (this would just use placeholder graphics and text labels).
• End of game turn logic
• Expanding transport network
• Invention Tree
• Inventors
• Computer players
• Final graphics

• User guide

It’s Still in Development!

Whenever I’m developing a game, or any other application involving some kind of graphical display, I always use placeholder graphics right from the start. The final, or even appropriate but not final, graphics can be added once everything else is working. You can see that an alien is in the wrong place just as well if the alien is a green square.

This placeholder approach was what I used for my menuing/button system. In fact, the system has been designed to allow full functionality and a quick game to be developed without any graphical work at all.

However I must say that I was slightly disappointed to find out just how many people who visit a game development site do not seem to understand this approach. If I was to get a positive vote for every person who questioned the point of having a tool tip appear beside a button that contained the same text then I would have won the contest! Apart from this little rant though I must say that the quality of feedback and interest for Industrial Revolution throughout development was very good. It was the public who convinced me it was worth carrying on after the rules fiasco.

How it Evolved

During the progress of the contest Industrial Revolution evolved. Some things were dropped before they were even coded. Other things were coded and then removed when it became obvious that they just did not work well. A couple of ideas only made themselves apparent during development.

The following is a list of what was dropped from the contest entry:

• Computer opponents
• Inventors
• Recruiting factory and construction workers
• Extended Invention Tree
• Additional transport upgrades

• Different maps

The following is a list of what was written but then dropped:

Shop Screen

Originally new transport and other things were to have been purchased from a shop screen. This screen was similar to the shop system in my uDevGames 2003 entry Garden Pests and a lot of the code came from that game also.

Office screen as main screen.

During early development the Office screen was the main screen where are all the moving of transport and other housekeeping was carried out. The enhanced Map screen made a lot of this functionality redundant so it was removed.

The following is a list of what evolved during development:

The Icon Wheel

Originally everything was controlled via buttons but this was changed to use a circle of icons along the same lines as NeverWinter Nights.

Technology Points

Originally the plan was to have various technology categories that the player built up, and reaching various levels gave access to new inventions. This changed to a system where the technology points were researched from a research budget and then used to ‘buy’ inventions. Had time permitted Inventors would have been required to build up these points using their various skill categories.

Unexpected Music

Due to the fact that Industrial Revolution had no story line to it I knew from the start that I would not be able to win the overall contest. With this knowledge I decided not to bother worrying about music for the game. This was the case right up until the first day of voting, when I showed the game to my line manager at work. As it happens, he has a Mac and a collection of music hardware and software and so he offered to create some music for me. The original idea was to have four pieces of music: title screen music, in-game music, good end-of-turn music and bad end-of-turn music for when a disaster had occurred. However due to time and file size limits we just stuck with the one piece of music.

Knowledge Gained

One of the goals of the uDevGames Contest is for the developers to expand their knowledge. In my opinion it is always easier to learn something new when you have an actual use for it, and the development of Industrial Revolution was the perfect opportunity for me to try out some new things.

Scripts

I’ve heard a lot of people going on about how using scripts for various things in games makes life in development a whole lot easier by cutting down on compile times when making small game changes. Personally I was not convinced about the idea as I find it quicker to hard code things than adding layers of additional work to process files. However the phrase, “Don’t knock it until you’ve tried it,” comes to mind so I gave it a go.

The area of the game I actually tried it out on was the in-game training tasks. One path I did consider taking the game down was to add levels that each required certain tasks to be completed. My plan was to have a script that would easily allow training tasks, and the possible level tasks, to be set up and loaded into the game. In total I must have spent about seven hours getting this system working correctly. There was no way that recompiling every time after editing the in-code task entries would take as much time as that!

What finally convinced me that I’d really wasted too much time on the scripts was that in order for me to test some additional game features using their own tasks I would have had to create multiple script files and keep copying and renaming them compared to just commenting out a couple of lines of code.

The script episode had not been completely pointless though as it gave me a chance to discover and really come to grips with a lot of Cocoa’s string handling abilities. I have put this knowledge to good use in some other projects that I’m working on.

Selectors

I finally got a handle on selectors during this project. I started off using them for a couple of simple things, such as calling the relevant screen drawing routine dependent on the current game state.

Next, I totally rewrote my Button class to use selectors instead of large chunks of switch statements.

Selectors also played a part in the training tasks, the Icon Wheel and Inventions, and briefly in the shopping system before it was dropped.

This new understanding caused me to become distracted from the contest with rewrites of sections of my planned Cocoa Desktop Games book.

The Future

The first task ahead of me is to fully document and tidy up the existing source code.

After the source code has been dealt with I will look at putting in the functionality that I had to leave out, with the exception of the computer opponents. I intend to get the game to a stage where it is completely playable with no opponents. Only when it is working will I add in the computer opponents.

However, before I think about computer opponents I’m toying with the idea of adding in some timers and giving the player the option of real time as well as turn based play, and even the option of mixing the two should they wish.

My other big plan for the game is to use the basic engine and build a construction kit for making similar kinds of games.

I also plan to produce a more detailed write-up of the development of the game and revised construction engine to turn into a series of tutorials, or maybe include it in my still to be completed book. Another alternative is to maybe turn it into a course at the iDevGames university should it ever come into being.

• Developer: Andrew Sage
• Language: Objective-C
• API: Cocoa
• Lines of Code: 8,352
• Critical applications: Xcode, Interface Builder, ClassBuilder (personal class building wizard app), OmniGraffle Pro (trial version), Adobe Photoshop, ProjectTracker, Microsoft Word
• Development Hardware: iBook G4 933MHz 256MB

• Test Hardware: iMac G4 800MHz 768MB

Tough Times Ahead

Right after the beginning of the contest my father’s health turned worse. Between his illness and passing away, I was busy for the first three weeks of the contest. Then, when I got back, work was in crunch mode and I needed to catch up on top of it all, pushing development of Headache! further and further off. Given those delays, it was important to keep the game within a level that was reachable before the deadline. Luckily, I had made sure to design the game concept to be scalable, allowing for basic gameplay, and letting things get added as time presented itself.

headache03.gif

Gator

What Went Right

Scalable design

In any situation where you are on a deadline it always makes sense to make your design scalable. We stuck to the core gameplay and made sure that was pretty good from the beginning. By doing this we created a fun game, and allowed ourselves to add some really great graphics and some fun extras that really enhanced the game and polish.

CVS and Multiple Development Systems

My uDevGames entry for last year, “Zed Nought,” was a pretty large game, and trying to get it to build on another system after the fact ended up being very painful. So, from the beginning, I made a decision to put everything into CVS, and to split my development time between my desktop and laptop machines. This also helped to act as backup for my source and artwork. An additional advantage to this approach was that I could do a clean checkout and see that it would build without my specialized environment.

headache04.jpg

Talking-heads

Great Artwork

Having a great artist really helped the game. It was already fairly fun to play, but once the final art made its way into the game, it really started to get a look of its own. A big part of the success of Headache! was in the art category. It is too easy for a lone-wolf developer to try to create art in a rush to ship the game. However, I feel that with each passing year the quality level of uDevGames entries will increase and having a true artist as part of the development team will become a must.

Flexibility

The final version of Headache! looks considerably different than I imagined it during the design phase. I had visualized a much more “cartoony” look and a very different sound for the music. However, the artist came up with a different look—a “realistic” one that really took the game to the next level. Also, when all testers said we needed the heads to somehow animate when they went away, it was added. However, care must be taken in how flexible you can be, as is illustrated by the next point.

headache05.jpg

Bad coder!

No Surprises at the End

There were a few things that testers (and my artist) really wanted to have me implement, but I was very wary of introducing instability at the end. I don’t mind being flexible, and flexibility had a lot to do with our success. However, there are some things that just can’t be added safely near the end of the development cycle. This was a hard lesson learned from last year’s contest. I added HID support to Zed Nought the day before the end of the contest, and then spent the next 12 hours trying to get the basic gameplay working again while adding in all of the art as well. Needless to say, I didn’t let that happen this year, and it paid off.

Memory Management

Rather than spending a lot of time hunting down leaks and agonizing over performance, I adopted and followed some good practices to keep memory leaks to a minimum. So in the end, I found only two real leaks using Apple’s tools. Of course, one was easy to fix while the other is still plaguing me, as I need to risk adding instability in order to really fix it.

Great Testers

I am lucky to have some friends that are really great testers. They all gave great feedback that made it into the game. They were especially good at helping me prioritize which issues needed immediate attention versus what could wait until after the competition. Unfortunately, I wasn’t able to get through the complete list of to-dos before the deadline of the contest.

What Went Wrong

Prioritization

There were some issues that could have been addressed had I tackled them earlier in the cycle. Some of this was because I was worried in the beginning about getting the basic gameplay done, and some of it was laziness. You always want to work on the fun stuff and find reasons to avoid the tedious stuff. Also, some of my feedback wasn’t available until later in the cycle.

headache06.gif

Everyone talks

Miscommunication

Although working with an artist was a huge boon to the game, one communication issue arose. During the concept phase, I had envisioned that users would be able to pick a “persona” that they could play as. This would be especially helpful with two player mode. However, it became clear that it wouldn’t be possible to put the characters into the game with the limited time we had left and make them look as if they really fit in the game. However, when I decided not to put the characters in, I unfortunately neglected to tell my artist that he didn’t need to make them. As he was following the design document, he spent a great deal of time creating the various characters. In the end, we weren’t able to use the many game assets he created and it would have been more fruitful for him to have worked on other areas of the game, such as the user-interface, which was left for last. Since he had spent so much time creating the characters, he was very disappointed that they weren’t featured in the final build. The good news is that I retained all the game assets, which opens the possibility for a two-player version in the near future so his characters will finally get the attention they deserve and will no doubt add yet more polish to the game.

A final issue that arose was with the witch doctor character that the artist had created. This character was pre-rendered and featured several poses based on the player’s actions. However, I had to omit the witch doctor from the game when the artist was unable to resolve a problem with the alpha-channel in the animations.

Coding Myself into a Corner

Given the time constraints, I found that I had coded myself into a corner. For example, the font renderer needed to have a way to change the color and a way to cast a shadow. However, the way it had been coded in the beginning was fairly specific to the original way it was being used. It’s too bad, because the text system is a great idea—it just had the wrong execution! The reason behind this problem lies in the next section.

headache07.jpg

Doug’s head

No Prototypes? Off with His Head!

One thing that worked really well for last year’s entry was the fact that before I added anything to the main app, I would prototype it out first. In this year’s entry, I started doing that. However, because of the system I was using, prototypes started taking up a large amount of my time. The overhead of getting a prototype up and running was getting to be much more than the time it took to implement the feature being prototyped. I’ve always found that implementing the prototype allows you to make all of your mistakes early. Then, when you rewrite the feature in the main app, you generally implement it much more intelligently.

Developing Quickly vs. Developing Correctly

I am gaining an understanding of the benefits of taking the time to code things correctly. Also, the idea of refactoring is one that really makes sense to me. Yet, for some reason, I failed to follow these principals as I should have.

The Artist Speaks

From Cartoons to the Real World

Once I had the basic concept of the game from Doug, I proceeded to make a concept game screen. The initial design document required cartoon-like graphics so I used a vector-based drawing program. The results were pleasing however I felt they weren’t enough to make the game win the graphics category. So I went back to the drawing board and went for a more realistic approach to the playing screen. Since the game was on an island, I incorporated island-like elements into the play screen, for example a jungle background, and the bamboo.

headache08.gif

Dr. Umfoofoo

Along with freehand painting in Photoshop, I used some royalty-free image clipart. The clipart went through numerous filters and other transformations before being added into the screen. To move away from the ultra-clean look, I tend to add a slight amount of “noise” to each element. In addition, the contrast and brightness was altered. These two steps gave the graphics a more “computerized” look—as though they were rendered in a 3D program.

Each element was stored in its own layer and then saved separately to give the programmer complete flexibility in layering the graphics on the game screen. Since the design document called for slight animation outside the “head-drop zone,” using separate layers would also allow for such things as insects flying in front of and behind different on-screen elements. The idea of adding extra animation to the game was very good. For example, the insects I mentioned. We also planned on having other animals pop in and out of the game, fully animated. However, since time was limited, they were dropped from the final game.

Where the Brush Ends, 3D Begins

headache09.gif

The heads

The topic of severed heads and how to make the graphics for such a game had me wondering if it would be “kid-friendly.” I felt that kid-friendly would be a necessary quality if we were to show the game at MacWorld (providing we won). I’m a strong believer that more games for the Mac need to have a “console-style” polish. So I made the heads as cute as could be. In making the heads, I first modeled a basic head shape in Cinema 4D. I then applied different morphs to the heads to provide for some variances, so the heads wouldn’t be static but provide some on-screen character, much like the classic Macintosh game Snood. In all, I made seven head colors with seven frames each. Although not listed in the design document, I also provided “evil-heads” that might be used for future versions of the game.

The game screen used a realistic art approach while the sprites retained some of the cuteness that the original design document outlined. Using a 3D application allowed for great time savings in creating sprites and also in animating them.

One World, Many Races

The initial story of the game had a cast of characters along with some background information. These characters would be used in the game to add extra polish and some interesting opponents in the two-player mode. A great part of my time was spent creating these characters in Cinema 4D. One interesting point was that I wanted to represent a wide range of people. Most games have a hero, and he is almost always an Anglo-Saxon male. The characters I created would allow gamers from around the world to see someone more close to home. I’d like to see more developers think in this manner! As Doug mentioned, although the characters were created on time, they weren’t incorporated into the final version for the uDevGames contest. Hopefully we will see a two-player mode added in the future and the debut of the witch doctor animation, which I was especially fond of.

headache10.gif

Poor menu system

It’s the Interface Stupid!

I often feel that many Mac games fail to inspire due to their user-interfaces. Looking at the platform, some companies really stand out in their approach to bring console-like menus and screens to their games. This is especially important as the demographics for Mac game players is changing, and also allows for easy localizing. With the character graphics taking a great deal of time, I left the user-interface elements for last. I envisioned having the witch doctor on the screen watching the characters’ mouse movements or interaction with the buttons. For example, if the gamer attempted to type the wrong key for the high score board, the witch doctor would shake his head “no.”

The buttons would also need to provide visual and audio feedback when selected and pressed. Time constraints forced us to use basic buttons—far below the quality level that I had envisioned! Looking at the final playable, I feel that we let gamers down in the user-interface. The buttons seem to be arranged randomly, and don’t offer the easy-to-use concept that we had planned. If I’m on the team for next next Headache! version, the user-interface will be my first priority.

Odds, Heads, and Ends

The talking-heads and gator were inspired by a fun “monkey” game by another developer. It’s a great idea, however I felt the font size and style was a tad hard to read on many screens. Hopefully Doug will address that problem and also include the many talking phrases that I created. The sound and music kept with the spirit of the game, but it sometimes gets a little repetitive. This is most likely caused by the 10MB limit. I can see the sound and music going to new heights if the game goes commercial, due to the fact that we had a great library of sound and music assets that were never utilized. Although I offered some pointers on gameplay, they were mostly for polish. Since the columns-type genre has been visited by many developers, I was always trying to push Doug towards more originality.

GoodDoug’s Conclusion

In the end, there are some very important lessons that I have learned. Using CVS and two machines for all of my coding made it simpler to deliver my code at the end of the contest. Flexibility is great, and it can be maximized by doing prototypes and being conscious of future refactoring. Also, taking time to keep all members of the development team apprised of all issues should make things much smoother next time. I’d like to give a special thanks to the people and groups that made Headache! possible: My artist Amaha, the staff at “Java Junction” on Seabright Ave. for keeping me caffeinated, my hockey superstar teammates on Strychnine and Fuzzy Bunnies for playing hard, and most of all, my wife Sandy and son Zachary (and the new one on the way, Kahuna). And of course to Carlos Camacho and the crew at iDevGames.

• Genre: 2D puzzle
• Developer: Doug Whitmore
• Url: http://www.gooddoug.com
• Team size: 2
• Released date: November 12, 2002
• Project length: 2 months
• Development hardware: PowerBook G4 800MHz and PowerMac G4 Dual 450MHz

• Critical applications: ProjectBuilder, CVS, OmniOutliner”:http://www.omnigroup.com/applications/omnioutliner/, BBEdit 6.5, Adobe Photoshop 7.0, Cinema 4D, Bias Peak

Even without full documentation on Cocoa, I still decided to use this framework due to the power of object oriented frameworks, and couldn’t bring myself to use Carbon. I also think that Carbon should only be used for transitions from Mac OS 9 to Mac OS X and not for new Mac OS X applications.

The Tools

Not only is Mac OS X a joy to develop with, Apple has also provided two stellar tools for developing programs for their new OS. On top of this, Apple distributes these tools for free; they can be found on one of the CDs that came with your copy of Mac OS X. You can learn more about Project Builder and Interface Builder at Apple’s Developer website. The coding for Evolution was created entirely with Project Builder and Interface Builder. Let me quickly cover what the two tools do:

Project Builder

Project Builder is an IDE that offers an editor for source code (and other types of files like RTF or property lists, among others) and provides a graphical front-end for the compiler and linker, as well as a graphical debugger. You use it to type the source code and punch buttons that cause the compiler to turn those funny lines of code into a nice little program. The tool covers a great variety of languages such as Java, C/C++ and, most important, Objective-C.

Interface Builder

Interface Builder seems to be a nice GUI editor at first glance. But it’s much more. You can derive classes within Interface Builder and connect the objects of your GUI (like buttons or pop-up menus) to methods, so-called actions, of the class that will control the GUI without writing a single line of code! Sounds confusing? Actually it’s very easy. Say you have an OK button in a dialog and you want the dialog to disappear when the user clicks that button. To achieve that you connect the button in InterfaceBuilder to the CloseThisDialogAndBeDoneWIthIt: action of the class¹ that controls this dialog. You save the Interface Builder file and all the work is done for you.

image2.jpg

The art for Evolution was created in Adobe’s Photoshop. The little critters and screenshots for the on-line help were saved in TIFF and JPEG format and added to the project in Project Builder. Adobe’s WYSIWYG HTML editor GoLive was also utilized to create the on-line help. With the exception of the Adobe products, game development with Mac OS X tools allows developers with any budget to enter the world of Mac game development.

What Went Right

Some might see a two month deadline as a great hurdle towards completing a game. However, I was confident that I had a solid design document to help keep my focus and that my choice of tools would allow me to submit my game on time. Sure enough, both factors contributed to the first playable being done in record time. With a playable version, I was able to quickly move towards adding new features and do extensive testing. The structure of the code also allowed new features to be added without breaking the game.

Choosing the Cocoa framework was a smart choice in that it enabled me to use the RAD tools Apple ships with Mac OS X and build on a well-tested code base. The ‘Learning Cocoa’ book from O’Reilly press contained about 95% of all the information I needed to write the game!

Another point that went right was having a helping hand when I needed it. Due to the differences of Objective-C to C++ there were a few bugs I just couldn’t spot. Christian Schaer helped me tremendously in the final stages of the game.

iDevGames opened the uDevGames Contest to Mac game developers from around the world, and I thought that game players from non-English speaking countries would want to play my game (and hopefully vote for it!) Thus, I made an early choice to localize the game to several languages. This decision proved to be extremely wise as I received comments from players who appreciated the fact that I took the time to provide a game in their language. The effort to localize the game was a piece of cake and I’d like to thank my translator, zozo, who completed the French translation. I added a German translation myself and only a few days after the first release I have been offered a hand in translating the game to Spanish for a future release.

image3.jpg

On the audio front, it always helps to have real musicians providing the soundtrack. Axel from Lunatica was very kind in allowing me to use their songs.

What Went Wrong

Although I had my design completed ahead of the coding process, and I used excellent tools, I admit that I wasted time during some periods (a combination of playing the Airburst game and my constant posting on iDevGames’ forum). If my project management skills matched my coding skills, I would have added many extra features such as Network play and additional AI players. Hopefully with the contest behind me, I can enhance the game further if enough players bug me.

I mentioned that using Cocoa was a boon to developing Evolution, but I must admit that I did have some rough periods during the development process. I had to look through sample source and tons of Cocoa documentation before I could complete a (sometimes minor) step. I think it was time well spent because I needed to learn the framework anyway. However, I’m sure that the drawing routines suffered from my lack of knowledge.

Audio problems also plague the game. It seems that the music skips due to the Evolution algorithm hogging the CPU. For some reason I never noticed that during debugging, most likely because I turned the background music off after a while—I’m fixing that in my next release.

When I started Evolution it was called Chainreaction, and instead of Amoebae the players placed bombs on the board. The situation in the news made me rethink the design with a less violent theme. In the end, I’m glad I did.

image4.jpg

Looking ahead

I’m planning to correct the problems with the music and re-work the drawing algorithm. I’m also eager to add in network play. After those problems are fixed, I plan to write a series of articles about the game and its use of several features of Cocoa to show how easy it is to implement a load/save game feature, proper use of the user preferences, sheets and localization. Apart from that I’ll write an IRC client using Cocoa.

Working on my uDevGames entry was a lot of fun, and I was surprised to see the number of Mac OS X entries. I remember that there was a thread in iDevGames’ forum from developers who didn’t want to release their source code. Although I’m a tad embarrassed to show my peers my own code, I think it is healthy for our platform to have as much source code as possible. This way, we can all become better developers and build a stronger gaming platform. I did my best to make my source code readable and really hope that other Mac game developers can benefit from my game. I’m also eager to look at the source code to the other entries as well! I strongly support giving back to the Mac development community so if you have any questions about the code, drop me a line.

Since most developers have heard of uDevGames by now, there’s no doubt they will be down in their labs hard at work on their uDevGames 2002 entry. This means the standard will probably rise even higher next year. I’m eager for the challenge and look forward to battling with you all for the honors of uDevGames 2002. My only request would be that iDevGames allows for a three month development duration so I can spend two months killing time.

¹ A class is a collection of data and code that works on this data.

• Game: Evolution (6.7 MB)
• Genre: Puzzle
• Developer: Sacha Saxer
• Team size: 2
• Released date: September 19, 2001
• Project length: 2 months
• Development hardware: PowerMac G4 Cube

• Critical applications: ProjectBuilder/InterfaceBuilder, Photoshop

The Tools

I used CodeWarrior 5 and ResEdit for all the programming and development. On the graphic front, Photoshop 3 and GraphicConverter were utilized to create and edit textures for the game. The sound samples came from various freeware sound libraries. As the 3D models didn’t contain complex geometry, they were coded in directly.

image2.jpg

alt=“Silly Balls”

What Went Right

One of the best decisions I made was to create an editor for Silly Balls. Although this took some time, the amount of time saved in creating all the levels was enormous. The editor is far from perfect and still requires the use of ResEdit for complete level creation. However, having the editor allowed me to submit the game on time. I’d like to advise new game programmers that a good level editor will not only save time, as in my case, but also contribute to the game’s development process.

The format for the levels was flexible in that I was able to add in extra features without the game engine breaking. This is another tip for new programmers: when creating your format to contain your game’s level, plan ahead so that new features can be added without the need to create major modifications to your game code. I hope to continue development on the level editor so that I can release it to the public in the future.

What Went Wrong

As you play your own game continually from concept to finish, your own view of how easy and how good a game it is tends to change. Hence the importance of outside play testing is crucial. This is something I didn’t do until a little too late. Silly Balls is far too hard in my view, although I can complete it without losing a life. The other major problem with Silly Balls was the lack of a design document for the uDevGames 2001 version. My plan was to release the game for uDevGames and continue work on the game even after the contest was over. However, knowing which features should make it to be included in the contest version became a challenge. Looking back, I should have made a concrete decision on what features would make it into the submitted game, and which features would be added at a later time. The music was also a weak point in the game. It was added at the last moment so I wasn’t able to test it thoroughly. (Note to self: never add features on the day of final submission.)

image3.jpg

alt=“Silly Balls”

Conclusion

As for the future, my next project is to Carbonize (and debug) Silly Balls. Then I will continue to work on that and a 3D tank game. I’m also looking to enter the Independent Games Festival ‘student competition’ after Christmas. Looking further ahead, I plan to move away from Carbon and concentrate completely on Cocoa and Mac OS X. Like many developers, I have always wanted to write an adventure game, so perhaps I might go in that direction when the time is right.

I found that it was great to work against a deadline, and it made me concentrate on finishing what may have taken years otherwise! My advice for uDevGames 2002 developers would be to get your game out as soon as possible. This allows for more play testing and polishing of the game before the voting period begins.

My last comment concerns public feedback. It is a vital process for fine-tuning a game so that it is fun and runs well on a variety of machines. However, I recommend that you find some committed beta testers early on and don’t count on the public for 100% of your testing. The reason is that some players may not be eager to re-download a large game due to limited connection speed or interest. I think that setting up a home page specifically for your game entry that allows gamers to easily add their comments or to download small patches before the voting begins would be a smart move.

Overall, the competition was a great success and the benefit to the community in terms of working code is enormous. I look forward to browsing the code from the other games and hope that uDevGames 2002 will be an even bigger event.

• Developer: William Thimbleby
• Genre: Arcade Puzzle
• Site: http://www.www.tribar.dabsol.co.uk
• Team size: 1
• Released date: September 12, 2001
• Project length: 1 month
• Development hardware: G4 400MHz MP

• Critical applications: CodeWarrior, ResEdit, Photoshop 3

3D,puzzle,RedEdit,Cocoa,Carbon,CodeWarrior