×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Struggles of Developing StarCraft

Soulskill posted about a year and a half ago | from the requires-more-vespene-gas dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

135 comments

Not so hard (5, Informative)

Anonymous Coward | about a year and a half ago | (#41273303)

If Blizzard's #1 priority wasn't 'obscene profit' these days, it might make the job a little easier/fun.

Re:Not so hard (-1)

Anonymous Coward | about a year and a half ago | (#41273831)

Hey, DRM is hard. You have to stop that one smart cow or the system is useless. I bet their herding practices take up 90-95% of their development time. And how are you supposed to make a game with only 5-10% remaining?

Btw, I think Blizzard has come up with a brilliant solution to the one smart cow problem. They make their DRM so obtrusive and offensive that no intelligent gamer would even consider playing their games. Thus, the DRM is never broken.

Re:Not so hard (1)

Culture20 (968837) | about a year and a half ago | (#41274233)

Hey, DRM is hard.

Yeah, DRM is hard, and Blizzard should be able to compensate its programmers for selling you DRM instead of giving their time away for free. Heck, they even package in a game as a bonus! This is partly sarcasm, because I do believe a portion of the higher prices we now pay are due to the waste of time (ours and theirs) that is DRM.

Bad code is a nightmare to debug (2, Funny)

Anonymous Coward | about a year and a half ago | (#41273307)

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

Teaching opportunity? (5, Insightful)

theRunicBard (2662581) | about a year and a half ago | (#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!

Re:Teaching opportunity? (4, Insightful)

K. S. Kyosuke (729550) | about a year and a half ago | (#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.

Re:Teaching opportunity? (5, Insightful)

aintnostranger (1811098) | about a year and a half ago | (#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.

Re:Teaching opportunity? (0)

Anonymous Coward | about a year and a half ago | (#41276067)

At some places where i worked mentioning that incoherent use of lists may be a problem would be seen as a major affront towards your co-workers "we did not know it better" may be thre reason but that does not mean that i should not analyze the problem.

Re:Teaching opportunity? (3, Insightful)

jones_supa (887896) | about a year and a half ago | (#41273565)

"How Not to Do Stuff 101"?

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

Re:Teaching opportunity? (2)

davester666 (731373) | about a year and a half ago | (#41275249)

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:Teaching opportunity? (4, Insightful)

neonKow (1239288) | about a year and a half ago | (#41274119)

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

Re:Teaching opportunity? (2)

wisty (1335733) | about a year and a half ago | (#41274431)

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! (2, Interesting)

Anonymous Coward | about a year and a half ago | (#41273321)

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:THANKS! (1, Funny)

Anonymous Coward | about a year and a half ago | (#41273369)

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.

Re:THANKS! (4, Funny)

Anonymous Coward | about a year and a half ago | (#41273395)

Huh. That's odd. The first time I had my balls sucked was in my mom's basement while playing WoW and eating Cheetos. That girl was awesome.

Re:THANKS! (5, Funny)

Anonymous Coward | about a year and a half ago | (#41273495)

Dude, the family dog doesn't count.

Re:THANKS! (0)

Anonymous Coward | about a year and a half ago | (#41275137)

How that sentence probably reads to most /.'s:

The first time I had my balls sucked [it] was my mom ... eating. That girl was awesome.

FTFY

(also, the lack of any exclamatory punctuation or similar mark-up belies your comment about how awesome she really was... I'm just-sayin')

-AC

The largest source of Bugs in Starcraft? (5, Funny)

Anonymous Coward | about a year and a half ago | (#41273329)

Obviously the Zerg.

Re:The largest source of Bugs in Starcraft? (3, Interesting)

Columcille (88542) | about a year and a half ago | (#41273679)

It's an ugly planet; a bug planet. A planet hostile to life as we know it.

Oh wait, I may have the wrong thing in mind...

Slashdot and Wikipedia are for fags. (-1)

Anonymous Coward | about a year and a half ago | (#41273361)

Not Gay Fags, no. Worse. I mean FAT, AUTISTIC, GEEKS!

Fapping to Little Ponies while compiling your Linux kernel for the 32nd time to hope your obscure wifi driver works. Slashdot, the worst of the internet since 1997. Wikipedia, putting [citation needed] on the blinding obvious. Admit you are all worse than reddit, fark and even 4chan if you are Slashdot user or Wikipedia editor.

Re:Slashdot and Wikipedia are for fags. (0)

Anonymous Coward | about a year and a half ago | (#41275099)

Yet here you are.

Thus demonstrating my assertion (5, Insightful)

Chelloveck (14643) | about a year and a half ago | (#41273363)

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 [thedailywtf.com].

Re:Thus demonstrating my assertion (1)

Anonymous Coward | about a year and a half ago | (#41273471)

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

Re:Thus demonstrating my assertion (1)

Anonymous Coward | about a year and a half ago | (#41275269)

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.

Re:Thus demonstrating my assertion (4, Interesting)

SplashMyBandit (1543257) | about a year and a half ago | (#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).

Re:Thus demonstrating my assertion (1)

Anonymous Coward | about a year and a half ago | (#41276463)

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 out on your ass so fast you won't know what hit you.
2. Your manager comes to you every day and spends 1/2 hour asking why the game/program is not meeting the minimum speed requirements and memory usage is higher than the target market machine is expected to have and they want progress RIGHT now.... They get really jittery if at the 1/2 way mark they can't demo the first 1/4 of the game/program internally and they soon start with the "well, if you can't do it..." and "we are afraid this isn't going to work, can we add more resources...." and if within a month of two you haven't made that progress, well, it's out on your ass.

And people wonder why game dev's burn out so fast and work insane hours under idiotic conditions....

Re:Thus demonstrating my assertion (1)

SplashMyBandit (1543257) | about a year and a half ago | (#41276985)

> 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 - it is in both your interests to politely explain how the project needs to stick to your original budgeted time.

Sucking it up silently without explaining the features you'd have to cut is not professional - in fact, that is really where developer "experience" comes in, old timers know when a fight cannot be won (which is actually, most of the time), and will politely point out when changes to a schedule or feature-set are risking the success of the project. Project timelines can be shortened successfully but features/scope are always cut/deferred for this to happen.

I feel that your scenarios are caricatures of how development used to work, rather than what happens when the team has any experience (which is more common now than in the early days of mass software development).

Re:Thus demonstrating my assertion (0)

Anonymous Coward | about a year and a half ago | (#41273481)

IMO There's that, but also the fact that when they make a game, it's a "one time" project and then you scrap the stuff, unless you make a rehash then use the same codebase with minor changes.
I'm sure a few of those companies are still trying to keep a base that will never change, and then all the rules can be coded differently.

Good thing that's the thing I'm trying to do with my project.
Now if I wasn't that depressed...

Re:Thus demonstrating my assertion (1)

phantomfive (622387) | about a year and a half ago | (#41273891)

It wasn't a one-time project though, it's going to be maintained and built on for at least two more releases.

This does explain why they aren't making huge changes to HOTS, though, the code is so brittle it would be too hard, and break too many things.

It also explains why Blizzard takes so long to get games out the door....

Re:Thus demonstrating my assertion (2)

neonKow (1239288) | about a year and a half ago | (#41274407)

[sarcasm]I'm glad that before you commented, you read any of the summary, or article, instead of just skimming the title and leaving a couple of snide comments.[/sarcasm]

This is StarCraft, the RTS game from 1998, not StarCraft II, the very modern game with a giant game engine. Games and code tended to be a bit more skeletal.

Re:Thus demonstrating my assertion (0)

Anonymous Coward | about a year and a half ago | (#41275619)

All your post explains is that you're an idiot. Honestly, just read the damn fucking summary before reaching wild conclusions about shit you have no clue about.

Re:Thus demonstrating my assertion (1)

srmalloy (263556) | about a year and a half ago | (#41273499)

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, 1.2.1.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.

Re:Thus demonstrating my assertion (5, Informative)

Chemisor (97276) | about a year and a half ago | (#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:Thus demonstrating my assertion (1)

K. S. Kyosuke (729550) | about a year and a half ago | (#41273541)

"fresh-out-of-college"

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

Re:Thus demonstrating my assertion (5, Insightful)

Chris Mattern (191822) | about a year and a half ago | (#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.

Re:Thus demonstrating my assertion (4, Insightful)

Lonewolf666 (259450) | about a year and a half ago | (#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.

Re:Thus demonstrating my assertion (0)

Anonymous Coward | about a year and a half ago | (#41273651)

As a fresh-out-of-college newbie programmer, I know better than to do this. It screams "bite me in the ass later".

Re:Thus demonstrating my assertion (1)

WrecklessSandwich (1000139) | about a year and a half ago | (#41273681)

Oops, forgot to log in.

Re:Thus demonstrating my assertion (0)

Anonymous Coward | about a year and a half ago | (#41276347)

What a clever boy you are! Too bad you hadn't just graduated in 1998 when Starcraft was released with all of this wisdom.

Re:Thus demonstrating my assertion (4, Interesting)

Chelloveck (14643) | about a year and a half ago | (#41273769)

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

Re:Thus demonstrating my assertion (1)

interval1066 (668936) | about a year and a half ago | (#41273779)

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

Re:Thus demonstrating my assertion (0)

Anonymous Coward | about a year and a half ago | (#41273905)

I have exactly the same experience. It's not too different from those stories where they ask five years experience in X when X doesn't even exist that long yet. Tools and technology used in game development is very varied. It's impossible to have experience in every language and game engine on the planet fresh out of education.

After reading the article it seems to me I would never make any of these mistakes, at least on the technical level. This should mean I am qualified to develop games right? I mean if they could do it...

Yet I'm still having trouble right now trying to find a full-time job in an existing development company, even after winning an award in the latest Hilversum Gamejam. I could start for my own company but I don't have any friends that I both feel comfortable working with and have the time/interest in starting up something like that, and working alone sucks for motivation.

Maybe I should have been born in 1975...

Re:Thus demonstrating my assertion (1)

Anonymous Coward | about a year and a half ago | (#41274033)

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 various side projects he's worked on outside of class.

The people they're looking for DO exist, it's just that (in my experience) the vast majority of graduates are not those people. The amount of coding a computer science degree forces upon you isn't enough to make you employable to a lot of places.

Re:Thus demonstrating my assertion (0)

Anonymous Coward | about a year and a half ago | (#41274921)

It is a computer science degreee and not a programming degree.

Re:Thus demonstrating my assertion (1, Troll)

pjt33 (739471) | about a year and a half ago | (#41275329)

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.

Re:Thus demonstrating my assertion (1)

godrik (1287354) | about a year and a half ago | (#41274439)

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:Thus demonstrating my assertion (2, Insightful)

Anonymous Coward | about a year and a half ago | (#41276259)

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, not a fresh out of college newbie programming failure.

Causation. Learn it. What really causes the crap? (5, Insightful)

VortexCortex (1117377) | about a year and a half ago | (#41273513)

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.

Re:Causation. Learn it. What really causes the cra (1)

SplashMyBandit (1543257) | about a year and a half ago | (#41276101)

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 affected everyone in the team. It is a surprised one of the more senior devs didn't see the problem coming and rectify it - but then most commericial games have insanely ambitious development timelines. Fortunately, mine game does not (since, as an 'indie', I'm not relying on it for my main income; and I'm not burning much capital on it either; slower to market, but guaranteed to be a better base for a long lived product line :) re-using the good code in later versions is where I'll make the real money).

Ignorance + Ego (5, Interesting)

Anonymous Coward | about a year and a half ago | (#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.

It's very common with programmers (2)

Sycraft-fu (314770) | about a year and a half ago | (#41274081)

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.

Re:It's very common with programmers (2)

Boronx (228853) | about a year and a half ago | (#41275265)

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

Re:It's very common with programmers (1)

SplashMyBandit (1543257) | about a year and a half ago | (#41276157)

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 would always implement the idea better. However, and this is what I think made these guys even greater in the end, eventually Sun realized that despite their impressive talents the bulk of great ideas was not actually in the room with them but actual out in the rest of the World (with customers and competitors), "The smartest guys work for someone else". Sun then started to outreach a bit and incorporated good ideas. Unfortunately, due to the impossibility of getting Sun stuff quickly and easily (their sales teams were ponderous and mental in the Internet Age - it was hard to buy their stuff without going through all the sale's teams hoops; despite the Sun gear being reliable and competitively priced) the company died.

So, if even the awesome Sun guys can humbly realize that they can learn from others (that is, sometimes others are just as smart or smarter) then perhaps we all ought to as well. ... I'd better follow my own advise I guess ... :)

Re:Ignorance + Ego (2)

Bengie (1121981) | about a year and a half ago | (#41274787)

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 (3, Informative)

ediron2 (246908) | about a year and a half ago | (#41274825)

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

Re:Thus demonstrating my assertion (1)

Fantasio (800086) | about a year and a half ago | (#41273595)

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.

Re:Thus demonstrating my assertion (0)

Anonymous Coward | about a year and a half ago | (#41273795)

Now tell us what projects have you done that are actually more impressive than theirs, tough guy :-)

Re:Thus demonstrating my assertion (0)

Anonymous Coward | about a year and a half ago | (#41275295)

Yeah. That's why I after 10 years running my own game company (writing the framework and most of the game code) I left for Google.

Re:Thus demonstrating my assertion (0)

Anonymous Coward | about a year and a half ago | (#41276941)

The *really* crazy thing is that he explains that it's important to have some kind of optimized doubly-fuzzing-whatever-mod-on-a-linked-list so that it's easy to "save game", allowing to "easily" save hundreds and hundreds of units positions etc.

However back then several games were already using deterministic game engines and only saving player inputs (and the time at which they happened) and the PRNG and then could recreate any game state: for debugging, to offer replay functionality and to offer the "save game / resume" functionality.

Warcraft 3 does it that way: only saving player inputs in the replay files (which is why a long height-players game where every player has a lot of units fits in a tiny replay file).

But anyway: they did deliver and it is all that matter. WarCraft 2 was amazing (I was using Kali to simulate a LAN over the Internet to play competitive WC2), StarCraft 1 was amazing and then... WarCraft 3 came and there are still players playing WC3 *today*.

But, yup, it's amazing to see how much crap they can come up with and yet deliver block buster titles.

Criminally Insane (2)

Mr. Underbridge (666784) | about a year and a half ago | (#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 (5, Informative)

Anonymous Coward | about a year and a half ago | (#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:Criminally Insane (1)

Anonymous Coward | about a year and a half ago | (#41274769)

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.

Re:Criminally Insane (1)

Anonymous Coward | about a year and a half ago | (#41275309)

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.

Re:Criminally Insane (0)

Anonymous Coward | about a year and a half ago | (#41275991)

If you use STL's allocation, you are then hit with creation + assignment of objects (at least the implementations I looked at - Visual Studios and Gnu's). If only STL could use in-place new. I'm sure there is a reason why it couldn't, but it ends up being rather expensive.
The big advantage to STL is that it a) works rather well and b) it is typically all in-line code and modern compilers optimize that very nicely.
I always tell my developers, use STL first, if, at some future date we determine that the STL is the biggest performance bottle neck, then we will replace it with something we spun ourselves. I'm guessing here, but 80% of the STL collections we use are wrapped in other classes with mutexes etc. So replacement, if it ever was needed, would be easy.

Re:Criminally Insane (0)

Anonymous Coward | about a year and a half ago | (#41276081)

If you use STL's allocation, you are then hit with creation + assignment of objects (at least the implementations I looked at - Visual Studios and Gnu's). If only STL could use in-place new. I'm sure there is a reason why it couldn't, but it ends up being rather expensive.

Older compilers often lacked (or failed to consistently apply) the Return Value Optimization. I assume this had gotten better by the mid-2000s, but I've never actually checked. Once move constructors from the C++11 standard are widely supported (adoption of new language/library features shouldn't be as slow as it used to be), writing custom STL allocators that are efficient across implementations should be straightforward.

- T

Re:Criminally Insane (2)

AuMatar (183847) | about a year and a half ago | (#41274797)

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:Criminally Insane (2, Interesting)

Anonymous Coward | about a year and a half ago | (#41275483)

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 object linked list.

I suspect more errors occurred when the object was removed from one list, but ended up still live in another list. That was the hack. First the object existed in one area, but they needed another list to cut cycles, so they reused pointers and ended up with using deleted memory.

The cause of this is not simply "crap programming", but crappy design. Or perhaps "moving target" during development.

Re:Criminally Insane (2)

autocannon (2494106) | about a year and a half ago | (#41275051)

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 pointers....a lot. And think they're so god damn smart that they never ever have to check them for null.

Re:Criminally Insane (0)

Anonymous Coward | about a year and a half ago | (#41275243)

+1 insightful (actually modded you that)

I absolutely hate dealing with those kinds of developers.

Inexcusable (0)

Anonymous Coward | about a year and a half ago | (#41273609)

Given the freely available sys/queue.h from FreeBSD [active-venture.com], which provides macros for several different list types and the common operations on each, this is inexcusable.

Re:Inexcusable (1)

Octorian (14086) | about a year and a half ago | (#41273685)

Macros I actually used extensively when I was in college, and wanted to use common data structures in C code. Of course I only knew about those macros because I knew people who were very involved in FreeBSD that told me about them. (Though writing common functions for linked-list implementations is something you kinda learn in FRESHMAN level CompSci classes.)

these days: STL and Boost (0, Insightful)

Anonymous Coward | about a year and a half ago | (#41273797)

These days nobody should be writing there own containers, except in VERY atypical situations that don't arise for most people. There are perfectly good implementations of both intrusive and unintrusive containers in STL and Boost, and if you aren't using them, you are being incompetent.

Re:these days: STL and Boost (4, Insightful)

CastrTroy (595695) | about a year and a half ago | (#41273949)

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.

Re:these days: STL and Boost (0)

Anonymous Coward | about a year and a half ago | (#41274031)

Yes, agreed - I should have been more clear in what I wrote. I do realize SC was written a long time ago and this wasn't an option at the time. I was mostly trying to contrast to how things are today, not trying to blame them in any way. My fault for poorly communicating.

You had to have been there (5, Interesting)

The Optimizer (14168) | about a year and a half ago | (#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.

Re:You had to have been there (-1)

Anonymous Coward | about a year and a half ago | (#41274079)

I'm sorry, but no, at that point in time most of us coding then were not worried about "saving two bytes" or squeezing every CPU cycle out of development. Efficient code was important, but there still had to be a balance. If caught between saving a couple of instruction cycles and writing my own inline memory management or a standard memory function for a linked-list, you can be sure I'd use the standard game-wide function.

Yes, CPU cycles were important, but so was developer and debugging time. Even when I was working on Assembly code in 90s in order to gain more performance I was still calling tried and tested memory handling functions to avoid mistakes like the ones laid out in the article.

Re:You had to have been there (0, Insightful)

Anonymous Coward | about a year and a half ago | (#41274193)

If only you had a 5 digit UID to lend any credence to your history in the industry.

Re:You had to have been there (0)

Anonymous Coward | about a year and a half ago | (#41274489)

A 5 digit UID? Maybe you should look at his post again. He joined *before* Slashdot even had UIDs. You did too, but I suspect that you're getting too old and can't remember.

A low UID means ... (1, Insightful)

Anonymous Coward | about a year and a half ago | (#41274845)

If only you had a 5 digit UID to lend any credence to your history in the industry.

A low UID means that you know about slashdot a long time ago. It does not mean a damn thing on any other topic.

The GP has point. There was a balance, even in the mid to late 90s. The GGP overstates things, if you were worried about the overhead of calling a common function you made that function an inline or macro. And the fact that my current slashdot account has a 7 digit UID in no way changes the fact that I actually worked on Starcraft and know Pat Wyatt and his partner in crime Mike O'Brien.

Re:A low UID means ... (1)

jittles (1613415) | about a year and a half ago | (#41275689)

A low UID doesn't even mean that. I started reading Slashdot in 1999. My UID is from only a few years ago. The only reason I ever even registered an account was to post on a topic I felt very strongly about. So no, I don't put any stock in UIDs at all.

Re:A low UID means ... (1)

Bengie (1121981) | about a year and a half ago | (#41277125)

Ditto, but I would have loved to have the epeen factor. I did have an ICQ number in the 1mil range......

Re:You had to have been there (2)

b4dc0d3r (1268512) | about a year and a half ago | (#41274147)

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 and fixed, but a lot of bigger compiler companies licensed other STL providers, making an incestuous mess of versions.

I never really embraced the STL from that point, using only the patched VECTOR which I could be relatively confident would work without slicing off entries above the first 64k.

According to wikipedia and supplemental info, here's how the STL spread:

HP (1994) -> SGI (1997) -> STLPort
+- probably underpinned Rogue Wave -> Apache
libg++ > libstdc++
Dinkum -> Microsoft VC++

I didn't immediately find info on how much Dinkum or libg++ relied on the original HP implementation, if at all, but Dinkum's STL was out in 1995, which seems like fast turnaround for one guy.

Re:You had to have been there (1)

cicuz (1414125) | about a year and a half ago | (#41274331)

Juicy stuff, here.. Please write a blog post as well? Would love it, and thanks for the work you did anyway ;)

Re:You had to have been there (1)

SplashMyBandit (1543257) | about a year and a half ago | (#41276207)

> "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 years - and resulted in problems (which grizzled Slashdotters remember) and bad perceptions which no amount of PR money is making go away.

Saving 2 bytes here and there but being so frantic you miss out on big optimizations is not the mark of a heroic programmer or heroic era. It is the mark of people that were then too new to know that "software engineering" requires thought and planning, not caffeine-drenched seat-of-the-pants hackery.

Re:You had to have been there (0)

Anonymous Coward | about a year and a half ago | (#41276675)

The hell are you talking about. Quake used QuakeC for the game, and ran on a 486/66 with 16MB. That's the difference between someone who knows what he's doing, and morons who try to do everything by hand in C++.

Pfft, Starcraft (0)

Anonymous Coward | about a year and a half ago | (#41273951)

Myth is still superior in every department.

Re:Pfft, Starcraft (2)

DahGhostfacedFiddlah (470393) | about a year and a half ago | (#41275513)

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?

Class Hierarchy (1)

phantomfive (622387) | about a year and a half ago | (#41274005)

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.

Re:Class Hierarchy (0)

Anonymous Coward | about a year and a half ago | (#41274615)

Oh god it's just like MFC.

Aaaaaaaaaaaaaaaaaaaaaaaaahhhhhhh.

Oh god even the captcha knows: Atrocity.

Good read, thank you. (0)

Anonymous Coward | about a year and a half ago | (#41276263)

That is all.

really? (1)

amoeba1911 (978485) | about a year and a half ago | (#41276435)

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! Looking at bugs, they have some weird funky bugs, for example pressing two keys simultaneously in Diablo 3 made the wizard completely invulnerable. What kind of crappy coder lets that get in there?

Re:really? (1)

Hsien-Ko (1090623) | about a year and a half ago | (#41276555)

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 (1)

berniemne (2116414) | about a year and a half ago | (#41276979)

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.

Horrible, awful inaccuracy in post. (0)

Dahamma (304068) | about a year and a half ago | (#41277289)

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

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...