Why are you making games? No, I don’t mean “why are you making games?”. Also, I don’t mean “why are you making games?”. And I certainly don’t mean “why (on earth) are you making games?”. I mean the question in the purest, most abstract sense. Just “why are you making games?”.

This was a key question for me last year, I spent a lot of time thinking about it, and I thought other people might benefit from asking themselves the same question. To see where I’m coming from, let’s do a quick flash back.

It’s late 2011. Miguel and I finished working on Casey’s Contraptions and my daughter was born. I took a couple months completely off from work (new dads will understand why), and then, right at the turn of the new year, I decided to start working again. The plan was to prototype a few of the juiciest ideas, pick one that really stood out, and make a new game in a few months. How hard could it be, right?

Right?

It turns out it was a lot harder than I ever imagined. I was confident in my list of hundreds of game ideas that I had been adding to over the years. I picked one idea, made a quick prototype in a day or two, and decided that I wasn’t as excited about that idea as I thought. So I picked another one, and another prototype that didn’t go anywhere. Then another, then another, and then another. This went on for months.

By the time I realized that my prototype icons weren’t fitting in a single page on my development iPad, I started worrying that something was wrong. Prototyping is great, it allows you to find the truly great ideas and all of that, but I wasn’t any closer to a game idea I wanted to make than when I started.

At this point, I even started prototyping game ideas I knew I was not going to make, just to remove any pressure on me, as well as to get it out of my system how much I hated those game genres. It was an interesting effort, but, as you can imagine, it didn’t lead to any shipped games.

I did, however, help me start figuring out what was going on. I realized that the prototypes I was creating were dissatisfying because my intentions were unclear. I wanted too many conflicting things out of this next game, and that was pulling the game in all kinds of opposite directions.

I wanted to make a unique a different game, yet at the same time I wanted it to reach a huge audience. I wanted to ride the wave of financially successful iOS games, but I didn’t want to sell my soul with freemium-based games, and instead, I was going to make a “good” freemium game. I wanted to make something innovative, but I wanted to do it in just 6-9 months. I wanted it all, and I wanted it yesterday. Bad combination.

That’s when I sat down and asked myself point blank “why am I making games?”. Or at least the more concrete version “why am I making my next game?”. That’s a surprisingly hard question to answer really honestly. I had to peel away a bunch of layers until I found the answers to my question.

My specific answers don’t matter because there isn’t a right and wrong answer. Any answer is good as long as it’s honest, from the bottom of your heart. There are as many valid answers as game developers out there. Some people make games because they want to be famous, others because they want to make money, others because it’s the only thing they know how to do, others because they want to win awards, others because they want to reach as many people as possible, others because they want to tell stories, etc, etc.

It’s actually amazing it took me this long to ask and confront this question. When you’re working on a game company things are different, and you don’t need to do that level of introspection. But once you go indie, it becomes really important. Even though I’ve now been indie for 6 years, I’ve been going in automatic pilot all this time, kind of skirting around this issue and winging it. I see a lot of indie developers out there doing the same thing, with greater or lesser success, but still conflicted internally about what they’re doing.

Once you have the answer to your question, you can use it to guide you in any big decisions related to game development, and even in life in general. Which projects to tackle, or even what features to add to your game, will often be easy to decide if you keep your goals in mind.

For me, within two weeks of answering the question, I had settled on not just one, but two different projects that I was super-excited about. Both projects are still moving along and I hope to start sharing information about them soon.

So I encourage anybody reading this to make some quiet time in the next few days, and pose yourself the question “why am I making games”. Once you find your answer, not only will it help you with future decisions, but it will make you more satisfied with them.

The main idea of the talk was the importance of “flexible pricing”: Letting players spend as much money as they want to get more enjoyment out of the game and customize their play experience. Flexible pricing can result in revenues much higher than the traditional fixed price approach (derived from manufactured goods). It’s also orthogonal to the concepts of freemium and social games, and we’re only scratching the surface in ways to effectively implement it in games.

Here’s the official conference abstract:

Did the biggest fans of your game spend more money on it than someone who played it just a few times? If not, you’re leaving a huge percentage of money on the table. This session will talk about how digital distribution has made fixed prices obsolete and how you can take advantage of flexible pricing through in-app purchases in your games. We’ll also talk about the consequences (good and bad) of making a game free to play. The session will present hard data from iOS platforms, but applies to all digital distribution platforms.

Answering questions preemptively: I definitely don’t think that allowing players to spend the amount of money they want is “evil” in any way. And someone during the comment came up with a great point: Isn’t it more “evil” to have players spend $60 on a game, just to find out 10 minutes afterwards that they don’t like it or it doesn’t run very well on their system/network?

I was going to record the audio, but unfortunately I forgot to turn on Audacity before the talk. Note to self: Start recording when I set up the laptop, even if it’s 10 minutes ahead of time.

One Price Does Not Fit All

View more presentations from Noel Llopis

[Slideshare mobile] [Slides in pdf format]

This was my third 360iDev Game Jam, and it gets better all the time. It’s great to see that it has become a 360iDev tradition, and that the number of people participating is going up every time. The last couple of times we had one invited guest to participate remotely (and preside over everybody else in the big video screen), but this time we opened it up so anybody, anywhere in the world could join us and participate in the updates and discussions through the web site (big thanks for Mike Berg for all the excellent work on the web site!).

What’s The Point

Some people don’t understand what the point of the game jam is. Other people see the value in it, but disagree with what other people see. The point of a game jam is the same as a jamming music session: To create something while surrounded by other developers and feed off each other’s energy and enthusiasm.

In addition to the jamming aspect of it, different people have different goals, and they’re all just as good and valuable:

• Trying a new game idea
• Learning a new API or technique
• Making a finished product
• Starting something new
• Being totally experimental
• Stretching their comfort zone

There were even people using the game jam as a means to make progress in their own game or app they had already started. It’s a bit far from the original intent, but why not? It’s the jamming part that is the most important.

I was glad to see that most people decided to work the theme (“changing the world”) in the game somehow. I definitely find that having some constraints helps me focus and be more creative at the same time.

One of the most attractive aspects of a game jam for me is that it’s a very focused, but very short effort. Yes, it sounds epic: “A full night of pizza, coffee, and coding…” but it’s only 8-10 hours. That means the cost of “failure” is minimal. It’s about a work day. That’s it. So that means it’s possible to try new, risky, experimental things, and, most importantly, be OK if they don’t work out. You don’t learn by succeeding at everything.

Swapping Roles

The last two game jams, I experimented with different kinds of game designs (heavy use of multi touch and limited visibility). This time around I’m in the middle of a new project (Casey’s Contraptions), and Miguel and I did about 5-6 prototypes earlier this year, so I wasn’t itching to do another experimental gameplay prototype.

So instead, Miguel and I paired up again, but with a twist: He would do all the programming and I would do all the art. How’s that for crazy? Actually, he’s in a lot better shape because he’s a good programmer in addition to being a great artist. Me, on the other hand, I can barely find my way around in Photoshop to copy and paste images from Google Images, so this was definitely going to be way out of my comfort zone.

As you can expect, we didn’t make as much progress as we had hoped. On the other hand, I never had more fun or learned more new things at a game jam before! It helped a lot that I wasn’t just flailing around with Photoshop, but that Miguel was there giving me pointers and showing me what the right way of doing things was. I went from not knowing that there was such a thing as a path tool, to becoming relatively proficient with it over the course of the night. It was like drinking a potion of +5 to Photoshop skills.

Apart from learning a lot, I also developed an even deeper appreciation and admiration of game artists. I knew it wasn’t easy stuff and that you needed a lot of talent. What I wasn’t quite fully appreciating is how technically involved art creation is! It’s very different from traditional painting and drawing, and it’s very highly technical. In a way, it’s almost like 3D modeling in how it requires mastery of a very complex tool and you need to work on very small parts for a long time.

Here’s a screenshot of the game showing all the assets I created during the jam:

Lessons Learned

Some random, unsorted, lessons learned from this jam:

• Come ready with an empty project you can start working on. The jam is not the time when you want to start stripping out old code. I learned that one in my first game jam, but didn’t come prepared with an iPad project (Hint: the iPhone -> iPad automatic conversion sucks–does anything automatic not suck?).
• Everything takes longer than you think. If you think you’ll just finish the game by morning, it’s probably too big. Choose something smaller.
• Learning stuff during the jam is great. Just adjust expectations about what you’ll create (we knew this going in, but still caught us by surprise).
• Take a moment to interact with the people around you. We’re all in a hurry to make something awesome, but take some time to talk to other developers. It’s well worth it, and makes the long night more bearable (and energizes you more).
• Pizza and coffee is a killer combination. I suspect I might never have to go to sleep if I keep the two in balance ;-b
• When wifi sucks, it’s hard to take the time to post updates or read other people’s updates.
• Hotel wifi always sucks.
• The jam is not a popularity contest. Sure, it’s great to show it off the next day, but make sure you create what you want for yourself and not based on what will demo best the next day.

If you haven’t done a game jam, you should. I strongly suggest collaborating with at least one other person, and doing it live with a bunch of other developers. The energy is incredible and it will be an experience you’ll learn a lot from and will remember for a long time.

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. This will be my last post for iDevBlogADay for a while (need to give those people in the massive waiting list a chance!), but I’ll definitely continue posting regularly.

Session description

The common-sense approach to make money on the App Store used to be to do anything to get on the top charts. In-app purchases changed all of that. Good in-app purchases can make your app profitable without being anywhere on the charts, and are the best hope for the independent developer. Come to this session to learn why IAPs can be so effective and how to leverage them effectively: what makes a good IAP, how to increase your user involvement, how to present IAPs in an attractive way, what things attract users, and what things turn them away. We’ll go through lots of detailed real-world data from Flower Garden and other games with strong IAPs.

Presentation slides: [Slideshare] [pdf]

I’m going to say this very clearly so it doesn’t get lost in the middle of a paragraph.

360iDev is the best conference you can go to if you’re doing any kind of iOS development.

There. I’ve said it. And no, they’re not paying me any to say that.

I’m clearly not the only one who feels that way either. Just earlier this week Mike Berg wrote a post about how awesome 360iDev is, and we didn’t even compare notes. Great minds think alike apparently.

Yes, Apple puts the big show for WWDC. It’s a unique experience: the keynote, the crowds, the unveiling of the latest technologies, the sessions, the labs… But in the end, it’s a big show from Apple to woo its developers. You’re getting the official message through very polished presentations. Which is fine, but it feels a bit… too polished. Too streamlined. Too overproduced.

Talk to developers who’ve been to WWDC multiple times, and you’ll quickly find out that the parts they like best are the labs (access to Apple engineers) and the networking (some with Apple, but mostly with other attendees). That’s why keeping track of the parties during WWDC is almost a full-time job!

For Developers, By Developers

360iDev on the other hand is a conference for developers by developers. You don’t get fed the official party line. Instead, you get to hear how some API really worked (or didn’t) in the trenches, how developers had to work around bugs, or, why not, how some technology was a dream to work with. Nothing like hearing it straight from the horse’s mouth.

Strong Game Development Track

There are usually three simultaneous tracks at 360iDev: Business, Sights and Sounds, and Development Tricks. As you can expect, sights and Sounds is usually entirely devoted to games, and there’s plenty of game-related info in the other tracks as well.

I’m going to be totally honest here: The quality of the sessions varies a lot from one to the other, and they can be somewhat hit or miss. When the presentations are awesome, they’re really awesome. And on the average, I’d say they’re very good. That’s the flip side of not having a super-rehearsed, super-polished presentations like WWDC.

Hacker Vibe

You walk into WWDC, and you get a very strong corporate feeling (trying to be developer friendly). The moment you walk into 360iDev, it has a palpable hacker vibe [1]. The people presenting might not have the most polished slides, but they can do some amazing things on the iPhone. There are even presentations on the internals of the iPhone and what’s going on under the hood, something you’ll never get from Apple!

Game Jam

As a perfect example of the hacker mentality, the Game Jam has become a regular feature at 360iDev. On the last night, developers get together in a big rooms, and either flying solo or grouping into teams, they create a game prototype in a few hours. The next day at lunch, we have a big gathering and get to demo the games created the previous night to everybody. What a perfect (and exhausting!) last day to the conference!

It’s Nimble And Agile

This might not seem like a big deal to some, but it’s very important: 360iDev happens twice a year. Technology conferences that happened once a year might have been fine 10-15 years ago, but as the pace of technological advance continues to accelerate, once a year doesn’t cut it anymore. Especially if you have to submit talk proposals 6-8 months in advance, they’re old news by the time the conference rolls around.

360iDev is much more agile than that. It happens twice a year, and you only need to submit a general overview a few months in advance. Given the content of a lot of the talks, they probably come together just weeks (if not days) before the conference itself. That’s part of the reason for the uneven quality of the talks, but it’s a price worth paying.

Networking

360iDev is a small conference. I don’t know the official numbers, but I think there are usually around 200-300 attendees. You’ll be seeing the same faces all three days, especially the ones that share your same interests and end up going to the same sessions as you do. Even if you’re a total introvert, you’ll end up meeting a bunch of new, very interesting people, and creating lots of new possibilities for your future.

Even better, the speakers are part of that small number of attendees, and they get to hang out with everybody else. There aren’t special VIP parties, or secret off-site invitation-only parties (if they are, they’re so secret I missed them). Everybody hangs out during the sessions, at lunch, and the evening festivities. So if there’s someone in the speaker list you particularly want to meet, this is your chance.

It’s not just other developers either. The iPhone media often comes to the conference as well, so you might get a chance to talk to people from TouchArcade or TUAW.

