Jeff On Games

So, I'm generally disappointed in the state of game journalism and game criticism, but I won't talk about that too much today. It's been harped on by people far more eloquent than me and I don't think it needs to be reiterated. However, last night I got a copy of this month's Game Informer (the one with inFAMOUS on the cover) and I have to say I'm really, really disappointed in one of their articles, one that could have been used to actually provide critical insight into games that both gamers and game developers put up on a pedestal for whatever reason. The article is their Second Annual Sacred Cow Barbecue.

Now, normally, I'd be all for this, but literally, here's their list of Sacred Cows and a basic summary of their complaints about each game:

• Chrono Trigger: The plot is cliché and unbelievable. To quote the article: "Chrono Trigger proves that RPG dorks will buy literally anything, just as long as it's Japanese and doesn't make a lick of sense."
• GoldenEye 007: The graphics suck and the controls are bad (compared to current dual analog controls).
• Gran Turismo (series): It's too realistic. They also didn't like the career mode and lack of online play.
• ESPN NFL 2k5: It's put on a pedestal only because EA stole the rights to all NFL games. It's no better than Madden.
• Half-Life (series): The plot sucks and Gordon Freeman isn't an interesting character. To quote the article: "For a series that's been praised for its great storytelling we sure as hell can't make head or tails of this convoluted collection of sci-fi drivel." Also, no online pay "that's not Counter-Strike or an addon pack," and a one line complaint about physics puzzles.
• Super Smash Bros. (series): All of the game's characters are Nintendo has-beens. To quote the article: "… there are [only] a few characters … that have sold a game in the last 20 years". Also, the game doesn't necessary require skill to win.
• Rez: It's a standard rails shooter with a derivative visual style (of Batlezone and Tron according to GI), derivative gameplay (of other rail shooters) and derivative soundtrack of "generic techno music that even superstar trance hacks like DJ Tiesto and Paul Oakenfold would be embarrassed to spin."

Okay, as a challenge, I'd like my readers to find the actual design flaws that GI points out in any of these games.

Go ahead I'll wait.

That's the thing, GI fails (with the exception of possibly its complaints about ESPN NFL 2k5) to point out any actual design flaws in any of the games it attempts to knock off its high horse, even though every single one of these games has design flaws that can easily suggest that it is over-rated in one way or another. Faulting Gran Turismo for being too realistic or faulting Super Smash Bros for (essentially) implementing rubber-banding mechanics is like faulting comedies for being funny and tragedies for being sad. Faulting Golden Eye for looking like crap compared to modern games or for its bad control scheme compared to the dual analog sticks is like faulting "It's a Wonderful Life" for using old styles of directing and cutting, or faulting pre-Citizen Kane movies for not using post-Citizen Kane conventions. It misses the point of why the game is good in the first place.

If you want to write an article like this, and if you want to actually be taken seriously as a game critic, maybe you should actually think critically about the game instead of finding very small quips that don't actually affect the game in any reasonable way. Chrono Trigger is not considered amazing because of its plot, but because of the way the plot unfolds, the open ended section at the end of the game, and the amount of freedom you're given within the linear plot. Half-Life, similarly, isn't necessarily considered amazing for its story, but for how that story is presented, and how the designers worked around the fact that your character shouldn't talk (as that would break immersion).

And don't even get me started about their complaints about Rez. Faulting each individual component of that game is like faulting a hot fudge sundae because hot fudge and ice cream aren't actually interesting on their own.

Honestly, I feel like this article was simply meant as flame bait, and I'm almost sorry I felt the need to fan the flames. That said, GI is (according to their cover) "The World's #1 Computer & Video Game Magazine" and I wish that I could at least expect that magazine to publish something a little more insightful than what you can get on their forums every day, but I guess that's asking too much.

(Note: The whole point of this post is to get you to join the IGDA Tools SIG, but I don’t get to that until below the fold, so I’ve decided to just push it up front here for those of you that don’t feel like reading my long tools rant. So, instead, please just go join here)

I’m a firm believer in tools.

