iDevGames

On tonight’s broadcast of The Gamesome Mac, the Mac gaming radio program, hosts Sean Smith and David Finley, together with iDevGames’ Editor-in-Chief Carlos Camacho, host the uDevGames 2004 Awards Show. Now in its fourth year, uDevGames is the annual independent Mac game development contest. Sponsored by iDevGames, the Macintosh game developer community, this year’s contest has attracted 31 entries and over $33,000 in prizes.

“This year’s games are the best ever. The quality is way up,” said Carlos Camacho. “Contestants had three months to develop a Mac game from start to finish. So that other developers can learn from their experiences, all games and source code are made freely available, and tonight’s winners will publish post-mortem reports on the development of their games.”

Not only will Sean, David, and Carlos announce the winners and runners-up from uDevGames 2004, they’ll also talk with some of this year’s contest developers, take questions live from listeners in The Gamesome Mac’s chat room, and give away over $1,400 worth of listener prizes.

The uDevGames 2004 Awards Show can be heard live on MacRadio from 6 to 8pm Pacific Time, 9 to 11 pm Eastern (Tuesday from 0200 to 0400 UTC), and on demand thereafter. Listeners can tune in at The Gamesome Mac’s Web site, where they’ll also find archives of past programs. QuickTime 6 and a 56K or faster Internet connection are required.

The Toolkit

As an off-shoot to my game development, I also maintain a codebase called SDLGameBase, which is a simple setup, event loop and teardown routine for 2D games. So of course the choice to use that was a bit of a no-brainer as far as I was concerned (more on this later). It uses C++ as the main language, and I did most of my developing in Xcode, apart from some external libraries which I built at the command line using the standard UNIX configure & make approach. For graphics I tend to use Photoshop for drawing and compositing images, and most of the sprites were hand drawn by me.

First Steps

Originally, I wrote a small demo application called BuzzTest, which simply had a bunch of flies flapping their way around the screen. For added interest, I had a fly-swatter which followed the cursor, and could be used to squish the flies, leaving a nice bloody trail behind it. But this was just a distraction and not really a start on the game proper. However, it did throw up a few problems…

SDL — Just Too Slow

I was using the standard SDL blitting routines, which were causing problems when I had lots of flies on the screen at one time. Once I was drawing a background image as well as all the sprites, the frame rate slowed right down to a crawl, even with the addition of a dirty rectangle system so that I wasn’t redrawing the entire screen each frame. At this point I still had bags of time left, as it was only a few weeks into the contest, so I decided to bite the bullet and go to OpenGL, purely for the speed boost. This was actually pretty straightforward to do, since I was able to keep most of my SDL setup code. I rewrote most of my drawing code to abstract away the OpenGL calls, which was fine since I only wanted to do 2D graphics anyway. The main sticking point here was getting the images to load correctly and bind to textures so that I could use them to texture quads which I then would draw to the framebuffer. I also had to find a decent font rendering library, and I eventually settled on FreeType and FTGL, which were an absolute nightmare to build and bundle with the game. Eventually I managed to build and link static libraries which were distributed within the game bundle.

Real Life Kicks In

Towards the end of the summer and at the beginning of the university term, I found I had very little time to work on Frogspawned due to work and study commitments. Eventually it got to the stage where I had a frog who could jump around the screen and eat flies, but not much else, and there were only two weeks left until the deadline for entries. Undeterred by this, I abused the goodwill of my other half and several gallons of coffee, and put in a string of late nights to get the game done.

Cutting Back

Obviously, in this time period I was never going to get as much done as I’d originally hoped, so I decided to abandon having several types of level, and stick to only one scenario—the pond. I had originally intended the game to progress through several scenes: the pond, the meadow, the railway, the road, and finally the school, but this was not to be. However, in the last few weeks I did manage to draw all the graphics to replace the placeholders I had used during development, adding 10 levels to the game, a time limit on each level, as well as a main menu, instructions, customized controls, and all the little features that go towards finishing a game. I even managed to find a decent free music loop to go into the game, but as comments showed, perhaps it wasn’t the best choice of style (hard-rocking guitar) to go with the game. Never mind…

The Final Project

I did manage to get the game in on time, in a pretty much complete state. I didn’t get as much done as I’d have liked, but then I wasn’t taking the whole project particularly seriously in the first place. Overall I’d say I was happy to have turned out a half-decent game in a very short space of actual development time, and I’m now going to take a bit of a break until the new year, when I will start work on a new project entirely!