360iDev three full days of sessions, one day of tutorials, one night of game jam, three evenings or parties, and one conference full of awesome. And that for a fraction of price of the big conferences. How can you go wrong? [2]

[1] I mean hacker in the good sense of the word, not in the “cracker”, malicious one!

[2] If this doesn’t convince Gavin and Craig to come to 360iDev, I don’t know what will. Go buy the awesome Linkoidz so they’ll be forced to attend :-)

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.

This year will GDC will host the first ever iPhone Summit on Tuesday and Wednesday. It’s great to see the iPhone getting that much recognition as a gaming platform. Definitely way more than last year’s presence at the conference. Both days are going to be packed with awesome sessions, and I will be giving a presentation on mixing OpenGL and UIKit on Tuesday at 11:15am. I’ll definitely be around throughout all the summit (except when I sneak out for a few minutes over to the Indie Summit which unfortunately happens at the same time).

The rest of the conference looks amazing as usual. There are always way more talks that I want to see than I can actually attend. In particular, I’m really looking forward to a lot of the design talks because they’re very inspiring and directly applicable to any kind of game development. Also, rumor has it I might be making a quick guest appearance in a certain session on Saturday.

Finally, if you’re an iPhone developer, make sure to come to the IDU party on Wednesday evening, and meet us for drinks on Thursday evening after the IGF ceremony.

I’ll be running around with a busy schedule, but you can always follow my Twitter updates to know where I’m at every moment. I look forward to seeing everybody again this year!

The idea was to get together Tuesday evening, starting at around 7PM, and to code all night and have an iPhone game (or at least a prototype) done by morning. About 25 showed up, working on about a dozen projects. Participants were welcome to group into teams or work solo. There were no restrictions as far as themes or technology. The only rules were that you had to finish something by morning (no leaving something that was 5% of a game) and you had to start the game from scratch (no finishing a game you had started a while ago).

The reason behind doing a game jam is to be able to quickly create game prototypes and decide if they’re worth pursuing further or not. Much better to spend a few hours one night and then throwing it away, than spending several months with multiple people involved. Also, the heavy time constraints often help participants by focusing them in the ultimate goal and forcing them to adopt creative solutions. Being all together in one large room added a lot of energy and made it possible to work really focused for many hours without a huge amount of caffeine (although the large amounts of coffee provided by Jay really helped!). In the end, we even ended up getting a late-night fiddle serenade by Phil Hassey. Try that at home by yourself! Owen Goss liked the idea so much, he decided to jam with use remotely through video conferencing!

One specific thing that I wanted to avoid with the game jam was the idea of giving any sort of prices at the end. I really wanted to keep the jam as an environment where people would be free to experiment and fail. If people were thinking of potential prices at the end, they would be a lot less willing to go out on a limb and try different things.

My goal going into the jam was to experiment with game mechanics that relied heavily on multi touch. I felt that very few games made good use of multi touch (aside from pinching) and that it had the potential to create something very different from the single-touch based game that we’re used to from mice for the last 20 years. The flip side of it is that a multi-touch game was much riskier and unknown. Could something that multiple simultaneous touches be fun, or would it be frustrating? Would your fingers get in the way and clutter the screen, or would it be a new experience? In the back of my mind, I was definitely drawing inspiration from the fantastic game Bug Bugs, by Igloo Games.

I did all the coding myself, but I teamed up with Evan McMahon from Veiled Games and he did all the awesome art in the prototype.

Owen Goss joining the iPhone Game Jam remotely

What Went Right

Started with an idea

I went into the jam with the idea of experimenting with multi-touch game mechanics. I also had in mind a setting that would be a good backdrop to those mechanics: You control a large, round spaceship in interstellar travel. As you travel between the stars, you need to collect different resources to power your ship and provide all necessary materials. Each type of resource goes in a different bay (which are located along the outer rim), so with two fingers you rotate the ship to move the collecting bay forward, and with the other hand you drag the different resources you encounter. Some resources aren’t useful, so you need to flick them away so they don’t hit the ship. Finally, other resources need to be combined before they can be processed, so you first need to bring them together, and then drag them to the ship.

You only have 10-12 hours to build a game, so if I didn’t have an idea going into the jam, I would have wasted precious time trying to figure out what to do while I could have been working on the game.

At the same time, I didn’t have the idea fully fleshed out and set in stone. I definitely let things change based on what I saw as I was implementing it. So it’s good to strike a flexible medium between having an idea and letting it evolve during the jam.

Used familiar tools

Just the day before, David Whatley raved about how great Cocos2d was for prototyping, and that same day, my friend Serban gave a presentation on using Cocos2d. I’m on record saying that I can’t stand to work with Cocos2d because it imposes a particular (totally backwards) architecture on you, and I can’t ever see myself shipping a game with it, but I can see the value in using it for prototyping.

The point of this jam (for me anyway) wasn’t to learn some new tech, but to experiment with gameplay. So I really considered it, but in the end, I decided to work with something I was familiar with, and used my (very small) codebase using straight OpenGL. I’m very glad that I did because I never felt that working at that level got in the way (other than one frustrating moment related to the first point in “what went wrong”),

Didn’t worry about performance

This is a hard one for me! The last two talks I’ve given are all about performance on the iPhone, but even thinking about performance here would have been a waste of time and resources. Sure, the game had to be fast enough to run on the actual device because playing a game on the phone is a very different experience than playing it on the simulator. Besides, a game like this requiring lots of multi-touch was impossible to play on the simulator.

But at the same time, I didn’t have to submit it to the App Store come morning, so I decided that as long as it ran on my 3GS, I didn’t care about anything else. That meant it could be very suboptimal and be a total memory hog. I didn’t care! I wasn’t even releasing resources!

The result, it played perfectly fine on my phone, and I spent zero time trying to optimize it or taking a longer route because of performance or memory reasons. On the other hand, just the tiny, single level I created is about 12MB, so it’s clearly very bloated.

Teaming up

As I mentioned earlier, I teamed up with Evan McMahon to create the art for the game. He wasn’t at the conference, so we organized everything through IM and Dropbox. The experience was great because not only did he create some awesome-looking art, but he really motivated me along the way. We played off each other’s energy and came up with new ideas because of the collaboration.

Going solo would have been OK because I was surrounded by a room full of like-minded developers hacking away at their games, so that would have helped keep up the energy levels, but it wouldn’t have had nearly as much of an effect as working directly with someone else. My only regret is that Evan wasn’t there with me.

What about the art itself? Was it a waste of time to add it to the game? After all, it didn’t help me make a better decision about the multi-touch game mechanics, did it? It wasn’t a waste of time at all for me. First of all, it took just as long adding some nice art than it took to add stand-in art because there wasn’t anything special about it. But most importantly, there is a feedback loop between the look of the game and the gameplay and feel of the game. So seeing the art in the game definitely changed how I felt about it and the decisions I made about it during the night.

What Went Wrong

Didn’t have a project ready

This just goes to show my lack of experience with super-rapid prototyping. I didn’t have a project ready to get started with the prototyping. I originally created a blank OpenGL project from XCode, and quickly realized I would be missing all the set up for sound, the view controller structure, and even some of the default touch-handling. So I grabbed one of my current projects in development, stripped it of everything game specific, and turned it into the project for the game jam. Not a big deal, except that it took me a good 20-30 minutes to go through this, and in the process I deleted a couple crucial lines that gave me lots of problems with OpenGL for the next 30 minutes. Doh!

Next time: Come prepared with a blank project, ready to go.

Running up against technical stuff

I went with OpenGL instead of Cocos2d on purpose to avoid having to deal with learning technical stuff sleep deprived in the middle of the jam. Unfortunately, it turns out my understanding of the multi touch event API wasn’t up to snuff to handle 5 simultaneous touches, starting, moving, and ending, each of them affecting a different object (or different parts of the same object). During the jam I wasn’t writing unit tests either, so that made for a pretty confusing time until I stepped back for a second, hit the documentation and Apple’s touch sample program, and tried to gain a better understanding of what was going on. Hint: Apparently looking at the touches in the UIEvent* parameter passed to touchesBegan is not a good idea, and you need to look at the ones passed in NSSet*.

Not enough time!

I certainly didn’t get as far in the prototype as I had hoped I would. There’s only one type of resource (ice chunks) and the control mechanics need to be improved quite a bit.

Is it possible that if I had used Cocos2d I would have gotten more done of the prototype? Yes, it’s possible, although I won’t know until I try it. Is it possible that half way through the prototype I would have encountered something that Cocos2d couldn’t do and I was left stranded? Yes, that’s also possible. And that’s a big reason why I don’t like framework-y type of APIs, and instead I would rather have a toolkit type of API so I can call into it and do the work myself whenever I want instead.

In any case, this is the flip side of “using familiar tools”. I will definitely experiment with Cocos2d in the future and consider it for another game jam if I’m familiar enough with it and I feel it speeds up development.

Everybody still going strong late at night (but not quite so perky anymore)

Conclusions

I think Space in Stereo has potential, but right now it’s too early to tell if it’s any good. The basic mechanic is there, but it’s not fun by any stretch of the imagination. I already learned a bunch about it though, including that some things weren’t nearly as much fun as I was hoping would be. For example, rotating the space station with two fingers… well, sucks. The better control scheme is to move the space station by dragging around the middle, and rotating it by dragging a finger around the edge in a circular motion. That was also what everybody was instinctively doing when they were trying out the game.

The game is just at the point that spending another 4-5 hours on it would answer a lot of questions about how fun it can be. I’m definitely planning on spending that time and then making a decision. If I decide not to go ahead with it, it’s not a big deal. Great games come out of making a lot of different prototypes and throwing away all the so-so ones along the way.

As far as the Game Jam itself, it can only be described in one word: Awesome. It was everything I was hoping for and more. I can’t stress enough how much it helped to have everybody else around you and being so focused for that period of time. I had heard much about game jams, but I had never actually participated in one. After this one I’m sold. I can’t wait until the next one!

Gameplay footage of Space in Stereo

Session description:

The iPhone has a very powerful engine under that shiny hood when it comes to floating-point computations. This is something that surprises a lot of programmers because by default, things can slow down a lot whenever any floating point numbers are involved. This session will explain the secrets to unlocking maximum performance for floating point calculations, from the mysteries of Thumb mode, to harnessing the full power of the forgotten vector floating point unit. Stay away from this session if he thought of reading or even (gasp!) writing assembly code scares you.

• Presentation slides (pdf format)
• Sample project

Thanks for everyone who attended the session and for the great feedback so far. If you’re going to be in China next month, I’ll be giving a very similar talk at GDC China.

Session description:

This session will describe the iPhone performance optimization lessons learned through many hours of tuning. We’ll start with an overview of the performance analysis tools available on the iPhone SDK to help you narrow down your performance bottlenecks. Then we’ll cover the best way to set up your render loops, rendering best practices, how to deal with the limited memory, or even how to drop down to assembly to use the forgotten vector floating point unit.

Presentation slides (pdf format)

Obviously I’m biased when I say the class is going to be awesome (which it is), but I can also say with total honesty that 360iDev is an incredible conference. It’s very different from WWDC, but that’s what makes it so great: It has top-quality content and speakers, but it’s small and intimate, so you get to meet and hang out with all the other speakers and participants. It was at the first 360iDev conference back in March that I met Keith and Owen (among many other cool developers) in person for the first time and that’s how App Treasures was born.

So if you’re on the fence, I hope you give it a try. See you in Denver!

The class is aimed at iPhone developers without previous OpenGL experience. It’s going to be very hands-on, and you’ll create both 2D and 3D applications during the weekend. You’ll learn all the basics: cameras, transforms, and how to draw meshes, but we’ll also cover some more advanced topics such as lighting, multitexturing, point sprites, and even render targets. Most importantly, you’ll walk away with a solid understanding of the basis, which will allow you to continue learning OpenGL and advanced computer graphics on your own from the docs, samples, or even browsing the API directly.

The main requirement for the class is that you’re familiar with the iPhone development environment and that you have basic knowledge of the C language. Beyond that, to the the most out of the course, you should be familiar with the basics of linear algebra (vector, matrices, and dot products). Anything else, we’ll cover it all during the class.

Registration is now open, and you can get some great discounts by registering early and attending the 360iDev conference. For more details, check the official announcement page.

Hope to see some of you there!

The presentation went very well. The room was *completely* packed, with every seat taken and people standing along the walls. In retrospect I shouldn’t be surprised because it was the only iPhone presentation in the main GDC conference. Clearly there is a huge amount of interest in the platform. I’m already pushing to have a lot more iPhone content for next year, so you can all look forward to that.

Because it was the only iPhone presentation in the main GDC, I had to keep it very high-level and focused on the question of “what can you expect if you switch to develop games on the iPhone”? Not like I can really answer that, but at least I can share what my experience was. Hopefully next year I can really dive into some juicy tech topics.

In the meanwhile, if you’re dying for some more technical content, go check out my latest column in Game Developer Magazine dealing with multi-touch input devices with the lessons I learned from Flower Garden.

Update: Ari Braginsky recorded the audio of the session (part 1 and part 2), so if you want, you can follow along with the slides. Thanks Ari! I believe that the synced audio and slides will be available through the GDC web site for registered attendees too.

Session description: This session will cover the experiences of a professional game developer, used to 200+ person teams, multi-million dollar budgets, and 3+ year schedules, who left all that behind to become a one-person indie company developing exclusively for the iPhone. It will explain how things are different and how some things are very much the same, and will show specific examples of graphics technology, development environment, and asset pipeline. I will be using my current iPhone project, Flower Garden, as an example. The audience will learn what the transition is like and what to expect going indie making games for the iPhone.

