Iteration

Game development is all about iteration.  It’s very clear that the best games are almost always the most iterated.  This is accomplished through tools and engine tech that enables iteration.  The more times you get to touch a level or  a mechanic, or an asset, the better it feels, plays or looks.  I’ve talked before about how if someone can’t iterate something, they can’t own it. I’ve recently realized that there is more to it than that. 

It is true, that if you can’t iterate something in the game, you can’t own it.  But even more, if you can’t effectively iterate something then you can’t own it.  I don’t mean you shouldn’t own it, from an organizational perspective, or a philosophical perspective.

I mean, literally, that you can’t own it.  Whatever the agreement within the group, whatever people tell you, you actually cannot own the piece of game you think you own if you can’t effectively iterate it. 

What do I mean by effectively?  This is the “fluffy” part of the idea, I will admit, and it will change from team to team. Basically the more expert the team, the more high quality the team expects the product to be, the more effective each member needs to be at iterating their part of the game.  If you’re a bunch of high school students messing around with Unity trying to make a first person shooter, then no one is going to be that effective, unless you have some kind of super genius in your group.  If you’re a level designer at Infinity Ward, you’d better be able to make intelligent changes quickly in a positive direction to your level, since that’s basically your job.

For instance, I can’t really own a mission in a  AAA open world game.  I don’t really have the skills to be effective when making changes to the mission.  I can observe and make gross changes that keep the player from getting lost or dying over and over, but I won’t be able to make smart subtle changes that quietly guide the player to success or properly leverage whatever sandbox mechanics my open world game has.  I’m a good programmer.  I think of myself as a reasonably good game designer, but I’m not a professional mission designer, and while I might have some talent in that area, I don’t have enough skill to be effective right now.  Not to say I could never be effective, but if I’m a member of a AAA team, I need to be effective immediately.

So this seems pretty good, if you can effectively iterate part of a game, then you can own it, right?  Not so fast.

The problem with game teams is that they’re full of people.  And just because you can  do  a job, doesn’t mean everyone agrees that it’s your job.  So if you don’t have buy-in from the team that you’re meant to own the part of the game you’re trying to iterate, all the work you’ve done will likely be thrown away because someone the team considers to be the “owner” of the feature might not like what you’ve done, or might even be offended that you were working on something they considered that they owned.  So in order to own something in a game, you need to be able to effectively iterate it, and you must also have agreement from the team that you own it.

So what happens when the team thinks that someone owns something, but they can’t effectively iterate it, who owns it then?  No one.  Which is a pretty crappy place to be on a piece of game.  If the effective iterator isn’t allowed to own the game, it can be incredibly frustrating. Similarly, if the person who supposedly owns the feature or piece of the game isn’t able to be effective in iterating it, that can be incredibly disheartening for the individual and anyone else touching that piece of game.

So who’s the gatekeeper on this?  Who makes sure the right people own the right work?  Mainly management.  Each discipline’s management should ensure that the people working on the parts of the game are being effective in their iteration, and production needs to ensure the right people are working on the right things.   This isn’t generally a problem one finds in art.  Usually the difference is clear when it comes to artwork.  Though even in art there are points of contention.  Who writes shaders?  The technical artist?  The graphics programmer?  Obviously it depends on the team and the engine, but even this seemingly clear distinction can get a little muddy.  What if you have a super genius graphics programmer who can write any shader, but has no sense of what looks good?  Get the programmer to build a system that can be iterated easily by artists.

When it comes to design and code it gets incredibly muddy.  Partly because so much of design basically is programming, even if it’s not in the native language the game engine is using, and also because “design” as a discipline is poorly defined and understood throughout the game industry.  The current rule of thumb I’m trying to go with is if a programmer is unable to effectively iterate the mechanic, a programmer must provide tools for a designer to do so.  When the programmer is iterating the mechanic him or herself, then the programmer is basically a programmer/designer, and I think that should be fine.  If you have an incredibly fast hotshot programmer with zero design sense or desire to understand game design better, that programmer needs to provide clear, usable interfaces for a designer who has the necessary skills to be able to effectively iterate the game.  The iteration loop needs to be tight.  The designer should not have to come to the programmer for iteration, the designer needs to be able to iterate him or herself.  Long iteration loops can completely kill momentum or prevent it from ever starting in the first place.  Clearly there will be some give and take, and the programmer has to implement new features the designer needs when the designer needs them, but this can’t be things like tweaking constants, this has to be the programmer actually adding a real feature.

