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.

[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!

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.

Spring was supposed to be the season of flowers, new leaves, and good weather returning. Here in San Diego we don’t get much of that, or rather, we get it all year around. So Spring can really sneak up on you, and before you realize it, it’s already gone. Spring also seems to be the season for game-development conferences and travel: just a few weeks apart we get Sony’s conference, Microsoft’s, and, of course, GDC. I’m not even going to count Dice and E3, also happening around the same time.

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.

The SIGGRAPH conference continues to evolve with the times. Ten or fifteen years ago, it was very academically driven, solving problems that nobody had solved before just for the sake of doing something different or more realistic. Today, SIGGRAPH has a much more pragmatic character. Most solutions and techniques presented have been developed out of a need for movie rendering, model authoring and manipulation, or even real-time graphics applications. At the same time, SIGGRAPH has retained the same rigorous background that it always had, making it quite a change from what we’re used to in game development.

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.