BecomingIndie.key.zip

I’ll be sharing my experiences transitioning from traditional AAA console game development, with teams of 100+ people, multi-million budgets, and several years of development, to indie iPhone development. There are a surprising amount of things that carry over from “big game development”, and quite a few that are totally different. I’ll go into what’s involved making games for the iPhone, and what game developers can expect when making the transition.

Apart from my talk, I’m particularly excited about this year’s GDC. It seems that the amount of content on indie game development and iPhone game development has shot through the roof. On Monday and Tuesday we’re treated to not just one, but two great summits: The Independent Games Summit and GDC Mobile! Last year, the Independent Games Summit was the best part of the show. Meeting all the other indie game developers out there and hearing their experiences was great. This year I’m hoping for more of the same plus all the iPhone-specific content.

Of course, the main conference is packed with great content too, but I haven’t had time to go through all of it and pick the sessions I want to attend yet. Too busy wrapping up my current project.

So if you see me around the show, stop by and say hi. I’m always glad to meet other fellow developers, and it’s always nice to put a face with a name for those of you that I know know through Twitter or online blogs.

With all that going on, I realized I never got around to writing my impressions about GDC. It really was a great conference with some very good highlights. My travel is far from over, and I’m heading out to the airport to catch my plane to London in a couple of hours, but until then, here is my quick take on this year’s GDC.

This year I decided to come for the tutorials happening two days before the main conference. The first day I bounced between “Advanced Visual Effects with OpenGL” and “Software Engineering Issues in Multiplayer Games.”

The OpenGL tutorial was exactly what you would expect: lots of material from previous years and a few good bits of information. The first thing I was happy to learn is that Microsoft changed their decision on how OpenGL will be implemented in Vista. It will no longer be a layer on top of DirectX; instead it will be a first-class citizen in its own right. Now, I’m not an OpenGL fan. Up until recently I never had to work much with it, and now that I have, I admit that I like the Direct3D API much better (I’m just not a fan of implicit global states). But I’m very glad to see that OpenGL is going to be treated correctly in Vista and given the opportunity to compete with Direct3D.

I was also pleasantly surprised by the tools NVidia is releasing for OpenGL development. NVPerfKit is a bit like Pix for DirectX; combined with gDebugger, it starts making OpenGL a lot more attractive. They’re supposed to release version 2.0 soon, but I didn’t find it on their web site. It’s really interesting how much NVidia is pushing OpenGL lately. At one point it felt that it was over for OpenGL, but it really has been making a comeback in the last couple of years. Now if they can only improve Cg…

The tutorial “Software Engineering Issues in Multiplayer Games” managed to surprise me, and I wish I had spent longer there than I did. It really was focused on the software engineering aspects, rather than on the multiplayer part of it. Lots of good information and war stories of large-scale game development.

Tuesday I spent it exclusively in the Direct3D tutorial. The biggest new thing was DirectX 10, with several talks focused on that. Apart from the new cool tech features (such as the stream out feature or the geometry shaders), DirectX 10 is quite a departure from earlier versions of the API. A couple of things make me scratch my head in puzzlement. DirectX 10 supposedly won’t have any caps to query anymore. Hardware is either DirectX 10 compliant or it isn’t. That’s great news for developers. However, I also learned that DirectX 10 is going to be tied to the Vista operating system, and new versions of DirectX will only be released as part of new versions of Windows. Unless I’m missing something, that means that hardware won’t have an opportunity to change and grow while running on Vista. That would be horrible for hardware manufacturers, but at least they have OpenGL to show their new features. Or maybe it means that Microsoft is planning on doing a yearly operating system release. It will be interesting to see how it plays out.

The best session on Tuesday was clearly Natalya Tatarchuk’s talk on the Toy Shop demo. She spent a full hour dissecting the demo, covering every rendering trick and effect they used. Considering how impressive and packed the demo is, it was clear that she could have spent a full day talking about it. Some effects are awesome, like their smeared rain reflections on the road, but it was funny to see how they clearly spent quite a bit of time doing things that are completely lost, like diffraction on the light that goes through the droplets on the store window. In any case, if you haven’t seen the demo, download it right now.

Wednesday was the start of the main GDC sessions. To kick things off, Sean and I gave our talk on test-driven development. I was really surprised at how packed the room was and how well received it was, judging by all the questions and positive comments. It’s great to see that other people are also very interested in TDD and are thinking about applying to it game development.

The next-generation animation panel was pretty interesting as an overview of what could be coming down the pipe for animation. I was already familiar with most of the content except for Ken Perlin’s new foot-placement work, but it was a great overview anyway. I’ve been quite excited about data-driven animation for a couple of years, and Lucas Kovar’s work is very promising. I think the only thing holding that technique back from being applied to games is the memory requirements, but I would love to spend some time trying to make it practical. Victor Zordan’s work is also very promising, combining dynamics with data from motion capture, which would be great for games (using ragdolls to predict and blend into falling animations for example).

Thursday was definitely the big day (for sessions, although that’s always the biggest day for parties too). The day started with the excellent session on “Advanced Prototyping” by Chris Hecker and Chaim Gingold. I really can’t say enough good things about it: it was packed with interesting, non-obvious information, it was very well presented and full of energy (it’s Chris we’re talking about, so of course it is!), and extremely motivational. They did a top-notch job preparing for the presentation and it showed. The pair had a very interesting presentation style that felt almost like a conversation between them two, and it worked very well. It was hands-down the best session of GDC for me. The talk covered things like why you want to prototype, what constitutes a good prototype, how you go about prototyping things, what to prototype and what to leave out, how to put the results together, etc, etc.

I don’t really understand why it was classified under the game design track. It really was more of a programming, production, or just all-around session. Even so, apparently the session was full and they had to turn people away. I really hope that they recorded it on video and they make it available online.

At one point they described what they considered to be a good codebase for prototyping. The funny thing is, I completely agree with every point they brought up, but for me those are characteristics I want in any codebase, not just one for prototyping. They are all things I value very much: ability to change, flexible, code vs. content, use of scripting, etc. In particular, the comment of frameworks vs. toolsets really hit the mark. That’s something I’ve been pitching for a while, but I really consider frameworks to be fundamentally broken for the type of development I want to do. Instead, I want a set of tools (functions, classes, whatever) that I can put together in any way I want instead of being constrained to one predefined structure (even if it has hundreds of callbacks, like MFC).

I think I was the only person in the packed Civic Auditorium left cold by the Nintendo keynote. Yes, it’s great to have Satoru Iwata give a GDC keynote, but I really didn’t connect with his speaking style or his message. I found it content-free and not very engaging (it didn’t help any that I was stuck in a corner of the top balcony—apparently there was a screen in the middle of the stage that I was not able to see that explained a lot of his strange comments).

On the other hand, Will Wright’s keynote was just the bomb. Somehow every year he manages to deliver amazing talk after amazing talk. I knew I really wanted to hear his session, so I chose to stay in the auditorium instead of going out again to get a free DS game and have to wait through that whole line. Good choice! I was able to get the best seat in the house this time around.

Will’s keynote cannot really be described in one paragraph. People have asked me what it was about, and I’m left without words. The point is not what it was about, it was the whole experience! It’s like being 12 years old again and going to a summer blockbuster that hits you from the beginning and doesn’t let you go for the next two hours. I left the auditorium dazzled and super-motivated. Isn’t that enough?

On the surface, the talk was about how he goes about researching new projects, interleaved with what he learned about astrobiology for the development of Spore. You can try getting more of an idea what it was about here and here (and a short video here). That’s another talk I hope GDC puts online very soon.

I have to admit, that after Will’s keynote, the rest of GDC was fairly anticlimactic. Maybe next time they should leave it for the last day to build up the grand finale. The only session that I attended that really stands out was Tim Moss’ God of War talk. I was expecting something a bit different, but it turned out to be a mini-postmortem of God of War. In particular, he talked about how they were organized, what their priorities were, and how they went about solving problems. I found it very interesting on many different levels, but the most interesting part was that they do things very differently to how I would go about doing them (or how we’re doing them at work right now). They also have a very different set of constraints: they have a very small number of very senior programmers, so they do anything they can to minimize using their time. They end up developing very general solutions, while right now I would advocate for the very specific solutions. It’s clear that their approach worked very well for them, so it’s great to see how different teams can tackle different problems in a variety of ways.

One pattern I noticed in this year’s GDC is that, for technical talks, the more general the talk, the more I enjoyed it. As soon as they got bogged down in details, they became much less effective. A lot of it has to do with the dry nature of the topics, and the fact that I can get all those details from a well-written paper. On the other hand, the more general talks (advanced prototyping, Will’s keynote, or the God of War one) were all very motivational and inspirational. In the end of the day, that’s what GDC is about for me: inspiration and socializing. And this year’s GDC was a huge success by that measure.

Unfortunately, whereas for the last couple of years real-time applications, and games in particular, had a relatively strong presence in SIGGRAPH (at least compared to past conferences), this year they were nothing more than a blip on the radar. I really hope that SIGGRAPH can correct that and continue the trend they had been setting for the last couple of years and continue including some real-time and game content.

Even so, SIGGRAPH is a great conference to attend. Unlike GDC, you can’t expect to apply what you learned in every session directly to your game. Most of the time, we’re years away from even starting to consider most of the solutions presented. The true value of SIGGRAPH comes in the form of giving us a different perspective on graphics, explaining a different set of problems, and using a different set of tools to solve them. So what you’re likely to walk away with are new ideas, different thoughts, and lots of excitement.

SIGGRAPH has a variety of session types: papers, sketches, panels, and courses. Papers are the more traditional sessions, in which a group of three or four papers are presented by their authors along with some videos of their results. The paper sessions range from outstanding to almost useless (usually when somebody simply repeats the formulas in the paper without offering a different perspective). Sketches are very interesting because they are early looks at some of the work in computer graphics. They often feel much more natural and fresh than the paper sessions.

This year I had the pleasure to attend what I considered to be the best paper presentation I’ve ever seen: “Wavelet Noise” by Rob Cook and Tony DeRose. The paper was an attempt to improve on Ken Perlin’s classic noise function. From the very start, they showed why it needed improving, and proposed a new function. It was all done in a very clear, intuitive way, showing very clear plots of the Fourier analysis of the different noise functions and why one was more desirable than the other. The best part of the presentation was when Rob Cook explained how, with only two weeks to go before the paper submission, they discovered a major flaw in their function, and how they desperately looked for solutions and finally found a good fix in the nick of time. The presentation had it all: a solid theoretical foundation, a good speaker, excellent visuals, and a touch of drama.

As an aside, it is interesting to see how different some paper presentations are from others, and what a huge difference the speaker makes. It seems that the more experienced the speakers are, the less they rely on formulas and equations, and instead they can just say what things are about in a more natural way, whereas most students tend to rely heavily on the math to carry their message. Coincidentally, I was reading Surely You’re Joking, Mr. Feynman! on the train in my way back from SIGGRAPH. In one of the chapters Feynman reflects on his early experiences giving talks at conferences and reaches a similar conclusion.

A theme that was ever present in this SIGGRAPH was that of natural phenomena: fluid dynamics, deformable models, plants, etc. I particularly enjoyed the papers on deformable models (“Animating Sand as a Fluid”, “Coupling Water and Smoke to Thin Deformable and Rigid Shells”), and dynamics of solids, and in particular the “Meshless Animation of Fracturing Solids”. The implementation of those papers were still in the range of 20-30 seconds per frame, so there’s a ways to go before we can implement them in a game, but they were very interesting nonetheless and might even result in some partial implementation relatively soon.

Interestingly, a lot of the implementations mentioned in this year’s SIGGRAPH were done in Java. I thought that was really interesting because I kept assuming that most of them were done in C++. For something that is as computationally expensive as what they’re working on, it seems like an odd choice of language. But on the other hand, if they value development time over performance, then it might be a good choice. It can also be a result of changes in the curriculum of universities over the last several years shifting towards Java.

The other set of extremely interesting presentations was on character animation. As in the past few years, data-driven character animation was well represented, and it seems like a great way of going forward in the future. Physically driven animation was also present, but I don’t see it having much future on its own. It’s the perfect complement to data-driven animation, but by itself, I don’t see it creating good, stylized human motion any time soon. There is a group at UCLA working on combining physically based human motion with kinematics-based techniques that looked quite promising.

One of the few game-related sessions was the one on believable AI-driven characters, in which panelists (mostly from EA) discussed the future of characters. The good news is that all the questions raised in the panel are the questions we’ve been asking ourselves for a while, so the problem is real and other people are working on it. The bad news is that there were no real answers to the problem.

Another game-related session was titled “Jump! Shout! Dance! Sing!”, and dealt with alternative input devices for games. During the presentation, panelists showed some of the upcoming games that use new input devices (Guitar Hero, Karaoke Revolution Party, which combines karaoke with the dance pad, and a Sony music game with a synth/DJ input device). I’m a sucker for music games (like Amplitude or DDR), so I loved seeing what’s coming down the pipe.

Graphics hardware also had a big impact in SIGGRAPH, with lots of courses and presentations dealing with GPUs. Somehow, even though a lot of those talks were intended for real-time rendering, I found them a lot less interesting (it seems I can read plenty GPU tricks-du-jour in books or whitepapers).