I actually believe that good tools, provided both internal (from actual tools departments) and externally, are key to the success of any software development company, but especially game companies. I would go so far to say that 80% of any programmer’s job in a game development company is, or at least should be, making tools that make artists, designers, and other programmers happy. These are your engine programmers. They do good work, and they’re very important.

However, there should also be a good number of your programmers who’s *only* job is to keep your artists, designers, and programmers happy. These are your dedicated tools programmers, who do nothing but code and fix tools and process all day. If you don’t have these people, you’re missing out. Why? Think of all the places tools touch, or should touch, in game development and process that don’t actually involve working with your engine.

First, everyone benefits from a good build pipeline. Whether you’re doing continuous integration or not, having fast turnaround on art and code changes is always a good thing. Additionally, if everyone can grab changed assets quickly from central servers, that means work can get underway faster in the morning. The tools to do these types of things are usually available, but if you think an engine programmer (or worse, a producer) is going to go find them you are sorely mistaken. Of course, having that good build pipeline means also having good source control, and usually means having good integration between your source control and your tools for creating and exporting assets. And here, there aren’t usually tools available to you. You have to make them yourself, but the jump in productivity from this type of integration is enormous.

Additionally, programmers need tools themselves, but only the select few will think to make them, and usually only for themselves, on an ad-hoc basis. Deployment scripts, revision / code review change scripts, Visual Studio / WinMerge integration; these are all tools I’ve seen created by fellow programmers at game studios that never get passed around. But even then, there are tools that are incredibly useful that an engine programmer might never get around to. Memory inspectors, automatic bug reporters (and potentially bug collators), output filtering systems, external debug consoles, formal logging / metrics. All of these things are useful for programmers (and, in the case of formal logging, designers), but very few have (or will take) the time to really look into them as possibilities. Not My Job Syndrome.

Lastly, dedicated tools programmers have the time and ability, to keep up to date with the latest tool releases and technologies that people are using for tools in the game industry. This is key, because new concepts (like monkey testing, automatic crash reporting, formal logging / metrics, uses of XML / XSLT) pop up every day, and sometime lead to enormous gains in productivity. Without the time to look into them, engine programmers tend to lean on old technologies, with the “It’s not broke, don’t fix it” mentality. This is dangerous to your productivity, since sometimes it is broke, and your programmers just don’t realize it.

Now, if you feel like I do, or you want to learn more, I highly recommend joining the new(ish) IGDA Tools SIG. The SIG is dedicated to staying on top of best practices for tools development, posting about new tools that are becoming available, and hopefully (eventually) being a great educational and discussion resource for tools developers. If you are interested, I urge you to join. You will not regret it.

So a little while back I asked for your questions on the game industry. Bryan was kind enough to ask two very good questions, both of which are almost too advanced for a breaking in FAQ, and I felt were too important to be pushed to a comment, but they deserve answering, and I apologize for waiting this long to answer them.

The first question:

Some developers cite 60 hour, 6 day a week schedules like they are trying to drive people away from the industry. They speak as if this is acceptable and that only those with true passion for the work can hack it. Am I ignorant in thinking that someone - passionate or otherwise - could not possibly sustain quality output under these conditions? Is this an accurate snapshot of the industry?

This is a hard question to answer. At times, Bryan is absolutely right: it seems like developers cite their long hours in order to drive people away from the industry, and sometimes seem to wear their long hours and tough crunches as "badges of honor" (as one developer I know put it). This is a shame, as it drives perfectly talented individuals away from the industry.

But the question is, is this reality in the game industry, and I'm afraid that the answer is yes, especially if you are new to the industry. Though you don't work those hours constantly, crunches can be pretty brutal, and can last for quite a long time (depending on the company and the game). There's definitely a reason that the game industry has something like a forty percent burn out rate within five years. Think about it. That means if you're sitting in a hall of developers new to the industry, look to your left, then look to your right, one of those people will not be in the industry in 5 years.

However, I will say that many companies and individuals are trying to correct this. Any company that has a CEO or lead developer on or active in the IGDA Quality of Life SIG is one where these types of hours will not be the norm. Some studios that run scrums do so because they want to avoid long periods of crunch. But, understandably, sometimes these studios are hard to get jobs at, because they attract some very talented individuals that understand, like you do, that these types of crunch to more to hurt productivity than help it. However, if you can join a company that knows how to avoid crunch, balancing the rest of your life becomes fairly easy.