What Went Wrong

Debugging

I spent a long time debugging near the beginning of the project to get the flies to be released from memory properly in various situations where they could be eaten, as in some cases I had several pointers to the same data kicking around—probably due to bad design on my part.

Project Management

The timing of the whole project was quite awry. This was mainly because I had no plan that I was trying to follow, and I’m still not too bothered about this. Most of the work was done in the first two weeks and last two weeks of the contest!

What Went Right

OpenGL

Switching to OpenGL was a big win in terms of the speed boost it provided. It will also be a big help if I ever want to build a truly 3D game world. With most of the boilerplate code written and tested, I am quite happy that I can take it and run.

Graphics

The game graphics were great fun to draw, as all the frog poses were done by hand in Photoshop. I’m not much of an artist, so I was pretty chuffed with how they turned out.

What Next?

The main thing that I will be taking from this project is the OpenGL graphics code. I am planning to add it into the next release of SDLGameBase, which should hopefully make it a much more useful code base for both myself and others to use. Apart from that, I intend to leave this game alone. If anyone enjoys playing it, then that’s great—if not, then at least I enjoyed making it!

SDL,C++,Xcode,OpenGL,FreeType,

Project Overview

Kill Dr. Cote was originally a game that a few friends and I made with Hypercard in 1995. It was a simple, black-and-white top-down shooter, but was quite popular on AOL and got a lot of e-mails.

In the remake, you’re thrown once again into the oddly octagonal laboratory of the diabolical Dr. Cote. The object is simple: “Shoot Everything.” Use the keyboard to run around like a maniac while using the mouse for your firepower. Aim, click to fire, and right-click to chuck a grenade. Wave after wave of zombie test subjects will hound you, with the occasional visit by the Doc in person. It is simple, intuitive, and very, very addicting.

Team and tools

The dev team this time around was just myself. As a result, I knew right from the start I’d have to eventually wear every hat, and get everything done much faster than usual. There were some big lifesavers along the way (Garageband and Photoshop) but next time around I definitely want to team up with a talented artist.

Xcode was the IDE of choice for this project, as it’s free and easy (enough). For graphics, Photoshop rules. Period. You pay for what you get, but it’s so worth it. For sound editing, Audacity ended up being the tool of choice, and turned out to be a lifesaver for its ability to export to Ogg Vorbis. For music, I used Apple Garageband along with a Juno-106 MIDI synthesizer.

For additional libraries, I used OpenGL, SDL, SDL_mixer, and SDL_image. SDL was a great decision—it made a lot of mundane things very easy, and it meant that the bulk of the project was cross platform. There’s a Windows port of Kill Dr. Cote being worked on as I write this.

What Went Right

Sticking to the original vision and designing everything first.

During these three months, I’ve kept a notebook for the design of Kill Dr. Cote. It’s a 100-page notebook filled to the brim, and everything is written down in there somewhere. Whenever I envisioned something, it went in the notebook to make sure I lost none of the details. The game follows this notebook 99.9 percent of the time. The list of guns I came up with in the first week of the contest became the exact selection of guns in the final game, except for the mines, and they all behave exactly the way they were designed.

I wouldn’t say it’s as much of a design document as it is a design journal.

Having awesome gameplay and controls from day one.

As soon as I had my first prototype finished, I knew that winner or not, this game was going to kick some serious rear. I can modestly say that the gameplay rules—even better than many commercial games. This gameplay really motivated me and gave me tons of momentum.

I’ve always firmly believed that controls make or break a game. I believe it even more now. Kill Dr. Cote’s controls are simple and intuitive. One hand moves, the other shoots. They’ve been that way since the original prototype, and they haven’t changed, aside from adding more key quads for movement (keypad, and IJKL). Having them customizable would make them perfect. The result is that the game, despite its difficulty, is incredibly easy to pick up and play.

Amazing support from friends, family and peers.

Seriously, I couldn’t have done it without you guys. My friends and family were very understanding and supportive of me during these three months. Things were bumpy at some points, but eventually everyone realized how much this meant to me in terms of both my future career and personal fulfillment. I have friends who let me bring my laptop with me when I would come to hang out, tell nearly everyone they met that they knew a game designer, and even sneak me into their yoga classes to keep me in halfway decent shape.

