Slashdot Mirror
The Struggles of Developing StarCraft
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.
If Blizzard's #1 priority wasn't 'obscene profit' these days, it might make the job a little easier/fun.
... congratulation... what a fresh piece of news !
This is so pefect for Computer Science courses! Someone might actually look up from their laptop at the lecture slides if this gets mentioned!
Thanks to Blizzard's new and idiotic direction with WoW, I discovered private servers and can finally enjoy the game again either on: vanilla, BC, or Wrath servers. Cataclysm and on, can suck my balls.
Obviously the Zerg.
Thus demonstrating my long-time assertion (ever since my stint in the video game biz) that video game developers are crap programmers. No common routines to manipulate a heavily-used data structure? Not even a set of macros? This kind of story belongs over on The Daily WTF.
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
{{Citation Needed}}
Thus demonstrating my long-time assertion (ever since my stint in the video game biz) that video game developers are crap programmers.
Broad Generalisations are almost always wrong. There are some game developers, especially those who have experience in other fields of software, which aren't "crap programmers". Video Games are some of the most hardware intensive programs, utilising every major feature and capability that the system supports. Sometimes it's acceptable to break the 'best practices' rules to get a little performance (if the profiler says it's warranted), but I agree there's no reason to be manually managing linked lists.
Sometimes a 'Lead' programmer will be the worst of them all, and the others must follow the bad example or be made an example of. Let's not lump all game programmers into the horrible coder pile. As you've pointed out, TDWTF has plenty of examples of nightmares from all sectors, not just video games. That the game developers allow studios to get away with "crunch time" consistently instead of firing the dumbasses in charge who purposefully gork the schedule is both a large source of bugs and proof we need a union or better work conditions at least. I can forgive crunch for one project. Maybe even two in a row... but every single game? Yeah, that's either abuse or incompetence. Either way, it's why I only buy (and work on) indie games now. They tend to have better working conditions, even if some of the beginners in the indie market churn out even worse code -- At least they have an excuse in not knowing any better; What's that say about the "pros"? That they're all crap programmers, or that the programmers are forced to write crap code? I put it to you that it's the latter, not the former.
I'm a scientist with a CS minor and some experience doing SW engineering (probably badly) on small projects. Even *I* know you abstract the actual storage and provide some simple accessor/insertion functions to prevent people from actually touching the storage implementation. For a couple of reasons: 1) to prevent goofballs from creating pointer messes, and 2) so that, if you want to, you can completely rip out the actual storage implementation and replace it without breaking anyone's code. I'm sure there are also reasons 3) - Eleventy, but those two are pretty obvious. Not to mention which, it only adds maybe a couple hours (if you're diligent and paranoid) over the short term, and probably saves weeks over the long term.
Not to mention which, aren't there standard libraries to do this stuff? Did STL not exist back then?
There are certain types of software development that seem to attract people who have a combination of significant ignorance and huge egos. Game development is one such field, and Ruby on Rails web development is another.
These people often are quite young, and as a result of this often have little to no academic background or formal training of any sort. Although they're quite ignorant, they don't realize this fact. This prevents them from keeping their egos in check, which in turn makes them think they know everything. Believing that they're all-knowing, they never both to seek further education or investigate alternatives, and continue to make the same mistakes over and over.
Having worked in both the game development industry and doing web development more recently, I do have to say that the RoR programmers are much worse than the game programmers. At least the game programmers usually have some understanding of algorithms, and many have a solid understand of mathematics, even if it's all self-taught. Compare this to the RoR programmers, many of whom refuse to learn about databases, even though they're generally developing database-driven applications. You wouldn't believe how many times I've encountered people like this who don't know any SQL, and who don't even know what database indexes are.
I was working 'down the street' if you will at the time, as a programmer on one of their direct competitors (Age of Empires), and it's easy to forget the circumstances we all were working under at the time.
People weren't using Templates in games for a couple of reasons - Familiarity being one, but the state of the code was new, and especially the asm outputted by compilers was often very inefficient which it was not outright BUGGY if you pushed it. Templates were still very new then.
Also, you tend to forget how slow and limited PCs were then -- Your phone today probably runs circles around not just the machines that games were run on, but the PCs used to develop them.
The System Specifications "On the Box " for Starcraft were - A Pentium 90 (or equivalent - that could be a 486-133) , 16MB of RAM and Windows 95 or NT 4.0, and a SVGA video card with 512kb or 1MB of VRAM. Think about that for a minute. These were 2d video cards, not 3D. Age had almost identical specs. A full rebuild of AoE on our Dev machines (Pentium Pro) took 15-20 minutes to make.
It was very normal to worry about saving 2 bytes, or just a few cycles of CPU time back then. So you did everything bespoke by hand, and didn't genericsize much.
And to be honest. We didn't know then what we know now. The programming practices most of my peers just do automatically today -- we hadn't developed/learned them yet. We did what we could with what we had in knowledge and tools, and shipped complete AAA games for costs in man-hours and dollars that seem ludicrously small today.
Don't get me wrong, Besides being a lot of work, It was a lot of fun too. One thing I remember was our companies putting each other on the Beta Test list for our upcoming games.
Yeah, but starcraft was written ages ago. It was released in 1998. Which means they probably started coding it in 1996. Possibly earlier. It was probably based off code from Warcraft which was released in 1992. It wouldn't be a stretch to say a lot of the code is close to 20 years old. Granted, it still gives them no excluse for not writing their own library so they didn't access the data structures 100 different ways, but it's not like standard libraries were avaialble for a lot of this stuff back then.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
I call it Smartest Motherfucker in the Universe Syndrome. You see it all the time on Slashdot: People who seem to think they are gods gift to development. They'll talk about how amazingly stupid Company X is for not doing thing Y, when it is clear they have NO idea of all the shit that would be involved in that. They berate others for bugs in code, yet their own code is bug ridden, and so on. They are just convinced they are WAY smarter than all those other dumb programmers (and IT people, and managers, etc) out there.
It's a pretty common affliction and leads to more than a few problems. You are correct that it seems to congregate in some areas. I'd expand the RoR thing (though they are pretty bad) to just "web development" in general. Probably because of the massive market and low barrier for entry, it attracts a lot of people who's knowledge does not match their talk.
Wait a second - did you just try to troll fans of a 15-year-old game? For your next trick, maybe you can jump into the Genesis-vs-SNES wars, or go political and claim that Dole's going to kick Clinton's ass?
Last post!
Suppose you have a collection of unit objects, and your main game loop involves iterating through each of them and performing some time-step (move, regenerate energy or health, cooldown weapons, etc.) Now at any point in the "simulation" that is an RTS game, a single unit decides/discovers that it must be deleted. If you are already iterating over units in a doubly-linked list, it is exactly 2 pointer operations for the unit to remove itself from the master list. If you had used a singly-linked list you would need to spend O(N) time searching for the previous unit.
Oh, and given that you're already iterating over every single unit in the game, you don't need the random lookup that a hashtable provides. Actually, you probably can't afford the lookup table unless it is already solving another problem for you. CPU cycles and cache footprints matter when you want to push the limits of the hardware.