Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
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 nhat11 ( 1608159 )

      This article is about SC gaming development back in the 90s, the TC post is off topic and nothing to do with SC or the trials and errors it went through.

  • by Anonymous Coward

    ... congratulation... what a fresh piece of news !

  • by theRunicBard ( 2662581 ) on Saturday September 08, 2012 @10:38AM (#41273319)
    This is so pefect for Computer Science courses! Someone might actually look up from their laptop at the lecture slides if this gets mentioned!
    • by K. S. Kyosuke ( 729550 ) on Saturday September 08, 2012 @11:15AM (#41273525)
      "How Not to Do Stuff 101"? Don't do memory management by hand, use functions to factor out common operations? Honestly, I'm surprised that something written in this way made its way out the software shop doors in a working state.
      • by aintnostranger ( 1811098 ) on Saturday September 08, 2012 @11:19AM (#41273551)

        I'm surprised that something written in this way made its way out the software shop doors

        ROFL. I think most software is like that, what surprises me is finding that some widely deployed software is well coded.

      • by jones_supa ( 887896 ) on Saturday September 08, 2012 @11:23AM (#41273565)

        "How Not to Do Stuff 101"?

        Maybe. Lessons like that can be fruitful for education too.

        • How? These kinds of issues are OLD. They have been talked about, discussed, studied, and explained to death.

          At some point, you have to say, it's either the teachers or it's the students.

          For this dll "problem", just using a macro fixes the problem while retaining maximum speed [no function call]. Unless they are doing stupid "I know I'm in the middle of the list, so no need to do nil checks" BS.

          • Re: (Score:2, Insightful)

            by Anonymous Coward

            There are people who are very good at what they do. They study, read books, perhaps do their own scientific research, they learn from mistakes and constantly try to improve not only themselves, but also people and company around them. But there are not many of these people. Not only does it require passion, it also requires experience and most often a little luck that you have met someone who taught you things.

            Most people want to either do the minimum that is required or they simply lack of experience or kn

      • by neonKow ( 1239288 ) on Saturday September 08, 2012 @12:47PM (#41274119) Journal

        "How Not to Do Stuff 101"? Don't do memory management by hand, use functions to factor out common operations? Honestly, I'm surprised that something written in this way made its way out the software shop doors in a working state.

        How about "why not to do this," or "trade-offs of doing it like this," or "pitfalls of hacky solutions in big projects."

        There is a lot more to teaching how to avoid mistakes than just a checklist of what not to do; you have to give students and understanding of why not to do things, and how to think through all the possible pitfalls that their design decisions will make. I'd would've definitely enjoyed learning good coding practices from one lecture based on real life-lessons learned.

        • by wisty ( 1335733 )

          Yes, it's very context dependent. Too much architecture, and you "lasagna code" - so many layers it's impossible to understand. Not enough architecture, and you get "spagetti code". If you care too much about nice code, you get Haskell - beautiful by ultimately pretty useless. If you don't care about good code, you get Fortran - extremely useful, but so ugly no-one wants to modify it. (Yes, it's possible to write practical stuff in Haskell, and nice code in Fortran ... but it's rarely seen in the wild).

  • THANKS! (Score:2, Interesting)

    by Anonymous Coward
    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.
    • Re: (Score:1, Funny)

      by Anonymous Coward

      Dude, No one, and I repeat NO ONE is going to ever suck your balls until you get out of your mom's basement, stop playing WoW 24/7 and give up the Cheeto habit.

  • by Anonymous Coward on Saturday September 08, 2012 @10:40AM (#41273329)

    Obviously the Zerg.

  • by Chelloveck ( 14643 ) on Saturday September 08, 2012 @10:46AM (#41273363) Homepage
    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 [].
    • by Anonymous Coward

      yes, the fact that no programmer thought of writing general purpose list_add / list_remove functions is telling.

      • by Anonymous Coward

        If you RTFA you would see that they had that at the beginning, scrapped it to increase the speed of save time and then realized their mistake too late to fix it for release date.

        • by SplashMyBandit ( 1543257 ) on Saturday September 08, 2012 @05:35PM (#41276039)

          > "scrapped it to increase the speed of save time"
          That seems to be a real flaw in the mindset of games (and system) developers. They put in all these hacks thinking it'll shave off little slivers of execution time and overall make big savings when it is not the most significant impact on the assembled system. The time savings are usually negligible compared to bigger optimizations you can do later (using a profiler) and the development time increases (meaning you don't have time to run the profiler since you are too busy hunting down dumb bugs). As the great Don Knuth joked, "Premature optimization is the root of all evil".

          If you are a developer on these forums bragging how you used some trick to save a sliver of time it would be good to take note of this StarCraft experience - since more experienced devs simply roll their eyes when they hear such talk (recognizing such development practices as n00b traps, which we probably were tempted by ourselves at some point in the past). Write the program to be correct first (usually means the most straightforward efficient implementation, rather than the absolutely fastest implementation, should be used). Then, you can refactor (you *are* writing unit/integration tests, aren't you?) to get more efficient, all the while guided by your profiler to prioritize the development time you have remaining.

          nb: the best speed-ups are almost always algorithmic. Code hacks are minor. For example, by sitting down for several hours with a pencil, paper, and google I was able to analytically work out the optical transmission of a multi-band (eg. RGB) light source through and exponential density decay atmosphere using Mie and Rayleigh scattering into a simple analytic expression (for direct and single-scattered illumination) rather than use the integration that many other people use (eg. as published). This allowed me to implement the algorithm in a GLSL shader in real-time and saved on precious Video RAM (eg. no need to precompute and store the integral). Sure, other people have done this too, but my point is that the big speed up for me was to sit down and think rather than make minor code twiddles. Unfortunately, you need to be a good mathematician (using basic calculus and geometry in my case) rather than just a good coder to do this (which I guess may be hard for the poor young schleps that games companies hire and burn out).

          • by Anonymous Coward

            In every situation where I have tried for this approach, one of two things happen:

            1. A middle manager demonstrates the "working" software at the 6mos mark, see how much work we have done, and then the senior manager goes "Wow, that's great, lets drop the delivery date from 6 months from now to 2 months!"... and you end up running your ass off trying to get the last critical bugs out before they ship it .. and try to bring up anything and they say "Hey, we seen it working, it's ready!", argue and you'll be o

            • > and then the senior manager goes "Wow, that's great, lets drop the delivery date from 6 months from now to 2 months!"
              Well, it is your job as developer (or actually, the project manager's job) to show the work plan you have and point out what has yet to be done. It is mostly a matter of education such folks, and of course, planning (you do develop and maintain a work plan, yeah?). Just because they are senior and a manager doesn't mean you can't patiently explain why they can't arbitrarily move dates

          • by Anonymous Coward

            How do you write unit tests for a game? Or, less broadly, a physics solver? Reverse IK solver? Spawning algorithms? LOD level calculator? Frustum-culling? Shaders?

    • This is just ugly, horrid programming practice. I remember a project I worked on years ago that managed training documents with a built-in tree structure to the contents (1, 1.1, 1.2. 1.2.1,, etc.), and the first thing I did was write a library to manage a generic double-linked tree structure with a generic pointer to the actual content block, so I could use the same list manipulation functions for all the document types.

    • 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.

      • "fresh-out-of-college"

        If it was an actual CS/IT course, and not, say, English Literature, then it's hardly an excuse.

      • by Chris Mattern ( 191822 ) on Saturday September 08, 2012 @11:35AM (#41273623)

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

        In other words, video game programmers.

        • by Lonewolf666 ( 259450 ) on Saturday September 08, 2012 @11:50AM (#41273719)

          Without experience on the job. And this is important. I remember my own university time as a nice source of theoretical knowledge, but things like good development practices were not a topic.
          Of course, any halfway smart developer will eventually figure it out. But it may take one embarassing failure as a wake-up call. Tough luck (but maybe well deserved) for a company who only hired newbies and no experienced developers as team leaders.

      • by Chelloveck ( 14643 ) on Saturday September 08, 2012 @11:58AM (#41273769) Homepage

        Funny you should mention this. I just returned from a job fair at a major university where we were interviewing and hiring programmers. Yes, the new grads tend to be pretty green, but some of them are really good. It's not terribly hard to separate those who may just lack experience but who grok the fundamentals from those who really need to reconsider the last four years of their lives. I actually talked with seniors in CS who couldn't describe the difference between a queue and a stack.

        As for the article specifically... Yes, they had "fresh-out-of-college newbie programmers working crunchtime with no supervision". Hired by programmers who were themselves once "fresh-out-of-college newbie programmers working crunchtime with no supervision". It's a self-perpetuating cycle that is really prevalent in the games industry. (Or at least was prevalent at the time this story takes place, which is roughly the same era in which I was a games programmer. Thankfully I got out. That scene is nuts!)

      • I see ads for programmers like this all the time; they are looking for new grads and then present a laundry list of technical tools and experiences they (the employer) expect from these people. Maybe I'm wrong but it seems like they are loooking for people with exerience they don't need to pay top dollar. How odd...
        • by Anonymous Coward

          Or, possibly, they're looking for people who code a lot in their spare time instead of only doing the programming required of them in their degree. Which is, by the way, not enough to be particularly useful without further training. I am someone who codes a lot in his spare time and, though I haven't graduated yet, the few employers I've worked at love me because I require very little training and can pull my weight even as a co-op/intern. I know one guy in my year who's being actively head-hunted thanks to

          • Re: (Score:2, Troll)

            by pjt33 ( 739471 )

            Or, possibly, they're looking for people who code a lot in their spare time instead of only doing the programming required of them in their degree

            No, because as far as HR are concerned the 1000 hours of spare time you spent on your personal project don't count as experience in anything. If it's not for a company, it didn't happen.

      • by godrik ( 1287354 )

        Also they rewrote a linked list data structure out of need (or what they thought was a need) and not out of "hey let's write our own!"

      • Re: (Score:2, Insightful)

        by Anonymous Coward

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

        Fresh out of college newbie programmers that no one is mentoring? My college hires (well, my entire team, but especially my college hires) have every line of code they write code reviewed. Any more senior member of my team would have said "I don't sign off on this checkin until you use common routines for manipulating these data structures". And if they had signed off on it, I would have seen it, and then I would have asked the senior people who signed off on the checkins WTF?

        This is a management failure

    • 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.

      • Well, I'm surprised linked lists were being used. For my in-progress game (Java combat flight simulator) I will almost never iterate over lists. Using an (associative) 'map' structure is vastly more efficient at runtime. You can still access the complete set as you would an unordered list if you need to, but most of the time you are trying to find a specific object based on some criteria (which the map is good for). Yeah, sounds like having a green programmer work on a bit of code that was heavily used affe
        • associate hash maps were some exotic thing found in unversities. your main tools, turbo pascal and microsoft C++, had no such thing. you would have had to write the whole hashmap from scratch. considering they couldnt wrap their heads around writing linked list functions, i dont think a hash map would have worked out any better for them.

          but people should remember the times. this was when a few MB of RAM was considered pretty damn good, dialup was normal, you went to something called a 'software store' to bu

          • There were some excellent libraries, eg Turbo C and C++ libraries, the BGI etc. Although it has to be said that there wasn't a standard 3D library (well, OpenGL [Doom!] and PHIGs etc were among the standards but not for DOS/early Windows PCs; the first version of DirectX came well after gaming was established and it leaked resources like a cardboard bucket - I remember having 20 player connection slots that accumulated and were never recycled, just awful stuff from Microsoft for those of us that were looki
    • Ignorance + Ego (Score:5, Interesting)

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

      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 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

        • by Boronx ( 228853 )

          I find giving them a huge task with complicated data structures and having them fuck it up does wonders for their humility.

        • Here's an interesting data point that reinforces your statement. For a long time Sun Microsystems was considered to have the best assembly of engineers in IT (although their sales team was balkanized and not customer focussed, hence Sun's demise, but that is a different store). The Sun engineers knew it, and anyone who knew anything also knew it.

          For a long time Sun was subject to 'Not Invented Here' (NIH) syndrome. Since they were the smartest whatever they didn't seem to look around much since they woul

          • by Anonymous Coward
            For a long time Sun was just the cheaper Unix solution. Once Linux became the cheaper "Unix" solution Sun was doomed.

            Sun were far from the best. Even Unix in those days was not even viewed as the best, just "good enough".

            There were plenty of other contenders with superior reliability and uptime - just more expensive and hence people bought Sun - since it was cheaper and good enough.
      • by Bengie ( 1121981 )

        who don't even know what database indexes are.

        Or people who kind of do and put them all over the place. Nothing says fun like a clustered index on a GUID with a default fill factor.

      • 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).

      • by Stiletto ( 12066 )

        +5 Insightful, for basically trying to start a language-war? Really?

        Good programmers are good programmers, and idiots are idiots, regardless of the language or framework they use.

    • Unfortunately, this is not specific to game programmers at all. I happened to inherit some code a few years back with the same mistake. I replaced thousands of lines of pseudo repetitive code used for accessing the central data structure, by a common routine. This corrected a large number of bugs, decreased the size of the source code and removed a few size limitations which didn't have to exist.You've got crap programmers everywhere and I don't think that all game programmers are crap.
  • by Mr. Underbridge ( 666784 ) on Saturday September 08, 2012 @11:14AM (#41273523)

    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?

    • 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.

      • by Anonymous Coward

        Even today, STL tends to be avoided in game programming. Most STL implementations are pretty well developed and tested these days, but a lot of senior developers are still burned from back when it wasn't. More importantly, there is a lot of need for control over how the memory is managed, especially in memory limited systems like consoles. Think static buffers and memory pools instead of new calls everywhere. STL doesn't (or at least since last I checked) work well within those guidelines.

        • by Anonymous Coward

          You can use any allocator regime with STL - it's part of the standard. The allocator is specified in the container template type. The best reason not to use it was the 1996 era compiler errors for templates; 10-50 lines of template stack trace per error. God help anyone working on that, I don't know how the guy who wrote STLport survived.

      • by AuMatar ( 183847 )

        Back then most compilers didn't even do templates. We're talking 1996- Borland was still one of the most popular compilers, and if it ever had templates it was the last version.

        • Re: (Score:2, Interesting)

          by Anonymous Coward

          Game devs were using Wacom C compiler. C++ wasn't even used much, never mind templates. You had actions overloaded like,

          struct object;
          typedef void (*action_func)(struct object *);
          struct object{
          [object data here]

          action_func action; /* THIS HOLDS YOUR "AI" */

          struct object *next;
          struct object *prev;

          Of course, most devs would abstract insertion and removal and moving functions of data from such an obje

    • You're absolutely right. But you have to account for ego. There are developers out there that just don't trust anything not written by them. These guys are self righteous know it alls, and they don't take well to criticism. Thus if you ever do get a chance to look at their code you quickly realize a few things:

      1. No comments
      2. Basic functionality is rewritten all over the place
      3. They produce unnecessarily large sloc.
      4. The code does not handle non go-path well, if at all.
      5. Motherfuckers like poin

    • Wish I had thought of that for [] . Per chance what is the fastest sorting method for key / value pairs. I couldn't ever find a satisfactory one and just defaulted to showing 500 best but then they still have to be sorted to find the 500 best.
    • by GuB-42 ( 2483988 )

      TFA part 2 : []

      The author suggests to ditch the STL in favor of "intrusive lists". In intrusive lists the links are part of the data structure. It breaks the data/container separation but provides many benefits in term of performance and reliability.

  • by The Optimizer ( 14168 ) on Saturday September 08, 2012 @12:11PM (#41273861)

    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.

    • Even 1998, Visual Studio had old STL headers which caused memory corruption, data loss, and crashes.

      Apparently a legal dispute stopped them from providing STL updates for 6.0, and they pointed users at Dinkumware's site for manual patching. I think these were the same as the 1997 VC 5 STL, so problems around 1995-1998 with STL were to be expected.

      It was developed privately and presented as a standard in 1993. HP's 1994 release was the basis for a lot of implementations.

      There were bugs, and they were found

    • by cicuz ( 1414125 )
      Juicy stuff, here.. Please write a blog post as well? Would love it, and thanks for the work you did anyway ;)
    • > "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."
      Microsoft were famous for doing stuff like this. I remember some story about changing the bootloader for a 5% speed up when booting a 386 that hampered Windows for a few versions (since they needed to remain as backward compatible as they could all sorts of cruft hung around). This kind of thinking cost them a lot of headaches over the year

    • by TheLink ( 130905 )
      Yeah, I noticed they didn't use revision control yet. Did your team do without it as well?
  • Check out this class hierarchy from the code:

    CUnit In case you couldn't tell, a CThingy is a sprite that can be drawn, a CFLigny is some kind of particle engine, a CDoodad/CUnit is some artificial separation of concerns. This is in SC1, btw.

    • by Stiletto ( 12066 )

      I never understood the practical purpose of prepending a "C" to each of your class names.

      Today, it serves a very useful purpose: It unambiguously identifies a 1990s-era Microsoftie who can't change his ways.

      • I could tolerate that if their names had more meaning than 'thingy' 'flingy' and 'doodad'. The C is the most meaningful part of those names!
  • Blizzard was never any good when it came to programming. Their games are always extremely slow, so you can tell in the back the code is doing some pretty funky inefficient stuff, and the bugs are a glimpse at the underlying spaghetti code. Blizzard's coding should be taught in classes as: What not to do. They're still horrible programmers: UT3 renders ultra-realistic scenes 60fps flawlessly with all the settings on max, while Diablo 3 struggles to draw some top-down view... and that's just the optimization!

    • Dunno about you, but Starcraft ran slick even back in the day on my slow Pentium. Even the latest Starcraft patch works fine and I can even replay demos at a high timeskip without hitching problems on 100mhz.
  • Hmm strange, I've played the shit out of Starcraft and Brood wars. Single player and LAN, too. And not once it crashed. I think it was stable enough.
  • 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).

    Please explain how a doubly linked list now makes add & remove O(1). The rest of us shlums have been relying on hashtables when we needed O(1) and assumed linked lists of any variety were always going to be O(n) at best...

    • by smellotron ( 1039250 ) on Saturday September 08, 2012 @10:10PM (#41277437)

      Please explain how a doubly linked list now makes add & remove O(1).

      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.

      • by Dahamma ( 304068 )

        Your assumption is you already have the item you want to remove. The quote was "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".

        Of course you can write code to be efficient with a list if you are not searching the list, and if you have a reference to a node without any context to the traversal, a doubly linked list is a good idea. But your explanation was a speci

  • With twice the number of units of its predecessor — StarCraft had a maximum of 1600...

    Nope. Starcraft's unit limit is 1700.

    • by admdrew ( 782761 )
      Wyatt comments a number of times about his spotty memory (it WAS over 10 years ago), so he probably deserves a little slack on the exact numbers.

Order and simplification are the first steps toward mastery of a subject -- the actual enemy is the unknown. -- Thomas Mann