Category Archives: Philosophy

IGDA GameCafé Report

IGDA, Philosophy, Video Games

Last night I attended the second GameCafé held by the Montréal chapter of the IGDA. Due to the fact that people who ordered food received it a little bit later than anticipated, discussions started an hour late, which meant I spent most of that hour listening to Phil and Antoine trade quotes from Anchorman.

Jason Della Rocca, the IGDA’s executive director, preambled the discussions by relating a recent exchange he had with Jack Thompson, an infamous anti-games attorney, who called him an idiot and a jackass on MSNBC. This was apparently in response to Jason calling him out as a massacre chaser. Anyway, you should check out Jason’s post about his e-mail exchanges with Thompson, for the full story.

Industry discussion notes.The discussions I took part part in were decent, for the most part. Digital Distribution was once again lauded as the exciting new business model that will enable indie developers to carve out a niche in the marketplace, but that super publishers like EA will continue to dominate in the retail sector. *yawn*

Micropayments were mentioned and someone pointed out that Asia is way ahead of the West in this regard. Apparently they have made it exceedingly easy to pay with plastic over there, even going so far as to build card readers directly into laptops. This is pretty interesting to me and I wonder when/if it’ll catch on in the West.

Studio discussion notes. At the table about Studio level Future of Work, there was discussion about whether teams that are geographically separated and communicate only over the internet will become more common in game development. The consensus seemed to be that it could work, but meeting in person at least once goes a long way towards creating team cohesion.

I’m a big fan of long-distance collaborating. I’ve made songs with people I’ve never even met in person. However, I think that with music the medium itself is a kind of communication. It is, in fact, easier to understand what someone is going for if they just record a bit of music than if they try to describe it in words. I think this falls apart a bit when dealing with a game because it is audio/visual/interactive; there is no single medium that can act as an intention carrier. For this reason, it seems to me there will always be the need for teams to work in the same physical space. I find that when I’m trying to figure out a programming problem, it really helps to talk it through with someone in person.

Career discussion notes. At the Career discussion table I felt like there was a bit too much focus on working in a studio. But good things were said about how people tend to be happier when they are busy, even if they are not super thrilled about the game they are working on. On the other hand, if it is clear to everyone that their game sucks, it can be really demoralizing. I floated the idea that studios ought to work it out so that when people finish a project, they just get a week or two of paid time off so that they can recover and be ready for the next project. The way it is right now, people are typically pushed onto a new team immediately after finishing a project, even if the new team doesn’t need them right away. Much twiddling of thumbs follows and people get bored and restless. The only difference from paid time off is that they are required to come in to work and occupy a chair. It was mentioned that at least one game developer in Montréal is trying to implement some training programs, so that people can work on improving their skills during downtime, which sounds like an excellent idea to me, but that it’s not very organized yet.

There were many comparisons to the movie industry made during table discussions and also in the final roomwide discussion at the end. This seems to happen every time developers get together to talk about making games. It’s usually mentioned that the game industry is young and is similar to the movie industry of the early 20th century, mimicing the studio model. This comparison is then used to speculate about the future of how work will be parceled out (i.e. outsourcing) and whether that will be good for the industry. People will point to the movie industry and hold up independent film as proof that a change in the distribution of work can only be good, but I’m not so sure I buy that.

Making games is complicated. Possibly more complicated than making a feature film. Part of that is due to the lack of really good high-level tools for making games, but I think part of it is also inherent to the medium. One can view film production as a series of discrete processes: write the script, shoot the footage, edit the film, apply special effects, record the score and foley. Each of these activities can happen pretty much independently of the others. Also, there is usually no going backward. People don’t often decide to shoot more footage once they are in the editing process. Games don’t really work this way. You can’t really decide if your gameplay is any good until you actually implement it and play the game a bit. So you can’t really separate the design of the gameplay (i.e. scriptwriting) from the implementation of the gameplay (i.e. editing?). You see how my analogy is already falling apart? I think developers would do well to stop thinking about how they need to catch up with the film world in terms of work flow and process and what have you, and start focusing on what is good for the medium of games, specifically. No one knows better how games are made than the people who are making them.

Why Make Video Games?

Philosophy

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.