The enthusiasm from my peers has been overwhelming as well. The first feedback on Kill Dr. Cote I ever received was “Holy CRAP this game is fun! I could hardly tear myself away from it to write a reply…” (Thanks Alex!) The response to the game has been overwhelmingly good. Upon releasing the game to the public (uDevGames, MacUpdate and MacGameFiles… holding off on Apple and VersionTracker for now for bandwidth reasons) I got a lot of emails from new Cote addicts—enough to start a mailing list. It’s really awesome to get another email or two a day saying how much butt the game kicks. It’s been constant fuel for me throughout the contest.

Burnout recovery.

About halfway through the contest I burned out—hard. It was a result of running into a huge roadblock with the graphics (see “What Went Wrong”), overworking myself with everything else, and realizing that I had neglected my classes so much that I had to drop some of them. I was working myself to the point where I’d literally fall asleep out of my chair and sleep all night on the floor. All I could do was open up Xcode, stare at the code for a bit, then I’d need to take a nap.

So I started taking days off. I felt I did a good job of taking weekends and sometimes entire weeks off from coding. I set aside “asset weekends” where I would only work on drawing or music. (From my blog: “If I catch myself with Xcode open at all this weekend I’m going to kick my own a**.”) I took several trips out to California: a week-long trip to Venice Beach, and a weekend to my sister’s apartment in Fullerton which I barely remember except for the excessive drinking.

Because of these extended breaks I was able to come back to the project completely rejuvenated and ready to kick butt. Hope you’re taking notes, EA.

What Went Wrong

Focusing too long on gameplay.

Way too long. I didn’t even have graphics or music until the third month. The player and Dr. Cote didn’t have graphics until the final few days. The graphics that I did put in ended up being rushed and sloppy. The main in-game music track, “Brain Eating *****,” was meant to have another verse complete with synth solo. Never got it. I copied the first verse, changed the few chords at the end, and looped it. The slashing sounds you hear are corners being cut.

So what was I doing the whole time? Gameplay—more guns, more explosions, more enemies, more carnage, and it all had to be awesome. While I personally don’t consider it a mistake, I can see how it could have hurt my contest scores in graphics and sound. My personal priority was to have a game that was fun as heck, and addictive in that good, one-more-game way, and not have a game that skimped on the fun just to maximize my votes in as many categories as possible. Think I’m just saying that? Check out the story.

It was a personal decision. I suppose whether it was wise or not depends on your attitude toward games and toward the uDevGames Contest.

Not having graphics style pinned down.

This drove me absolutely nuts, and was a major reason behind my burnout halfway through the contest. The original design had everything in 3D. Player, zombies, Dr. Cote and the robots were all supposed to have 3D models. The player would have skeletal animation with keyframing, as would the zombies. You could also blow off arms and legs and they would separate from the skeleton and move independently.

The problem? I had absolutely no freaking idea how to do any of this. I’d never done 3D before, never mind skeletal animation, and my 3D modeling skills were… well, I have no 3D modeling skills.

The alternative was to make everything 2D sprites, and just put them on billboarded quads. But it looked weird, and didn’t seem as cool. I went back and forth on this literally a dozen times during the second month. It caused me all kinds of stress. I kept trying to learn skeletal animation, but I had no idea how to create the required assets. None.

What eventually tipped the decision in favor of 2D sprites was Excessive mode. I loved tweaking the guns to make them ridiculously powerful, and I finally decided to put them all together in a difficulty level with about 500-1000 zombies at once. There is no way in the world I’m putting 1000 3D models on the screen. I loved Excessive mode so much that the only way to make it remotely playable would be to make all the zombies 1 quad.

Very rushed and fatally buggy November 6 release.

The weekend before November 6 was extremely rushed and stressful. The player graphic still wasn’t in, Dr. Cote didn’t even exist yet, and many key pieces of the game were missing. The only sleep I got that weekend was by accident, when I’d roll out of my chair and just not want to move for a few hours. To top things off, this was the weekend after I had miserably failed a midterm, and had made the decision to drop two classes.

As a result, a lot of bugs snuck through when I put that build up—really big freaking bugs with sharp teeth and acid spit. The next morning I had emails saying basically that the game was awesome but it keeps crashing, or has stopped running altogether. I wanted to scream. I watched the download count shoot up in horror. It was my first finished game and it fatally crashed on launch.

