The Last Mile is Hard. #Gamedev
Big video games take forever to make. In the time it takes to start and finish a AAA project, you can get a university degree, or make a baby and watch it grow and start walking. In that same amount of time, people can gain or lose 200 lbs, or start a business and sell it. A lot of stuff happens in the time it typically takes to make and ship a polished AAA game.
Because life happens, the team working on a game as it goes into the polish and debug phase is not the same team with which you started the project. People’s priorities and passions have shifted. The core experience of the game was not the same a year ago as it is now. The story is different. Content has evolved. Some features will probably have been cut. Systems that were supposed to do X might be seriously under-developed compared to their original vision or intent.
Closing a game is hard work. You’re 90% finished but now you have to walk the last mile, closing bugs, and selecting which polish tasks to do because the deadline is coming. Choices will need to be made, and working smart is important.
Polish is mostly not for “New Ideas”
A polished weak idea is typically much better at this point in game production than a new good idea. The weaker idea has probably been tested, had a few bugs closed. Maybe focus groups have shared their opinion on how [weaker idea] impacted their gaming experience. You can polish a component you know well.
Actual new ideas may or may not work out, leaving you with potentially more bugs, clashes with other systems, or a fun-factor that is hypothetical and may take weeks to improve. New ideas should be seen as risks.
In the Last Mile, what we want are reliable results. Even if the user experience of the hat-crafting system isn’t wicked good, it’s probably better to improve and make tiny tweaks to a known component, rather than try to re-invent the feature.
Triple AAA literally means: The good parts of this game are really good, and the rest doesn’t contain too much suck. Polish is about smoothing out player frustrations, highlighting cool things, and nerfing the impact of things that kinda suck.
Debugging Is Not Ever Only Two Months’ Work
Polish tasks tend to set at high priority (because it’s way more fun to talk about improvements than bugs), but debug is what makes your game suck or not suck. Consistent player experience is produced by finding, tagging, and fixing thousands of bugs. The smaller and more trivial bugs become: the better for your players.
Teams only have a chance of grinding that list down to low-impact bugs if they spend a lot of time in full-blown, don’t-do-anything-else, debug.
Doing final debug is hard work and requires disciplined organization. This is true for a lot of reasons, mostly that fixing high priority bugs often involves large code or data changes that leave hundreds of smaller bugs spiraling in their wake. Things break. Cleanup and code and data stabilization takes time.
Time needed for debug can be predicted by reviewing how the team handled previous deadlines. If last-minute changes and a lack of planning impacted game quality on previous milestones, it will happen again unless you work with all departments to create a plan where people switch from polish to debug on a clear schedule. Code and data cannot submit changes on the same deadline. Player controls and movement should lock before tutorials and missions, and AI should lock either after or before story missions, but not all departments can all share a deadline without impacting each other’s work in unpredictable ways.
Trust Your Passion
As the project grinds towards the Last Mile, your team will be tired. People start looking forward to the end; they know it’s almost over. And just like running a race or crushing your workout: you should not quit until you’ve done everything you can.
(As a director, I count on other people to tell me that it’s time for me to go away because we’re transitioning to debug and creatively the work is done. It’s never easy to leave friends still working, but the fact is: at a certain point I don’t add value — my teams don’t need me to tell them how to close bugs.)
I make big games; I’m always conscious of the fact that at some point literally millions of people are going to play what the team has created together.
Our players will not know or care that one mission or one level is buggy because the guy who was supposed to help with that part of the game world was sick for two weeks, or that the mission that’s kinda too hard for most people is because of an AI bug that we didn’t have time to deal with. Once the game is live, there are no excuses, however reasonable.
Trust the passion that brought you into games in the first place, put the gas pedal down, and make something great.
