Seeing Polished Work = Motivation

March 21, 2008 12:43 am Sir Haxington Game Development

This is pretty straight forward, but creating something for your game and bringing it to a finished, shippable state is the only way to go.

“But Jesse, we don’t have time to get it finished! We need to just get it working and move on!”

Bzzzzt. I’ve seen it time and time again. We’ll create some half-baked prototype feature, get an event “working,” put in a temp animation, or place a temp texture. Then, people on the team will start complaing about it, laughing about it, or whatever. Placeholders tend to stay in the game for way to long, and it starts demotivating people. It’s really hard for people, even those working on the game everyday, to see past temporary and placeholder assets. And that’s really bad for team morale. Above all, everyone on the team should believe in the game you’re working on, and placeholders won’t help with that.

Okay, not all holders are bad. I think in some cases, if they look really close to final, that’s an okay thing, especially if you’re placeholdering for memory concerns. I think this is espeiclaly true for sound and VO. However, really bad, or even medicore placeholders will damage team morale, and I think hurt the overall quality of the game in the long run.

The proof is in the pudding. Latley, we’ve not been using as many placeholders and simply getting everyone on the team to bring things to completion. You can see and feel the difference everyday. People are more excited about the game because they can see the end result now. They’re not imagining what the guy will look like when an AI jumps off a ledge and stabs a guy, or seeing two guys t-posing into each other with “placeholder” written accoss their chest. They are seeing the final model of the guy stab the other final model of the guy with the final animation and it looks awesome. On top of that, andy little issues that come up are fixed immediately because the problems are immediately seen. We’re no longer predicting what problems might arise “if we do it this way.”

One last thing to add, is that finishing things rather than layering is much better according to Joel Spolsky, who wrote an awesome book, “Joel on Software” which everyone should read if you work in the games industry. One concept he drives home is to fix problems as they arise and fix problems before moving onto the next problem. The reason is that if you move on, all the variables you have stored in your short-term memory about the problem, feature, or issue will go away once you move on. So, if you “task switch,” then you’ll end up having to re-learn how to solve your problem later, which will take way more time than if you just fixed it in the first place. That time could be spent fixing other bugs later, adding more polish to the game, or even implementing a new feature. All that extra time adds up. Just remember that next time you’re at work until four in the morning fixing a problem you should have fixed weeks or months ago.

So there you have it. Finish first, then move on. I can’t imagine doing it any other way. If you don’t then I feel sorry for you.