If you’ve gotten this far, congratulations!  Granted I’m probably only congratulating myself.  I love talking about game development, and I was thinking about this stuff so I wanted to get a bit of it down. Thanks for reading!

GDC 2007

This year's GDC was very valuable to me. It was great to meet more Bioware and Pandemic Australia folks. Project Bravo sounds very cool, and it sounds like they have a fantastic team working on it. The dinner was nice, and getting to see Mass Effect was great, I'm really excited to play it. Some notes on some of the stuff I saw.


Playstation 3

Since I'm going to be starting PS3 development soon, I focused mainly on Sony's PS3 talks. I actually came away very impressed. Going into GDC I had assumed that the PS3 was barely more powerful than the 360 on the CPU side and definitely slower on the GPU side. I'm still pretty sure the 360 GPU is quite a bit better (mainly due to shared memory and processors), however I'm now fairly convinced that the PS3 CPU is quite a bit faster than the 360. After seeing the Edge demo and hearing some of the statistics it's pretty clear that you'll be able to do quite a few things on the PS3 that the 360 will likely be too slow for. Unfortunately for Sony, this seems to only be very useful for first party teams. Third party teams will likely end up with better looking 360 games due to availability of memory and extra graphics card power. Edge does look fantastic, however.

Sony Keynote

The Sony keynote was entertaining, if not totally relevant to developers. It really felt like an E3 keynote, not much about actual development or the development process. I'm going to reserve judgement on the Home stuff, but at this time it seems kind of annoying, I'd rather just use menus, I think.

I think people are kind of underestimating what's going on with SingStar PS3, because people aren't really talking about it, but this product could be huge. It has very broad appeal and a youtube like quality with the availability of uploading videos. Also having a song store that you can buy any song from could be a huge positive for Sony. Particularly since their parent company owns a record label.

Little Big Planet looks absolutely fantastic. I can't wait to mess around with this game. Great graphics, interesting gameplay, the ability to create my own content? Where do I sign up? And it looked like a lot of fun, too. Sony, Please don't let me down.

Miyamoto Keynote

The Miyamoto keynote was interesting, if perhaps overly long. I was also disappointed by the way the GDC people handled these "big talks". They didn't allow people to go straight in and wait for the talk, but instead opted to create a huge line that ended up having the same effect. The first people in ended up getting the best seats.

That aside, it was an interesting keynote. There was no information about new nintendo products (which I enjoyed), and he mainly talked a lot about Nintendo's business strategy and his own personal vision for making games. It was an interesting talk, but there wasn't a huge amount of new information. Miaymoto is a very engaging speaker (though it was translated), and he showed an amazing facility with the wii remote (which he used for his slideshow).

Odds and Ends

All in all, it was a great experience, I love San Francisco, and I was really glad to have the opportunity to attend this year's Game Developer's Conference. Even if I hadn't learned anything from the sessions (I did), I would have really enjoyed networking with the people from Pandemic and Bioware and just experiencing the event.

Protoyping is Underrated

Maybe underrated is the wrong word. Underutilized? I'm not going to say that prototyping is the silver bullet that will save the game industry from itself, but man, it sure can help. The ability to think, talk, act, and decide upon things based on decisions made while actually playing the game versus trying the same things when all you've done is thought about the game is just very powerful. How can you really decide that something sucks when you haven't even tried it? Some ideas are just obviously unfeasible or just plain don't sound like fun, but there are plenty of things that only show up once they're partially implemented.

A lot of companies pay lip service to prototyping but actually end up just implementing things too fast. And frequently gameplay can be one of the last things to be implemented. Having something up and playable is rarely as high a priority as prety graphics, this is somewhat understandable due to the fickle market that seems to be easily swayed by graphics, thus causing publishers to depend on graphics as a selling point and making it more difficult to sell them on gameplay alone.

And let's face it, fantastic gameplay with crappy graphics will rarely sell huge copies unless there is something truly amazing, new, and different (witness Wii). Even then it's unlikely. How many "fantastic" games do hardcore gamers lament as being killed due to an ignorant or immature marketplace. So yeah, prototyping is a tough sell to a manager of a game studio.