A big draw for a lot of people for this year’s SIGGRAPH was undoubtedly supposed to be George Lucas’ keynote. The room was certainly packed (I can’t even estimate the number of people there–maybe 10,000?). I’m sorry for everybody who was there with high hopes. After some interesting and insightful keynotes by some big names in past years (like Bruce Sterling in 2004), I also had high hopes. However, as soon as it started (after a loooong award ceremony where everybody patted themselves in the back) it was clear that Lucas only agreed to show up and answer questions for a while, without having prepared any speech or insightful comments. The most interesting thing to come out of it is that Lucas wants to see games that we can talk to and they talk back. Given how ubiquitous headsets are in consoles these days, that might happen sooner rather than later.

The Electronic Theater had a lot of good stuff. It had fewer big blockbuster movie snippets than other years and more independent, really creative shorts. Some of them were an absolute blast. If you have a chance to see the Electronic Theater DVD, make sure you check it out.

The emerging technologies area is getting wackier and wackier every year. This year’s top contenders for the wackiest technologies were a straw-drinking simulator that gave you the feeling of drinking different drinks just by pushing air into your mouth, and a device that allowed people to be remote-controlled by altering their sense of balance. That last one looked somewhat disturbing so I didn’t end up trying it on myself (but it was really fun watching other people bobbing around the floor).

All in all, SIGGRAPH was an excellent experience again. SIGGRAPH is a window into a different world, and as game developers, we can only benefit by trying to look through that window and even participate and share some of our own experiences.

It seems that this year’s GDC came and went and somehow I never got around to writing a quick report. Part of it was due to decompressing after a very exhausting event; part of it was catching up with things at work and all the stuff going with the change to High Moon; and part of it was just due to other commitments (there, now you see what a terrible runner I am). But I figured it was better late than never, so here we go.

I first have to comment on the location. This year’s GDC was in San Francisco instead of San Jose like it has been for many years. I went in with an open mind thinking that San Francisco would be pretty cool but that it would have the drawback that I wouldn’t know my way around as well as in San Jose.

In the end, however, I felt that San Jose was a much better location. I didn’t particularly care for the area (Market and 4th through 6th Streets). Things felt very busy and spread out, and it didn’t have the sense of community you got in San Jose. As soon as you step out of the conference center you become just another person in the street, but in San Jose, just about everybody walking around in the evening was a game developer. Fortunately, we’re going back to San Jose next year. Yay! I missed not going to Bella Mia this year (and I didn’t even make it to The Stinking Rose as I had hoped to).

Clearly, the underlying theme of GDC 2005 was the console generation change. I started writing a few thoughts about it, but it’s such a big topic that it deserves a whole article on itself. I’ll put it up this weekend. For now suffice to say that it’s going to be a huge change. The PSX to PS2 console change was nothing compared to this. Fasten your seatbelt because it’s going to be one bumpy ride!

Interestingly, another subtle theme brought up in many talks, either directly or indirectly, was customizable gaming. Allowing players to play their own music, put their own pictures in the game, skin their interfaces, control how their characters evolve, choose the layout for their buildings, and create custom paint jobs for their cars. That’s nothing new, especially in the PC world. We’ve been doing that for years. Still, I think it’s finally hit the big time and that’s going to be a required feature going forward.

I have a friend who was playing City of Heroes last year. He thought the game was OK, but the part he had most fun with was actually playing around with the character creation setup. It really was amazing what you could do with your superhero characters. Maybe it was a bit too much to do before you even get attached to your character, but it certainly looked a lot more interesting than clearing another sewer of rats or beating yet another bad guy somewhere.

Personally, I never really cared much for game customization. Sure, it’s fun to see your character change in an RPG, but I really couldn’t care less how my car looked in Need for Speed, or whether I could choose the pants for my character in a third-person action game. I think this might be a generational thing though. I grew up with TV that you had to watch when things were on, and you didn’t even have that much choice of what was on. Now kids expect to watch what they want whenever they want to.

The cell phone ringtone business is huge. Something like a one-billion-dollar business. That’s just amazing when you consider how quickly it got there. So not only are people wanting to customize their gadgets, but they’re willing to pay for it. Tattoos and custom clothing are also huge and that’s one way people have of expressing themselves. Even though Allard’s keynote was a horrible waste of time, that’s the most interesting point he made (yes, I didn’t get a free TV, was it that noticeable? I would have still thought it was a terrible keynote, though).

I definitely don’t like the trend towards seeing games as services though. Call me old fashioned, but I like my game to be in a box (or hard drive; digital distribution is even better), and I like to know it’s going to be there when I want to go back to it. The idea of games requiring internet connections, auto-updating themselves, and blurring the distinction between single and multiplayer totally puts me off as a player (although I admit it sounds like lots of fun from a technical point of view). Case in point: Half Life 2 was at the top of my list of games to buy, but Steam simply killed it for me.

The highlight of the show this year was again Will Wright’s talk. I kept telling everybody to get there early, but it totally blew my mind when I saw a line coiling around the convention center a full twenty minutes before the start of the talk. I guess the organizers got caught by surprise also. Those who know me know I can’t stand to wait in line. But this one was well worth it. The talk was simply indescribable. Will has the most understated way of giving a talk: he doesn’t yell, gesticulate wildly, or resort to fancy multimedia or loud music with smoke machines on the stage. Yet somehow he manages to be extremely engaging and interesting from the very beginning. I said it before and I’ll say it again: “I’ll go to any talk Will gives, even if it’s about the most uninteresting subject imaginable. Somehow, he’ll make it interesting.”

And this year was no exception. He emphasized the importance of procedural content in this next generation, and to drive the point home, he showed a demo of his latest project, Spore. I thought it was extremely cool that he looked into who has experience with procedural generation of content, came across the mod scene in Europe, and recruited a team of demo-makers to prototype his game.

Will also emphasized the importance of customizable content and also of leveraging the content created by other users in your own game (in this case automatically, without you having to download anything). We’re going to see a lot more of that in the next few years.

Other than Will’s, what were some of the outstanding sessions this year?

I totally loved the Bruce Oberg’s talk “The Picture Worth a Thousand Bugs” about how they manage the game state for Sly Cooper 2 at Sucker Punch. That’s one of those areas that I’ve never seen implemented correctly and it’s always a big mess of spaghetti scripts and random code all over the place. Instead, they organized into a very clean and effective dag system, which allows them to visually display the state of the game and set up game flow in a very easy way, as well as fast-forward and rewind the game state for easier bug tracking. Go read his slides now.

Eric Malafeew’s talk on “Data-Driven Programming Made Easy” was very interesting also. That’s a topic I’m very interested in because of all the architectural and system consequences that it has. It’s great to learn about how other teams solve certain problems in their games. Besides, my wife and I are huge fans of Amplitude, so I had to find out more what’s behind the scenes.

Some of the other really solid talks were the one on the “Age of Empires 3 Graphics Engine” (they had eight full-time programmers on graphics alone!!), and Matt Noguchi’s “Halo 2 Content Management” talk (any self-respecting console game should have something very much like that, including data hotloading).

Finally, I also attended the IGDA Quality of Life Summit. There was nothing new, but it contin ues to be very necessary to keep bringing that topic up and discussing it. It saddened me to see a room packed with over 300 people across the room attending the “infomercial” session on the Windows Developer Day, and have only about 50-60 people in the Quality of Life session. Still, that’s a lot more than there were at the white paper unveiling last year, so at least it’s a positive trend.

The summit included a panel of several game developers to discuss the issue of crunch time. I was hoping to get some heated discussion going, and it seemed it was going to be that way when David Perry and Julian Eggebrecht stated that game development is all about passion and that passionate people are going to crunch and that’s how great games are made. Just as a point of reference, David was quoted in a magazine a few years ago saying “Never trust a programmer with a tan”. Then somebody in the audience confronted them by asking what measurements they took to verify that crunching in their past projects actually increased productivity instead of making things worse. From there on there was a lot of humming and hand waving and back pedaling to the point that the whole panel sort of agreed that crunching is not always good or necessary.

It was a pleasure to actually see Steve McConnell speaking at the summit. Sure, my perception was colored by the fact that I finally got to meet my hero face to face and even got to chat with him briefly after his session. The point of his talk is that by improving our development practices we can develop games for less money and with less need for overtime. Of course, even if we did, some people would argue that crunch time would not go away, which is very true. The causes of overtime run a lot deeper than that. Still, it’s a necessary first step. My main regret is that very few people got to see him, but what he had to say was very applicable to the industry as a whole. It’s also a great trend to look beyond the games industry for solutions to our problems. Kudos to IGDA (and Hank Howie from Blue Fang Games in particular) for bringing Steve to GDC.

GDC lived up to all expectations yet another year. I walked away totally exhausted, but at the same time energized and inspired and full of new ideas. Now it’s time to do some more research, put them to good use, and ship a great game with them. Don’t forget to submit your own talk ideas for near year’s GDC to give back to the community and contribute with your own experiences!

GDC can be a little intimidating the first few times you attend. With well over 10,000 attendees and 30 simultaneous sessions at any given time, as well as keynotes, expo floors, roundtables, special events, and parties, it’s natural if things feel a bit overwhelming at first. This article will help you navigate your way around GDC more successfully and help you get the most out of this year’s conference.

Get to know people

GDC is all about the talks, the tech, and the expo, right? Bzzzz… Wrong! GDC is first and foremost a great place to meet new people in the industry, exchange ideas, talk about different topics, and network in general. My memories of past GDCs are not so much about specific technical details (those come and go pretty quickly), but are about people: people I met, presenters whose talk I went to see, old friends I ran into, etc. If you do only one thing at GDC this year, make sure you make an effort to meet new people. You won’t regret it.

• Talk to the person sitting next to you. I’m serious. When you go to a talk and have a few minutes before the session starts, introduce yourself to the person sitting next to you. Chances are he (or she, although that’s significantly less likely at GDC unfortunately) is interested in many of the same topics you are since you’re both attending the same talk. He might have worked on some games you played, or the other way around. Don’t do it just at the talks either; breakfast or lunch is another great opportunity, and so are parties or other special events.
• Bring business cards. Talking with new people is a start, but continuing to have some contact after GDC is over can be really valuable. Make sure to bring a good stack of business cards with you and hand them out to anybody you meet and talk with for a while. You never know where your next contact is coming from, and it’s always good to know how to get in touch with the people you meet. If you don’t have business cards, have some printed right away, even if you’re a student or are currently out of work. It’s not for appearances’ sake, it’s just that it is much more convenient that having to write down people’s email address on the spot.
• Vary your social circle. Going with coworkers or friends to GDC can be very rewarding. You all go through a similar experience, compare notes, etc. It can feel much more secure when you’re thrown in such a chaotic environment. But make sure you vary your company a bit. If you just hang out with your coworkers all the time, you’ll miss out on meeting lots of new people. Strike out on your own at least some of the time.

Tutorials

GDC traditionally opens up with two days of tutorials. These are day-long sessions on one topic. They are not part of the regular conference, and you need to register for those two days separately (or get a GigaPass).

• Mix and match. Committing a full day to one thing is not something you want to do lightly. I find that I end up getting a lot more out of mixing and matching my tutorials. Tutorials usually start out with introductory material, and then get more advanced as the day goes on. So my usual strategy is to start with one I don’t know much about, and then move to others for which I’m only interested in the advanced topics. Sometimes I’ll even go back and forth between two or three, switching at every break, trying to hit the parts that interest me the most.
• Warming up. The meat of the conference is the last three days. That’s when everybody comes, the expo floor opens, and everything is moving at full steam. In comparison, the tutorial days are like a nice warm-up. There’s only a fraction of the people, not many events, and things are less frantic in general. If this is your first time at GDC (and you or your company can afford the extra price tag), I would suggest coming to the tutorials at least once.

Choosing sessions

If meeting people was the most important aspect of GDC, attending good sessions is the second one in the list for me. With so many simultaneous sessions going on over the last three days, it can be really challenging to decide what to attend. Unlike the tutorials, mixing and matching is not really an option because the sessions are usually only one hour long without any breaks. So, how do you go about choosing what sessions to attend?

• Does it benefit from a presentation? It sounds like a silly question, but really think about it. Is the topic something that would benefit from a presentation? A presentation that is highly mathematical might be easier to parse offline just reading the paper at my own pace rather than having it forced into my brain in one hour. On the other hand, just reading the slides for a session about the speaker’s experiences and anecdotes just won’t cut it. Peeking at the slides or paper before the presentation sometimes gives you a good idea how much you’ll get out of the session itself.
• Choosing the right depth. Usually that means the topic is something I don’t know much about so I’m looking to get a nice overview in a digested format to get me started, or it’s an advanced topic and I’m looking to get lots of tasty insights and an interesting question-and-answer section after the talk. If the talk is going to present a topic I’m familiar with at an intermediate level, there’s probably not much point in attending.
• Try something different. The first couple of times I attended GDC I made the mistake of sticking very closely to sessions that were directly relevant to my work. I think that was some misguided attempt to “maximize” what I got out of GDC since the company was sending me there. Sure, don’t blow off all the relevant sessions, but make sure you find some time to explore other topics and even different tracks. If you’re a programmer, go to a design or an art talk. If you’re into graphics, you could spend all your waking time going from pixel shader session to fancy lighting model session and not see anything beyond that. Take a break and hit an AI session instead, or a networking one. I guarantee that you’ll get a lot more than you think out of trying them.
• The speaker is very important. When you’re reading a paper, all you care about are its contents, but a speaker will completely make or break the presentation. I have learned over the years to really pay attention to who the speakers are, what their experience is, and, most importantly, how well they can present things. If there’s an interesting-sounding talk given by a speaker who totally butchered a presentation from another year, I’m going to think hard about the alternatives and I’ll consider getting the slides afterwards. On the other hand, there are some speakers whose talks I will unconditionally go to, since I know it’s going to be an awesome experience. For example, I really don’t care what the topic of Will Wright’s session is; if he’s talking, I’ll be there. I’ve attended enough of his talks to know he’s an amazing speaker with really good insights. Besides, his presentations are perfect examples of ones you just can’t get the same thing out of by looking at the slides.
• Create a schedule. Don’t wing it. There are lots of choices to make and there isn’t that much time (or places to sit down) in between sessions. I recommend deciding what talks you’re going to go to ahead of time, preferably the night before. Lately at GDC, you get a fold-out schedule of the full conference, which is great for marking what sessions you’re interested in and knowing at a glance where you’re going next. Another schedule-making tip: decide what roundtables you want to go to, but don’t add them to your schedule until the end. They’re repeated three times (once each day), so you might be able to fit them in a slot when there isn’t much else going on.
• Keep some backup. I don’t really want to encourage people to come in and out of a session while it’s going on, but there’s also nothing worse that being stuck in a session that you know you’re not going to get anything from it while there are all sorts of good sessions going on at the same time. If you’re not too sure about a particular session, keep another one in mind. If things are not going anywhere in the first five minutes, make a beeline for your backup session. If you do that, please sit towards the back or near an exit row to avoid disturbing people when you leave. Since you selected your backup session ahead of time you’ll waste no time selecting a new one and you’ll be able to make it for most of the second session.

