Here are a few pictures from the new office. Things aren’t completely set up yet (that bare wall is waiting for some Flower Garden and Casey’s Contraptions posters that should be arriving today).

The thing I like the most about this office is the light. It’s a corner office and it’s aiming north, so that means great, indirect light all day long. Oh, and the windows can be opened to let some fresh air in. That might seem like an odd detail to mention to some of you, but you’d be surprised how many office buildings in the US have windows that can’t be opened. Really.

Both desks are adjustable, standing desks. The main desk in the pictures is the large frame GeekDesk one. I used to have the small frame because I didn’t have the room at home, but I love the extra space, especially with the 30″ display! I’ve kept the small desk to the side, that way I can invite other people to come work from here for the day (indie work day!) or even (gasp) hire someone if the right time comes.

The rest is pretty standard: whiteboard (I prefer use one much larger, but that’s what I had around), bouncy ball (gotta have a bouncy ball!), and couch (pretty important to unwind, or just to take a break from standing all day).

So far, I’m very happy with this setup. Working from here is definitely invigorating, and the separation between work and home helps a lot in both locations. Maybe once our daughter is older and going to school I’ll consider working from home again, but this is perfect for now.

What does your work setup look like? Post some pictures and let me know. I love seeing other devs work setups.

Contrary to popular belief, I’m not that picky when it comes to a development environment. Or at least, it doesn’t feel that way to me. I want the basics, that’s all. Doesn’t everybody want this?

• Have 2-3 source code windows opened side by side.
• Build and see the output.
• Do everything with keyboard shortcuts.

There are lots of other things I want (project configuration, debugging, run tests), but those are the ones I’m doing 99% of the time. I never had a problem doing any of those things with past development environments.

The hit list

Having more tools and options is great. I love having the option to do advanced operations on my code, but I want to decide when to use those tools, not being bombarded by them. That, in a single sentence, is why Xcode 4, out of the box, is completely unusable for me.

Attempting to do something as simple as type code and build it is extremely frustrating. Xcode will react to me doing that by flashing all sorts of stuff on screen, bring up sidebars with messages, change which source files are displayed, draw squiggles all over my code, and flash alerts overlays. All of that, while not showing me the build output.

Working on Xcode is an extremely noisy (visually) and distracting experience. I understand it’s trying help me, but it’s failing miserably at it. I’m trying to concentrate on what the code does, and I feel I have a parrot yelling stuff from my shoulder and flapping in front of the screen in some misguided attempt to help me code better.

That might work for some people, but not for me. I’m the guy who turns off “spell check as I type” everywhere because I don’t want to be taken out of flow while I’m typing (I’ll do a spell checking pass later on, thank you). I don’t have notifications on my mail or Twitter; I check them explicitly when I want to. Now take that kind of annoyances and multiply it times 10 and you start getting an idea of what working on Xcode 4 is like. Xcode 4 feels like it’s squarely designed for the texting/ADD generation.

Fortunately, most of it can be remedied and turned into a half-way sane environment.

Here’s how to tame the noise in Xcode 4:

• Autocomplete is one of the worst offenders. Turn it off! Good autocomplete is awesome, but I’d rather ask for it (with a keystroke) than have it bombard me constantly. Not just that, but it’s so badly implemented that it will a) put shadows on top of the text I’m typing b) replace the text I’m typing on the fly so I can’t even see what I typed (see screenshot below). Off with it!



• Having the whole screen flash with squiggles on and off while I’m typing isn’t helping in any way. Xcode is trying to “highlight instances of selected symbol”, which is a really useful tool, but not while I’m typing/thinking! Not just that, but half the time it will add extra squiggles to the screen to make sure I can’t even read the symbols themselves. So off with that one too.

  

  Here’s one very frustrating thing: When I turn off the option to automatically highlight instances of the selected symbol from the settings, I lose the ability to do that at all. Yes, you heard that right: I can’t (as far as I can tell) press a key and have the IDE highlight all the instances on demand. No sir, that’s not the way it was intended.

• Continuing with the theme of noise and distractions, having a sidebar popup and start showing me errors with my code as I’m typing is also definitely NOT helping. Fortunately we can turn off “Show live issues” in the general settings.
• One thing that Xcode 4 appeared to have gotten right is the idea of showing multiple source files at the same time. Now many IDEs do that by default these days, so that was a plus. Unfortunately, it’s part of the “smart” assistant. As a general rule, I end up turning off anything with the word “smart” in it, and this is no exception. The assistant tries to present “relevant” files to the one I’m working on. No, no, no, no! *I* want to decide what to display and what to work on. Just get out of the way and let me do that easily. You can turn off the view to “Manual”, which helps a huge amount.

Just those changes make Xcode 4 into something that at least I can type into and not get sick at my stomach. We’re making progress.

Now I can finally build and… everything goes wrong. Xcode doesn’t show me the build output and it decides to flash a “build completed” screen overlay in case I looked away in the two seconds it took to build. Seriously? Maybe my attention was drawn into some of the flashing squiggles and I forgot it was building.

Fortunately for my sanity, it’s possible to fix both those things. The alert is easy: Go to behaviors, “Build succeeds” and turn off “Show bezel alert” (make sure it’s off for all the others while you’re there).

The other one is a bit trickier, but it’s certainly possible. Set up the “Build starts” behavior to open a named tab and go to the current log. Like this:

Now when you build your project, you’ll get to see something sane like this. It might initially be as a tab, but you can drag that out and make it into a separate window of its own so it doesn’t obscure the source code window:

You should be able to navigate through any issues found during the build with Cmd + ‘, or, if you like the fancy issue display, press Cmd + 4. Things are so much better when you initiate them on demand rather than when they’re forced on you!

Finally, a couple minor UI annoyances that are easily fixed:

• The toolbar is positively huge. I feel crammed in the high-res 15″ MBP (1680 x 1050), so I can’t imagine how anyone works with something smaller. In any case, hiding the toolbar helps tremendously. As a bonus, the setting is per window, so your source code windows get the extra real estate, but the build output window keeps the toolbar so you have easy access to changing the target platform.
• Line wrap is on by default. Seriously? Off.

The suck list

If that was everything, I’d be happy. It means that even though Xcode 4 ships with retarded defaults, it can be whipped into shape into something usable. Unfortunately, there are a two major things I haven’t found a workaround for:

• Can’t build a single file. Someone at Apple, in their infinite wisdom, decided that building a single file was obsolete with the awesome new feature of “show live features”. Except that “show live features” sucks and has to be turned off. Apparently you either take it their way, or the highway, because there isn’t an alternative. As with the case of highlighting symbol instances, there isn’t a command I can use to “show live features” on demand.

  The alternative is doing a full build. Most of the time that’s fine, but whenever you’re doing one of those refactorings that breaks half the codebase, then you’re really screwed. The only way I can stay focused in a case like that is by cleaning up one file at the time, but this makes it impossible as you keep getting errors from all over the codebase. And as you fix one, the first error in the next build might be in a different file. Very annoying to say the least, especially because this was working and they removed it on purpose. I never file radar bugs (long story), but I made an exception just for this.

• Build configurations and schemes. Did you notice that when you built the project earlier there was no option to choose debug vs. release or some other configuration? That’s another one of those decisions that make you wonder if Apple uses Xcode to manage their own projects (and if they do, what kind of developers or projects they have).

  They turned something simple like project configurations that nobody ever complained about, into something byzantine worthy of some of the best efforts from Redmond. This gets the award for “most complicated feature nobody needed or wanted”. It seems now we have an extra layer of indirection. So you act on a scheme, which then decides which configuration to build and what to do. That’s why there are “Build for analysis” (debug), “Build for running” (release), “Build for testing” (WTF?), “Build for archiving” (distribution?).

  After spending some time with it, I’m still confused how I would go about running the release configuration, or how to mass-edit all the schemes at once (every target seems to get a different scheme).

  The whole schemes thing leaves me completely speechless, and that vein on the side of my forehead is pulsating just from thinking about it, so let’s just move on.

The good

After you take the time to fix Xcode 4 into something usable, and (somehow) put up with the new broken features, is there something to like?

I had to dig deep, but I found a couple of things that I like better than Xcode 3:

• Much better project settings UI: Multiple panes, showing multiple values for different configurations, etc. Way better than Xcode 3.
• Better semantic analysis. During the build process, Xcode 4 was able to correctly flag some problems in my code that Xcode 3 never warned me about. Mostly to do with constness of parent-scope variable when using blocks.
• Better keyboard shortcut support for opening files in different windows (assistant pressing the Option key). I never found a way to open a file in a specific window in Xcode 3 without having to use the mouse.

And that’s pretty much the whole good list that I was able to find

Conclusion

Xcode has been progressively evolving from version 1 until version 3.2. I have no doubt that’s the reason for some of the quirks in the later versions. Xcode 4 seems to be a total re-design and re-implementation, and suffers from the classic second system effect. It’s change for the sake of change, most of the time scrapping useful features and not offering useful alternatives.

I’m sure I only scrapped the surface of the horrors of Xcode 4 in the day I spent with it. I didn’t look very closely at the debugger or the Interface Builder (saving those for another day). I keep hearing about developers with stability problems with Xcode, although I didn’t run into any crashes (but I hardly did any real work with it).

Overall, my recommendation is that, if you’re comfortably working on Xcode 3, stay as far as possible from Xcode 4. We’ll all be forced to move there sooner or later, but in the meanwhile you can continue being productive. Maybe by the time they discontinue Xcode 3, Xcode 4 will have improved a bit.

These are mostly quick notes to myself so I remember what to change when I upgrade my main machine, but I thought other developers hesitant to upgrade to Lion might find it useful as well.

Things that had to go

I found Snow Leopard (and Leopard before it) to be very palatable out of the box. I don’t remember any things I absolutely had to do. Lion, however, had some questionable defaults. Or at least, ones that I just can’t take.

After making these changes, Lion was quite usable:

• Turn off “natural” scroll direction. The fact that before you can run Lion for the first time it forces you to scroll that way should be a tip off that people aren’t ready for this one yet. Maybe in a few years it will make sense to have it as the default, but now it’s just against every single computer out there (including most Macs).

• Autocorrect. This is not an iPhone. It *has* a perfectly fine keyboard. Thank you.

• Setting up Spaces. Oh, excuse me, Mission Control (sigh). This is the one I was really afraid of. I absolutely rely on having about 8 spaces (2 monitors in each) open at all times and swapping with a keystroke. That’s something that I’ve been using for many years (first in Linux, then hacked onto Windows XP, and finally in Leopard/Snow Leopard). I just absolutely have to have that.

  Update: There are still a couple annoying things with the new setup. You can’t see the number of the desktop you’re currently on, like you did with earlier versions of OS X. Daniel Collin pointed me to an interesting thread on StackOverflow where people are discussing how to get access to desktop numbers. Give it a few more weeks. Also, when you restart the computer, Lion is smart enough to restore all the apps to their last state… except that they’re all opened in the first desktop, not in the one they were when the system restarted. How difficult would that have been? Here’s hoping it’s fixed in a patchupdate soon.

  The good news is that it’s possible to set up Lion that way. The bad news is that by default, it’s quite far from that. Bring up Mission Control and create by hand as many desktops as you want. Then go to System Settings | Keyboard | Keyboard Shortcuts and turn on one for each desktop. And for the love of god, please go to Mission Control settings and turn off “Automatically rearrange spaces based on most recent use”. Clearly Apple doesn’t think people want to go to a space directly, and instead prefer to browse them one at the time.

The next few changes just made my experience better, but they’re not absolutely musts:

• This might sound dumb, but Finder didn’t have a good way to easily browse my files. Instead, it has this weird “All My Files” view that jumbles together all your junk there. I have no idea who thought that was a good idea. Maybe Apple is trying to wean users from browsing around the file system. In any case, you can drag your home directory to the sidebar in Finder and that makes it much easier to browse. While you’re at it, turn off the “Hide extensions in files” dumb setting.

• Having used a Mac for several years, I’m much more sensitive to ugly UI elements. That’s why it’s so weird that, by default, Lion has the sidebar font in all programs just very slightly larger than the regular system font. Fortunately I wasn’t the only one bothered by that and it’s an easy fix.

That’s about it. Lion is not very nice and usable (i.e. looks like Snow Leopard). You have that weird “full screen” button on the top right of all windows, but that’s much better ignored (which funny that, was the feature Apple really pushed in their PR for Lion). I have no idea why anyone would want to use that other than the usual word processor that blocks out everything else. If I want to have crippled multitasking, I’ll just use the iPad.

Good things about Lion

So far, if all I’m going to do is disable new features so it looks like Snow Leopard, is there there any reason to upgrade to Lion? I surprised myself, but the answer is yes (although they’re all very, very minor).

• Resize a window in any corner and cursor feedback (finally, only 20 years late to the party).
• Perfect contact and calendar syncing with Google. I can’t tell you how much I appreciate that. I use Google as the backend for all my mail, calendar, and contacts. With Snow Leopard you could sync them, but you had to do some digging and mess around with the sync program. With Lion it works out of the box. Totally awesome. That alone makes it worth the upgrade.
• Much improved Mail UI: Better layout, better shortcuts, better conversation view, and, my favorite by far, finally an Archive command for Gmail. Archive doesn’t exactly do the same as archiving in Gmail, but it’s close enough. Finally I can have two different keyboard shortcuts: One for trashing an email and another one for archiving it.
• The jury is still out on how Lion restores the application state when you launch an app. I’ve been pleasantly surprised a couple of times, and annoyed a couple other times that I had to close a bunch of useless tabs. Maybe there’s a shortcut like Shift + Cmd + Q that quits and app without saving state? That’d be handy (OK, that one is not it Oh wow, it’s Option + Cmd + Q! I love it when something makes sense like that and you can guess it. OK, so that makes this feature very cool.
• Slightly improved Safari (better download management). I really don’t see a reason to use Firefox or Chrome when you can use the preinstalled Safari. But then again, I can’t stand web UIs and I use native clients for lots of things.

Must-have apps

It’s actually quite refreshing to use the bare minimum number of extra apps beyond what comes with the OS. But there are some apps I just have to have in order to do anything. The main two are 1Password and Alfred. I can’t recommend them highly enough. They completely change how I work and make me ten times as productive (you’ve probably noticed by now that I’m not a mouse person).

After those two awesome super-apps, is the second tear of very useful ones: JustNotes, Things, and TextWrangler.

Probably Dropbox should be there somewhere, but for some reason, I still haven’t felt the need to use it heavily. I know some people put almost everything on Dropbox and can use across computers. Maybe it’s because I only have one that I haven’t felt the need for it too much. 1Password and Things both sync from the iPhone so it was really handy restoring all my data. I probably could have done the same thing with Dropbox.

Tomorrow I’ll post similar quick notes about Xcode 4. Those might not be quite as positive though.

For me this marked my fourth year as an indie developer. It’s not a huge milestone by any standard, but the fact that I’ve been going at it for this long and I’m not broke yet means it’s a sustainable business. Actually, as you know if you followed some of my numbers posts, this was the first year that income from my apps finally became (reasonably) profitable. Now, *that* is something worth celebrating!

Doing this kind of small-scale game development is exactly what I would do if I didn’t have to worry about money at all, so this is truly living the dream for me.

Goals

All is not sunshine and roses in Noel indie-land though. I accomplished some of my goals for this year, but missed others by a mile and a half:

I released a bunch of Flower Garden updates and ran a bunch of promotions that kept bringing revenue up. That went very well. Check.

Miguel and I also submitted Casey’s Contraptions to the IGF (with three hours to spare the day of the deadline). I’m very proud of that one. Even if we’re not selected as a finalist, the experience of submitting it and finally participating in the IGF was fantastic. Check.

Games shipped. Hmm…. That’s the total fail. The only new game I shipped this year was Lorax Garden, a very short project in collaboration with Oceanhouse Media, mixing their Dr. Seuss license with the flower technology I had already developed. I didn’t even manage to ship Casey’s before Christmas like I was hoping to do. I could make excuses but there’s no point. Real life happens and things go slower than planned (that topic is already brewing for a future post).

My goal for next year is to ship three new games, but always of the quality that I can be proud of. I’ll have to be very careful about design and scope to achieve that (I’m hoping that hanging out with Ian and Dave will rub off some of that genius they have for making awesome games on a crazy-short schedule).

Games From Within

I started my blog, Games From Within, exactly 7 years ago today. I guess that counts as my longest-running project. Some years it was sorely neglected with just a few posts, but this year I spent a significant amount of time on it, thanks in large part to #idevblogaday.

These were the most popular posts for this year (based on page views, which RSS readers make much harder to track):

• Making A Living (Barely) On The iPhone App Store (aka The Numbers Post)
• Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP)
• The Const Nazi (This one is a total surprise that it made it this high up!)
• Making A Living (Comfortably) On The App Store (aka The Numbers Post #2)
• Prototyping: You’re (Probably) Doing It Wrong
• Google App Engine As Back End For iPhone Apps
• Increase Your App Ratings On The App Store
• GDC 2010: The Best of Both Worlds: Using UIKit with OpenGL

2011 should be an exciting year for me personally and for all indie game developers out there. Happy new year everybody!

New beginning

When my job position got terminated last summer, I decided I would take a break from working for big companies, and try to make a game on my own at home. I’ve been in the video game industry since the late nineties, I’ve written code for a few released PC and console AAA titles and probably as many canceled ones, and I wanted to do something different at least for a few months. Go back to the roots of game development, when one or two guys could create something in their garage or bedroom, without spending years and millions of dollars on it.

Platform choice

I’m a C# fan, I won’t deny it, I even explained why back in 2007. I also toyed with XNA each time a new version was released, and I like how straightforward it is to use. When the beta version of the tools to develop for the Windows Phone 7 (WP7 for short) became available, just at the right time for me, it seemed like the obvious choice for what I wanted to do. And developing for a brand new platform sounded exciting as well, even if it was perhaps a riskier bet than targeting well established markets.
For those who don’t know much about WP7 development, I just want to highlight a few key points:

• Applications are written in Visual Studio using C#, and either XNA or Silverlight. This may come in the future, but at this point you are not allowed to mix them, and use the controls of Silverlight with the faster rendering of XNA, for example.
• In App Purchases are not supported yet.
• Programmable shaders are not available for WP7 (they obviously are for the PC and XBox360) in the current version of XNA. Instead, you have 5 predefined shaders with features that can be toggled on and off (such as fog or per pixel lighting). These shaders should cover most of the usual needs, but if you want something very specific that they don’t support, you’re out of luck (or have to fall back to multiple passes and alpha blending).
• Paid applications have a trial mode, that allows users to evaluate them before making a purchase. Unlike on XBox Live Indie Games (XBLIG), where the game just abruptly stops after 8 minutes, developers have a complete control over what they want to show in trial mode (for example, the first few levels of a game, with no time limit, or without the ability to save, etc). In theory, this means you shouldn’t have to make a free version of your game in addition to the paid one, but I’ll come back to this later.
• The certification requirement document is only 27 pages long, table of content and change history included.

The project

I wrote a few ideas on paper, but they all looked too ambitious for a first project. One thing in particular that I wanted to avoid was to require a lot of content, since I didn’t even know how I was going to find an artist yet. During a bike ride, I thought about using photos, and that’s how I decided to make a jigsaw puzzle game. Not super original, I know, there are several of those on the iPhone and iPad, but there was none on the WP7 since it wasn’t released yet , and it looked like a good project of the right scope to keep things under control and learn the platform. For example, I had never worked with a touch screen device, and it was pretty obvious from the start that I was going to spend quite some time iterating on the user interface part of the game.

The game is called Jigsaw Guru, and you can go to http://www.fairyengine.com to see more screenshots and a video.

What went right

I actually already mentioned some of the things that went right in my opinion, but here is the full list:

• Working on a short project, without too much content to integrate, instead of picking another more ambitious and time consuming idea, was the right choice. My goal was to have Jigsaw Guru on the marketplace the day of the WP7 launch, I submitted it on 10/18 and it got approved on 10/23 (the update I submitted in December passed even faster than that), two weeks before the US launch and two days after the other territories started getting their phones. At times I still had more items on my to-do list than I would have liked, and I made a good push in the last 3 weeks to get everything wrapped up in time, but it never got too crazy.
• Knowing the tools beforehand, and using C# and XNA, definitely made me feel productive. The phone emulator was surprisingly stable in the beta, and the XNA forums were very helpful when I wasn’t sure about something. It’s also worth noting that the website used to submit bug reports allows everybody to see what other people have written, and vote on issues you think are important and should be fixed first.
• Garbage collection is the one thing that can hurt your framerate really bad when using XNA on XBox360 and WP7. But it’s not that hard to avoid: when I had a look at my memory usage late in the project, I only found two spots where I was creating some amount of garbage each frame (both related to strings). Basically what I do is each time the player goes from one screen to another, I load everything I need for the new screen, and I force a garbage collection. This gets rid of temporary objects that may have been created during the loading process, and objects from the previous screen that are not used anymore. After that, I don’t allocate anything, and the garbage collector never has to do any work.
• Finally: testing. Very few people tested my game while I was developing it, but my friend Alexis alone kept giving me more feedback than I thought I could handle. He never said anything was good just to make me happy, he reported every little detail he didn’t like, even and especially the ones I was aware of but never had time to fix (and maybe thought nobody would notice). Even if I sometimes felt he was nitpicking, this was exactly what I needed.

What went wrong

Developing for a new platform has its share of drawbacks, it’s just how it is. The final version of XNA 4.0 only came out mid-September, and before that I was working with the beta version. As mentioned before, it was pretty solid already, but there was no redistribution of the runtime. Which means you had to install all the tools to be able to just run the game, and you could only install them under Vista or Windows 7 because the phone emulator requires DirectX10, and some of my potential testers were still using Windows XP. So, even if what I was sending was a PC version of the game, they couldn’t run it on XP just because the phone emulator, which they didn’t need, requires a more recent operating system. To work around this problem, I made an XNA 3.1 PC version of Jigsaw Guru, but maintaining two versions side by side for several weeks and merging back and forth between them was not fun.

Coding for a device that wasn’t released yet also meant I could not test what I was doing on real hardware. I unsuccessfully tried to get a phone prototype, and basically the only way I found to run my game on a WP7 at the end of September was to go to a Microsoft event. Even there, I thought there would be phones locked to the tables, that developers could connect to their laptop and use for the whole day, but I was wrong: there was no such thing, and the 4-5 persons who already had a working application to test like me had to do it on the phone of the event’s organizer, when he wasn’t using it for something else. I was able to run my application twice for about 5 minutes each time, and fortunately everything seemed to be working fine, which is a testament of the reliability of the emulator.

When the game began to be really playable, with most of the screens that are in the final version, I started looking for an artist and a musician. I did it way too late, and I was lucky to find Aimee and Tim through the XNA forums, and that the time estimates they gave me just matched my own programming deadline. So, in the end everything worked out well, but even if I wanted to wait and be sure the UI elements were final before asking somebody to redo them, I believe I also waited just because I was more comfortable doing my programming tasks first, and that was a mistake.

Marketing was a difficult problem: I knew I needed to do some, but how? When Jigsaw Guru got approved, the WP7 wasn’t out yet in the US, and had just been released in a few countries of Europe and Asia, as well as Australia and New Zealand. Basically, nobody had that phone yet, and I couldn’t find any website reviewing its games. Even when I had a second look for the US launch, I only saw a couple of sites testing 2 or 3 of the official XBox Live games (that’s how they’re called even if they run on a phone), but nothing related to indie games. So, what ended up happening is I did nothing, and just hoped that because there weren’t too many applications on the marketplace yet (which is the reason for being a launch title, right?), people interested in jigsaw puzzle games would fine mine. Of course I was wrong, and the fact that the search in the Zune software didn’t seem to care about the keywords you enter when submitting your app, or couldn’t find my game when searching for ‘jigsaw’, didn’t help (this seems to be fixed now). I don’t know how other developers releasing WP7 games around the same time as me handled their marketing, but I would be curious to hear it, that question is still a mystery to me.

Downloads and sales

This could have been another paragraph in the “what went wrong” category, but I think this subject deserves its own section. Download and sale numbers for WP7 apps became available on Wednesday 12/08, and I don’t think anybody was thrilled. Don’t get me wrong: WP7 is a very young platform, there aren’t tens of millions of phones in circulation, sale expectations have to be low for now, and can certainly not be compared with those of competing platforms. No, what really surprised me is not the number of sales, but the number of downloads.

On the “top selling” tab of the Zune software (which is more likely based on downloads, like the Bing visual search), Jigsaw Guru has always been in the middle of the paid games from the puzzle & trivia category, the biggest category by far (about 45% of all games). Today for example, it’s 174th out of 363. How many downloads do you think this means on average? About 0.65 per day. This totally blows my mind, but is in line with a graph a developer made with the numbers from his 4 apps, that shows the relationship between the marketplace rank and the number of downloads.

One potential problem is it’s not obvious enough that lots of paid games support the free trial mode, and some players don’t know they can download them for free. But really, it all comes down to most players only checking the XBox Live and the free sections, and rarely visiting the paid one. Which is why although I said earlier that in theory, and thanks to the trial mode, you shouldn’t need to make a free version of your paid game, in practice it’s obvious this doesn’t work, and you have to do it. My friend Noel, who is an experienced iPhone developer, had actually told me I should release my game as a free, ad supported app; unfortunately, the ad SDK’s for XNA didn’t exist at launch and are still in their infancy, the one from Microsoft got released this month and only serves ads in the US, the other ones are either not finished or not stable yet.

So, what’s next? I’m submitting Jigsaw Guru Free (with the Microsoft ad SDK) this week, because as a developer, I still want people to play my game and hopefully have a good time with it. The two projects I started working on after Jigsaw Guru might follow the same path and be free apps from the start, whether it’s on the WP7 or another platform.

Most often, the advice stops there. So you get your initial sales spike and then sales go way down. What do you do then? Usually, developers release new features and updates. That’s great, but how do you get people to notice it. You need to establish some form of communication with your players.

Update Messages

The simplest form of communication is through the “What’s new” section in the update. You can use that section not just to list what features you added and what bugs you fixed, but also to let your players know about other things: plans for the future, other games to try, or even the URL for your Facebook group.

Credit goes to Igor for bringing up this idea and pointing out the URLs are even clickable in this field (but they aren’t in the app description).

Of course, if you’re like me and you update your apps only once in a while, this technique isn’t as effective. Right now my iPhone tells me I have 67 new updates available. I’m clearly not going to be reading through the release notes of each one.

In-Game News

A more direct way of reaching out to your players is to have some sort of in-game news system. At any point you can update a file in your web server with any news, and it is displayed in the game. It can be implemented in many different ways depending on “on your face” you want to be about it: a pop up that comes up when the user runs the game, a ticker that runs constantly across the bottom of the screen, or, what I did for Flower Garden, a news icon with a badge indicating how many unread items there are, that brings up the news page when you tap it.

Make sure players are able to click on URLs in your news messages so you can direct them to different web pages easily. More on that on a bit.

Emails

Update messages are only good for players who update their apps (ahem, ahem), and in-game news for active players who’re currently launching your apps. For maximum effect, you can send an email newsletter and that way you can also reach users who played the game at some point in the past, but aren’t currently playing it now. They’re the ones probably most interested in new updates and features, and chances are you can rekindle their interest in the game.

To do this, you should encourage users to register for your mailing list, or collect their emails with their consent in some other way. This was a technique I started using back in December of last year with great success.

I’m currently using Your Mailing List Provider as a means to delivering thousands and thousands of emails [1]. By the way, don’t miss a chance to join the Flower Garden mailing list

Facebook

Similar to the mailing list approach, Facebook groups can be a very effective form of communication. An additional benefit is that friends of your players might see them participating in the page and might make them try out your game.

Case Study: Pocket Frogs Cross-Promotion

All that is fine in theory. How does it work in practice? I have been using all four forms of communication for a while, and I’m definitely seeing good bumps of sales and downloads with each update and each major communication.

Last week, Ian and Dave from Nimblebit and I, decided to set up a cross promotion between Pocket Frogs and Flower Garden.

I updated the in-game news and send out an email newsletter coinciding with the latest Flower Garden update telling the players that if they downloaded Pocket Frogs from within Flower Garden, they would be awarded 5 doses of fertilizer. Nimblebit awarded players a flower if they downloaded Flower Garden Free from within Pocket Frogs.

When you have over a million downloads in a week like Pocket Frog did, that kind of player communication is the equivalent of a nuclear cannon. The effects of the cross-promotion were obvious the instant the news went live:

As you can see, Flower Garden Free made it all the way to the number 56 in the iPhone Top Apps chart in the US! The effect even spread to the paid version of Flower Garden:

Pocket Frogs at the time was hovering at around #9 on the charts, so it was difficult to have much of an impact on that position without major numbers, but we suspect it might have hovered there a little longer because of the extra downloads from Flower Garden.

Here is what the downloads for Flower Garden Free looked like for the last month. The Pocket Frogs cross-promotion is quite noticeable:

All those downloads also translated into in-app sales through the Flower Shop. Here are the revenues for that time period:

One consequence I wasn’t expecting, but in retrospect I’m not that surprised about, is that the ratings for Flower Garden Free dropped by a whole star (from 4 to 3), with a large percentage of 1-star reviews. That’s because a lot of people who wouldn’t have downloaded Flower Garden otherwise did it anyway, didn’t like it, and deleted it right away.

To wrap things up on a better note, there was yet another side effect of the cross promotion. The Pocket Frogs link was using my LinkShare referral code. Sending all those users to the App Store to download a free game link resulted in about $200 in referral profit for the week.

Conclusion

Communicating with your players is more than just profitable: It’s crucial to the sustained success of your games. Make sure you try to engage with them in every way you can, keep them up to date with developments in your game, and don’t hesitate to run the occasional cross-promotion, especially with other games that are a good match for your target audience.

[1] If you decide to use them and wouldn’t mind using my referral code (WQHVUF), I can get a small percentage back.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

Initially I dismissed it for me because I’m reasonably active: I either run or bike 5 or 6 days per week, and the rest of the days I go for a walk around the neighborhood. It was the combination of increased studies on the effects of sitting, some people in my social circle finally making the jump and raving about it, and me developing some problems in a hamstring that finally made me consider it more seriously. And trust me, if you’re a cyclist or a runner, the last thing you want to have is hamstring problems.

It turns out that my 5-mile morning runs weren’t making me immune to the dangers of sitting. It’s not how much exercise you get per day, but how long do you sit on a chair continuously. And no, buying an fancy, expensive chair might help with your back, but it’s not going to do one bit of good with all the other problems.

One of the many advantages of working from home is that I can try weird things that would be much more difficult in a regular workplace. I also have a track history of liking to experiment on myself [1], so it didn’t take much convincing to give this a try.

After some initial research, it appeared that the way to go was an adjustable-height desk. That way you can work standing, but you still have the flexibility to sit down whenever you need to. I also found out that apparently this is not all that uncommon in Europe. The only drawback is that adjustable standing desks are not easily available here in the US, and the ones that are out there are aimed at offices and big companies, with matching eye-popping price tags. Even though Flower Garden continues to do well, I wasn’t quite ready to plop down several thousand dollars on something I might end up hating.

So I decided to start cheap and work my way up from the bottom. First I had to decide if I even liked this whole working-while-standing thing. I wasn’t even sure I would be able to type! I thought about raising my desk with cinder blocks, but I would have to raise a lot and would make it very unstable. So instead, I created four stacks of books on top of my desk and put a board on top. Then I was able to put the keyboard, computer, and monitor on the board and give that a try.

Let me tell you: It was weird.

At first I didn’t know how to type. My fingers were constantly off to the side. It turns out my initial height was too low. You really want to have the keyboard at a height that puts a 90 degree bend on your elbows. That’s what they say about the sitting position, but somehow I can manage to have less. However, standing, I really needed that height.

Even once I adjust the height, the first day was kind of rough. After an hour, I was definitely feeling it in my feet. I think I did half a day the first day and I felt totally exhausted. All that running wasn’t helping that much standing at my desk apparently.

Fortunately things got better very quickly. In a few days, I was able to work for hours without much problem. I would find myself constantly shifting my weight between my feet and moving around a little bit. I was definitely liking that whole standing thing.

At this point I decided that the stack of books was too annoying, but I wasn’t quite ready for an expensive desk. So I picked up a Fredrik Ikea desk from Craigslist for $50. The nice thing about this desk is that it can be assembled so the top of the desk is almost at any height. You can’t change it on the fly, but at least it serves as a standing desk.

Finally I was able to work standing and be comfortable at the same time now that I had space for more than a mug along with the keyboard. The extra shelves on the desk were also very handy (one over the table top and one underneath).

After spending a couple of weeks with the desk, I decided that I definitely liked standing and it was something I wanted to continue doing long term. I felt more focused while standing, and my productivity was up. An unexpected side benefit was that when someone else comes into the room, they can walk right up to the desk and we can look at the monitor together, or look at some papers, much more easily than if it was a sitting desk.

However, it was also clear that I needed to switch things up a bit. Spending the whole day standing continued to be pretty tough on my feet, and it even made it so I didn’t want to work any longer than I had to. I really had to combine the standing with some hours of sitting down, which is probably a healthier thing to do anyway.

At this point I had two options: I could go full out and get a motorized adjustable desk, or I could get an adjustable draft chair which are tall enough to sit comfortably at a standing-height desk. Since I already had a nice office chair, and the Ikea desk was a bit wobbly set up like that, I decided to spend the money on the motorized desk.

Again, after a bunch of research, it seemed that one of the best options was to order a (very appropriately named), GeekDesk online. They have them in two sizes, Classic and Mini. It turns out I wanted something more in the middle (around 60″ wide), so I ended up ordering the Mini frame and a desk top from Ikea for $80. It wasn’t cheap, but it was way cheaper than the alternatives and all the reviews and experiences I read were very positive.

It arrived very quickly and it was a breeze to assemble. I did have a scary moment that it looked like one of the wheels didn’t fit in the metal opening, but I eventually managed to coerce it. Hopefully this kind of manufacturing problems aren’t common.

I can only describe the final setup with one word: Awesome. The desk isn’t wobbly at all, and it takes just a few seconds to change heights with the push of a button. Not just that, but I can fine tune the height at any moment in tiny increments. And in the sitting position, I can put it low enough to make typing very comfortable (most desks are set up too high to type really comfortably for me).

My daily work routine has settled into working standing in the mornings, sitting for an hour or so after lunch, standing all afternoon, and then sitting in the evening I have have to do some work. With the wonderful weather here in Southern California, I’ll often take my sitting work time outside in the back patio in the shade. So all in all, I probably spend one or two hours sitting down at the desk.

Yes, it was a significant amount of money, but it’s something I’m using every day and it improves both my productivity and my health. Definitely worth it.

Standing desks have one downside though. This situation happens embarrassingly often. Good thing I work home alone!

[1] A few years ago I gave polyphasic sleep a try. It was actually really great for gaining extra hours, but eventually I gave it up because I was constantly out of sync with the rest of the world. I’d do it again if I were spending months alone in a research station in the Antarctica.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

I loved the sound of that! I’ve been an indie developer for a year and a half, and I’m seeing more and more people taking tha route. I think indie development is necessary for a healthy game development industry. Where else are people going to try weird ideas, experimental development techniques, an commercially unproven designs? I think it’s a sign of maturity that we’re seeing a need filled by independent development next to the Maddens and Worlds of Warcraft and other chart-toppers.

I think 2008 will go down as the year that indie games made it to the big time: Braid, Schizoid, and World of Goo are just the top of the iceberg. It showed that it was possible to become an indie developer and make a living from it. 2009 has to be the year that indie development really explodes, right? The trend is certainly there. I’m constantly hearing about people or even whole teams leaving large development houses and starting their own, small companies. These developers are not trying to become the next EA, but they want to keep things small, creative, and, above all, fun.

If the only path for indie game development were downloadable console games on XBLA and PSN, the future wouldn’t look so bright. I used to be really excited about those platforms, but the restrictive zeal of Microsoft and Sony, the dingy royalty deal on XBLA, plus the high-development costs required for most games in those platforms, makes them very difficult to develop for and make any money from them. More and more, I’m hearing of donwloadable console titles with budgets around a million dollars. A million dollars!! That’s “just” a tad bit out of my indie pocket range.

Fortunately there are other paths. We have the usual PC market, which seems to be on its way to being abandoned by the major players but leaves a void for indies. Some guys seem to be doing well there, especially if you consider the Mac and Linux markets in addition to Windows.

Then there’s Nintendo’s WiiWare, which seems surprisingly much more open than the Xbox360 or PS3. I don’t have any friends who are personally developing for WiiWare, but I hear the barriers of access are not insurmountable. I’d love to see some sales numbers though. Nintendo certainly has the name to attract players and developers. Maybe they need to open up their DS development a bit too. Bob would like that for sure!

And then we have our last, best hope for indie game development: The iPhone [1].

The iPhone seems to hit all the right marks: Hardware advanced enough that you can develop really interesting and good-looking games, yet simple enough that one or two people can create a top title. Very open (the SDK and tools are available for free to anyone!!) but with a very clear distribution channel.

Given the low prices of games (between $0.99 and $10) on the iPhone, not only is it possible to make great games with a team of two people, but actually having larger teams can make development much less profitable. I can’t imagine how EA or Maxis are making any money from their iPhone games if they put even just 10 or 20 people to work on them for a few months.

In order for indies to succeed in the app store, it’s important that we get enough visibility. Right now, the big money is on the top lists that Apple publishes which are unfortunately out of reach for most of us. A trend I’ve noticed lately is that big publishers are starting to elbow out indies out of the Top Ten charts. I hope that’s not a trend that continues much further.

I’m glad to see that the app store has related links when you browse a product, and also a variety of independent web sites that are appearing trying to sort the iWheat from the iChaff. It’s a start, but we need more initiatives along those lines. In the meanwhile, support your indie iPhone developers. Or at least go out of your way to learn a bit more about them. If you haven’t seen it already, check out the New Year’s App Blowout Sale and pick up Sneezies, Up There, and Mouse House. All three totally adorable, very polished games.

Happy New Year 2009 to everybody! I’m sure this year will bring a lot of surprises and interesting developments.

[1]Yes, I shamelessly stole that line from my favorite sci-fi show.

Starting iPhone development was a bit of a change since it required me to work exclusively under OSX and use a new IDE (XCode). I had talked to people who found the change very cumbersome and found the new environment got in their way, so I approached it with a bit of trepidation.

It’s An OS X World

With my new Macbook Pro under my arm (actually, it wasn’t new, I bought it used off Craigslist because I couldn’t afford a new one), I embarked on an adventure to this strange, new world of OS X development.

Some background is necessary here: I”m a minimalistic, no frills kind of guy when it comes to my preferences when working with computers (although now that I think about it, it probably applies to most other things in my life as well). The first thing I do with a new install of Windows is turn off all the GUI animations (don’t get me started on the search puppy dog!!), most of the sounds, all the auto-complete and auto-spellcheck features, and automatic upgrades. When I want the computer to do something, I’ll tell it to do so. Otherwise I want it to be quiet and responsive.

My ideal Visual Studio setup is also pretty similar: No fancy web startup page, no animations, no autocompletions by default (unless I press CTRL-Space), out with all the toolbars, just give me two text windows side by side and control everything from keyboard shortcuts (which I’m still using the ones from Visual C++ 6.0).

Needless to say, I was afraid of clashing with Mac OSX’s environment. I had a suspicious that it was full of eye candy, GUI frills, and required a mouse for everything. Not a good match.

There wasn’t as much of a learning curve as some getting-used-to. There are some Mac quirkiness that I just don’t get: The disembodied menu on the top of the screen, the lack of change of mouse cursor when you can resize a window, or not being able to automatically restore a file to its original location from the recycle bin.

But those are all relatively small things that don’t overshadow the fact that I just love this new environment. I used to like the Windows fonts, but after a week of using a Mac, I can’t go back to those tiny, jaggedy Windows fonts. Handling of multiple monitors is perfectly integrated and works like a charm. In general, things Just Work (TM).

Then there are the things that I love from my time in Linux that I can’t live without: Multiple desktops with Spaces, a decent command line shell, or being able to tweak settings directly in low-level config files.

And the thing that has changed how I work the most: Spotlight. No need for icons everywhere, or “Start | Programs” or anything. Just start typing what you want and there it is. It’s like the return of the command line on steroids. Between Spotlight, Firefox smart locaton bar, GMarks, and Ubiquity, I feel right at home. Now combine them all somehow and I’ll be in heaven!

But Wait, What About Windows?

I ended up falling in love with OS X so much, that I quickly moved to it as my primary environment at home for everything. Frankly, these days, it’s pretty easy for me to change environments since most of what I do is online. Just give me Firefox (or a good browser) and I’m there: GMail, Google Calendar, Google Reader, Google Docs (hmm… I sense a theme here), and a Wiki cover most of what I do on a daily basis.

For the rest of the apps, almost everything I need runs under OS X: good media visualizer (Preview), photograph organizer (Lightroom), image editor (The Gimp/Photoshop), audio editor (Audacity), music player (iTunes), and a few more odds and ends. OS X comes with some great utilities out of the box too, like Grab, Preview, or Activity Monitor.

Unfortunately, there are still a couple of things that I can only run under Windows. The main thing are games unfortunately, so I need to keep my Windows box around just for that. Although I just started playing World of Warcraft and it runs great on my Mac. Thanks Blizzard! Apart from that, every so often I need to do something in Visual Studio, or run some application I wrote in .Net. For that, I go about it in two different ways.

I can run it on the Windows box itself. Instead of keeping two sets of keyboards and mice (or a switch box), I used Synergy for a while. It was pretty cool being able to move the mouse cursor from one screen on the Mac to the screen on Windows and continue working there, and that might be a great solution if you’re working 50-50 on both platforms. In my case, it was more like 90-10 at the time (more like 99.9 to 0.1 now), so it felt a bit of a waste to have a full monitor dedicated to Windows. Instead, I decided to use Remote Desktop to control my Windows computer from the Mac. Amazingly enough, Microsoft wrote a Remote Desktop app for OS X that works like a charm, much better than some of the VNC programs I tried.

Whenever I don’t need to run something that is performance critical, I reach for Fusion. I’ve tried many products in the past that claim to run programs for another platform in your own computer: Wine, CrossOver Office, earlier versions of VMWare, but they’re always plagued by problems and incompatibilities. VMWare Fusion really surprised me by running anything I threw at it flawlessly, including Quicken (yes, I need to switch to Mint or Buxfer) and some hardware-accelerated 3D programs (those were a bit chuggy though, but they worked). And the coolest feature ever: Unity–I can run Windows apps in a window of their own directly on the Mac desktop. Totally awesome! On top of all that, I can have multiple snapshots, restore earlier states, and I can even run other operating systems like different versions of Linux. A geek’s true dream!

Some people will claim that I have drunk from the Apple kool-aid, and to a certain extent, they’re right. But I’d like to think I was swayed by many good reasons having to do with using the computer and being more productive, rather than Apple’s brainwashy, lifestyle marketing message. That and the smooth feel of the Macbook against the palm of my hands, its sleek profile, and sexy design.

What about XCode and development? That’s another story for another day.

Since both Charles and I are tech guys, we knew we could implement our game idea without any problem and make it sing and dance at a silky-smooth 60 fps. But would it be fun? Now that we have these brand-new designer hats, finding that always elusive fun factor is a big concern. The idea of waiting for a couple of months before we could tell if our game idea was fun seemed too risky, so we tackled that problem first and head-on by prototyping.

We could start at the bottom, write some low-level input handling, some graphics rendering, a basic asset pipeline, and all the other usual suspects. The problem is that, even if we try to keep things as simple as possible, it would still be several weeks or even months before we can actually start implementing the game itself. And even when we do, we’ll always be running up against incomplete technology and having to spend time fleshing it out as we try to make a game come out of the other end.

Instead, we decided to start with a prototype. This isn’t supposed to be a “prototype” that eventually morphs into a shipping game, or a prototype that uses the same technology as the production code, or even a prototype that’s used to impress the big-wigs to squeeze some money out of them (ha!). No, all that stuff detracts from the ultimate goal of our prototype. Our approach was very similar to what Chris Hecker and Chaim Gingold described in their GDC presentation. We had the need to answer one very specific question: “Is our game idea fun?” And we wanted the answer as quickly and cheaply as possible. Everything else was secondary.

Prototyping period

And so we dove into a prototyping frenzy. For our first day, we set up shop at the E Street Cafe. We opened up the place, took over a table, hooked up gamepads to our laptops, and hacked away furiously until late in the evening, fueled all the while by cappuccinos, gourmet tea, and pastries [1]. Yum! By the end of the day, we had the basics of the game implemented and even some of the more advanced features. Heck, we even thought it was kind of fun, but that’s because we were tired and we had been staring at Charles’ horrible programmer art all day long. In all honesty, it really was a pretty sucky game, even if the enemy characters were wearing party hats. But hey, that was just end of day one.

Over the next few days, we had to take a break to deal with all the paperwork and logistics involved with setting up the new company and the office, but we resumed prototyping as soon as possible. The plan was to keep hammering away at the prototype until we saw it was clearly fun, or we decided it was hopeless and we had better think of something new (or go back and beg for our jobs back). Charles took it even further and swore not to shave his beard until the prototype was fun, much to his fiancee’s delight (seriously, the only thing the ladies think is hotter than a game programmer is a bearded game programmer).

A week later, things weren’t looking too hot. The game hadn’t gotten much beyond what we had done the first day. Sure, we had a bunch of advanced features in, but it didn’t really make it much more fun. Were we on the wrong path?

The major breakthroughs happened in the last few days. First of all, we removed a key feature that had been there since the very beginning. We really thought it was going to be key to the whole game, but it really made the game too easy and boring. As soon as we removed it, the feel of the game changed completely and things started to look up.

Then, as we were discussing some other advanced moves and features, the idea for a minor feature came up. Since the caffeine hadn’t kicked in yet and I didn’t have the energy to work on the next big feature, I implemented our little idea in about ten minutes. Charles saw it over my shoulder and he started laughing and begging me to check in the code. It was an instant hit! We ended up liking it so much that we decided to expand on with a few features, and before the end of the day, it’s clear that it’s going to become a main gameplay mechanic in the final game. That day we went home knowing we were nearing the end of the prototype face. Good thing because Charles’ beard was starting to look scary!

One more day of tweaking the prototype and we officially called it done. We knew we had gotten there when we tweaked a small feature, fired up the game to see how it felt, and then spent 10-15 minutes going crazy with the controller because we were having too much fun. Another good sign was when we would start playing and then yell at each other to look at the crazy things we had just accomplished.

Finally, Charles was able to shave. Thank God.

The prototype

The prototype process was supposed to be as quick and cheap as possible. None of the code written was intended to be kept or extended to go into production code, and performance wasn’t an issue either. So, with that in mind, what did we use for developing our prototype?

C++ and Allegro. Yes, you read it right the first time. Let me say that again: C++ and Allegro.

With all the other choices available of higher-level languages and extensive game development libraries and frameworks, why on earth did we make that choice? Wouldn’t Python with PyGame or C# and the Game Studio Express have been better choices? The honest answer is that I don’t think either one of those options would have allowed us to get the prototype done any faster for several reasons:

• Small scope. The scope and size of the prototype was quite small, so there wasn’t much to be gained by using slightly higher-level language constructs or more complete libraries.

• Allegro. Even though it might seem like an odd choice and be behind the times, it’s precisely the old-school, fully procedural approach that makes Allegro so valuable. There are no frameworks, no enforced class hierarchies… heck, no classes or private members to get in the way. In Allegro, if you want to do something, you call the function and you’re done. Exactly what we needed for the prototype. In retrospect, SDL might have been a better choice since it would have allowed us to use a DirectX surface and do video capture more easily. But Allegro worked like a charm and we have nothing but good things to say about that experience [2].

• Proficiency. Both Charles and I are quite proficient at C++, so even if another language gave slightly faster development time, we more than made up for it by being very familiar with C++ and its libraries. For the prototype we allowed ourselves to use STL recklessly and with wanton disregard for memory access patterns and spurious allocations.  We also didn’t care about memory leaks at the end, so that helped get things up and running a lot faster.  Destructors?  Delete?  Free?  Cache coherency?  How do those equate to fun gameplay?!

It’s no secret that I’m an avid advocate of good software engineering practices for game development. As with anything, good software engineering practices have some very real and important benefits, but those benefits come with a cost. Because of the small scope of the prototype, and the fact that the code wasn’t going to survive more than a week or two, we decided to throw any software engineering practice that would slow us down in the least straight out the window!  Forget about accessors and private scoping; skip any unit tests; bye bye factories, loose coupling, and proper physical dependency management. Welcome to hackfest, check your engineering discipline at the door!

One of the things that made the prototype very successful for us was to concentrate on a single gameplay mechanic. We didn’t try to prototype the whole game, just the one bit we were most concerned about (and that was going to take 80% of the player’s time and attention). That allowed us to deal with a small subset of the game and iterate on it very quickly without getting bogged down by creeping features or dealing with a larger scope.

The prototype shamelessly used the worst programmer art imaginable (Charles + MS Paint == … you can imagine [edit: Charles] TOTALLY AWESOME SWEET). Yes, it looked horrible, but if the game was so much fun with those graphics, just imagine how it’s going to blow people away whenever we add some real art and animations.

Lessons learned

The most valuable lesson we learned was the value of constantly asking ourselves the questions “Is this fun?” and “What can I do now to make it more fun?”  That was actually really crucial. Having such a specific (even if subjective and nebulous) goal allowed us to remain in the right path. Sometimes it was tempting to add feature X or Y, but when we realized that it wouldn’t make the game any more fun, we quickly dropped it and moved to something else.

It’s important not to over-intellectualize the idea of “fun”, though. Sure, most of the fun comes from the choices the player makes and what happens as a result of those choices (even if the choice is to mash the buttons). But don’t underestimate the value of “fun” in having cool, flashy things on the screen, or to have the character jump with a nice ramp-up curve and land with some squishiness to give it that “just right” feel.

It was also very helpful to run the prototype by somebody else towards the end to make sure we weren’t finding it fun because we were simply delirious. Clearly, it has to be someone you can trust and who can understand what the prototype represents and not be put off by the stick figures. It was great to get confirmation from an outside source that it really was getting to be fun. We also got a bunch of feedback that made it a much tighter experience. A lot of it was pretty obvious, but we were too close to the game to be able to see it by ourselves.

As with most prototypes, it’s always very tempting to not throw it away and continue hammering at it until it looks like something that could be shipped. We didn’t really have a choice because of the technologies we went with (allegro is a fully cpu-based renderer), but we could feel the call of the dark side. It really was a good thing that we didn’t even try. Towards the end, the terrible hacked code we’d written was starting to slow our productivity. Code that bad builds up an “engineering debt” that you have to pay off sooner or later or you hit a wall.  Our particular wall came in the form of extending a pre-existing player action in what seemed like a trivial way.  Something like this would have literally taken about 5 minutes at the beginning of the prototype, but by the point we were at it would have taken closer to an hour. Heck, even having to go on for another week would have started to be painful. So in a way, the prototype came with a built-in self-destruct mechanism, which is a good thing because it discouraged us to continue working on it for too long.

Using existing technology is definitely the way to go. That way there’s very little “wasted” time getting up to speed. The fact that we were able to get most of the core mechanics of the game in the first day goes to show how useful is to hit the ground running instead of getting bogged down in how to load bitmaps or create a window.

Additionally, the procedural, non “framework-y”, non-object oriented approach of the API we chose made it much easier to bend to our will and make it work the way *we* wanted, and not the way somebody decided for us ahead of time. The fewer restrictions your prototyping API has, the easier it will be to do all the crazy things that come to mind during the prototyping phase.

The game

Unfortunately, we can’t really talk about the game right now. Just rest assured that we’re working on it at full steam and we’ll announce some details as soon as we can. Clearly, we’re not going to release the prototype since it has a good chance of scaring away any potential publishers in its current state. But if one day the game sells tons of units, maybe we’ll release the prototype as a “behind the scenes” feature so other people can have a glimpse at how things got started and they can laugh at our artistic skills.

Conclusion

There you have it. Now at least we can be confident that the game is going to be pretty fun. Sure, there are lots of aspects of the game that we haven’t prototyped, but we consider those to be lower risk and we’ll figure them as we go along. At least the core mechanic has proven to be fun. Now it’s just a matter of writing the production code and implementing it all. That simple. What could possibly go wrong?

[1] Money saving tip #1 for starving startups: If you have to pay for a 24-hour Internet connection in a coffee shop and you need to have several computers with Internet access, connect them with an ethernet cable and share the Internet connection from one of them. Ta-dah!

[2] Actually, I’ve been wanting to create a movie of the prototype in action, but I haven’t been able to. It seems that Fraps doesn’t work because it’s not using a DirectX surface, and saving each frame is too slow. Anybody has any suggestions? Don’t get your hopes up though, we’re not uploading a movie of the prototype any time soon, we’re just saving it to show our grandchildren one day.

The computer was laughably primitive by today’s standards: Z80 4MHz CPU with 64KB of RAM. What made it stand out from other computers at the time was a whopping 16 simultaneous colors (as long as you gave up half your horizontal resolution), three-channel square wave sound generation, and 3” floppy disks. Cell phones these days are hundreds of times more powerful than that computer. Heck, the chip inside your microwave oven is probably more powerful!

What was it that caused love at first sight with that computer? Impressive as they were at the time, it wasn’t the technical specs that attracted me. It wasn’t the silly games either, even though those were fun for a few days. It was being able to give commands to the machine and have it execute them immediately.

The computer booted directly into a Basic interpreter. I started experimenting with a few PRINT statements, then moved to FOR loops, getting input and solving algebra problems as if by magic. I spent endless hours typing game listings that came in magazines (usually with a few printing errors, which made them so much more fun to get working correctly). I experimented with graphics, sounds, and animations.

Before I knew it, the Basic interpreter was too slow and bloated and I had to graduate to assembly. Programming became a bit slower (especially since for some reason I could only save the assembly onto tapes, not disks), but the programs became thousands of times faster. I was finally able to draw sprites without annoying flickering, use all available memory, and even overwrite part of the ROM jump table to squeeze in a few extra KB.

I was hooked.

That experience totally changed the rest of my life. It caused me to study computer engineering and computer science, and eventually to write games professionally (much to my parents’ dismay).

If that little, primitive computer had that effect on me, today’s dazzling multimedia computers with broadband Internet connection must have a hundred times that effect on today’s children, right? Quite the opposite.

Today’s computers might be a lot more powerful, but they’re also a lot more complicated. Windows is very large and intimidating to a newcomer. It doesn’t exactly scream “play with me, experiment!”. Instead, it is a very closed system. It discourages experimentation, and you’re in constant fear of disturbing any of the overly complex configurations (like the registry or system dlls), not to even mention dealing with viruses and other malware. Linux is much more transparent, but it’s still far from an inviting system to play and experiment with for newcomers to computers.

Another problem with modern computers is the lack of a programming language out of the box. Things are actually a bit better now than they were a few years ago. Microsoft offers a free express edition of Visual Studio. Python and other scripting languages are also free downloads, and they also have libraries for game development. Unfortunately none of those tools come pre-installed, which makes it hard to get started and even harder to share your results with other people. Also, a lot of free development tools and environments today are geared towards GUI programming, which is very different from the free-form, take-control-of-the-machine approach that you need not just for games, but to really learn about the machine. There really aren’t many better ways to permanently scare people away from programming than showing them something like this.

Web development is a bit better because it tends to be simpler, and once you have a web server set up, it’s easy to show the results to anybody with an Internet connection (which I hope is everybody these days). Unfortunately it’s not particularly well suited for something like games with the exception of things like Flash.

Although I’m sure that part of it is nostalgia, I’m clearly not the only one who feels this way. Computer science enrollment has been dropping dramatically in recent years and there seems to be a lack of interest in learning more about these machines that surround us, beyond how to use a browser and how to share videos with friends.

Really, when I look at things this way, I feel bad for kids growing up today. They’re missing out on a huge source of enjoyment that I had growing up as a kid. Of course, today there are other new frontiers to explore, and they have the Internet with all the new social aspects, but it’s not the same.

So, is the dream dead?

I have often wondered, isn’t there a platform out there that is more like the 8-bit computers were in their day? The closest parallel today is game consoles, except that they’re very closed and proprietary and they’re only intended to play games. Sony started making some progress along these lines with the Yaroze program for PSX and Linux for the Playstation 2. Unfortunately neither program was particularly successful for a variety of reasons, but it was a start.

A couple of days ago, in the keynote for GameFest, Microsoft announced that they’re taking things further on the Xbox 360 with Game Studio Express. They’re planning to open it up and allow everybody to develop games for it. Even better, the code will be mostly common between Windows and the Xbox 360, so it will be possible to do a lot of development on the PC and then move it over to the 360 relatively painlessly. How cool will it be for kids to write their own games running on the Xbox 360 and be able to show them off in their friends’ living room?

It seems that the only language available will be C#. At first I was disappointed as I was hoping it would work with C++. Then I realized it wasn’t such a bad idea. If anything, it would be better if it were something simpler, more like Dark Basic, that people with very little programming experience can quickly start messing around with. Game Studio Express is supposed to include several tools and APIs that allow you to program things at a really high level, so that might be good enough.

I’m very curious about the details, though. For instance, are we going to be able to get our hands dirty and write as much C# as we want, or are we going to be limited to a very strict framework? Is the link between the PC and the 360 something that they’re going to expose? In other words, will we be able to create other tools that use that functionality to create new types of content?

A really important question is whether anybody will be able to play content created by users, or will they have to have some special payment-based subscription. Having to pay to develop for the 360 is not ideal, but I don’t see it as an unsurmountable barrier. However, if users have to pay and be part of the developer program just to be able to play some user-generated content, that would come close to killing its usefulness. I hope that Microsoft learns some lessons from YouTube and Google Video and realize that the lower the barriers for people to browse the content, the more successful it is going to make the product. People have been able to share videos for a long time already, but it involved downloading them, getting a player that could decode them, and playing them back. Now it’s as simple as clicking on a link, and that’s why it has finally reached critical mass.

I’m definitely keeping a very close eye on this project, and I’ll try to give it a test drive as soon as I get a chance. It’s a bit ironic that with dozens of multi-million AAA titles out there, the reason I might end up buying an Xbox 360 is the chance to do play around with some sprites on the screen and re-create a bit of the old 8-bit days. The dream might indeed be back.

The underlying current at this year’s GDC was the transition to the next generation of platforms. The change was in the air. It wasn’t just the topic of the talks, but it was also underlying the questions asked, the technologies shown in the expo, and even the conversations at lunch. It influenced every activity and message. If it wasn’t because of what was said, it was because of what was left out, or what was put on hold “for a few more months.”

E3 is just around the corner, so we can expect to finally get the official announcements of Microsoft’s next-generation console, and maybe even Sony’s. That will mark the official transition into the next generation.

And this is not just another console generation transition. This time it’s bigger. Much bigger. Certainly much bigger than the PSX to PS2 console transition we went through five years ago. Maybe even of the same caliber as the transition from 2D to 3D that we saw 10 years ago. The changes that are about to happen affect more than the hardware we develop for. They’re going to affect how we develop games, how we organize ourselves, how we sell games, what type of games we make, and even how we think about games. Winds of change indeed.

These are the major changes I see coming.

Content generation

As the consoles become more powerful, we can create much more detailed environments, and players are going to expect that. Whereas it took someone a day to create a Doom 1 level that was roughly in a shippable state, now it takes someone several weeks to create just some of the geometry that is in a room in one of those levels. The team sizes, especially on the content creation side, are going to balloon, and soon teams numbering in the hundreds are going to be commonplace.

Large volumes of content aren’t just going to affect team sizes. We’re already struggling to deal with the amount of content we’re generating today, so we better get ready for the demands of tomorrow. A smooth, fast, robust, and efficient asset pipeline is going to be of prime importance. Probably more so than fancy tech and clever algorithms. The games that are going to stand out from the crowd from the point of view of visuals and polish are the ones with really good asset pipelines that allowed their content creators to iterate over and over and come up with something very close to what they were thinking. Tech-centered teams might have some impressive algorithms under the hood, but the resulting product is going to pale in comparison to their competitors.

The whole topic of asset pipelines is very dear to my heart. I previously wrote about the MechAssault asset pipeline, and I’ve changed my mind about several things since then. Adding the demands of next-generation content is going to make this topic even hotter.

From a technical point of view, we also have to consider the rebirth of procedural content. This is something we had considered in the previous console generation (and quickly dismissed), but this time it’s going to make much more of an impact. In a machine that can render a gorgeous scene that fully fits in memory, we’re going to need to have either an amazing streaming system, or great procedural content creation (or both!). Will Wright drove this point home in his talk about his new game, Spore.

Alternatively, maybe we’ll see a more clear distinction in what paths games take. Some games are trying to follow movies in the experience they offer: they are short (8-10 hours or less), full of new content, and giving players totally new experiences throughout the game. These are what I call “interactive experiences.” Then we have the “real” games, or toys. These are not a content showcase, but a game, with some rules and some variations, and lots of interaction with the player. This is the category of Sim City, Amplitude, or even sports or driving games. Games like Grand Theft Auto fall in an intermediate category because they straddle both types of games (mostly a toy sandbox with a story bolted on top). The point is, the more difficult or labor-intensive content creation becomes, the more we’re going to see this divide.

Development model

Next-generation games are going to need large number of people during production, but pre-production will still require only a small number of people. That’s the case today, but this trend will be exaggerated further.

Up until now, small companies with only one or two projects at once just put up with it and didn’t fully take advantage of everybody during pre-production. But will they be able to keep doing that now when they need to staff up to 100 people per project during production? If they staff up, how are they going to continue in business between projects? Does everybody need to grow to a size of 200-300 people to have multiple projects going on at once and smooth out the production spike needs?

One alternative that has been banded about for the last couple of years is the movie industry model. Game companies could do pre-production with a small number of people, and then assemble a team just for the duration of one project. There are some among us (especially from the UK) who will say that that’s already happening, just unofficially, with companies regularly laying people off after a game ships (see recent Oddworld news after completing Stranger’s Wrath).

Personally, I really dread this development model. Not only does it mean that we’ll lack a stable paycheck (and probably have even more emphasis on crunch periods), but it also means that the industry is going to cluster around a few central locations. In the US that will most certainly be Los Angeles, San Francisco, and maybe one other city. This is necessary to have a readily available talent pool, but it’s really a bummer for those of us who’d like to live elsewhere. Not like there are many companies in remote locations, but today you can choose to work in places like Maryland, North Carolina, Western Massachusetts, or Texas. Tomorrow we might not have that luxury.

Outsourcing went from being something that other industries talked about a few years ago, to something that we now accept as fairly common for art resources or cinematics. Outsourcing is a great way of flattening the curve of necessary resources, so I fully expect it to become the norm. Anything that can be outsourced will be. And a few things that can’t be will also be outsourced. For now that means cinematics, static geometry, some animations, music and some sound, and maybe some level layout.

Is outsourcing going to affect programming? I don’t think so right now. The closest thing we have to outsourcing is middleware, which is also a trend that is going to continue to grow. Especially if companies want to hit the ground running for a large production project, it makes total sense to use as much middleware as possible. Just look at how many developers are flocking to the Unreal Engine 3. It’s a very good set of technology and Epic managed to position itself in the right place at the right time (i.e. console generation transition).

Multiprocessors

This is undoubtedly going to be the biggest architecture change we’ve seen in a long while: multiple processors.

We all know that writing threaded programs is difficult. But this is something that goes beyond making your program thread-safe; it’s going to be a whole lot more than that. We have to deal with not just splitting the game into parallelizable parts, but we have to make sure those parts don’t interfere with each other, and that they access main memory in a controlled, efficient way. The gap between CPU and memory speeds continues to widen, and adding multiple processors to the mix isn’t going to help any. Games that ignore memory access patterns are going to crawl along in next-generation hardware.

Sony’s PS3 is going to take things even further. It’s going to use a cell processor with multiple cores, but each of the cores only has access to a very small amount of local memory. Not exactly the everyday programming model of the hardware we’re used to.

To be able to take full advantage of the new hardware, we’re going to have to change how we think about our programs. Take a snapshot of your game engine architecture, tilt your head 90 degrees, and that’s more how it’s going to look now. Data-driven architectures and service-oriented systems are going to dominate this new landscape.

Fortunately this is not just a bizarre architectural decision that console manufacturers pulled out of a hat. They are just leading the way as far as future architectures. More and more multiprocessors are becoming the norm on PCs, and both Intel and AMD have been busy at work for several years to take advantage of this trend. When you can’t make your processors faster, cheaper, and smaller, you need to start thinking of different directions to continue improving performance. Herb Sutter has been talking about it for a while now and he also sees it the inevitable future. So, as a programmer, don’t be afraid to dive in and get comfortable with this architecture. Multiprocessors are here to stay, and it’s going to be a valuable skill in the future.

Online focus

It seems that everybody is talking online this, online that. Especially Microsoft. Personally, I’m a bit scared (and skeptical) of this trend. Even though I enjoy the occasional multiplayer game (and I’m enjoying Guild Wars quite a bit right now), I certainly don’t want to make all my gaming experience be multiplayer. I do enjoy playing against the AI, or against somebody else sitting on my couch. I certainly don’t want to wait 10 or even 5 minutes to get everybody together before we can start a game, and I most certainly don’t want to hear eight-year-olds yelling while I’m trying to unwind by playing a quick game in the evening. I don’t want that on a PC game, and certainly not on a console game, which is supposed to provide a quick gaming experience.

I think the PC went through that phase about five years ago, when online gaming was new and exciting and every game had to have an online component, but it has reached a more mature position now. In the console realm, online play is still pretty new, so it keeps being pushed as a big marketing point. Xbox Live was apparently a big hit (certainly much bigger than I predicted back when it was announced), but it’s still only a tiny fraction of the market. Console manufacturers and publishers seem to think that broadband penetration is what’s preventing more people from jumping online. Have they considered that maybe most people don’t want to play online?

It always amazes me to see games whose multiplayer component is a completely different game from the single player one. They are two totally different experiences duct-taped together in one package, and usually one (or both) suffers for it. Wouldn’t it have been better to spend the resources in one of those areas and do it well? For example, the Grand Theft Auto series got it right. Sure, they could have done multiplayer with capture the flag, conquest modes, etc, but that’s not what the game is about.

So please, let’s not get drawn in by the hype and let’s keep the single player alive.

Conclusion

Times really are a-changing. The potential changes to the development model scare me. I hope things are not as grim as they seem right now and small game developers can stay afloat and not have to move to California to survive. On the other hand, I’m genuinely excited about the new technical challenges and figuring out how they’re going to affect the way we develop software. Bring on those multiprocessor machines!

A few weeks ago, Joel wrote an article with advice for college students looking to become programmers. It was good, solid advice overall, but it was a bit too general, and it didn’t apply very well to the games industry. I often get email from people looking to get their first job in the game industry asking me for advice. What are companies looking for in candidates for entry-level programming positions? How come it’s so difficult to land a job? I can’t answer for the industry as a whole, but I can certainly tell you what I am looking for when trying to fill an entry-level programmer position.

Specifically, I’m going to concentrate on the case of someone without any previous industry development experience applying to game companies for the first time, possibly straight out of college. At the end I’ll touch on people switching industries with previous experience in other software industries. If you’re already in the games industry, then you already have a pretty good idea how you got there, and that experience will carry you forward much more easily than someone trying to break in for the first time. Still, you should be able to meet all these requirements in spades for your next job interview, so you might want to read on anyway.

The type of job openings you’ll be looking for are usually referred to as junior programmer, entry-level programmer, associate programmer, or something similar. Sometimes it’ll be listed simply as programmer but they’ll specify that previous experience is not required.

What exactly am I looking for, then, in an entry-level programmer candidate? Here is what I’d like to see, roughly in order of importance.

Enthusiasm.

Maybe this goes without saying, but I figured I would put it as my number one item. If you aren’t extremely enthusiastic about developing games for the first time, you might as well look for something else. In a couple of years you’ll be extremely disappointed and will be thinking of switching industries anyway.

How do you show this enthusiasm of yours? Working on a project of your own is an excellent way of convincing potential employers that you really care about this stuff. Write some small games, participate in some open-source projects, make some mods, do whatever you want, but work on some game-related projects. I would recommend working on several small projects, and then try to work on one larger one to get exposure to several areas and get experience working on a large code base.

Make sure to bring up those projects in your resume and put them on your web page (yes, we do check web pages and google for people before bringing them in for an interview). In a way, they’re the closest thing you have to experience in the industry. Be ready to discuss your project, why you did things in certain ways, ask how other people deal with particular issues, etc.

Always learning.

You’re about to finish your college education. If you think you’re done learning, think again. You’ve just finished the base that allows you to continue learning. Especially in this always-changing industry, you will always be learning new things: new platforms, new APIs, new languages, new approaches, new styles, new everything. Don’t think for a moment you can learn a couple of things and then stick to them without learning anything new.

It’s great to be confident in your skills, but if I catch a whiff that the candidate is set in his ways and is not interested in learning anything new, it’s “hasta la vista, baby.”

So go out and learn new things. I always like to be reading a technical book on things directly applicable to what I do at work, and maybe some on things that are more off-the-wall. In addition, I recommend reading trade magazines (Game Developer Magazine, Software Development, C/C++ Users Journal, etc), conference journals (GDC, Siggraph, ACM), web sites (Gamasutra, Flipcode, GameDev.net), mailing lists (gd-algorithms, sweng-gamedev, gd-general), and just about anything you can get your hands on. Don’t be afraid to look at open source projects (Nebula Device, Crystal Space), figure out how they do things, and even participate in their development.

The book The Pragmatic Programmer recommends learning one new computer language every year. It might be a bit of overkill, but it’s certainly not a bad idea. Even if you’re not planning on using Smalltalk or Ruby, it can only broaden your skillset and give you new perspectives on things. Learn about garbage collection, dynamic languages, etc. Of course, make sure you have the basics covered and you have a good grasp of C and C++ before you branch into other languages.

Plays games.

Doh! If you’re going to be developing games, you better play games on a regular basis. You don’t have to be a hardcore player, but you should enjoy playing some games. Be ready to discuss your tastes in games, what you’re played recently, why you liked them, etc. It’s not like you’re going to be designing the games (after all, you’re applying for a programming position), but it’s good to have an idea of what you’re aiming for when you’re creating a game. Also, the more you enjoy playing games, the more of a reason you have to actually want to work on them.

In my time in the industry, I’ve only known one programmer who didn’t play any games (and he was extremely talented to boot), but he was certainly the exception to the rule. If you don’t like games, you better have a really good reason as you why you want to get in this business.

Skills.

Ah, yes. It finally had to come up. As an entry-level programmer, you’re expected to learn a lot on the job, but you need certain skills to be useful and productive from the very beginning. Hobbyist game programmers obsess about DirectX and OpenGL. That’s fine, but don’t worry too much about it. You’re not going to see a single line of those APIs unless you’re hired as a graphics specialist (unlikely for a junior-level position). The specific skills will depend on the exact job and company, but these are pretty universal given what typical junior programmers get to work on.

• Fluent in C++. Most game development (for PCs and game consoles) these days is done in C++, so you’d better be comfortable with the language. Knowing the syntax and compiling “Hello world” isn’t good enough. A class in college isn’t going to cut it either. The ideal candidate will have at least read Effective C++ and will have used C++ in some significant projects (either your own projects, or in some term projects at school). You should be able to discuss the order in which destructors are called for classes with inheritance, when you need to provide a copy constructor, or what const-correctness is and why is it a good idea. If not, hit the books right away.
• Basic 3D linear algebra. As an entry-level programmer, you’ll most likely work extensively on high-level game code at first. To do things effectively, you’ll need a good understanding of the fundamentals of 3D linear algebra. Make sure you know your dot and cross products, how to calculate them, but, most importantly, what they represent and when you should use them. You should be comfortable with relative coordinate systems, and matrices as transforms (I don’t care if you know the formula for a rotation matrix, just that you know how to use it). Calculating if an object in the world is within a certain distance from the player, and within a certain angle of its aiming direction, should be close to second nature. Review your linear algebra books from college or check out Mathematics for 3D Game Programming and Computer Graphics
• Software engineering. This is not a requirement for total entry-level positions, but it’s certainly a nice bonus. Unfortunately it’s not often emphasized (or even taught) in many schools, but being familiar with good software engineering practices is very important. Learn all you can about good object-oriented design, design patterns, encapsulation, unit testing, physical insulation, etc. There’s more to programming than knowing a language or API. This is difficult for people straight out of college, but it’s a huge bonus when you have it. Internships could help with this, but they’re not nearly as crucial for me as Joel says. I’d rather see an impressive set of home projects than a couple of summers working at IBM or Sun (on one hand I see a guy with lots of internal drive, and another one that needs to be told what to do and needs guidance). Having both would be awesome.
• Tools. I certainly don’t expect new programmers to be familiar with the exact tools we happen to use. However, the ideal candidate should be familiar with version control, should know how to use a debugger, etc.

Ability to get things done.

As an entry-level programmer, you’re going to be thrown in the water and you’re going to have to figure out a lot of things by yourself. Sure, you’ll hopefully get some supervision, and people will be able to answer a lot of your questions and work with you. But you’ll be expected to tackle something, learn about it, and get it done.

Here’s one that I completely agree with Joel: Make sure you get a degree, and do the best job you can with it. Sure, a degree doesn’t measure many things, but getting a good GPA means that you were able to stick with something for four years, even when things got tough or when you had to do things that you didn’t feel like working on. Working in games is not all fun (even if it’s all games), so making sure that people are not easily discouraged and can get things done is very important.

Another way of showing that is, as I said earlier, by working on projects on your spare time. That shows someone who went to the effort of creating something while learning something new. It doesn’t have to be a super-polished, finished game, but it should be more than a couple of classes that compile without errors and print “OK”.

Well-rounded education.

Knowing things outside of games is a good thing (knowing the detailed history of the Star Wars universe doesn’t really count). Taking and doing well in classes in a variety of topics in college is a good start. You may think that your South American archaeology class will never be of any relevance, but you’ll be surprised how things you learn there will come in useful in the most unexpected ways.

Make sure you do something beyond games. Take up a hobby of something totally unrelated. Some of the best candidates are art enthusiasts, practice sports seriously, are into oriental philosophy, or play the viola. I always ask about people’s hobbies during an interview. Usually the weaker candidates won’t have any hobbies or their only hobby is playing computer games.

I really think that if you’re going to dedicate yourself professionally to games, you need to have some interests in other areas. Also, being familiar with wildly different subjects allows people to approach problems from a completely different angle and come up with very creative solutions. Don’t discount the importance of a well-rounded education.

One thing you should not worry about at this point is specialization. If you have one in mind, that’s fine, and share it with your employer so you can plan a way to get there. But keep in mind that at first, breadth is more important than depth. It’ll be much better for you to learn as much as possible about game development in general. The brightest graphics guru who only knows about graphics will not be half as effective as he could be if he had broader experience developing games.

However, one specialty you can jump straight into is tools. Learn the APIs. Write some tools. Create an editor for an existing game. However, don’t think of tools as a temporary thing to pay your dues. Tools are an extremely important part of game development, now more than ever, so you can make a full career as a tools programmer.

How about people from other software industries with some years of experience? There’s a certain bias against them in the industry. On one hand, they’re not considered to have the right “experience,” and then they ask for too much money because they have several years in development already. You can bring a lot of experience, and a lot of it will be different. That’s very valuable, but the company needs to see that. Play that angle in your resume/interview. Explain how your skills can be invaluable to the company (and that also shows you’re familiar with the development process). Doing a game-related project on the side can go a long way to convince a company that your heart is in the right place.

If you only take one thing away from this article, this should be it: Always be looking to learn new things. Always read new books. Always try new things. Always be willing to listen to and try a different approach. Someone like that will quickly gain a huge amount of experience and become an invaluable member of the team, but the converse (someone with lots of experience not willing to learn anything new) is nearly useless in a rapidly-changing field.

Having said all that, I’m afraid we’re not currently looking for any entry-level positions at Sammy Studios. We might be hiring again this summer, so check back then. In the meanwhile, hit the books and sharpen up those skills.

This article was first published in the April 2004 issue of Game Developer Magazine.
Printer-friendly format.

Introduction

After years of being almost completely technology-driven, the driving force behind games is finally swinging towards the game content itself: level design, models, sounds, story, cinematics, etc. Major technological leaps are not making enough of a difference to set games apart from each other. Game content will also continue getting larger and more complex. The amount of content going into AAA games seems to double every few years. Since there’s no hardware upgrade for the artists and designers themselves, content doesn’t get created any faster.

A successful game needs to provide top-notch content, and the best way to provide it is to optimize the content pipeline so that artists and designers can create, preview, add, and tweak new assets as easily and rapidly as possible.

The content pipeline is the path that all the game assets follow, from conception until they can be loaded in the game. Game assets include everything that is not code: models, textures, materials, sounds, animations, cinematics, scripts, etc. During their trip through the pipeline, assets might be converted, optimized, chopped to bits, or combined. In the end, the asset is in a format that will be shipped with the final version of the game.

The first issue to consider when defining the content pipeline is its efficiency. With large teams of artists and designers constantly creating and tweaking game content, the content pipeline becomes a critical path. A slight inefficiency in the pipeline, such as taking one full minute from the time a change is made to the time it can be seen in the game, can easily cost a company thousands of wasted man-hours during the course of a project. Alternatively, if the content creators don’t preview their work as frequently, the overall quality of the game will suffer.

The other main point to consider is robustness. The content pipeline is the jugular vein of a project: if it breaks it can quickly kill the whole project. You can’t afford to have 30 idle people waiting for the pipeline to be fixed, or working around it and consequently losing half their work. Whatever happens, the pipeline must always work correctly.

Bird’s-Eye View of the Pipeline

What does an asset pipeline look like? It depends on the project. On one extreme, in some projects the pipeline is minimal and informal: assets are exported from their tool and loaded directly in the game. While that might be sufficient for small games, it usually doesn’t hold up well in large projects: Where are the files stored so multiple people can work on them? How are assets for multiple platforms dealt with? How can the format of the resources be changed easily? How can any extra processing be applied to them?

On the other end of the spectrum, pipelines can be very deep and elaborate. Adding a new asset to the game requires going to the pipeline guru and asking him to add the new content, causing turnaround time to suffer significantly.

This article presents a general pipeline that many different game projects can adopt and modify to fit their needs. It is fairly lightweight and provides a quick turnaround time, yet it allows for any number of expensive steps to be performed on the assets along the way. This is the pipeline that we’re using at Day 1 Studios for our current Xbox project, MechAssault 2. A previous incarnation of this pipeline was used in MechAssault 1. This pipeline might be a good starting place if you’re just beginning a new project, or you can try to adapt some of the ideas that make sense for your current situation.

Figure 1. A partial view of the MechAssault 2 content pipeline (only models and textures shown).

Figure 1 shows the pipeline for some of the major types of assets in MechAssault 2. The following sections describe in detail each of the pipeline stages.

Source Assets

Source assets are those created by artists and designers, usually through some specialized tool (both in-house tools and off-the-shelf ones). A source asset is one that can be put into the pipeline and will be converted into the final asset without any human intervention. The key idea is that source assets should contain all the information necessary to add them to the game correctly. A material should have all its specular parameters specified, and a model should have all the flags in the weapon barrels so the game knows from what point to shoot projectiles. This is what will allow us to automate the pipeline later on.

The way source assets are created can vary significantly. Sometimes they are created through a set of different, very specialized tools (one for modeling, one for texture creation, one for specifying game information, one to lay out a level, etc). Other times, one large tool (often done as a plug-in in the model-editor program) can be used to create all the assets and export full levels.

Since the source assets contain all the information needed for the final assets in the game, we should treat them very carefully and protect them from being lost or accidentally overwritten. Using a version control program provides a centralized location for all assets, prevents people from overwriting each other’s work, and keeps a history of previous versions of each asset. Keep in mind that source asset files can sometimes be as large as several hundred megabytes each, so make sure your version control program is up to it and can also deal well with binary files.

Pre-rendered movies and sound are also game assets, but they’re often treated differently because of their huge size. They might have a slightly different path through the content pipeline: Maybe movies won’t be kept under version control, or maybe they will but only the most recent version will be kept in the database.

Intermediate Assets

Intermediate assets are exported directly from the source assets, usually with the tool they were created with. This requires a bit more plug-in work in the form of exporters if you’re dealing with off-the-shelf tools.

The intermediate assets are in a format that is very easy to read, parse, and extend without breaking backwards compatibility. These assets should contain all the information we could possibly want in the future, even if some of it gets discarded before the end. Loading performance is of no consequence at this point; we’ll leave that up to the final assets.

Plain text files are the perfect match for our requirements. In addition, XML is a particularly attractive option to structure those text files, especially if we need to represent information hierarchically. Doing so will also provide us with a whole range of tools and APIs to edit, parse, and transform files with minimal effort. If XML files are overkill for your needs, you can still use a simpler format like INI files or even write your own with minimal effort.

What is the purpose of having this intermediate asset format?

The main reason to have it is to provide a buffer between the source assets and the final ones. Final assets are optimized to load blazingly fast, but as a result, their format will often change and render previous versions unusable. In an ideal world, we would be able to efficiently re-export all source assets automatically into the new final asset format. Unfortunately, we don’t live in an ideal world, and that is often impractical. Many off-the-self tools used for modeling and texture creation are not easily and efficiently driven from the command line to batch re-export thousands of models at the time. The intermediate format is not likely to change much during the course of a project, so we can always use it as a starting point to generate our final assets.

Another reason for having this intermediate format is to defer some of the complex and time-consuming operations like mesh optimizations or lightmap generation until a later time instead of doing them at export time. Also, we often end up creating a set of final assets for each platform we’re dealing with. Without the intermediate format, artists would have to export a set of assets for each platform, ensure they’re in synch with each other, and wait while each set of assets is converted and optimized every time an asset is changed.

Last but not least, having an intermediate format provides an excellent point for debugging and experimentation for the programmers. Intermediate assets should be in a very easily readable format, so anybody can view the contents of the asset, and even make small modifications for testing and debugging purposes without having to re-export them.

For MechAssault 2 we’re exporting full models into one XML file: all the hierarchy information, meshes, vertex data, and materials are included into one large XML file. One of those files for a detailed model can easily be 3-4 MBytes.

As much as plain text is a really nice format to work with, exporting textures into text format would be overkill. In the case of textures, we export them into 32-bit tiff files with custom information in the comments field containing any information artists specified from within Photoshop: bit-depth, dithering, mip-mapping options, etc. The advantage of this format is that all the image is still there since it’s exported at full 32-bits (although soon we’ll have to worry about larger color channels!), and images can be examined with any program that displays tiff files. Again, mip-mapping, changing bit depths, and dithering are not cheap operations we want to do at load time, but we’ll postpone all that until later.

It can be very tempting to modify an intermediate asset directly for many reasons: a “quick” change right before a milestone, the change we’re trying to make is not exposed through the plug-in of the tool, etc. We did exactly that in MechAssault 1 and ended up regretting it. We were too pressed for time to provide good plug-ins for our custom material types, so artists would modify material parameters on the intermediate assets directly. Those parameters would get overwritten next time somebody else re-exported the model and would have to be re-entered by hand. If you absolutely must modify intermediate assets, then consider providing full re-importing capabilities back into your source assets; however, this is usually not a trivial task. For MechAssault 2 we’re sticking to only making changes in the source and providing much better plug-in support, and things are running much more smoothly.

Even though this intermediate format is very flexible, chances are there will come a time during a project when it will be necessary to break backwards compatibility. Don’t fight it; get ready for it instead. Make sure you have versioning as part of the format, and that you can easily run a script through all exported intermediate assets and convert them to the new format. Since you hopefully chose an easily parsed format such as XML, the conversion process should be almost painless.

Final Assets

The final assets have been highly optimized so they can be loaded and used as efficiently as possible in their target platform. The specific file format doesn’t have to be particularly robust or withstand many format changes since the final assets will be regenerated many times a day. The number one goal here is speed. Ideally, this resource should be a direct memory image of what it’ll be in when it’s loaded in the game, so that it can be loaded straight without any parsing. The standard warnings about optimizations also apply here: don’t blindly optimize everything, and spend your time in those assets where you’ll get the most benefit.

If you’re doing multiplatform development, you’ll probably want to have one set of final assets for every platform. That way Xbox textures can be in their own format, and PS2 textures can be packed and formatted differently. At Day 1 Studios, even though we were only developing for the Xbox, we have two sets of resources: one for the Xbox, used in the game, and one for the PC, used in our PC-based tools.

The type of operations done at this stage range from quick ones such as simple format changes, to somewhat expensive ones such as mip-map generation, dithering, or compression, to really time-consuming ones such as lightmap generation and mesh optimizations. At this point we don’t care too much about how long it takes to perform an operation, we just care about the final result and how optimized the final asset is. As a result of this step some assets could be split into different assets (for example, our model XML file is split into several smaller files containing vertex and index data), and sometimes multiple assets get combined into one larger asset (packing a set of textures into one larger texture).

At Day 1 Studios, this step is performed by a command-line conversion tool, which takes a set of intermediate assets and produces the final assets. The actual conversion happens through a set of conversion plug-ins implemented as DLLs, each of which takes care of converting a particular type of resource (identified by filename extension or a header on the file itself). Any resources not handled by the conversion plug-ins are just copied straight through without any modifications.

Be warned that doing a full resource conversion on all the assets of the game can be a very time-consuming operation. There can easily be hundreds of thousands of files, and each of them needs to be loaded, parsed, converted, and saved in the new format. This process can take up to several hours even with a fast CPU and a very fast hard drive. Minimizing this time will help with the overall turnaround time, so you might want to profile the conversion program to find any obvious bottlenecks. Other solutions include doing incremental conversions (only convert files that have changed since the last build), and doing distributed builds (have a farm of machines where each one takes care of converting a subset of the resources).

During this step we should also generate errors and warning messages as necessary. Sometimes an asset won’t meet the requirements to be converted successfully (for example, a texture might be marked as needing mip-maps but it has dimensions that are not a power of two). It’s much better to prevent invalid assets from making it this far down the pipeline by preventing them from being generated in the first place, but we should still be ready for them here. By keeping a log of all the failed conversions and all the warning messages, the art and design leads can quickly identify what the problems are and correct them for the next build.

If you have specific dependencies between resources that need to be enforced (for example, packing all the textures for a particular model together and the textures need to be converted before they’re packed), you might want to use an existing dependency-management tool such as make or jam.

Catalog Files

The final step of the pipeline consists in packing all the loose final asset files into larger catalog files. A catalog file is nothing more than a large file containing other files inside, possibly along with their names and hierarchy information.

The advantage of using catalog files are pretty obvious: reduced number of open/close file operations, enforced physical proximity between files, easier and more efficient distribution of assets, faster directory parsing, etc. Surprisingly, not all modern games provide catalog files with their assets (you can usually tell who the guilty parties are by the outrageously long load or install times!).

Using a standard catalog file format (such as .zip, .cab, or even .wad) is very convenient because there are already-made tools to create, load, and view them. On the other hand, you might not have as much control over them as you want (for example, to enforce a specific file alignment or ordering for optimal seeking performance on a DVD).

In this step, the final assets for each platform are packaged into separate files. You might want to have separate catalog files for each level, or have sound and music on a separate catalog file from the rest of the assets. Those strategies will depend on how you need to load resources in your game. Once these catalog files are created, they can be copied onto the network and everybody can copy them locally to their machines or work with them directly from the network if there’s enough bandwidth. The game and the tools should be able to read these files directly and load any of the resources inside transparently.

The Fast Path

Unfortunately, the process we’ve described so far isn’t exactly speedy. To make a change and see it in the game, we need to go through the following steps: modify a source asset, export the intermediate one, check it in version control, kick off a resource conversion, and wait for a few hours until new catalog files are ready. That doesn’t meet our earlier requirement of a fast turnaround time.

The solution is to provide a fast path into the tools and the game that bypasses all the time-consuming steps. In our case, we made it so both the tools and the game could load intermediate assets as well as the final assets (see Figure 1 again). All an artist has to do to see how their updated texture looks in the game is to export the intermediate asset, copy it on the directory where the game or tool expects to find it, and run the game. You can even provide a macro or a button that does all those steps at once, including launching the game to the correct level. The artists just make a change, push a button, and see their new assets in the game. It can’t get much easier than that.

How exactly is the local file loaded instead of the one residing in the catalog? That’s part of the magic of the file manager. As far as the tools and the game are concerned, they’re just opening a file like any other. However, our file manager gives local files priority over catalog files so they override any similar entries in a catalog file. Whenever the game attempts to open that file, the file manager redirects it to the local file. Otherwise it loads it from the catalog as usual.

Since we designed the intermediate format so it was easy to parse and modify, but not fast to load, isn’t that going to slow loading levels down to a crawl? It would if all the resources in the level were in the intermediate format. The idea is that only the assets that artists and designers are working with at the moment are going to be found locally in the intermediate format, so load times are only going to increase by a very small amount.

This approach also requires that the game and all the tools have code in them to load and parse assets in their intermediate formats. That is not a trivial amount of code, but chances are you’ve already written it to make it part of your conversion tool. However, you might want to strip this code out of the final shipped game, so separate it cleanly and surround it with conditional compilation statements so it’s easy to remove.

There is one important lesson we learned from using this fast load path: Make sure that your fast load path and your normal path (following the rest of the pipeline) both produce the same results; otherwise you’ll have some very disconcerted artists who are not sure why their assets look different after they check them in. In our case, we were using one library for texture conversion in the slow path and a different one in the fast path. The results were often similar, but sometimes different enough to raise a few questions. Whenever possible, use the same code in both paths.

Putting It All Together

Now that the whole pipeline is in place, we can finally start thinking about automating the process. It should be relatively straightforward to create a script to get the latest source or intermediate assets from source control, run the conversion process on all of them, and package them on the catalog files. Perl and Python are some good glue languages for that type of tasks. The most difficult aspect of the script is making it robust enough to deal with errors (network going down, version control server being down, etc), so take good care of that from the beginning. With such a script in place, we can run the resource build automatically once or twice a day, or on demand when new resources are needed.

The more we automate the content pipeline, the more important feedback becomes. People are not going to be watching every step of the pipeline, so we need to collect all the important information and deliver it to the people who care about it. In addition to gathering all errors and warnings, we might also want to collect other information, such as memory footprints, texture usage, or even some rough performance statistics. All that is best done as a final step to the resource build, running each of the levels in the game with the latest resource and executables. As a side benefit, it also serves as a very rough smoke test of the build.

Robustness was one of the goals of the pipeline from the very beginning. Part of it involves making sure that the conversion and packaging tools work flawlessly and report any errors correctly. The other part is making sure the game and the tools are never left in an unusable state because of bad resources. A good philosophy to maintain is that bad data should never break the game or tools; an artist or designer should never be able to crash the game. It might sound a bit radical, but it’s worth aiming for that goal. Any engineering time spent towards this will be paid back many times over as soon as assets start being added to the game at full speed. When loading a level, take the time to report any loading or initialization errors, disable the entities that had problems, and move on. In addition to that, it’s helpful to put some sort of ugly debugging model (a big pink lollipop in our case) in place of any entity that failed initialization.

Further Work on the Pipeline

Turnaround time is very good already, but we’d like to make it even shorter. We’d like the game to detect that some assets have changed and load them on the fly. This can be particularly beneficial for games without discrete levels where reaching specific locations is a time-consuming task.

A full resource build for MechAssault 2 can take up to an hour and a half. We’d like to further investigate the possibility of doing distributed builds. There are open-source, general frameworks for doing distributed operations that could be easily added to the process. We might also want to look into integration with the build systems such as Ant for added robustness.

Games are very different from each other and teams are organized differently, so content pipelines will vary significantly from project to project. It is important to identify the assets for a given game, what kind of operations will be done to them, who will be working on them, and at what stage of the development they will occur. Use whatever pipeline organization works best for your particular needs and automate as much of it as possible. The artists and designers in your team will thank you for it, and you’ll end up with a much better game in the end.