So what did I do? I took the day off, (see “What Went Right”), actually went to my one remaining class, had lunch with a friend, ate sushi, had fun. It was rejuvenating, and that night I fixed every last bug, and answered every last email. In my replies I offered to continually keep people updated whenever I made more bug fixes and updates. Everyone was very receptive, and that first round of bug reports became my mailing list.

What I learned from uDevGames 2004

A better understanding of the development cycle.

While I was developing, I was able to schedule very effectively. I had monthly, weekly and daily goals, and achieved the vast majority of them. That is, up until I released the first close-to-finished build on Halloween night (build 4). It added a ton of new stuff, and it got lots of feedback and suggestions. As a Mac app there were still a lot of holes, and there were a lot of bugs. These all needed to be addressed. The problem is, addressing all of them pushed everything back about a week and a half. With about a month left in the contest, that was about a 33 percent increase in the time I would have required.

Everyone’s always told me that debugging something takes just as much time as coding it in the first place. I believed it and braced myself but still wasn’t ready for the vast increase in time.

Finally, it’s hard not to suffer from feature creep when you get tons of emails all with the same few suggestions, many of them really cool and feasible. Upgradeable weapons and Internet high scores? Too awesome not to have in the game, but everything adds to the time budget.

Being a lone wolf sucks!!

The advantage of being a lone wolf is that the resulting game is purely my vision, and that makes my ego happy. There are no arguments, no group discussions/votes over some inane nonsense like the initial upward velocity of the zombie giblets. What I say goes, because there’s no one to argue with me. This makes things go way faster. Plus, there’s no one to check my sick sense of humor. “Shoot Everything” probably never would have made it into the game if it were put to a group vote. Honestly, how many serious developers would be willing to throw away any chance at winning the story category for a few tongue-in-cheek laughs?

However, the disadvantages turned out to be many. The most obvious is that I had to wear all the hats: Programmer, Artist, Musician, Marketer, and Producer. The result is that I had way more mutually exclusive work on my plate than I really wanted, and the quality of the game suffered because less of each got done. The other obvious disadvantage is that I’m not particularly good at a few of the hats. I’m horrible at art, and it’s obvious from the sprites. I hate doing it, and it hates being done by me. I have a newfound respect for artists, and I definitely want to bring a talented artist along for the ride next time. As for music, I love working on it, but I’m still an amateur musician, and it takes time. Finally, working alone means there was really no one there for constant motivation. Having a teammate means having someone to potentially let down, and that always fires me up. Having another person working on the game with me may very well have prevented my burnout halfway through the contest.

Future plans for Kill Dr. Cote

There are a lot of ideas I had for Kill Dr. Cote that never made it into the game. There are also a lot of ideas I had that I knew I’d never be able to do with my current skills and time budget, things like multiple playable characters each with a different weapon set, boss monsters, different laboratories with traps; the list goes on. The only way to truly realize all these ideas would be a future sequel.

As for the game as it is now, I want to implement all the minor features that haven’t been put in that I had planned to finish before the contest deadline. Things like the robotic hunter-killers, a cooler SNES-style cinematic intro, upgradeable weapons, and Internet high-scores, along with a round of bug and gameplay fixes. I’m definitely not done with the game just because the contest is over.

After that, I’ll probably create a website to host the Kill Dr. Cote Internet high score list, and any future projects. My personal site just doesn’t do the game justice. It needs a proper vehicle!

There will be a point however, where the planned changes will have to be put off until a sequel. I love Kill Dr. Cote but I’m eager to move on to my next project. I have a lot of cool ideas that I’m sure fans of Kill Dr. Cote will love. Someday, though, you can count on me returning to the laboratory: “Kill Dr. Cote… Again.”

Conclusion

Truthfully, these have been three of the most exciting months of my life. A look at the original Kill Dr. Cote from 1995 makes it obvious that I’ve been working towards being a game developer since I was a kid. uDevGames gave me the motivation to follow through and finish a game, and getting to know and prove myself to my peers at iDevGames has been a really wicked experience. Regardless of how the votes turn out, no gamer nor developer can deny the blissfully addictive butt kicking they get from Kill Dr. Cote, Gib on!

Xcode,OpenGL,SDL,gameplay,3d,SNES

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