As a final point, I will say that you absolutely need some sort of passion to be in the game industry, though not necessarily for games (you can be passionate just about writing really clean SPU code like some people I know), and not necessarily because of the long hours you’re going to have to work. Really, you need passion because 90% of the work in the game industry is just as tedious and monotonous as work in other high tech disciplines, except that your pay will be lower, your benefits will be lower and customers tend to be pretty ruthless. If you can ignore all of that, working in the game industry is pretty damn awesome.

The second question:

How does it start for most developers? Specifically people today. Obviously we have not been making games for our Commodore since we were 8. Do most come from other disciplines with experience in related fields? Are most newbies (to the industry) today fresh out of college, eager to show their talents?

So, interesting story. I’ve been talking with my co-workers and other Boston game industry people for a while and they like telling stories about some of the geeky things they did when they were younger (from programming to electrical engineering, to whatever). Now, I’ve always been interested in games, but I didn’t really get into programming until late high school, and I didn’t really make a game until college. So, I’m evidence that you don’t necessarily have to program the Commodore since you were 8 to become a productive member of the game industry. That said, I wish I had some of those stories (a failed RPG maker game is about as cool as my stories get).

However, now more than ever, you have to start looking early for game industry jobs, because entry level jobs become more and more rare as time goes on. When you hit college, you should start networking, get to know people, and start feeling your way around the industry. Additionally, start making games, and (if you can) find other people to make games with, especially if you’re not at a college or university that has a games program (this is common advice that I give to everyone). If you wait to start networking and wait to start actually making games, it will be harder to find a game industry job as a “newbie.” If you take a job elsewhere, you’ll find it hard to make the time to make games after college, and, even if you do, you may find it harder to adjust to the inevitable pay drop (note this pay drop is programmer centric, artists I’m told get paid very well in the game industry compared to other industries). Basically, the idea is to take the time when you have it (in college) and take the risks when you’re young. Show that you are interested in the game industry early. By waiting, you just make it harder for yourself.

Hopefully that helps with your question. If you have any more, please feel free to post them!

The 2007 Game Career Guide issue of Game Developer magazine is out, and a nice digital version is available for download. I actually wrote one of the articles for this in the Top 10 Tips section for programmers looking to get into the game industry. Now, the tips in the guide are pretty generic, and really aimed at a high school / starting college demographic. However, if you're in that audience I totally suggest you give it a read. It can only help.

When I was writing the tips, I actually thought of a whole bunch of others that I wish I had known just coming out of college and looking for a game job (or when I was looking after a year as a government contractor). I thought about putting these tips in, but they were really for a completely different audience (namely, me 3 years ago) and partially politically charged. So, I left them out, made the article advice more focused and generic, and decided when the article came out I'd post the other tips to my blog. They make better blog fodder anyway.

So here’s a few tips for those of you that are about to take that first job in the game industry. This is from personal experience and a few years of misery in the game industry, and it should all be taken with a grain of salt.

1. Know you development style, and know the company’s as well. Before you commit to working for a company, know how they work. If you’re a stickler for process (like myself) make sure you know whether the company you’re about to work for is as well, or if they’re willing to adjust to become so. If you’re more the “get things done” type, besides being doomed in the long run, you shouldn’t go to work a place advertising that they’re full agile, full XP. Granted, working there might do you some good.
2. Don’t undersell yourself. Money isn’t everything, but being underpaid really sucks, regardless of nebulous bonuses that are promised (Note: I was underpaid in the IT world way before I went into the game industry, so this really applies across the board). Know what other people are making in the industry in your area. Know what you’ll need to live comfortably on, and know how skilled you are. You’ll be thankful later.
3. Always improve. After you get your first game job, don’t think you can coast around on easy street. Don’t ignore new technologies coming out (outside of games too guys), because you never know how much you could improve things at a company just by paying attention to advances in things like .NET and database development
4. Know what you’re getting into. Make sure your significant other knows too. Crunch sucks. And it’s almost everywhere in the game industry. Avoid places that have horrible crunches (very hard) or make sure your significant other knows that there will be months at a time where you might not see each other. It’s sad, but a reality.
5. Know the company’s stance on conferences. If you’re the type of person that likes going to GDC and likes talking at GDC (like me), know whether your company will allow you to do that. Also find out what they’ll reimburse you for, and what they won’t. You don’t want to find out a month before GDC that they don’t want you going. That just sucks.