Roundtables and keynotes

Roundtables and keynotes are the two most popular session formats after regular talks. Roundtables are small(ish) sessions with up to 40 or 50 people, in which the attendees engage in discussion on the roundtable topic. Keynotes are very large sessions of general interest, so they’re usually scheduled in an auditorium or some other large theater-like venue.

• Come prepared to talk. A roundtable is not a regular talk. Don’t walk into a roundtable expecting to sit on a corner and learn from other people. Come prepared to talk, or at least with questions of your own. If you just sit there and listen to other people, you’ll probably won’t get as much out of it as you could and it’ll be more boring for everybody. A good roundtable is a controlled, lively discussion where everybody participates, and can be much more rewarding than any regular talk.
• Continue the discussion. If you end up participating in an interesting discussion and you’re still interested in the topic when the roundtable ends, don’t let it die there. Go up to the moderator or the other participants who were part of the discussion, exchange business cards, meet up for lunch, or just say hi and perhaps continue some conversation through email.
• Don’t get discouraged. The same way that a good roundtable can be the highlight of a conference, a badly-run one is an awful experience, with a couple of people shouting at each other and the discussion drifting all over the place without giving you a chance to participate. If that happens, don’t get put off from roundtables permanently. Give another one a try sometime (maybe on a different topic). They really can be very rewarding.
• Go to the keynotes. Unless the topic is something you really, really don’t care about, make a point of going to the keynotes. They are usually general and interesting enough that appeal to everybody. They are often given by fairly big names in the industry, so this is your chance to see them in person.

Expo floor

The expo floor is open during the main three days of the conference. There you can see all the major companies involved in the industry trying to sell you software, hardware, books, services, or anything in between.

• Give the expo a try. I have to admit that the expo is not one of my favorite parts of GDC, but it’s still worth checking out every year. I particularly like browsing the small booths of unknown middleware companies, or of products I hadn’t seen in person before. I don’t really see much point in the big booths (NVidia, ATI, Microsoft, Sony), other than to say, “we have a presence here.” You will have plenty of time to visit the expo in between talks, after the sessions, or even during some of the breaks they make in the schedule specifically to let people visit the expo, so don’t skip any sessions just to walk around the expo. It’s usually not worth it.
• Swag hunt. If you’re in the hunt for swag, the expo floor can be a fertile ground. In years past there was a never-ending supply of t-shirts. One year I walked away with 18 new t-shirts, and some of them were being literally thrown at me as I was walking by a booth. Now it seems that companies are tightening up and the t-shirt supply has dried up a lot, but there’s still a lot of swag to be had if you’re into that kind of thing.
• Job fair. I can’t really say much about this. There are usually lots of companies there, but the booths seem to be mostly full of HR people, so it’s not like you can walk up there and start talking with the developers and find out how things really are at the company. Their booths are usually so packed with candidates walking through and filling applications that I can’t help but feel that your stuff is going to be thrown on a pile and will get lost in the shuffle. Is it really much better than submitting your application online? I’m not quite so sure.

Parties and events

I’ve heard of people who come to GDC and don’t even get a pass. They just go for the parties and apparently they have a blast. Whatever floats their boat, but it seems like a monumental waste to me. Parties have their place (especially if, unlike me, you actually like to drink alcoholic drinks), but to me the real GDC happens during the day.

• Look around for parties. There are many more than you probably know. Apart from the official parties, there are lots of invitation-only parties going on (usually all the big companies throw parties: Microsoft, Sony, EA, middleware providers, etc). Getting an invitation is usually just a matter of asking for one. Keep your eyes peeled and ears open and you’ll hear about them. Worse comes to worst, just swing by their booth and ask them what you have to do to get a pass.
• Meet people. You can try and use the parties to meet more people, but the setting is less than ideal (dark rooms, loud music, and lots of drunk developers).
• Check out the events. Apart from being another great opportunity to meet new people, some of the events can be quite entertaining. The Game Developer Choice Awards are the closest thing to Academy Awards for the games industry, so it can be an interesting event to go to. Besides, if you last all two hours, you get your GDC t-shirt at the end. The Independent Games Festival is always very interesting, and at the very least you should check out the games in the expo floor. It’s amazing what some of the independent developers can do with a budget of exactly zero dollars. We can certainly learn a thing or two from them.

Logistics

• Hotel reservations. If you don’t have a hotel reservation by now, you’re in trouble. You usually need to book those months in advance (December is a good time to do that—make a note for next year). Your only option right now might be doubling up with someone else who already has a room and split the cost.
• Trip. I don’t know why, but lots of people assume that the last day of the conference (Friday) is less interesting than the rest and leave early. Don’t do that. There are enough interesting talks all around to last the full three days, and more if GDC lasted longer. Don’t leave until Friday evening or Saturday morning.
• Location. By now I could give you great tips about San Jose, where to eat, what places to go to, which ones to avoid, but this year GDC moved to San Francisco, so that’s totally new to me. I’ll have to ask other people for advice instead.

And that wraps it up. Make sure you get lots of rest and sleep before GDC. You’ll need every ounce of energy for a very exhausting, but extremely interesting week. This is our industry’s biggest event, and it only happens once a year, so make the most out of it. And remember, make an effort to meet new people and say hi if you see me :-)

Photos courtesy of the Game Developers Conference.

The first day is where the real meat of this second part was. It was a postmortem/analysis of the tech involved in some of the most successful games today (Halo 2, Half Life 2, The Sims 2, and Stranger) done by the tech lead (or someone close to that position) for each of the teams. Each of the talks was packed with information and some of them are freely available online, so I’m not even going to try to summarize the talks. Instead, this is going to be more of a highlight of things that caught my eye or I thought were particularly important.

Jay Stelly on Half Life 2

[amtap amazon:asin=B000ID1AKI]

Nobody is going to argue that the Half Life 2 development didn’t have its share of problems: repeated delays, “Steam” issues, etc. Still, there is no doubt that Half Life 2 is a great game and there’s a lot to be learned from Valve’s approach.

One driving goal of the Half Life 2 tech was to design around the workflow. The technology should adapt to the way content creators want to work, and it shouldn’t get in the way. This also means that the asset pipeline should let people iterate as much as possible with no dependencies on other people or parts of the game. It seems like an obvious statement, but I think a lot of companies are missing that. This is going to become extremely important for next generation consoles, and I predict that companies that don’t completely adopt this paradigm will fall by the wayside.

One of the ways they went about designing around the workflow was to create a layered system with different levels of abstractions to represent their concepts. I really think that’s the only way to go when building complex systems (otherwise we have the tall building with shaky foundations syndrome), but it just struck me how they were always reaching for a higher level of abstraction than I would have normally considered. Having that extra level of abstraction allows for better separation of content creation tasks.

For example, they could have left their sound system at the level of abstraction of sound emitters and listeners. Most games stop there. They went one level of abstraction higher and modeled sound environments, which include a collection of emitters, and sound processing parameters. Then each of the sound environments could be applied to particular locations in a level. This approach allows the sound designer and level designer to work in parallel, bringing their work together at any point they want while they’re still iterating.

But workflow doesn’t apply just to designers and artists. Programmers also do some work, you know? So, not surprisingly, another driving point of the Half Life 2 technology was to improve the programming environment. They had 14 programmers in their team, which starts to be a bit on the large side, so that was yet another motivation to go with a very layered system. Different programmers could concentrate on specific areas and not interfere with each other’s work. They also made the distinction between system code (engine) and leaf code (game-specific code), which helped organize things. Interestingly, they went with a DLL-based approach to reduce link times, which often stop fast programmer iteration dead in its tracks.

One drawback of the extremely layered approach was that Half Life 2 was completely memory bound. Heavily abstracted and layered object-oriented systems usually have a memory access pattern that looks more random than lottery-winning numbers. That means they can kiss goodbye to a lot of cache consistency, and the program is going to be constantly stalling, waiting for data to come from main memory. This is a very serious problem, and since memory is going to continue getting slower relative to CPUs, it’s something we’re going to have to deal with.

Program performance was never a major driving force behind programming languages, and especially not nowadays, but it would be interesting to come up with a language that allowed for good modularization and design, but at the same time being extremely cache-friendly. On the other hand, scratch that thought. We have much bigger problems to solve with programming languages before we worry exclusively about cache performance.

Interestingly, general scripting didn’t work for Valve very well. Instead, in the future they plan to go down the path of C++ program behavior, with data that can be easily changed from text files. As long as adding new C++ functionality can be done very quickly, and there’s good communication between programmers and designers, there’s no reason why that can’t work.

Chris Butcher on Halo 2

[amtap amazon:asin=B00008J7NZ]

Chris started right away with a very insightful observation: The Halo games are really a world simulation, where the player is just another entity moving around the world. On the other hand, the Half Life games are more of a player-based simulation, where everything happens for the benefit of the player.

The whole Halo engine is based around the concept of “tags,” which is something that Bungie has used in most of their past games. Tags are just a hierarchy of variable-length block arrays, and each block is made out of basic data types. Tags describe the properties of a game object, as well as how meshes are represented. The part that surprised me is that tags are actually defined in the C code itself as opposed to being an external data representation that then gets processed and generates some C code (which would have been a much cleaner way to separate tools and engine).

The tag approach has lots of advantages. It has full introspection abilities and it can be used to easily load and save data. Also, because everything in the engine uses it, it means that if we have a generic tag editor, we can use it to change any of the data. They even go as far as seeing the level editor as a fancy, graphical editor for the tag system.

Because the tag system is hierarchical in nature, Bungie creates their entities by using composition instead of inheritance. In my opinion, this is totally the right way to go. You want an enemy to have a weapon, not to inherit from a HasWeapons class.

One thing I still can’t really understand is why Bungie is using plain C for most of their game. Don’t get me wrong. They can clearly produce great games that way, but it just seems that with C++ they could do it more easily or faster. I understand that right now they can pretty much save raw memory and load it straight back into the game, which would be very difficult to do with C++. Still, if that’s the only benefit, I’m sure it would be relatively easy to set up a system to do transparent serialization in C++ as well and reap all the benefits of the language.

As was the case for Half Life 2, they also spent considerable amount of time trying to improve the artist workflow. They use resource hotloading, automatically detect changed files, etc. So with a lot of resources, their artists can just re-export the asset and see it live in the game in a few seconds.

For memory allocation, they tried to minimize dynamic memory allocation at runtime (although they admit there are a few out there), but all allocations are bounded, which really is the only way to deal with a fixed-memory system like a game console. Apparently Havok is one of the exceptions to the rule since it doesn’t make any hard guarantees on memory usage, so they had to treat it specially. Also, their world simulation is perfectly deterministic, which is great for repeating bugs. Their world view (rendering, sound, etc), however, is not deterministic.

Charles Bloom on Stranger’s Wrath (presentation notes)

[amtap amazon:asin=B0006I5I58]

From the very beginning of the talk, Charles Bloom adopted the underdog role and played it to perfection. He made it very clear that Stranger’s Wrath was a very different project from Half Life 2 or Halo 2. Whereas we had just been told that the teams of Valve and Bungie were full of talented and experienced programmers, Charles claimed that Oddworld had a much wider mix of talent, with many more weak links. In his words, not everybody can have the super programmers from Half Life 2 or Halo 2. That’s a funny way to start, but it really drove a point home about how Stranger was perhaps the project that most people will be able to identify with.

So in that light, the Oddworld method relies a lot more on putting a lot of responsibility on the shoulders of their lead programmers. They’re in charge of reviewing the code of other programmers, and making sure everybody stays productive. The philosophy behind code is that any code should be easily usable by everybody, regardless of their skill level. It also means that code needs to be robust, and should be hard to break or do wrong things with it.

This is a very interesting point. I totally agree with the idea of robust, defensive code, but for different reasons. I believe that’s a good practice in general, even if your team is full of “super-programmers.” Later on down the line, it will be a lot easier to work with that code, or modify it, or anything. Using the excuse of “the programmers in my team are really talented” to write brittle or badly encapsulated code is a really near-sighted attitude. I was glad to see that Charles later mentions in his “rants” page (entry from 12-06-04) that he really thought that code robustness was a good quality in general, independent of your team composition or skills.

The same attitude applied not just to the code, but to the game engine and the tools themselves. They never wanted the game to go down and prevent people from working, so they always tried to cope in the best way possible with missing assets, incorrect data, etc. All great things to aim for in my opinion. I have applied similar rules in some of my past projects and they worked out great.