BugThug is the first game I have completed since nine years ago. In that time frame I had gotten very close to completing a game for Mac OS 9, but got caught up in the transition to Mac OS X and had a lot of dead technologies with which I was very familiar. Fast forward to 2004, and I was working on my uDevGames 2003 entry privately. Seeing the entries so far, and reading the rules for this year’s uDevGames, I decided I should enter in the hopes of providing a simple SpriteWorld demo for people to learn from. I dropped what I was doing in the game I was working on before and during the first half of the contest, and dove right into BugThug. In hindsight, it was a very good decision for me.
Read the rest of this entry »

Development Tools

Because I was a beginning developer, I didn’t have all the fancy, expensive tools that most other people seemed to have. In fact, I created my game and all of its assets in only four different applications: TNT Basic to write the game, Appleworks 6 to create the graphics, PlayerPro to write the music and sound effects (yes, the sound effects are all made out of musical instruments!), and TextEdit to write everything from the licenses to this postmortem. And the best part about it? The only cost for all this software was the twenty-five dollars to register TNT Basic.

Well, as it turns out, I didn’t really know what I was getting into. I signed up for the contest as soon as I could and began work on my game. I soon realized that it is a lot easier to make a game if you know exactly what it is you’re going to make. But I wasn’t really set back by this, I just happily opened Appleworks and started drawing pixel art—something I had never done before in my life. If you’ve played this game, you’ve probably noticed the low-quality 32-bit graphics. Every single image in the game was made by me in Appleworks, my first ever attempt.

1.pict

What Went Wrong

Music

When my game had become complex enough that it took a while to test it (every time), I decided that it would be a bit easier on me if I added a bit of music that I could listen to while I waited to for everything to happen. Of course, at the time, I didn’t see this as a problem with my game. If I was getting bored… well, other people might be too. But anyways, I just went and opened PlayerPro, and started figuring out exactly how good music sounds. I guess I never found out. I wrote all of the music that went with the game with PlayerPro, and I still to this day cannot figure out why people rated it as well as they did.

Ignoring Beta Testers

I had the game beta tested, and then ignored my beta testers—never a good idea. The basic game concepts were in good order, but the way in which the game ran was just much too ugly. I found out the hard way: when people play games, they want to play them, not spend five minutes setting up their game. I had made the assumption that people wanted to customize their games in the maximum number of ways possible, but I found out that this is only true if it doesn’t take any time.

The Gameplay

The thing that nobody would look at. I can’t say that I blame them. The most annoying bug was the thing that pretty much demolished the game—the keys went crazy. Well, almost. It turns out that TNT Basic in Mac OS X has some complications with the keyboard buffer, and sometimes if keys were pressed a bit too often, they would register in the reader and keep on getting read into the computer long after the player had let go of the key. There was a simple solution to this for the player, but it still annoyed them, and me. This problem stayed with my game through voting, and it even earned a place in the readme.

Sprite Collision

I ran across a problem in my game, and never found out if it was a coding problem, or a glitch in TNT Basic. When the player built up their ship, at the end of each “stage” (there were eight of them), the picture of the player’s ship would be copied and stored as a sprite. This was necessary because the player’s ship image changed depending upon what the player was purchasing. But unfortunately, the image copied was a very large area, because of the large sizes of some of the ships. So if a player picked the smallest ship class (a fighter), the entire large area around it would be copied as part of the image. And then I couldn’t shrink the sprite. The large area around the ship counted as the ship’s ‘bounds’, so if someone shot at a ship and missed it, but just slightly, it would still register as a hit. This was another bug that stayed with my game, but fortunately not very noticeable due to the high average velocity of most of the weapons used.

Selection Menu

I got lots of good feedback about how not to make a selection menu. Apparently, the setup I used was way too inefficient. It was a linear system: the user picked components for each section, and progressed along an an eight-point line. But once you picked something, you couldn’t go back. This was because of the ship picture. Once the picture was “taken,” it replaced the older copy of itself, a bad idea on my part. People also suggested that it should be much more flexible, and the players should be able to choose whatever component they wanted at any time. I think that this would have been a good idea too.

Game Design Issues

Many gamers didn’t like the idea of building a ship. Many suggested that players should be able to buy “pre-made ships,” or at least be able to save their ship designs so they wouldn’t have to redesign it every time. I actually had started working on a procedure to save ship designs, but I had to drop it due to time constraints. I guess it would have been a good idea to squish it in anyway.

2.pict

What Went Right

