Gamasutra is part of the Informa Tech Division of Informa PLC

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.

Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: 2K Boston/2K Australia's BioShock
View All     RSS
January 20, 2022
arrowPress Releases
January 20, 2022
Games Press
View All     RSS
If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Postmortem: 2K Boston/2K Australia's BioShock

September 2, 2008 Article Start Previous Page 4 of 4

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.

Game Data

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

Team Breakdown

In the Boston studio:

Programmer: 1

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

In the Australia studio:

Programmers: 12

Artists And Animators: 10

Designers: 5

Audio Developer: 1

Producers: 2

Testers: 1 in-house, 7 contract

In the Shanghai studio:

Artists And Animators: 12

Designers: 3

Article Start Previous Page 4 of 4

Related Jobs

Question — Tiburon, California, United States

Question - South Park - Lead Level Designer (WFH/Remote)
Roto — Columbus, Ohio, United States

Lead Producer (Principal)
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States

Senior Animator
Champlain College
Champlain College — Burlington, Vermont, United States

Assistant Professor of Game Art

Loading Comments

loader image