I’m pretty new to this whole video game programming thing and because of that I’ve been asked in a couple of interviews why I want to make games. I think it’s an important enough point to address here.
Large Problem Space
Writing video games means knowing at least a little bit about a whole lot of stuff: graphics, sound, physics, collision detection and response, decision-trees, state machines, animation, UI, character control, camera control, etc. If you are making a game that focuses on a unique mechanic or some kind of real-world modeling you might have to learn a bit about something that isn’t normally included in a game.
For example, when Heather and Phil wrote the design for Glee, they initially decided that they wanted actors in the game to respond to individual instruments in the music. That would have meant diving into the complicated field of music information retrieval. I told them tracking individual instruments would be way too hard but that we could probably track beats. So, we went with that and I spent about a month reading up on beat detection and implementing an algorithm in Processing (which has since been improved upon and incoporated into my audio library for Processing, Minim).
Getting to learn about all these different problem domains and implementing workable solutions (even if they are simplistic, like using only circles for collision detection) is a lot of fun. I love learning about new things and I love it even more when I feel like I have a strong enough grasp on the subject to use it in some meaningful way. Since the problem space will likely change from game to game, it means that there will always be something new to sink my teeth into or an opportunity to revisit a problem that I haven’t thought about for a while.
Pretty Pictures
Games never use the standard Windows GUI. That’s cool. It’s nice to work on something that doesn’t look like every other desktop application. It’s nice to work in 3D where I feel like there’s something to explore out there. It’s nice to just be able to rotate around 3D models, even. Making a game feels so much different than writing a web app or other standard GUI based app. It really changes my relationship to the software.
Interactivity
Games are interactive, but more than that, games are usually highly reactive. A game responds to user input in more ways, and in more unpredictable ways, than a spreadsheet or a word processor or an audio editor. Not only is it a lot of fun to program that reactivity, but it is also a lot of fun to test it, to find the quirks in it, to iron those out, to be surprised by something you’d never imagined happening. It’s a huge payoff to design a procedural animation or actor state system with lots of different behaviors and transition cases and then to see it actually working the way I planned. I mean, it’s way cooler than seeing the chunk of HTML I requested from a web server show up in the place on the page where I wanted it to appear, even if I’m using the AJAX technique to make it happen.
Fun
Games are fun (if they’re good, anyway). I like making something that is fun to use. I like watching other people play the game I’ve made, with a smile on their face. This was really brought home to me at GAMMA 01. I got to see the game I’d programmed up on a big projection screen, vector graphics smiley faces pulsing to the music, being played by all sorts of people. Every time I went by the computer, someone was playing the game and enjoying it. That’s awesome! When I get to work on a game that is commercially released and hopefully get to see people enjoying it in their own homes, investing time in it like I’ve invested time in great games like Katamari Damacy, Guitar Hero, Elebits, and Okami, that’s going to be even more awesome.