Some of the votes I got were actually pretty high (e.g. four).

Weapons

Once I got into pixel art, I found that making some of those 60-frame weapon animations was actually pretty fun, although I can’t say that I’m much of a design student. I think that overall, some of the weapons looked pretty good. My personal favorites were the plasma spread array and the space-time disruptor. The plasma spread array shot off a large cloud that slowly expanded and changed colors from yellow to dark red as it travelled. The space-time disruptor was a bunch of lines rapidly crisscrossing, but when used in large numbers gave a wicked-looking effect.

Story

I spent a bit of time working on it, and I felt that I would get a decent vote on it by most developers (which I did). But I guess not many people got far enough to read most of it. And I thought I wrote it okay, but one voter left the comment that I should spellcheck the game (always a good idea).

3.pict

Looking back on uDevGames

One of the good things about this project was that it was actually for a contest. Not only did this contest push me to make a game that was actually playable, but to make one that would be fun, enjoyable and look good. I also cannot list all of the things that I learned while participating in the contest; the looming deadline made me strive to learn how to get things done, and quickly. Even if you never before have made a game in your life, I would challenge you to take part in this contest and just try your best. You’d be surprised what you can get done if you actually have a strong motive behind you.

Plans for Astroknights

Unfortunately, I have to say that with all of the feedback I got, I’d pretty much have to go back and change everything from the ground up in order to get the game how people want it. I might release a small, patched version, but that would probably be it. I have to say that I learned a lot, but as I game, I don’t think that Astroknights as it is makes the cut. The graphics were described as “cheesy,” the sounds as “corny,” and the gameplay as “lacking,” but I guess that all could be fixed. The most important thing holding me back is the bad code structure that I used. It just really wasn’t meant to be played with much. But hey, there’s always next year.

TNT Basic,beta testers,gameplay,sprite collision,game design

What Programming Language?

I hear this question a lot, typically from kids who have just discovered that there’s more to a computer than a web browser, and who are curious about where to go for here. The people who ask this question typically don’t have any specific project in mind; if they did, it would be a lot easier to answer them. Instead, they’re really saying “I don’t know much about programming, but I think it might be kind of fun. Where’s the best place to start?” An experienced programmer on a dark day might answer the question “What programming language should I learn?” with “None. Learn to play a musical instrument instead.” Today is not a dark day, however, and I’ll do my best to answer it.

The person I’m addressing this article to isn’t the person that has as their objective “I want to write a Windows application” or “I want to write a GUI for Bittorrent on Linux” or “I want to write a little tool that will run on my Mac to talk to iTunes.” The target of this article is someone who has a general desire to become a software developer but doesn’t yet understand how to get there.

So in that context, the high level, vaguely accurate answer to the question “What programming language should I learn?” is “It really doesn’t matter.” Partially this is because the question is ill-formed. The specific language one uses is mostly orthogonal to developing the skills one needs to be a good software developer. Let’s look at what those skills are, first, and then later we can come back to the question and make some actual recommendations, rather than just rejecting the question.

High-Level Skills

A developer needs to be able to describe a problem to be solved. She needs to be able to break the problem down into smaller, easier problems. She needs to be able to describe a set of conditions that constitute solving the problem. She needs to be able to think of tests that determine whether a given program or part of a program are correct.

Those are the sorts of skills every good developer has regardless of whether they’re writing code for themselves or for the marketplace. If a developer wants to work on a project with other people, be it open source or commercial, she needs additional skills. She needs to know how to find and read documentation. She will need to know how to use an Applications Programming Interface (API) that someone else has provided. She will need to be able to know when to use an already-existing API (“almost always”) versus developing a new API (“almost never”). She will need the discipline to not be constantly reinventing the wheel. She will need to know how to write documentation. She will need to understand what makes code maintainable (correct and adequate documentation, proper use of namespaces, consistent formatting, useful comments), and to actually use that knowledge when she writes code.

All of those skills apply no matter what your weapon of choice is in terms of language.

Classifying Languages

There are three rough categories of languages of interest to the modern programmer: imperative languages (sometimes you’ll hear these described as procedural) such as C, C++, Java, Pascal, and Modula-3. Imperative languages are about providing a sequence of commands for the computer to execute. In functional languages such as ML, Lisp, and Scheme programs aren’t so much executed as they are mathematically evaluated, as with the lambda calculus. And scripting languages such as Perl, Python, and Tcl which allow for rapid prototyping of simple tasks. Note: yes, I understand that there’s no academic reason to separate scripting languages from their imperative compiled brethren, but there are practical reasons which I’ll discuss later.

