Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming Real Time Strategy (Games) Games

The Struggles of Developing StarCraft 135

An anonymous reader writes "Patrick Wyatt led production efforts for several of Blizzard Entertainment's early games, including Warcraft 1 & 2 and StarCraft. Wyatt has just published an in-depth look at the development of StarCraft, highlighting many of the problems the team encountered, and several of the hacks they came to later regret. Quoting: 'Given all the issues working against the team, you might think it was hard to identify a single large source of bugs, but based on my experiences the biggest problems in StarCraft related to the use of doubly-linked linked lists. Linked lists were used extensively in the engine to track units with shared behavior. With twice the number of units of its predecessor — StarCraft had a maximum of 1600, up from 800 in Warcraft 2 — it became essential to optimize the search for units of specific types by keeping them linked together in lists. ... All of these lists were doubly-linked to make it possible to add and remove elements from the list in constant time — O(1) — without the necessity to traverse the list looking for the element to remove — O(N). Unfortunately, each list was 'hand-maintained' — there were no shared functions to link and unlink elements from these lists; programmers just manually inlined the link and unlink behavior anywhere it was required. And hand-rolled code is far more error-prone than simply using a routine that's already been debugged. ... So the game would blow up all the time. All the time.'" Wyatt also has a couple interesting posts about the making of Warcraft 1.
This discussion has been archived. No new comments can be posted.

The Struggles of Developing StarCraft

Comments Filter:
  • Not so hard (Score:5, Informative)

    by Anonymous Coward on Saturday September 08, 2012 @10:36AM (#41273303)
    If Blizzard's #1 priority wasn't 'obscene profit' these days, it might make the job a little easier/fun.
  • by Chemisor ( 97276 ) on Saturday September 08, 2012 @11:09AM (#41273501)

    If you actually RTFA, you'll discover that this error was made by fresh-out-of-college newbie programmers working crunchtime with no supervision.

  • Re:Criminally Insane (Score:5, Informative)

    by Anonymous Coward on Saturday September 08, 2012 @11:32AM (#41273607)

    STL was around, but C++ compilers were still shitty. You could get internal compiler errors or codegen problems if you tried to do anything complicated with types (like partial specialization). I also doubt that STL was taught in CS degrees then, you had to discover it existed yourself.

  • Re:Ignorance + Ego (Score:4, Informative)

    by ediron2 ( 246908 ) on Saturday September 08, 2012 @02:19PM (#41274825) Journal

    Testify, brother!

    My favorite SQL Prima donna was a guy that sr mgmt thought was a prodigy; they overrode our objections and put him solo on a project. Not knowing basic shit like normalization, his app hinged on queries that make my eyes to water just thinking about them a decade later: if QueryName matches name1 or name 2 or name 3 or name4, then again for every other advanced search field. The pinnacle was the advanced search query. It went on for a dozen pages, several just querying 8 wildcardable keywords against almost all columns. Since everything was one huge flat file of redundant columns, indexing couldn't save it. 'Find me commercial plumbers in zipcode X' often timed out after 10+ minutes and would peg one of 2 cpu's on the E450 we were using.

    Two encounters like that bozo convinced me that Prima donnas are a project-killer sort of risk, even if (like code-smell) you sense the problem long before you can articulate the specifics. (NOTE: primadonna != smart or brilliant or savant).

Never test for an error condition you don't know how to handle. -- Steinbach

Working...