Patrick Wyatt on the development of Starcraft

[Outlawedprod]

http://www.codeofhonor.com/blog/tough-times-on-the-road-to-starcraft

During the development of StarCraft, a two and a half year slog with over a year of crunch time prior to launch, the game was as buggy as a termite nest. While its predecessors (Warcraft I and II) were far more reliable games than their industry peers, StarCraft crashed frequently enough that play-testing was difficult right up until release, and the game continued to require ongoing patching efforts post-launch.

Why? There were sooooo many reasons.

My jaw dropped at the multiple inheritance part.

[Sheepherder]

That could be better.  This is just plain terrible though:

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.

[proudft]

I'm trying to imagine some macro that would make that less horrible, but my brain just shorts out.

[KallDrexx]

awesome find, thanks for that.

[Fordel]

I can't wait till he goes into detail about why the pathfinding in SC was so hilariously shitty 

[Hawkbit]

I almost interviewed with him last year for TERA support.  My resume looked like ass and I never made it to the third interview 'level'.  Probably for the best, because I likely wouldn't have had a job today.  Shame to miss the opportunity to work in the industry, but I got a more stable gig.  Seems like a decent guy, though.  

[Amaron]

That could be better.  This is just plain terrible though:

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.

This one really surprised me.  I can remember learning C++ around when D1 came out.  Even the textbooks at the time were warning people to use a library for this sort of thing.

[Lantyssa]

And we were no longer an underdog; with the successes of Warcraft and Diablo continuing to fill the news we sure wouldn’t be getting any slack from players or the gaming press. In the gaming world you’re only ever as good as your last game. We needed to go far beyond what we’d done previously, and that required taking risks.

Telling quote that some people in the industry need to be reminded of.

[tmp]

I'm trying to imagine some macro that would make that less horrible, but my brain just shorts out.

I must be missing something because the whole arrangement seems fairly trivial to begin with..?

in the unit type template: labels of lists the unit of this type should be part of; building, power unit, whatever else you group together
keep track of your lists in a table, associate each with its label. Something that may come handy elsewhere so you'd want to have it anyway
in the unit instance: iterators to nodes of relevant lists

to link: for each label in unit template find the list in the table -> add( unit ) -> store iterator in unit instance
to unlink: for each label in unit template find the list in the table -> remove( relevant iterator )

... and that's all? as long as you don't do anything stupid with the list table/lookups you still get the fast removal rate they're after while avoiding all the mucking with individual class members and link code for each type, like in the suggested alternative in the followup to the article -- it's fully flexible/automatic and you only ever need to alter label lists in the unit template to change how it's getting grouped. That extra menial work route they picked... idk.

[Ironwood]

Ask him and post the answer.

[Salamok]

There are a few rebuttals in the comments to his preferred solution.

[Lantyssa]

Linked Lists are hard.  At least it seemed so from cleaning up MUD code.  Much like pointers, they seem to muck with people's brains.

[Though C++ in general doesn't make sense to me.  I'm too set in my C-like ways.]

[Yoru]

Pointers are something that many programmers, especially those who never encountered a lower-level language early in their career, never quite seem to be able to fully grasp.

As a result, an understanding of pointers is one of the things I look for when screening candidates; the other being recursion. In modern environments, you may not bump directly into them, but they're still important when doing architectural and algorithmic work.

[proudft]

I'm trying to imagine some macro that would make that less horrible, but my brain just shorts out.

I must be missing something because the whole arrangement seems fairly trivial to begin with..?

It's not trivial at all, because if you screw it up once, anywhere, the whole thing falls apart.  And instead of using a proper separate function of some kind to add or delete links (which they already had, ready, but decided not to use) they just cut & paste lines of code in willy-nilly - and it sounds like they had them everywhere. 

An #ifdef macro could make it easier to read and less typo-prone (and would be 20% less awful), but there still wouldn't be any spot to stick in a quick text trace or easy-to-find hit in the debugger.  So the thing is going to be randomly crashing when one of those random lines is inevitably missed or mistyped with something like a unit type # instead of a unit index #, constantly.

[Amaron]

I must be missing something because the whole arrangement seems fairly trivial to begin with..?

You're imagining it as something that was designed ahead of time.  If they didn't pay attention to the problems and created a mess then it wouldn't be trivial to fix it.

[Salamok]

This just reinforces my belief that although it is possible to create good programs it is next to impossible to write good code on projects of decent size or complexity.

[proudft]

Well, every project that isn't from, say, NASA has something shameful hidden in it somewhere.  At some point you just have to say 'welp, it works, nobody show this to the review.' 

[Zetor]

As an ITsec evaluator / researcher, I am 100% fine with this. Food on the table, and all that.

[Samwise]

This just reinforces my belief that although it is possible to create good programs it is next to impossible to write good code on projects of decent size or complexity.

It's possible, but it requires that you budget time and effort to keeping your code maintainable rather than adding new features.  

Imagine trying to explain to a non-coder in management that you need to take a month off of adding features to make your code "prettier".  

[Abelian75]

That could be better.  This is just plain terrible though:

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.

Yeah, THAT was the part that was jaw-dropping.  Holy GOD.

[Samwise]

I'd be quicker to condemn such tomfoolery if I didn't still have the source of the first C++ app I ever wrote.  It keeps me humble.   

[Salamok]

This just reinforces my belief that although it is possible to create good programs it is next to impossible to write good code on projects of decent size or complexity.

It's possible, but it requires that you budget time and effort to keeping your code maintainable rather than adding new features.  

Imagine trying to explain to a non-coder in management that you need to take a month off of adding features to make your code "prettier".  

Even then it is just a matter of time before TNG comes along and decides it is easier to replace all of your carefully written code with bits of his own or some new feature comes in that has to be done asap and isn't compatable with the current code structure.  If there ever is perfect code it can only exist in a vacuum and isn't long for this world.

[NowhereMan]

The major problem seemed to be that they spent most of a year working crunch time with a deadline of 'two months from now'. When you're rushing to get stuff out the door you can't really budget the time needed to fix everything up. Even though spending that time would have meant that they would probably have saved time over the course of the actual release period, classic example of less haste more speed in that regard.

[tmp]

It's not trivial at all, because if you screw it up once, anywhere, the whole thing falls apart.

Yeah i meant that more in the sense of "i don't get why it wasn't avoided in the first place when it'd cost like an hour-two of thinking/coding upfront". If they went about it like Amaron is guessing then definitely, sorting it out once the mess was in place is another kettle of fish.

[Lantyssa]

Lots of junior coders and no one to guide them.  It really is like working on a MUD!