When programming almost any (modern, useful) language, you’re going to find yourself using a variety of directives. Some will be part of the core language specification: in C, integer arithmetic and assignment will be the same on every platform. Others will be part of a library that is likely to exist on any platform your program runs on (e.g., studio in C). Lastly, there are APIs which are platform-specific; a C library routine to open a dialogue box on a Win32 OS would be an example of this.

Specific Cross-Language Skills

Learning to program skillfully is something that comes only with great time and effort. There are plenty of programs that will compile just fine and run correctly that can still be called “bad programs,” in the sense that when you look at the source, it is clear that the author doesn’t have a grasp on some fundamental concept. The three little pigs built houses of straw, sticks, and brick. All of them served just fine as shelter, but only the brick house was strong enough to withstand the wolf. Your goal should be to not just learn how to make your programs run, but how to be confident in their correctness, robustness, and performance, before you’ve written a single line of code. To achieve that state, which may seem like a paradox, you need to understand the concepts underlying the craft of programming.

A shorter way of saying this is: don’t worry about learning the syntax of a language. Don’t concentrate on it. Don’t spend time worrying about it. Learning where the semicolons or parentheses go will come by itself, as you write code and go through compile-run-test cycles. Look that stuff up when you need to, but understand that “learning what a constructor in Java looks like” is, in the long term not a valuable thing to concentrate on. Learning what a constructor is and what it does is a valuable thing to concentrate on.

So that’s what you shouldn’t focus on: syntax. What should you focus on? Here, in a vague sort of didactic order, are concepts that I expect a skilled programmer to understand regardless of the language they are using—even if the language they are using at the moment doesn’t actually support the item in question.

• What a variable is.
• How variables are typed. Why type is important.
• Scope (Lexical, Dynamic).
• Assignment.
• Basic data structures.
• Basic control structures. Conditionals.
• Pointers.
• Dynamic storage allocation. Garbage collection. How to manage memory if your language doesn’t have GC.
• Linked lists. Hash tables. Btrees.
• Iteration. The off-by-one problem. How to avoid it.
• Recursion. When to use it. (“almost never”).
• Basic algorithms—sorting, searching, etc.
• Categorizing the run time of a piece of code (O(n), O(n^2), etc).
• Debugging techniques, from diagnostic prints to using a debugger.
• Assertions and how to use them properly.
• Basic object oriented programming concepts (inheritance, encapsulation).
• Threads. Typical concurrent programming mistakes, and how to avoid them. The producer/consumer problem.
• The difference between locking a mutex and waiting on a condition variable.
• Synchronous vs. asynchronous operations. Callbacks.
• Event-driven models.
• Exceptions. Strategies for handling errors generally.
• Advanced testing strategies. Fault injection.

Any one programming language you choose, unless you’re really going out of your way to be obscure (e.g. Prolog), should get you through at least half of that list. Then you can decide whether to stick with the language you started with for the rest of the list, or start on a new one to fill in the gaps.

Practical Considerations

Programming is fundamentally a “learn by doing” activity, so your language choices are somewhat constrained by the need to use a language that can actually run on your operating system of choice. This still leaves you with a fairly wide set of options.

Language availability isn’t the only practical consideration. If applicable, is there a debugger for the language you want to use? What set of libraries will you be using? How much documentation is available for the language you want to learn? Is there an active community you can turn to for help?

Enough Already. Just Tell Me What to Learn!

I’ve tried to make the point here that whatever languages you decide to learn, you should be able to develop your skills over a period of years such that when you decide to learn a new language, it will just be a trivial matter of absorbing the new language’s syntax. However, in the interests perhaps of sparking debate, I’ll give my own personal opinion on teaching languages. Nothing in this section should be construed to mean that I’m saying that languages other than the ones I’m recommending aren’t any good (except Modula-3. Modula-3 isn’t any good—I’m saying that.)