The differences between Halo 2 and Strangers didn’t end there. Even though they’re both somewhat similar games, both Xbox exclusive, they’re as far apart as you can get from a technology point of view. Halo 2 tried to be as minimalistic as possible: it hardly used any C++, they avoided dynamic memory allocations as much as possible, etc. Stranger, on the other hand, embraced C++ and a lot of its advanced features: they used dynamic memory allocation, the STL, smart pointers, and even exceptions. Yes, exceptions! (They did turn them off for release, but they made good use of them during development as part of their defensive code style). So, in spite of all the differences, they still managed to make a game that rivals Halo 2 as far as the technology and pushing the Xbox to its limits.

Another area where Stranger is totally different from Halo 2 is how game entities are organized. In Halo 2 everything uses composition, which to me feels like the natural way of creating them. Stranger apparently makes heavy use of multiple inheritance to achieve the same effect. And not just multiple inheritance of abstract interfaces, but full blown classes with their own implementation. I’m really surprised that the system worked well for them and I’d definitely be curious to learn more about it.

From the asset pipeline point of view, Oddworld also uses hotloading of resources to see changes in the game in an almost instantaneous way. They also stressed the importance of build farms and distributing a lot of that processing.

Interestingly, Charles admitted that most of their data was generated by manipulating plain text files. No fancy GUI tools (other than Maya for level editing and layout). Just plain text files. I think people sometimes forget how easy it is to work with text files, and get all wrapped up into making fancy tools that end up limiting what they can do. Clearly, text files are going to need very strong validation to deal with all the errors that are introduced by typing things by hand. The only thing I didn’t like is that apparently at Oddworld that validation happens at load time. I would have preferred it to happen as soon as the file is saved to give feedback right away to the creator.

Andrew Willmott on The Sims 2

[amtap amazon:asin=B00009WNZA]

This talk was a bit different from the others. First of all, the Sims 2 is a very different game from the ones presented so far. It was also clear that the talk was going to be different just from the emphasis in the title “Shipping the Sims 2.” Andrew didn’t go into tech details as heavily, but gave an overall overview of the project organization and statistics. This was by far the largest of all projects presented (it had 250+ people at the end!), but that’s not so unusual for an EA project.

A lot of his talk dealt with the pressure they had to deal with, and the challenge of organizing so many people. Being the followup to the best-selling game The Sims couldn’t have been easy, and throwing that many people at it at the wrong time could have made things close to impossible. The fact that the project slipped and Maxis was moved to a new location months before shipping certainly didn’t help any!

One of the most interesting facts is that Them Sims 2 used a visual scripting language called Edith, and at the end, they all hated it and wanted to move away from it. That has been my experience as well with visual scripting languages. The only time visual scripting languages might be OK is if they generate a text-based script that you can then manipulate just like any other text. Otherwise, there are just too many disadvantages: difficult to copy/paste, can’t grep anything, hard to do multi-script changes, hard to view history/differences in version control, etc. Andrew mentioned Lua as their likely scripting language of choice in the future.

Another interesting technical fact was that they made heavy use of scene graphs, but they were also very dissatisfied with them and they mostly got in the way of the game programmers. At one point I was a fan of light scene graphs, but I’ve changed my mind in the last couple of years, and I also prefer to organize elements in much more specific containers (and keep the same element in multiple containers for different tasks).

As a really funny aside, The Sims 2 uses a technique I thought it was well dead and buried: dirty rectangles. I’m not kidding. I thought I saw the last of those when I started using page flipping in the VGA days, but apparently it was useful, given their problems rendering so many objects in view. My hat’s off to them for even thinking of it!

Like Stranger, The Sims 2 made heavy use of C++ as well, with dynamic memory allocations, STL, etc. That’s not all that surprising since it’s PC-only game, but it’s still a good point of reference.

The rest

The last day was much weaker than the first one. I really wished we could have extended the first day to the full conference (either by looking at other games, or by digging deeper into some specific topics).

The one really worthwhile session that stood out from the others was Casey Muratori’s talk on “Designing Reusable Code.” Coming from someone who wrote two versions of Granny, it actually had some very interesting insights. It was clearly coming from the point of view of writing middleware (as opposed to writing reusable code to use in multiple games in the same company). The most important observation is that people will want to integrate your code in different ways. At first they just want a quick and dirty integration just to get it working. Later they’ll want some more control to fine tune things. Finally, towards the end of the project, they’ll want to take over a lot of the aspects of the code, such as loading and memory allocation.

To support that pattern of usage, Casey suggests having several levels of interface exposed. One high level interface that accomplishes the basic functionality with a single call, a more detailed one that requires more work on the part of the user, all the way down to the detailed functions. I absolutely agree with the overall principle, but I think Casey was suggesting taking it to the extreme, to the point that he was suggesting that just about every function should be made public and that loading something should be a matter of streaming the data into memory without any other function calls required. That’s just a bit too extreme for my tastes. I also happen to value simplicity of interfaces very highly, so there’s the big question of how to organize those interfaces to make sure they don’t seem more complicated than they really are.

Casey also argued that the best way to develop an interface was to use it before you actually implemented anything. Since that’s exactly what one of the things that test-driven development accomplishes, that was music to my ears. I was also shocked when we had a show of hands to see who was doing test-driven development, and about 10-15 people from the audience raised their hands. Yay! I’m glad to see I’m not alone.

Another session worth mentioning was Brian Sharp’s talk on how to integrate a physics engine into a game. He brought up a bunch of really good points and anybody integrating a physics engine into their game for the first time would do well to track down the slides and read them carefully. Some of the points were obvious, but some were very interesting, such as how it affects the interactions between different programmers and designers, and what people might expect out of them.

The rest of the sessions ranged from simply OK, to a couple of pretty bad ones, that totally felt like a sponsored session where they were trying to sell their product. It was too bad that the conference ended on such a low note, after starting with the amazing first day (and the really good first two days).

I really hope they organize a similar conference for next year, but the key is going to be to come up focused, relevant topics. Personally, I’d like to see one of the sessions concentrate on asset pipelines: both overviews of current projects, and specific techniques and organizations (use of databases, concurrent editing, integration of source control, etc). All in all, it was a great experience, though. The small size of the conference and the great speakers and attendees made it really unique, and gave me an opportunity to finally meet a lot of people I had only interacted with through mailing lists before.

I’ve been saying for a while that the “next frontier” of game technology is going to be characters. Not fancy graphics. Not physics. Not online play. We can now create worlds that have exquisite lighting, fancy details, and complex environments. And we can do it in real time too. Sometimes you start to wonder if we’re really approaching movie-level quality. Then a character walks in and that illusion is permanently destroyed: the feet slide as the character slows down, the animation pops as it transitions between different poses, the arm interpenetrates the table when he leans on it, the skin looks more like paper, and the hair look like it has been plastered down with super glue. In other words, the character has less charm than a zombie straight out of a B-horror movie.

It is no surprise then that the first two days of the GameTech seminars were dedicated to characters. It approached the problem from two different angles. First it examined how we can try to make better looking characters. Then it addressed the question of making them move in a more realistic way.

It started by covering some of the latest advances in hair and skin rendering from the Siggraph and special effects crowd. When we’re talking about physically rendering and simulating each individual hair as a link of 10 or more jointed segments, you know we’re way beyond what’s currently possible in games. Still, it’s a glimpse of where we’re heading in a few years down the pipe. In the meanwhile, understanding the full simulation in detail might help us come up with shortcuts and tricks that look somewhat like the real thing.

The skin rendering part was much more down to earth. Even when it was approached from the movie production point of view, what they’re doing is not as far from what could be possible soon. As a matter of fact, they are already way past the point of diminishing returns in regards to quality improvements. Some of the models for subsurface scattering presented only produced extremely subtle changes (I wouldn’t even be able to call them improvements, although I’m sure they look closer to the reference photographs).

ATI showed off their newest Ruby demo. I really was expecting more by way of character animation, but they had some pretty fancy lighting which used pre-computed lighting sampled at a bunch of points in the environment (along a couple of splines in the tunnel), and applied in real time to the moving characters. For skin rendering, they are just blurring the diffuse lighting to fake subsurface scattering. Interestingly, they’re using a shader that does a Poisson disk filter, which seems to be popping up everywhere you look nowadays (depth of field, shadows, subsurface scattering,…). A few years ago, shiny bumpy things was the in thing. Now it’s blurry diffuse effects.

The animation section is where things really started getting interesting. We all know that the days of pure pre-canned animation playback are numbered. So far we’ve only been making attempts at correcting grab animations, or to plant the feet on the ground with IK. But there’s more that we can do. Much more.

Lucas Kovar and Michael Gleicher presented some of their research in the area of data-driven character motion. The results were absolutely stunning. They approached the problem of creating new animations in a variety of ways, but they all had in common that they were creating new animations based on captured animation data. One approach looked at a bunch of motion data and created animation trees from it with nearly seamless transitions. For anybody who has tried putting together a simple animation tree for a third-person game, that produced really amazing results (although they were also using really complex animation “trees”).

The parametrized motion project was really impressive and I think has a lot of future in game development. It synthesized new animations based on existing similar animations. So out of a few walking, turning, and jumping cycles, it could generate a new set of animations to adapt themselves to the current game environment. It was also demonstrated with more complex animations like martial arts movements or even cartwheels. At the heart of this approach is the idea of match webs, which are a data structure used to find potential matches to similar animations. The applications to offline animation authoring are obvious, but I really think it’s possible to apply it at runtime as well. They were able to show some impressive results with just a few animation data sets.

The next day, David Wu approached the problem of adapting animations to the environment by trying to solve the physical constraints. While it might be a reasonable approach to “fix” animations or to make minor tweaks, it really didn’t show the potential of the data-driven animation approach. The most interesting thing I got out of David’s talk was his comment about how many game developers lack an understanding of what’s going under the hood in middleware packages (especially for physics) and so they can’t take full advantage of its capabilities. I don’t think that’s true for something like graphics or sound. I wonder if that means we haven’t exposed the right interface to physics middleware packages. Or maybe physics is more complex and more tightly coupled to the rest of the game. David went on to present what he considers is going to be the future interface of physics (he compared it to the advances that computer graphics made once we all agreed on using the polygon as a basic primitive).

Finally, a third way of approaching animation synthesis was presented by Torsten Reil, from Natural Motion. He tackled the problem by using a set of controllers and running it through a set of genetic algorithms to develop the motion he wanted out of them. Unfortunately, it felt that he didn’t want to get into many details when he was asked questions from the audience, probably because of patent issues and the fact that Natural Motion is selling a product based on that research. Because of that, it felt a bit like a sales pitch “Look at this cool tech. Now come buy our tool that does it all for you.” A lot of the demos showed used a combination of genetic algorithms to derive the controllers, plus some artist tweaking, and a few heuristics. Right now, this approach is limited to offline animation only. Still, it was very impressive to see the results of the genetic evolution of bipedal motion and hear what type of troubles they had to go through to generate them (they had to resort to using a stabilizing controller like training wheels on a bicycle to be able to past some of the local maxima that were preventing further evolution in the right direction).

Of the three approaches, I’m really excited by the data-driven techniques. I really believe that we can start applying some of those techniques in games relatively soon (this next generation of consoles even). The big advantage it has is that it doesn’t just generate a plain walking animation. You can feed it whatever type of specific type of animation you want: sneaking walk, female walk, big guy walk, etc. You can then adapt those type of animations to your game and get the style you wanted perfectly integrated in your game.

Finally, Tom Forsyth’s talk on “How to Walk” was a very down to earth, practical and well illustrated. Basically, he started by saying that most games out there right now have terrible walk cycles. That’s particularly a problem for third-person games, where the player is constantly seeing his avatar move around the world. It’s a topic he’s particularly well-qualified to talk about since he’s currently developing Granny. The key idea from his talk is that the animation should not drive the movement of the character in the world. It should always be the game that is moving the character, and the animation system should do its best to keep up and minimize artifacts (the only situation when this was not true is when moving the character up and down over a flight of stairs or some other discontinuity, or during cutscenes, when the player is not in control). He explained how to effectively blend animations (make sure they’re synched), how to use leaning forwards, backwards, and to the sides when the character changes direction or speed, etc. He showed all these techniques with a neat little demo that will probably be bundled with the Granny SDK.

That was a lot of stuff for just two days! Every night my brain would be full, ready to explode, but it was really a great session. It was a great mix of current academic research projects, movie effects, and current application to games. But that wasn’t the end. The next two days we would switch gears and cover engine and tools technology. I’ll talk about those in the next article.

The Québec region (where Montréal is located) has some impressive statistics to boast about: over 40 companies involved in game development, and over 2000-full time employees (with the giant Ubi-Soft topping the charts with over 1000 employees alone).

Having said that, it shouldn’t come as a surprise that the first Montréal Games Summit was organized this year. It brought together some great speakers from both Canadian and US companies, and it attracted almost 600 attendees for the two days of its duration.

I attended to give a talk on agile game development, but I really enjoyed the rest of the sessions I got the chance to see. Overall, the conference had a feel of a mini-GDC, somewhat like the GDC roadtrips that they used to do years ago (what happened with those, by the way? They were great little events and had a much more personal feel to them since they brought together people local to the industry in each area).

Even though it was a quick in-and-out trip (red-eye flight in one day, late flight out the following day), I also got a chance to walk around the center of Montréal (and to practice my rusty French right away with an insistent taxi driver who spoke no English at all and wanted to know why Bush had been re-elected). Walking around Montréal, it was easy to think I was wandering around a city in France, especially in the old city section, around the Rue Saint-Paul and the Rue de la Commune. The city was really clean and walkable, and it was a real pleasure to stroll around in a chilly November morning.

