This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
4. Inefficient processes and tools.
Many of the processes and tools we used to develop BioShock were inefficient or confusing in implementation, leading to slow iteration cycles and bugs. Using a modified version of the Unreal engine, which the team had already used to ship two previous games, gave us a huge head start in developing BioShock. The gameplay team was able to mock up a playable version of the core game mechanics in just a few months, and the team's familiarity with the tools allowed us to get new gameplay spaces up and running quickly.
However, the ease and familiarity of the workflow often led us to accept a solution that was faster to implement but slower to use rather than taking the time for a more efficient implementation.
For example, there was no good convention for how to name script actions. Depending on the system, one script action might be called "Change < SystemProperty > " while another would be called "Set < SystemProperty > " or "Modify < SystemProperty > ". With hundreds of scripting actions available, designers often spent way too much time searching for the right tool to use. This could have been avoided with a scripting code standard.
The content baking process for the console was time-consuming and difficult to troubleshoot. Frequently the only way to either identify or resolve a bake problem was to re-bake at the cost of up to an hour of work, and if the tools were actually broken in some way, it would take at least another bake cycle to be able to work effectively again.
Once we reached crunch time, it was extremely painful to have to wait for the bake process to complete when people could have been working productively instead. We should have put more energy and time into speeding up the bake process sooner.
5. Poor data collection.
One of the most frustrating things about our decision to be more data-driven in tuning the game was the lack of actual good data to base that tuning on. Our game log system was barely adequate to analyze single play-throughs and became completely unwieldy when trying to analyze a single log file containing data from multiple play-throughs. We had no good methodology to define what information was logged and at what level of detail, so the job of parsing out the logs into understandable "gameplay metrics" was painful, slow, and ended with inadequate results.
To further complicate the problem, most people in the office used shortcuts or cheat codes at the start of a level rather than playing from the beginning of the game, which caused us to base a tremendous amount of early tuning on a shaky set of assumptions about how players would choose to build their characters.
Our goal when we set out to make BioShock was very clear. We wanted to get to the next level, moving beyond our suite of critically acclaimed games to make a blockbuster. A lot of factors aligned to make this possible: the commercial backing of 2K; the game design knowledge we'd acquired from building System Shock 2; the technological familiarity with our Unreal-based engine that we'd built with previous games. But we still had to figure out how to make it all big-blockbuster big.
A lot of our problems came from underestimating how big the task of making a triple-A product for multiple platforms and multiple regions really is. And other problems came from over-estimating our capacity to solve those problems using our existing procedures and staffing levels.
If there's an over-arching theme of our development, it's that we, like many other developers, believe that ultimate success in this industry comes from iteration. You have to build, evaluate (and have others evaluate) and be prepared to throw things away and rebuild.
The products we make are just too complex and our industry reinvents itself too rapidly to do anything else. But we believe that if you are truly prepared to turn a critical eye on your own product and honestly respond to that criticism you'll get quality at the end. As to whether you get a blockbuster, only time will tell.
Developer: 2K Boston and 2K Australia
Publisher: 2K Games
Platform: Xbox 360 & PC
Release date: August 21, 2007
Development time: 3 years
Number of full time developers at peak: 93 in-house developers, 30 contractors, 8 on-site publisher testers (see the sidebar on pg. 22 for details)
Hardware: PC; AMD Athlon X2 dual core or Pentium 4 Intel-Duo dual core processors; NVidia Geforce 8800 graphics cards; Xbox 360 dev and test kits
Software: Microsoft Visual Studio 2005, Perforce, Xbox 360 SDK, Xoreax Incredibuild, Visual Assist X, Araxis Merge, BoundsChecker, Purify, VTune, 3ds Max 8, Photoshop CS2, ZBrush, Flash 8, SoundForge 8, Sony Vegas, Acid, Ableton Live
Technology: Unreal Engine, Bink, Havok, Fmod
Number of files: 3,775
Lines of native C++ code: 75,8903
Lines of script code: 187,114
Artists And Animators: 15, plus 2 borrowed from Firaxis
Designers: 6 in-house, 1 contract
Audio Developers: 2 in-house, 7 contract
Producers: 3 in-house, 2 contract
Testers: 13 contract, plus 8 on-site publisher testers
Artists And Animators: 10
Audio Developer: 1
Testers: 1 in-house, 7 contract
Artists And Animators: 12