First, learn a compiled imperative language. I very much like Java as a teaching language. I have a few reasons for liking Java. In addition to being somewhat cross-platform (cue mocking laughter), it is actually a fairly elegant language with a robust, extensive, powerful and most importantly for the novice, well-documented set of APIs. One of the things I like about Java as a teaching language is that it’s always very clear, because of the namespace design, when you’re using a “built in” command versus when you are calling some library API; I’ve seen novices using C and C++ get confused when the distinction wasn’t as clear to them. There are many resources to help the novice Java programmer get off the ground. A student learning Java can learn about Object-Oriented programming concepts, threads, events, dynamic allocation and garbage collection, advanced data structures, and most of the items on my list above. The fact that Java runs in a virtual machine is both a benefit and a drawback—it will probably slow your development of understanding how these high level data structures map to the architecture of the machine you’re on, but you can always go back and learn C later. Also, the syntax of Java is simple enough that it won’t pollute you or ruin you for other languages (the way, say, Objective-C would).

And in the interests of disclosing any bias on my part: I don’t program in Java on a day to day basis. My day job is all C, all the time.

Next, learn a functional language. Lately I’ve been toying around with OCaml and ML, and I like them, but really its hard to go wrong here. Lisp, Scheme, ML-these are all fine choices. I haven’t examined it yet myself, but I’ve been told that Microsoft Research has a neat language called F# which is basically a version of OCaml that can call .NET library functions. That’s pretty tempting, because it has such an aura of the forbidden about it-take a pristine, educational, not-very-useful-in-practice language and turn it into something that can be used to develop Windows applications. Mmmmmmmmmmmmm, forbidden transgressive language.

Uh, what? What was I saying? Um, yeah, F#. Very bad. Don’t use that! It’s morally wrong. Learn Standard ML. Yeah.

Lastly, learn an interpreted scripting language of some sort. I like Perl, but Python has a big following, too. People will tell you that scripting languages are just as powerful as compiled languages. They’re right. But it’s been my personal experience that because of the environment scripting languages grow up in (“Oh my gosh, I have to change all occurrences of this string in every file on the server within 10 minutes, or I’ll be fired”) the idioms in common usage aren’t as carefully thought out. Shortcuts are taken. Error cases are punted. Sloppiness is rampant. I agree fully that this is more of a cultural matter than anything intrinsic to the design of a language, but I can’t ignore the reality, and that’s how I see it.

If you’re an experienced developer and you’d like to chime on this topic, please feel free to comment below. The only thing I ask is that you keep in mind that the topic is languages for learning the craft of programming, not languages for best accomplishing a specific task. Thanks.

Additional Resources

• The article that inspired me to write this when I came across it: Peter Norvig’s Teach Yourself Programming in Ten Years.
• I recently wrote an article on why we use pointers. You might like it.
• My favorite Java book is Peter van der Linden’s Just Java’.
• Microsoft Research’s F# project.
• Wikipedia entry for the lambda calculus, the formal system behind functional languages.
• In the interests of balance, the author of CVSup explains why Modula-3 is great. (But he’s wrong).
• The Skeptic’s Guide to Objective-C.

Re-printed with permission from the blog Tea Leaves.

how,to,learn,programming

Shawn Hargreaves writes on the pros and cons of developing open source games for Linux. He focusses on the unusual characteristics of game development, as well as talking about the significance of open source for commercial products.

Most game companies have developed a number of in-house utilities, editors, file converters, and in some cases actual code libraries. These are often very rough and highly specialized for a specific task, but would be a prime candidate for open sourcing. If you take the small amount of extra trouble to write these tools in a slightly more generic way, there is a very good chance that other people will take up the burden of improving and maintaining them for you. Likewise for the support code used in the game itself: basic things like resource management, text plotting, and object rendering get written over and over again, because the old version is never quite flexible enough to work in the current project. If these things could be done once, properly and openly, it would save a great deal of wasted time for everyone. Some companies have tried to standardize these things internally, but usually don’t have the resources to do a suitably thorough job of it.

Shawn makes his living writing commercial console games.

• Related Link: Playing the Open Source Game

The Indiegamer Forums offer a venue for the discussion of the business, technical and personal side of independent game development. The debate is pleasingly professional and on-topic!

• Related Link: http://forums.indiegamer.com Forums

Apple has written a short guide to programming for multiple UNIX platforms in a variety of different programming languages. Perl, Python, Ruby, C and others are covered in the article, which explains how to install them and use them in Xcode. For anyone looking to get started in cross-platform UNIX development, this article offers a good place to start.

• Related Link: Developing Cross Platform UNIX Applications With Mac OS X