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!