Wednesday, October 31, 2012
Saturday, October 13, 2012
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.
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.
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.
Friday, October 12, 2012
When I first started out in programming there was a feeling that I didn't need to know any other language than c++. As the years went by I picked up python and thought that that was all I needed to round out the languages I knew. Over the last couple of years though, I find that it's become more and more the case that I really don't think you can get by without dabbling in many languages.
If you're doing Web development you're going to need more than one language.
So how does this affect how I think about games development?
Invest in scripting languages.
Don't invest in just one language. Try out a few and use them whenever they are the best for for a problem.
Don't shy away from low level languages. Use them when appropriate. I don't assume that two languages is enough. Then stick some medium level on there too such as java or c#. I won't ever enjoy working in those languages, but many gameplay programmers and tool developers love them for quick UI integration. They also have the benefit of being very fast to compile. Where did you find the most coupling your c++? Is it gameplay core by any chance? The abi way of handling linking fixes those horrible link times and even helps oxmplie times as there is less parsing going on in the first place.
Anyway. My point.
One language is not enough. The only programmer that thinks that one programming language is enough is a programmer that only knows one language.