Saturday, October 13, 2012

Changes, pain, process

A big part of games development is the constantly changing design. To think you can build a game from a design document given to you on day one and work your way through it until you reach feature complete on some distant day long away with no interruptions is the illusion not just held by publishers but the illusion that is the root cause of overtime and underappreciation in our industry.

For some reason, publishers still expect development companies to produce precisely what they presented in initial meetings. For some reason they also think that research and development can be estimated with tiny margins for error and the black-swan effect will never hit them.

This is one of the reasons companies like Rockstar are great. They don't have milestones for some arbitrary features laid out in some design document that defines whether you get your milestone payment. They just do what needs to be done to make a game great until the game is great enough to sell and then they finish it and sell it.

This is what makes working for a publisher so hard and painful. You end up balancing development tasks with milestone tasks that you know are completely unnecessary but you have to do them otherwise you won't get your money you need to live.

Changes are a necessity for good game development. They're a necessity for non game development too, but from the outside looking in, it appears that other industries ideas of change only include small changes. Changes that don't have far reaching effects.

Why is this? I have been told many times over the years that "games developers could do it right if only they employed proper project management techniques." but I'm not convinced. The reason I'm not convinced comes down to two differences between games development and traditional software engineering.

Reason 1

Games are actually harder to make. They are. Looking at any codebase I've worked on over my whole software development history, the ones that are more complex, have the most bugs, and have the highest number of special cases; they have always been the games. I've worked on tools coding, server side coding for gameplay, robot control software, and other small things, but even the smallest game becomes a complex beast of a codebase. Why? Because games are naturally interconnected. Every game is a web of events and reactions. Every game is a combination of input leading to many results that are combined into many other results and only then do you get an output in the form of a complex rendering of an internal game state.

Games are hard to write because there is so much going on and everything has a side effect.
I learned that Bloomberg had a 100 mloc codebase a while back. That doesn't surprise me any more. They have a lot if code in a very large number of interconnected modules, but they don't have any single project that uses 10 mloc. That means they can go into any of their hundreds of projects and make changes without fear of causing a cascade of changes just to support one new feature. It's not a property inherent of good software engineering, but a property of not having to interact with multiple modules all running proprietary binary interfaces in the same process.

Games are just harder to write, and even harder to modify once they are written.

Reason 2

New must have features that massively change the game are introduced into the last days of the project.
This isn't a lie. It happens. The last days of any game are frought with danger as the balance and trading of just one last feature against a submission fail bug possibility causes the studio to ramp up the overtime and bring out the bug guns of empty promises of bonuses and the chance to work on future projects, projects that have been sitting on a back burner just waiting for the chance, for a moment of downtime.

These moments never come for many as once a project is completed, the development company cannot expect any more funding from their publisher as usually contracts contain no extra money to pay for second submissions or any rework required to fix bugs. Once any small excess has been eaten up by finally getting the game through submission, the company is out of money and has to start looking at pushing its workforce into more work, or worse, out the door.

So how do we fix this? Can we?

I think we can, and but we have to teach everyone with which we come into contact a bit of the Rockstar mentality. Sure, they force their workers to do some horrific overtime, but having been there, I wouldn't say that it was at all necessary. I think it's just a culture thing. What they do right is still right. What they do right is not decide on what is going to be in a game until they've almost finished developing it. Once they're at their last few months, they look at what they have and take that as their base game. They look to cut what isn't great, look to polish what could be, and implement any last features that might be awesome. That's it. It's a simple formula, and it's worked for years.

Make a game until you only have enough money for a few more months of development, then polish and debug the shit out of that mud covered diamond.

1 comment:

wererogue said...

Broadsword was the only games dev that I've worked for that didn't build change into their process. Everyone else* uses some kind of (usually worryingly broken or bastardized) version of scrum. Agile may be the sweetheart of software engineers, but it's the backbone of game dev.

* Clearly not everyone. But it's pretty prevalent.