Now, this advice is kinda slanted toward people that have a lot of confidence in having a lot of offers in the industry (which doesn’t happen often), but following this advice will at least let you know what you’re getting into before you jump in and become miserable.

Edit: An executable version of Sort is now available on my site here. There are some bungs in it still, but I'm going to try to get them out soon as I develop the game past the prototype state.

Last weekend, I participated in the OLPC Game Jam, working on games that would run on their XO platform. We were given three days to write a game in PyGame, and considering I'd never used python or PyGame before that Friday I thought I did pretty well.

The game I created was called Sort: a gesture based game about sorting shapes for points. The best way it was described at the Jam was "a combination of Zoop and Set," which I felt captured it nicely. If there are any problems with the game (besides the programming bugs I mean), it's that there's little to know feedback on how you're doing. One of the requirements of coding for the XO is you shouldn't use text (because of localization issues), which made scoring feedback hard. I also didn't have time to integrate backgrounds (to show you where you were when you focus various piles) so was kind of bad too. If anything went right, it was definitely the control scheme. It felt good to gesture towards a pile and have the shape move there, and it worked really well on the XO (and would on any touch pad really), so I'm generally proud of what I created.

A few programming thoughts about programming in Python. First, I will never get used to the whitespace being significant. This is personal preference, and it wouldn't keep me from programming in the language again, but I still have problems with it.

Second, Python's implementation of (what amounts to) duck typing, helps a lot when you're coding fast and don't want to have to go back and program interfaces. That said, I'd (personally) rather have the compiled language that will tell me when I've passed a type wrong. I just make those mistakes way too often, and I hate having to wait until I've hit that particular part of the code during a test run to have it fail. I fall into the category of people that prefer compile time errors to run time errors. I alway compile everything at high warning levels, I try to remove all warnings, and I do my best to make sure all of my functions are as type safe as possible. No casting from void* and the like. So, moving to a language where there are no compiler errors was really a complete change in philosophy for me, and it was tough. That said, it's awesome for a scripting language.

So, given thoughts on Python, yes I like it, and I think it's great as a prototyping language, especially with PyGame. But, I think I like Ruby as a scripting language better, and I'll take C++ or C# over it when I'm working on a big project any day. No offense to python, it just all comes down to personal preference.

By the way, if people are interested, I"m probably going to continue working on Sort, to "finish" the prototype at least. After that, I may look into making versions for a few platforms (including my phone maybe?). I'll also try to get an .exe version on my site soon so people that don't want to download python and the various modules I used can play it.

I know I promised these slides on Monday, but I was busy driving (yes, driving) back from Orlando and it totally slipped my mind. However, better late than never, so the updated slides are now available. There were only a few minor changes to this talk, mostly just in explanations of some of the patterns, as well as an additional slide explaining why engineering is important. Other than that, pretty much the same.

GDC is coming up. I'll have much to say about it afterward. By the way, if you are not subscribed to it already, I highly recommend reading the ScholarBlog. It's a blog I started 3 years ago for the IGDA GDC Scholars to write about their experiences at GDC. Although not as rife with content as I would like, we've gotten a few people to volunteer this year, and I'm hoping they'll supply some interesting insight into the life of a GDC Scholar.

I’m giving a talk at Full Sail this Friday, similar to the one I gave to UMD a few months ago. I’m fixing a few flow issues in the talk as well as adding a bunch of clarification and explanation, especially to the design pattern section of the talk, which can get very confusing as it currently stands. I will post the revised slides once I get back from Florida, so expect them around Monday.

Additionally, GDC is coming up in just two weeks, and I will definitely be there. Darius and I agree that GDC is definitely the best week of the year (at least professionally). I always learn a ton going to GDC, though not necessarily from the talks (the two day tutorials excepted). The talks are there (at least for me) to give me a few things:

1. A broad overview of a topic I am completely unfamiliar with, and I don’t expect to leave these talks with ability to actually implement them. The talks on rapid prototyping, test driven development and agile project management were those for me last year.
2. A set of pointers explaining how I can do something I already do better. Microsoft’s talks on concurrency and memory management were that for me last year.
3. A broad understanding of the state of the industry and where it’s going in the future. EGW (in some respects), talks from big console developers and middleware providers, the Burning Down the House sessions, and just the general atmosphere are those talks for me.

Certainly there are other talks that don’t fit in to these categories, but this is generally how I divide up GDC.

I think though, that where GDC really shines is the ability to hang out with other professionals. Just by sitting around and talking to other developers about their development problems, there’s kind of this knowledge osmosis that occurs, and it’s totally worth going just for this (if you can afford the pass, or are lucky enough to speak). Hopefully I’ll be able to meet some of you (the few that I haven’t already) there. Be sure to leave a comment and let me know you’re going. It’s going to be a great week!

Shashdot is reporting about the Gamasutra questions of the week concerning the possibility of a video game Oscars. Thankfully, the question of the week had a few mentions of the GDCAs, though mostly from people I know (Darius is quoted, as well as Coray).

I think probably the best comment in the whole thing comes from Ben Hoyt:

Perhaps the most fundamental difference between our industry and those for which these awards shows are more successful, is this that these industries can legitimately claim to have "an Academy" that represents it. To do that, one of these organizations (IGDA, AIAS, perhaps another), must offer a package of services that makes membership worthwhile, while also limiting that membership to truly qualified professionals. Only then will such an organization be able to really claim that it speaks with a voice that represents the opinions of the people who make games.

I have to agree with Ben here. The IGDA tries, but in my mind it still can't really say that it is the definitive voice for of developers with "only" about 10,000 members (though I will say, that number is pretty awesome). I do think, though, that this is changing as the organization grows both through the IGDA's own efforts and through the evangelism of some of its members. Furthermore, as more and more student and independent members, some of whom are very active and very strongly believe in the mission of the IGDA, begin to grow into their positions as professional game developers, that 10,000 number begins to get more slanted toward the true voice of developers. I know many student members or simply "unsigned" members that over the past few years have joined the rank of the professional, and are still just as evangelical about the IGDA as the were when they started. This is good, I think, and it can only get better.

Going back to award shows, there are two (serious) shows that are mentioned in the Gamasutra article: the GDCAs and the DICE awards. I could go into the reasons I personally like the IGDA over the AIAS generally, but in terms of awards, there's one major reason: take a look at the nominee list for the IGDA over the AIAS. Notice anything missing from the AIAS awards? How about the actual people responsible? Jason made a post about this, which is why it's fresh in my mind, but I think it's important. It's like this quote from the Gamasutra article (which I actually whole heartedly agree with):

The industry needs to starting approaching public relations by identifying individuals associated with the creative process of electronic games. Get Tim Schafer on Conan O'Brian. Get Will Wright on the Today show. Once the public starts identifying individuals with the electronic game industry, more clout for an awards ceremony for the industry would exist.
-John Seggerson

Although many game developers would reply with "but I don't want to be famous" (or as I've overheard Warren say (paraphrased), "there's nothing more ironic about fame in an industry that wants to take control away from the creators.") but, really, we need to put a more human face on game development. It doesn't matter that, in reality, a whole team made a game. A whole team makes a movie, but only the actors and the directors go on the press tours. What's wrong with your EP or designer going on the press tour? He's selling "your" game! More people will see "your" work! It's a good thing! Anyway, that's what I think.

As it stands, I think the IGDA will eventually "win" the awards "battle," for one very good reason: for the IGDA, the GDCAs are a means to an end, for AIAS, DICE is the end. It's labeled quite clearly in their respective goals:

AIAS:

Recognize outstanding achievement in interactive content and the entertainment software community.
Conduct an annual awards show and enhance the image and awareness of entertainment software.

IGDA:

To increase the recognition and respect of game developers and the art form of games.

Personally, I'm glad I'm with the organization that looks to gain respect for the developers and their art form, rather than the one that's mostly interested in the end content.