The conference started with a keynote by Ray Muzyka on the organization of Bioware. I already knew a lot of what was covered from earlier presentations (and here) and articles, but it always strikes me that they really have their act together at Bioware. They clearly have some very sharp people running the business. It’s interesting that they started the company without anybody having any previous industry experience (which goes to show that previous industry experience is not always necessary, and people can bring lots of new knowledge and experience from the outside).

I was also interested to learn that they use a matrix organization internally. On one axis they have individual projects, and on the other axis they have departments. They have clearly differentiated goals between departments (dealing with career growth and long-term plans) and the projects themselves (dealing with project-specific goals). They also continue having a lot of people per team, a trend they started with Baldur’s Gate (having about 80 developers back in 1999) and that continues today with Jade Empire having over 120. Whatever they do, they keep putting out quality title after quality title, and they only have a 3% yearly turnover rate, so they are clearly doing something right!

I was pleasantly surprised to see that my talk on agile game development was completely packed. Even though it’s not in widespread usage, people are clearly very curious about agile development in the games industry. It’s also always one of the favorite topics that comes up in the software engineering roundtables at GDC. Maybe in a few years we’ll start seeing some games shipped using agile methodologies from companies other than Sammy Studios.

That same afternoon there was an extremely interesting session on the AI of Full Spectrum Warrior by Quinn Dunki. She described some of the major goals of the AI development for Full Spectrum Warrior and how they went about doing it. She stressed the important of keeping things simple and the ease of debugging. To that end, they used simple, tried and true AI methods (mostly state machines), and completely avoided messaging systems, preferring to call functions directly and being able to stop the game at any time and look at the call stack. They also had some great visual debugging tools superimposed on the game to know what was going on with the AI at runtime. They also chose to avoid dynamic memory allocation (at least in the AI systems).

I totally agree with the idea of keeping things simple, but I think that code design and architecture considerations should come before debugging benefits. If something like a messaging system improves the architecture or maintainability, then I’d rather use it and find some ways to improve debugging. Also, with heavy use of unit tests, debugging should become almost unnecessary. Still, she did present a compelling case for her argument.

One of the most interesting goals for Full Spectrum Warrior was that they wanted to have zero foot slide. If you don’t know what that means, fire up any current 3D game with characters that move around and look closely at their feet. They’ll range from slight sliding, to major skating over ice like crazy. In either case, they make human animations look obviously fake and it makes animations lose their “weight”. If you think that’s a solved problem, fire up that game again. Turn the character around, transition between a walk and a run, stop suddenly. Chances are you will see feet slide all over the place. It’s one of those problems that seems trivial until you start trying to solve it. Only then you realize how difficult it really is.

The character animation of Full Spectrum Warrior is outstanding, so even if they didn’t reach their goal of 100% no foot slide, they still managed to do great job. Here’s one scary fact she mentioned: The game had a total of about 60,000 animations (yes, that’s the correct amount of zeros). Most of us don’t even come within an order of magnitude of that. Just thinking of managing all those animations makes my head spin!

The following day I attended a session dealing with the use of Softimage in the Half Life 2 asset pipeline. I was very impressed with some of the in-game sequences they showed us when the player gets to interact with other characters in the game. They had great tools to quickly set up a scene like that and all the interactions between the characters. It was particularly interesting how they imported specific assets or parts of a level into Softimage to create unique animations tailored to fit those assets. For example, animations where characters handle some objects or run over level obstacles were all created specifically for those assets. The results were very natural-looking animations that interacted with the environment almost to perfection. One fact that absolutely amazed me: Apparently they used no version control system for the assets of Half Life 2. I hope I misunderstood that! In any case, there’s one game I can’t wait to play.

Another keynote was supposed to deal with the making of Halo 2, by Michel Bastien, one of the producers from Bungie. Unfortunately, it got watered down to being the making of the cinematic sequences in Halo 2. Frankly, there was nothing new in that. They go through the usual different phases: scripts, storyboards, blocking shots, adding animations, lighting, music, etc. That’s all pretty standard stuff. We were treated to a few minutes of Halo 2 running on the Xbox, but I suspect you had to be a Halo fan to appreciate it (I only managed to play the first one for about 20 minutes for some reason).

Finally, Mario Rodriguez, a test engineer from Microsoft, gave an interesting talk on optimizing the build system. The talk was actually a lot broader than it sounds. It dealt with issues such as how to improve build times (through precompiled headers, structuring of code, or distributed systems–a lot of which I covered in an earlier article), running build verification tests, and distributing game assets to different people and machines, which, if you have 4 or 5 GB to pass around, it can be quite time consuming. Interestingly, they moved away from using xcopy to using a custom program and they’re getting much better results (not to mention also having a lot more control).

On that note, one of the things that I want to research in the next few days is the use of Scons as a code build system. It’s written in Python (which means you extend it in Python instead of strange Make or Jam rules), it’s correct (using data CRC instead of timestamps to determine when a file has changed), and, most interestingly, uses a network cache. If that works as I think it does, it might mean that developers can cut down build times by a huge amount if they sync to code that was used by the automated build machine for a build because the object files are already available in the network. If that’s the case, I will consider very strongly making it the build backend for our future projects at Sammy Studios.

Overall, the conference was a hit. The location was great, the quality of the talks was comparable to GDC, and it really managed to put Montréal on the map from a game development perspective. It was a bit out of the way for those of us living in the West Coast, but it’s really nice to have an industry event like this that is not based in California for a change. I hope it continues growing in upcoming years and attracts even more developers from the US.

The full-day tutorials were a bit on the weak side this time around, but the “Test Automation in Game Development” done by a group of Microsoft test engineers more than made up for it. I found it to be a very well-paced session, covering things in enough (but not excruciating) detail and with lots of very solid information. The topics towards the end were particularly exciting, dealing with unifying all the testing strategies under one system, and doing data mining effectively with the unwieldy amount of results generated by so many automated tests.

The sessions in the last three days were all very strong. I felt there were more quality sessions in the topics that interested me than in previous years. Interestingly enough, I didn’t go to many programming talks this year; for some reason, I ended up going mostly to game design and production talks, and enjoying most of them a great deal. The award for the most redundant talk of the show goes to the ones covering some form of real time global illumination. Maybe it was just me, but it seemed the same talk was given by a different person with a slightly different title several times each day.

The highlight of the show without a trace of doubt was Will Wright’s talk “Triangulation: A Schizophrenic Approach to Game Design”. After attending six GDCs, I have learned that there are some people that you simply have to go see. It doesn’t matter whether they decide to give a talk about how their baby girl is learning to walk; you’re guaranteed to have a great time and walk out of there with a lot of insights. Will’s talks are like that. This time he described the process he uses for designing a game, how he approaches the problem from multiple angles, and how he treats it as an infinite tree of possibilities that needs to be culled through experimentation and instinct. Even his digression into the history of the Russian space program was highly entertaining and bizarrely relevant. But please, when you bring Will back next year, give him the Auditorium. There was no excuse to put him in a medium-sized room that was already overflowing 10 minutes before the talk.

Soren Johnson’s talk from Firaxis on “The Civilization Series: How to Maintain a Successful Franchise” probably gets the award for the best unexpected talk. I might have missed this session except for the fact that I met Soren the day before and there was nothing much going on at that same time slot (except for the fourth rehash of the global illumination talk), so I decided to give it a try. Boy, was I impressed! Soren had some very good insights on game franchises and how to think about them in terms of technological/gameplay innovation and release frequency. He then analyzed in detail two very successful franchises (Age of Empires and Warcraft) and compared the decisions made for each of them. The talk finished up by presenting the Civilization franchise in terms of everything he described before, which wrapped things up in a very effective way. I can’t wait for Civilization IV!

A very simple, yet effective and informative talk was Brian Sharp’s session on “The Physics-Sound System of Deus Ex: Invisible War and Thief 3” (whoo-hoo, I made it to a programming talk for a change!). I really liked how he decided to approach the talk: Present an apparently simple problem (what sound do we play when two things collide), then start with simple solution and build on it as its deficiencies became apparent. He wrapped up the talk with a nice demo level with objects making all sorts of noise when they were being dropped on each other.

I had high hopes for John Carmack’s keynote. I met John a few years ago at the first GDC Hardcore Technical Seminars and I knew he was a reasonably good speaker and, most importantly, had great insights into the industry and future directions of the technology. Unfortunately I think this might have been a case where I was expecting too much and the keynote fell a bit flat in the end. He echoed a lot of the same things he mentioned back in 1999, such as the fact that graphics are getting better and better and other things need to catch up soon (especially physics and animation). He also expressed his concern about how more and more people are required every day to make a game, and he encouraged people to find alternate genres and different ideas that might be accomplished by a small team. I found it very funny when he lamented how Doom 3 was the first project he ever worked on where he didn’t have full control over the source code and there were even a few source files he hadn’t even opened. Welcome to our world, John!

A notable mention goes to the talk given by Toru Iwatani, the creator of Pac-Man, “The Secret of Pac-Man’s Success: Making Fun First”. It was very interesting learning what he was thinking when he created Pac-Man, and to get an insight into Japanese culture. The session was simultaneously translated and worked remarkably well. Besides, I even caught a few words in Japanese with what I’ve been learning from Shogun :-).

Another interesting talk was the “IGDA Quality of Life White Paper Unveiling” by Scott Bonds, Dustin Clingman, Hank Howie, François Dominic Laramée, and Greg LoPiccolo. They are bringing strong proof about something I’ve always felt very strongly about: The industry is really hurting because of the poor, non-sustainable work conditions. When people are working 60-70 hour weeks on a regular basis, they burn out. In the short term they won’t do their best work; in the long term, they’ll leave the company and eventually, the industry. The results from a recent Game Developer Magazine survey were surprising: Over 60% of the people in the games industry have less than 5 years of experience. But when combined with the results of the IGDA survey, they’re positively spine-chilling: 34% of the people are planning on leaving the industry in 5 years or less, and over 50% of them are planning on leaving in 10 years or less. Those are really scary numbers, and unless something is done about it, the industry is doomed to continue being stuck in its adolescent phase forever.

The best-talk-I-didn’t-go-to award goes to “Entertainment Experience First, Videogame Second: The Making of The Return of the King” by Neil Young. I don’t know what I was thinking when I chose to go to another (rather uninspiring) talk instead. To add insult to injury, I was actually in the room next door and I could hear the audience roaring with delight through the wall. I don’t think the audio proceedings will cut it either considering it was the Visual Arts keynote. I’m still kicking myself over that, so don’t even think of mentioning it to me again.

Stepping back and looking at the sessions I attended, there were a couple very strong underlying themes. The first one is that the teams necessary to create a top game continue to get larger and larger. People are finally starting to realize that the development methods traditionally used throughout most of the industry are falling short and something needs to be done about it. It’s probably no coincidence that the number of attendees to my software engineering roundtables has been increasing every year. Also, middleware is making its way into more of the talks, often as a side or secondary theme.

The other sub-theme apparent in many of the talks was a lament (or alarm, depending of the talk) about the lack of innovation in game design. Speakers were urging developers to think of new approaches and not try to compete with the big players in well-established genres. The only hope of spark was the downloadable game IGDA competition, where innovation is still alive and well. Hopefully we’ll see more activity along those lines next year.

I’ve never found the GDC expo floor to be particularly interesting. It’s a great way to meet face to face with tool creators and middleware providers but not much else. It’s not like I’m going to purchase Renderware Studio on an impulse buy, and it’s not like I haven’t read all the specs and seen demos of the tools I’m interested in. Still, a few times you might come across some small company that had gone under your radar before. I didn’t spend much time in the expo this year, but I got the impression that it was mostly the same faces from last year, no surprises there. However, the expo was always a chance to renew your t-shirt wardrobe. In years past, you would be literally bombarded by t-shirts being thrown at you by the vendors as you walked past their booth. You get a cool t-shirt (hopefully not in fat game developer standard xx-large size), and they get advertisement for a year. Not this time. Maybe the economy is down, maybe the industry is getting ready for another change with the next generation consoles looming on the horizon, but t-shirts were more scarce than hens’ teeth this time. Either things change next year, or I’ll have to actually buy some t-shirts for the first time in years! :-)

Next year GDC will break with tradition and be hosted in San Francisco. I admit I was finally becoming fond of San Jose, but changing venues will have its own share of advantages. It would be fantastic if they decided to change locations every year like SIGGRAPH and we ended up with a GDC on the East Coast once in a while. In the meantime, I can look forward to dinner at the Stinking Rose every night!

Images from gamedev.net.

Session 1 | Session 2 | Session 3

Overview and Attendance

Thanks again to everybody who attended the roundtables this year. All in all we had about 150 people show up (with the first two sessions being completely packed), which means the interest in software engineering continues to increase as projects get more complicated, and team sizes and budgets continue to increase.

We continued the trend from previous years and we had about 30-35% of managers and project leads. That’s a good thing because for things to change management needs to get involved, and the sooner they do, the better.

The large majority of the attendees were working on PC and console games (surprisingly, about the same number of both), with very few handheld and web game representation.

C++ this year was the undisputed king of the programming languages (so much that I couldn’t count the number of hands). There were only a handful of people using straight C, but a higher representation of Java and higher-level scripting languages like Python or Lua. Several people were starting to use C# for their tools development.

One new piece of data I collected this year was team size. I really wish I could compare this against previous years, but the results were very telling even by themselves. Specifically, I asked for the number of programmers in their teams. These are the results:

• 1-5: 35%
• 6-10: 45%
• 10-20: 20%
• > 20: 0.05%

All of the programmers who were working on a team of 20+ people were either from Electronic Arts or from outside of the games industry. Still, the numbers are pretty high already, and those are probably just signs of things to come. Even John Carmack lamented the increasing number of people required to make a game in his keynote speech.

Wednesday 24th: Software Engineering and Techniques

The session started with a discussion of how can software engineering help game development. Lots of reasons were brought up:

• Reducing risk
• Reducing bugs
• Helping with reuse
• Easier multiplatform development
• Repeatability
• Reduce crunch time
• Easier transfer between projects
• Better support of their content teams

All of those are reasons that will continue becoming more and more important in the near future.

A few people had concerns about over-engineering things and brought up the need to strike a middle ground. Even so, nobody admitted to doing too much engineering in their teams (although people did have over-engineered, or over-complicated, pieces of code).

Coding standards

About 75% of the attendees actually had coding standards in their companies (or, in some cases, multiple coding standards!). Only about half of them actually followed them, but most people who had a coding standard found them useful. The reasons given were that it was a good leveler by making the code more similar throughout the project, and that it saved programmer time and headaches.

However, not everybody was in favor of them, and certainly not everybody agreed on what they should cover and in what detail. Some people argued that a coding standard should only cover interfaces and not interfere with implementation details. Some found it difficult to maintain a standard when interfacing with third-party code or APIs. A good point that was brought up was that a coding standard shouldn’t be too detailed

Code ownership

Participants identified three main types of code ownership:

• Team ownership: The whole team owns the code.
• Loose code ownership: One or two people are mostly responsible for an area of code, but other people can still modify it.
• Strict code ownership: Only one person can modify the code.

Very few people had team code ownership (the few who did were doing pair programming). Most people either had loose or strict code ownership. The benefits of team code ownership are avoiding the “hit-by-a-bus syndrome” (where you might lose your most important programmer because of some unexpected turn of events), and spreading the knowledge of the system to everybody and making all the team members more valuable. The disadvantages were that sometimes people did not take responsibility for their own actions. Team code ownership requires a lot of communication and might work best in smaller teams (5-6 programmers).

Code reviews

About 20% of the participants had some form of code review in place, but the specifics varied a lot. Some people’s reviews were just a quick look by someone else before the code was checked-in (code buddy). This was done more frequently around milestone time to avoid people checking in code that would break the build.

A few people had more formal processes in place, printing out the code, and reviewing it in more depth. However, a lot of people found this type of reviewing more tedious than it was worth, and it has the potential to quickly degenerate into pointing out formatting problems or allowing people to go off in tangents about their favorite language feature.

The question of what exactly was the purpose of the code review came up. It clearly doesn’t help any with code design because the review happens after the code is written and working. The main reasons listed were bug prevention and avoiding horribly inefficient code.

Automated builds

About 40% of the participants had some sort of automated build system in place (way up from the 15-20% of last year!). Most of these automated builds were done by custom scripts in a high-level language such as Perl or Python. How and when the builds are done also varied a lot: some people had them triggered with each check-in, others had a machine building continuously, and others were simply doing nightly builds.

Some of the benefits claimed for automated builds were checking that the code could always compile and link, and easier version labeling and tracking. A lot of people, in addition to building the source code, were also doing asset builds. As an additional step, many people were doing some form of validation on their executables by loading a few levels or playing back some input (especially random input). People collected the results of the build by either sending emails or posting results on an internal web site.

Two points of caution were raised: A fast turnaround time was important, otherwise the QA and the engineering team could get out of synch and make bug fixing more difficult. The other point is that bad automation could be worse than no automation.

UML

Only a few people were using some form of UML (about 10%). Most of them were just using it in the initial stages of development to sketch out some ideas and discuss them, but then the models were quickly discarded and not kept up to date. Interestingly, some people were generating UML after the project was complete to pass it along to another team.

Only one person was using many of the UML features (sequence diagrams, use cases, etc), and everybody else was mostly using it for static class design. Several other people reported doing initial design just using “boxes and lines” instead of formal UML, which worked very well for their projects.

Some of the tools people were using were ArgoUML(free and open source), Enterprise Architect, and UMLNotepad (free, open source). Not exactly UML, but several people mentioned Doxygen as a tool to generate some visual representation of the code, which was particularly useful to explore code without existing documentation.

Previous GDC roundtables

• GDC 2003. By the Books: Software Engineering in the Games Industry
• GDC 2002. By the Books: Software Engineering in the Games Industry

Session 1 | Session 2 | Session 3

Thursday 25th: Processes and Methodologies

From the initial discussions and show of hands it was clear the most people did not have one specific methodology that they followed during development. The majority of the participants admitted to using some sort of “code and fix” (or “hack and slash”, depending on the severity) approach. About 20% of the participants claimed to be using a more controlled iterative approach, while only about 6% were doing some form of agile development.

Agile development is a hot topic now and people seem very curious about how it can be adopted for game development since it seems to fit well with the chaotic and ever-changing nature of our industry. The rest of the session covered several aspects of agile development in detail.

SCRUM

SCRUM is a specific agile development process (like its more famous cousin extreme programming). It is best described in the book Agile Software Development with SCRUM by Ken Schawaber and Mike Beedle. SCRUM is not as radical a departure from traditional iterative development as extreme programming, so it might be easier to adopt for more conservative shops. SCRUM is currently being used at Sammy Studios with very positive results (but it has only been in place for slightly over a month). I’m really looking forward to hearing from them next year to see how it worked once they have more experience with it.

Perhaps the most characteristic part of SCRUM is its emphasis on 30-day iterations (called sprints). Like other agile methodologies, it requires small tasks (4-16 hours long), task estimates from the programmers, and continuous re-evaluation and prioritization. Meetings are frequent but very quick (no sitting allowed!). Applied to game development, the priorities for the tasks should come from the designers and the producers.

SCRUM allows for very good project visibility by keeping track of what tasks are completed and which ones are left for each iteration. It also allows to measure the development velocity (how many hours of real programming are done each day), which is invaluable when making estimates and schedules for the next 30-day sprint.

Test-driven development

Test-driven development is an integral part of many agile-development methodologies. For every feature, test-driven development requires that a unit test be written first before the feature is implemented. This is applied to all features of the program, and tests are refactored mercilessly as needed. Some good books on this subject are Test Driven Development: By Example by Kent Beck, and Test Driven Development: A Practical Guide by David Astels.

A surprisingly-high 18% of the participants were doing some form of test-driven development (especially considering that last year only a handful of people were doing any sort of unit testing at all).

The unit tests generated are a great form of regression tests for the code. Whenever anything breaks that has a unit test, you’ll know it right away (assuming the unit tests are executed very frequently). A good rule is that whenever a bug is found, first a test must be written that shows the bug, and only then the bug is fixed. That ensures it won’t pop up again accidentally. Other benefits of test-driven development is that it narrows down where to look for existing bugs, it serves as a form of documentation that can never get out of date, it helps tremendously with refactoring, and it forces a more modular design.

On the down side, it requires a large amount of “extra” code. People reported ratios anywhere from 1:1 to 2:1 of test code to application code. Some systems can be very difficult to test with unit tests, especially high-level systems or non-deterministic ones. Some people were using unit tests that compared the output of the renderer pixel by pixel with previous screenshots for some very specific rendering features.

Extreme programming

Two people in the roundtable were doing full extreme programming, but almost 20% of the people were using one or more features from extreme programming. The best introduction to extreme programming is the white book: Extreme Programming Explained: Embrace Change by Kent Beck.

Pair programming is one of the most controversial extreme programming features. A lot of people were doing it but only at some specific times (like near a milestone). One participant tried doing full pair programming for a small tool project and reported very positive results with it. Some of the advantages listed for pair programming was dissemination of knowledge, and training of junior developers. Interestingly, someone pointed out that pairing an experienced developer with a junior one was often a great combination because you would get the stability of the experienced developer but the fresh ideas and perspectives of the junior one. Just about everybody agreed that pair programming was much more useful than code reviews, which are often too late to do anything about any code problems. Also, pairing with another person could force developers to concentrate for longer periods of time without checking their email, answering the phone, or browsing the web.

Of course, not everybody likes pair programming. Some people feel they can be more productive by themselves, and especially if they are not comfortable with the other person or they think in totally different ways. The final output of two people pairing won’t be 2x the amount of code, but it’s supposed to be more than 2x as reliable (which means less maintenance and bugs down the road).

One interesting question was how to convince management to adopt extreme programming. The best answer was to make sure you don’t use the words extreme programming (and certainly don’t write it eXtreme programming or you’ll be doomed! :-) ). Talk about what specific processes you want to put in place, or even talk about agile development instead. Another view was to start applying some of the techniques of extreme programming without direct management approval, such as test-driven development, refactoring, or pair programming. Showing management a cost-analysis study comparing extreme programming and plain code-and-fix could be another, more direct approach.

Office layout

Extreme programming promotes an open-office environment (the bullpen environment). The possible noise and distractions are supposed to make up for the increase in communication. The participants were clearly divided. Some of them found such an environment very useful (to the point of putting the computers on desks with wheels to arrange things in whichever way made more sense for that particular project), but others wanted to have the peace and quiet of a single office that allows them to concentrate and be productive. Some of the people who had an open environment also had private offices where people could go sometimes when they needed to concentrate more. Finally, nobody seemed to like cubicles very much. They’re almost the worst of both worlds: noisy, but not as open to communication as a fully open environment.

Previous GDC roundtables

• GDC 2003. By the Books: Software Engineering in the Games Industry
• GDC 2002. By the Books: Software Engineering in the Games Industry

Session 1 | Session 2 | Session 3

Friday 26th: Languages and Tools

The vast majority of game developers seem to be using C++. Some reasons cited for using other languages were better integration with their environment (especially for Java and mobile gaming), faster development time with a higher-level language, or the availability of a refactoring browser. C# this year had several people using it for tools development. Some people claimed very positive experiences, but others said that doing managed C++ wrappers around their C++ code was much too cumbersome.

GUI-development APIs

Most people using C++ were also using MFC for building GUI tools. Some of the other GUI APIs mentioned were Qt, Borland Builder, Fox Toolkit, Perl with Tk and Python with wxPython.

Asset management

The tools people were using for asset management were:

• Visual SourceSafe: 40%. Horror stories of constant database corruptions, but it seemed to work (more or less).
• Alienbrain: 40%. People weren’t thrilled with it. Felt too heavy weight. Only good if you use some of the more advanced features.
• CVS: 8%. They were using a small amount of data.
• Perforce: 5%. Artists were happily using the default GUI without any trouble.
• No management at all: 5%. Considering switching to an asset management system.

The amount of data people had in their asset management systems varied between 2GB all the way up to 20 GB. One handheld developer only had 300 KB of assets total. Ah, the old times!

Source code version control

The breakdown for source code was very different than for asset management.

• Perforce: 40%. Most people here were using branching.
• Visual SourceSafe: 36%. Hardly anybody used branching (not a surprise).
• CVS: 20%. Tortoise GUI apparently is very good, although several people were using it through the command line only.
• Accurev: 4%. An interesting two-step check-in is the main difference of this tool.

Unfortunately, nobody was using Subversion, but several people had looked into it in the past. They just released version 1.0 so hopefully next year someone will have tried it.

Documentation

Doxygen was mentioned as a good documentation tool. It creates documents from specially-marked comments in the source code as well as the structure of the source code itself. However, not many people referred to the documents that were generated for the code they were working on. It seems that Doxygen’s primary use was to explore other people’s code or a third-party API.

Nearly 50% of the participants were using some version of Wiki in their development, which is much more than in previous years. People were using it for design documents, coding standards, and tool documentation. Some were even using it with their artists and designers, so it’s not limited to programmers only.

The main advantage of Wiki are that it is a permanent but interactive collaborative medium, so it has more structure than an email thread and it stays there permanently. It makes bringing new people in the team much easier. Some of the most popular Wikis are: Wiki (the original), TWiki, OpenWiki, MoinMoin, and of course, ScrumWiki gets a special mention.

A participant found a plugin for Microsoft Word to create chm (help) files very useful to go from Word documents to online help for the tool. Some other people used Robohelp to create the help files instead.

Some of the tools mentioned to explore the relationships between classes were:

• Understand C++
• TogetherC++
• Rational Rose code analyzer

Finally, a simple yet very effective tool was a simple whiteboard plus a cheap digital camera to capture the output and put it up on an internal web site (either that, or the fancy whiteboards with built-in printer).

Bug Tracking

The majority of the participants were using a bug-tracking program. Some of the ones mentioned were:

• Bugzilla: Ugly but effective and free. Hard to convince management though.
• FogBugz: Simple, lightweight, but limited reports.
• Mantis
• Plain databases
• Many publisher-specific bug-tracking

Some teams reported having conflicts between their own internal bug-tracking system and what the publisher wanted. Some people ended up duplicating entries on both, or only starting to use the publisher one after code complete.

Testing

Many people were doing unit tests this year. Most of them were using some form of XUnit (CppUnit, JUnit, or NUnit mostly). A few people were using CppUnitLite or another, lightweight custom unit-testing framework.

Several teams did some sort of higher-level test on their games. All of these tests were driven with custom scripts in Perl, Python, or some other high-level language. Some of the tests were done with scripting languages internal to the game itself. Some people were playing back input (including random input, aka, the monkey), and some were even using doing networking tests as part of their automated testing.

Previous GDC roundtables

• GDC 2003. By the Books: Software Engineering in the Games Industry
• GDC 2002. By the Books: Software Engineering in the Games Industry