But it's really important to sell it.

I think it's the difference between a crap game and a mediocre game, a mediocre game and a good game, and a good game and a great game. It's the difference between spending time, money, and manpower on something that's not worthwhile and saving your resources for what really works. It's the difference between long masturbatory discussions about "big ideas" and hard nosed, nitty-gritty discussions about what's working and what isn't.

So now that prototyping seems to be A Good Thing, how do you do it? Normally a game team consists of artists, programmers and designers. Designers is a pretty broad term, usually this refers to level designers and mission builders. Programmers control the functionality of the game. They're the ones who do the implementation. If a programmer has game design or visual inklings or can be trusted to properly iterate a system, it's probably smart to have them be the driving force behind prototyping the feature. Some programmers don't have this inclination and are still useful to have to implement things, so in that case, the programmer should be paired with a designer or artist depending on the feature. This way a programmer can implement the base functionality and the designer or artist can then take what's there and tweak it and ask for different or more functionality. An example of this could be a skin shader that a game needs to make a character look right, and a programmer who isn't that visually inclined. That programmer could go to an artist, show him or her what it looks like, and expose parameters in the 3d modelling package for the artist to use to make the shader look right, the artist could also ask for different looks to the shader, which the programmer would have to then go and implement.

The same could be done with a design feature, a programmer could implement a drivable vehicle and expose a bunch of tuning parameters, and a designer could step in and tune the parameters to make the vehicle "fun", and thus be the driving force behind the prototyping.

The one constant rule is whomever is actually doing the prototyping is in control of the feature. Having a document written up for a programmer to then "follow" is not prototyping. One gets a feature into the mindshare of the team, gets it implemented by a programmer, and then either the programmer iterates on it, or exposes values for other teams to use for iteration. No one is reading a document and implementing, because whatever is in the document isn't as good as what can be implemented. Period. Long, detailed design docs that aren't a product of prototyping are by and large masturbation.

Anything too difficult to prototype as a game mechanic is very likely too risky to implment in the game, and so should seriously be considered for cutting, even during preproduction. Prototyping should be able to come before technology. If there isn't enough technology to prototype, then the team should be reduced in size until there are enough programmers to build an engine for prototyping and enough artists to support the engine efforts, or an engine should be licenced that allows prototyping. There should be no designers on a team like this. Unless they can prototype in some other, existing game engine while the other departments are working. Having a team of people churning out documents that no one will read is an incredible waste of time. Even if people do read them, they're usually not well-considered enough to be actual gameplay features.

Agile development seems to be a good way to go about prototyping with a focus on refactoring. Early prototypes should be hacked in to get the feature visible to the various departments, and then refactoring should be used to ensure the code stays maintainable. Unit tests may also prove useful in this endeavor. This relies on a very good prioritization of features, however. Without a strong list of features with a good prioritization, you'll end up prototyping the wrong things first.

In the future, as game projects become so expensive that any wasted time or effort is a huge blow to the product's success, I think prototyping will become the difference between a successful team and a failing team. Prototyping shows the compromises that will have to be made early, and it shows the best parts of your game early. It saves tons of time, effort, and money. It's just the right thing to do.

Innovation is Overrated

I'm a game developer, and I used to frequent several game forums that I had read before I entered the game industry. One of the common topics in game forums has to do with innovation in games. Both bemoaning the lack of innovation in major games and celebrating small indie games that innovate SOMETHING for God's sake!

Personally I don't think game mechanic innovation is usually all that necessary. Give me a well-executed polished, by the numbers, game almost any time. The core design still needs to be solid, and if innovations have been made that your game has completely ignored, I might take issue. But overall give me Halo2 before Indigo Prophecy any day. I'd rather see a game that executes fully on all of its goals and manages to create a fun experience than see something that I haven't seen before but is done poorly.

This isn't a topic reserved for game enthusiasts, game professionals also fall into the innovate or die trap. It happens all the time where there are a ton of "shoot for the sky" feature requests, and not enough attention is being paid to the core gameplay.

This is not to say that innovation is bad, I think innovation can be fantastic, especially when well executed. I just think it's overrated. I'd much rather see execution than innovation.