Patrick Wyatt is a veteran programmer who has been making games for over 20 years. He's begun writing a series of incredibly insightful blogs on the development of Starcraft and other older Blizzard games. This is a must read for all Starcraft fans.
I’ve been writing about the early development of Warcraft, but a recent blog post I read prompted me to start scribbling furiously, and the result is this three-part, twenty-plus page article about the development of StarCraft, along with my thoughts about writing more reliable game code. I’ll be posting the latter parts over the next several days.
This post: Why StarCraft crashed frequently during development
Part 2: How we could have fixed the most common causes
Part 3: Explaining the implementation details of the fix
The beginnings of 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.
Orcs in space
StarCraft was originally envisioned as a game with modest goals that could fit into a one-year development cycle so that it could be released for Christmas, 1996.
The project leadership was comprised of the same folks who had started Shattered Nations (video), a turn-based strategy game along the lines of X-COM that Blizzard announced in May 1995 but canceled some months later.
The team members were regrouped to build something that could reach market quickly so Blizzard wouldn’t have a long gap between game launches.
Q4 1994 – Warcraft Q4 1995 – Warcraft II Q4 1996 – planned ship date for StarCraft Q2 1998 – actual ship date for StarCraft
The decision to rush the game’s development seems ludicrous in retrospect, but Allen Adham, the company’s president, was under pressure to grow revenue. While Blizzard’s early games had been far more successful than expected, that just raised expectations for future growth.
Given a short timeframe and limited staff, the StarCraft team’s goal was to implement a modest game — something that could best be described as “Orcs in space”. A picture from around the time of the E3 game show in Q2 1996 shows the path the game team originally chose:
StarCraft as it appeared in May 1996 at the Electronic Entertainment Expo. Yeah — I wouldn’t play it either.
But a higher priority project overshadowed StarCraft and stole its developers one by one. Diablo, a role-playing game being developed by Condor Studios in Redwood City California, was in need of additional help. Condor, a company formed by Dave Brevik along with Max Schaefer and his brother Erich Schaefer, was given a budget of only $1.2 million — ridiculously small even in those days.
The Condor team had no hope of making the game they aspired to build, but they did such ground-breaking work in developing something fun that it made sense for Blizzard to acquire Condor, rename it Blizzard North, and start pouring in the money and staff the game really deserved.
Initially Collin Murray, a programmer on StarCraft, and I flew to Redwood City to help, while other developers at Blizzard “HQ” in Irvine California worked on network “providers” for battle.net, modem and LAN games as well as the user-interface screens (known as “glue screens” at Blizzard) that performed character creation, game joining, and other meta-game functions.
As Diablo grew in scope eventually everyone at Blizzard HQ — artists, programmers, designers, sound engineers, testers — worked on the game until StarCraft had no one left working on the project. Even the project lead was co-opted to finish the game installer that I had half-written but was too busy to complete.
After the launch of Diablo at the end of 1996, StarCraft development was restarted, and everyone got a chance to see where the game was headed, and it wasn’t pretty. The game was dated, and not even remotely impressive, particularly compared to projects like Dominion Storm, which looked great in demos at E3 six months before.
The massive success of Diablo reset expectations about what Blizzard should strive for: StarCraft became the game that defined Blizzard’s strategy of not releasing games until they were ready. But a lot of pain had to occur along the way to prove out this strategy.
Awesome I really enjoyed reading the 2 Warcraft blogs as well, definitely gained some insight into the early Blizzard and reasoning for how stuff ended up how it did. Look forward to more!
This is one of the most interesting things I've read in a long time. I love how so much of the development sounds like it was on the fly, simply gamers working hard to do something great.
The entire team worked long hours, with Bob working stretches of 40 hours, 42 hours, even 48 hours programming. As I recall no one else attempted these sorts of masochistic endeavors, though everyone was putting in massive, ridiculous hours.
My experiences developing Warcraft, with frequent all-nighters coding, and later Diablo, where I coded fourteen-plus hour days seven days a week for weeks at a time, suffered me to learn that there wasn’t any point in all-nighters. Any code submissions [ha! what an appropriate word] written after a certain point in the evening would only be regretted and rewritten in the clear light of following days.
Working these long hours made people groggy, and that’s bad when trying to accomplish knowledge-based tasks requiring an excess of creativity, so there should have been no surprises about the number of mistakes, misfeatures and outright bugs.
Incidentally, these sorts of crazy hours weren’t mandated — it was just the kind of stuff we did because we wanted to make great games. In retrospect it was foolish — we could have done better work with more reasonable efforts
Probably a lesson everyone in esports could learn from, but when you get really into something it's hard to stop even if you're in the middle of a 30 hour binge. Really excited for the next 2 parts.
Had to laugh when I got to the part about pathfinding:
More Band-Aids: path-finding in StarCraft I wanted to mention one more example of patching over bugs instead of fixing the underlying problem: when StarCraft switched from top-down artwork to isometric artwork, the background tile-graphics rendering engine, which dated back to code I had written in 1993/4, was left unchanged.
Rendering isometric-looking tiles using a square tile engine isn’t hard, though there are difficulties in getting things like map-editors to work properly because laying down one map tile on another requires many “edge fixups” since the map editor is trying to place diagonally-shaped images drawn in square tiles.
While rendering isn’t so bad, isometric path-finding on square tiles was very difficult. Instead of large (32×32 pixel) diagonal tiles that were either passable or impassable, the map had to be broken into tiny 8×8 pixel tiles — multiplying the amount of path-searching by a factor of 16 as well as creating difficulties for larger units that couldn’t squeeze down a narrow path.
Had Brian Fitzgerald not been a stellar programmer, the path-finding problem would have prevented the game from launching indefinitely. As it was pathing was one of the problems that was only finalized at the end of the project. I plan to write more about path-finding in StarCraft because there are lots interesting technical and design bits.
Loved this part, especially from the perspective of the aspiring computer science student that I am. It's a really fascinating insight, especially the parts about how buggy and convoluted the entire process turned out to be.
I can't wait for the upcoming part about pathfinding and perhaps hearing more insight into the design of the original Starcraft. He alluded to the control group selection limit design decision in his previous post about Warcraft 1, though I would be interested in his thoughts on the selection limit in Starcraft and whether the UI was limited from a technical or design standpoint.
Also, the part about voice chat was really interesting. I once went back and read archived scans of Starcraft 1 in old gaming magazines, and it was interesting to see voice chat as a planned feature along with a lot of other stuff that ended up getting cut like neutral creeps and outposts as well as random weather events. I wonder what Starcraft 1 would've looked like if the production had gone more smoothly with no limitations to what the designers planned on wanting. It might not resemble the long-standing esport that we have now, but maybe that hypothetical version of Starcraft might still be a really cool RTS in other ways.
On September 08 2012 17:40 eviltomahawk wrote: Loved this part, especially from the perspective of the aspiring computer science student that I am. It's a really fascinating insight, especially the parts about how buggy and convoluted the entire process turned out to be.
I can't wait for the upcoming part about pathfinding and perhaps hearing more insight into the design of the original Starcraft. He alluded to the control group selection limit design decision in his previous post about Warcraft 1, though I would be interested in his thoughts on the selection limit in Starcraft and whether the UI was limited from a technical or design standpoint.
Also, the part about voice chat was really interesting. I once went back and read archived scans of Starcraft 1 in old gaming magazines, and it was interesting to see voice chat as a planned feature along with a lot of other stuff that ended up getting cut like neutral creeps and outposts as well as random weather events. I wonder what Starcraft 1 would've looked like if the production had gone more smoothly with no limitations to what the designers planned on wanting. It might not resemble the long-standing esport that we have now, but maybe that hypothetical version of Starcraft might still be a really cool RTS in other ways.
Not entirely relevant to your post, but if you check out the beta version of Starcraft (there's a few threads about it on TL, although actually getting it nowadays is quite hard to do), the voice chat capability is actually still referenced in it (and there's a document about how to set it up). The 3rd party program doesn't seem to be included though, so there's no way to try it out.
I think one of the most interesting removals (that wasn't mentioned in this blog) is that SC Beta had observer mode (as in, it had 2 observer slots in the game lobby, and you could choose to go to observer mode when all your buildings died). I'd be really interested to know why that feature was removed, as its amazingly useful (and reproduced by many mapmakers since it was no longer in the game).
I can't imagine Starcraft without technological quirks. I think ironically, in a test of time it made a multiplayer competition even "more" infinite. Air unit stacking, vulture patrol micro and few others weren't intended after all yet made people rediscover starcraft many years after release.
On September 08 2012 17:56 bgx wrote: I can't imagine Starcraft without technological quirks. I think ironically, in a test of time it made a multiplayer competition even "more" infinite. Air unit stacking, vulture patrol micro and few others weren't intended after all yet made people rediscover starcraft many years after release.
ya I wonder if this guy realizes that some of these "bugs" made the game so much deeper ..
Ok I read through it with my morning coffee. I personally have been involved with starcraft since 98 and learned alot of things on the surface, but I was also familiar with Storm.DLL which made me smile when I heard more about it. Being a huge fan of the starcraft editor it was really cool to read about the programming, even though he haven't covered the editor build yet. Imagine the possibilites if the starcraft voice chat would have been implemented. Voice commands in editor makes me jizz just thinking of it. This blog also proves some long lived myths wrong and confirms other. Can't wait for next part!
It should give some people perspective when they whine that blizzard doesn't release as fast as it could. Or when people ask them to basically recode a lot of game's engine so they could get some feature that was in BW.
Found it quite interesting that they were already thinking about implementing in-game voice chat way back on their very first game to have internet-based multiplayer
The entire team worked long hours, with Bob working stretches of 40 hours, 42 hours, even 48 hours programming. As I recall no one else attempted these sorts of masochistic endeavors, though everyone was putting in massive, ridiculous hours. Working these long hours made people groggy, and that’s bad when trying to accomplish knowledge-based tasks requiring an excess of creativity, so there should have been no surprises about the number of mistakes, misfeatures and outright bugs. Incidentally, these sorts of crazy hours weren’t mandated — it was just the kind of stuff we did because we wanted to make great games. In retrospect it was foolish — we could have done better work with more reasonable efforts.
....
While I implemented some important features in StarCraft, including fog-of-war, line-of-sight, flying unit pathing-repulsion, voice-chat, AI reinforcement points, and others, my primary job gravitated to fixing bugs.
Wait: voice-chat! In 1998?!? Yeah: I had it all working in December 1997.
....
When I say “argued vehemently”, I should mention that was more or less the only way we knew how to argue at Blizzard — with our youthful brashness and arrogant hubris, there was no argument that wasn’t vehement unless it was what was for lunch that day, which no one much wanted to decide.
....
So you’ve heard me whine a bit about how difficult it was to make StarCraft, largely through poor choices made at every level of the company about the game’s direction, technology and design.
We were fortunate to be a foolhardy but valiant crew, and our perspicacity carried the day. In the end we buckled down and stopped adding features long enough to ship the game, and players never saw the horror show underneath.
Such a magical read. Everyone go read it! You don't have to know shit about programming to enjoy this. Thanks for sharing!
Incidentally, these sorts of crazy hours weren’t mandated — it was just the kind of stuff we did because we wanted to make great games. In retrospect it was foolish — we could have done better work with more reasonable efforts.
Incidentally, these sorts of crazy hours weren’t mandated — it was just the kind of stuff we did because we wanted to make great games. In retrospect it was foolish — we could have done better work with more reasonable efforts.
StarCraft became the game that defined Blizzard’s strategy of not releasing games until they were ready.
D3 anyone? :D Great read otherwise, regression from low budget > great games to the contrary is sad, and really makes me want to see developers as motivated and creative as they were for those games, quitting commercial BS as anyway their games would probably sell better if they were just good...
Incidentally, these sorts of crazy hours weren’t mandated — it was just the kind of stuff we did because we wanted to make great games. In retrospect it was foolish — we could have done better work with more reasonable efforts.
StarCraft became the game that defined Blizzard’s strategy of not releasing games until they were ready.
D3 anyone? :D Great read otherwise, regression from low budget > great games to the contrary is sad, and really makes me want to see developers as motivated and creative as they were for those games, quitting commercial BS as anyway their games would probably sell better if they were just good...
Well they had to release D3. It was getting ridiculous with all the delays.
But it's cool to think that we basically have Diablo (1) and Condor Studios to thank for the fact that StarCraft was such an awesome game and not "orcs in space". Just think about everything we would have missed (with SC2 also, since everything would have been different).
StarCraft became the game that defined Blizzard’s strategy of not releasing games until they were ready.
D3 anyone? :D Great read otherwise, regression from low budget > great games to the contrary is sad, and really makes me want to see developers as motivated and creative as they were for those games, quitting commercial BS as anyway their games would probably sell better if they were just good...
To be honest the community pushed it way too much lol. D3 got delayed a lot and I bet if Blizzard wouldn't be under the evil rule of Kottick we'd see it a year later or something...
And it wouldn't fail at almost everything. Now they gotta fix it, while it hurt the Blizzard brand.
I wonder, have programming standards in the gaming world generally improved since then? Or is still just a matter of hammering out any old slop to meet crazy release dates?
I don't know why haven't anyone thought of NOT releasing the date of the game's planned day and only release any information after the game have been complete. think about it, the crowd won't get pissed off, gives you time to fix any kinks, and plus you don't have to worry about stress but work comfortably so that your product's quality is certain to be on the top echelon.
Its kind of like giving you a nice buffer zone to not worry about it. Plus you can play around with the hype and manipulate the customer until finally they'll go "Oh, lads and gents, here is the moment you have been waiting for..." accented by the cries of millions of fans.
Perfect timing for me to learn about this blog. Just finished my database class this past summer and starting on compilers this fall, giving me enough knowledge to understand what he's talking about Great read. Thanks for sharing!
i read this article yesterday, i really look forward to part2 when he will talk about the pathing. It's a great read but i'm afraid it's a little bit hard to understand for non programmers
While I implemented some important features in StarCraft, including fog-of-war, line-of-sight, flying unit pathing-repulsion, voice-chat, AI reinforcement points, and others, my primary job gravitated to fixing bugs.
Does he know about muta-stacking and other tricks players eventually learned to do with their pathing algorithms?
It was BroodWar that made Blizzard THE best company out there. Diablo was fucking great, and Warcraft 2 was quite good. And then came StarCraft and Diablo 2 that made this company legendary. Korean BW scene made BW one of the first profesional e-sport game. Later we had WarCraft III (quite innovative game) and WoW (this one I ignored, so i dont know).
...And than SC2 came - a great single player game with multi much worse than its previous instalment. Trully step backward. And than... Diablo III, that I intentionally ignored to not support ActiBlizz, and from reading complains from internet it seems to be good decision.
At first, I thought it was going to be yet another post on the beginning of SC, "Orcs in space" etc, but no! This is amazing and gives some much insight into the development... Great read.
Blizzard will never be able to make games like this again. Strange to think what heros can make a company grow so great can eventually be hollowed out. Definitely interesting to see that it was a fluke that StarCraft even became considered for serious development, when the company was already ready for a 'modest' (read: mediocre) title release. That Diablo is what spurred it on and raised the bar, and also took enough time to make it out of date so that Blizzard released three stunning games in a row, W2, D1, SC, is fascinating. Then of course D2 and W3 did not betray this trend. It was only after WoW that the company really begun to phone it in. Not the initial release of WoW, exactly, but release after release of 'additional content' or what might be called 'modest' releases. Creativity and innovation are delicate things, stability and low aspirations are very tempting. Why build when you're already making money? When build when you're already making even more money?
While rendering isn’t so bad, isometric path-finding on square tiles was very difficult. Instead of large (32×32 pixel) diagonal tiles that were either passable or impassable, the map had to be broken into tiny 8×8 pixel tiles — multiplying the amount of path-searching by a factor of 16 as well as creating difficulties for larger units that couldn’t squeeze down a narrow path.
Yeah, Diablo 1 had A LOT of passion channeled through the game, and it went through to the development and resurrection of Starcraft as added pressure. Imagine Diablo 1 being mediocre or not released, Blizzard would be dead long ago.
It's also interesting to see how many features and issues were thought of and reworked or removed because of hardware limitation. I think voice chat would be pretty horrific in Starcraft due to many reasons, a major one is that playing the game with dialup would be even more painful.
The Starcraft article was amazing, and it also made me read his other articles, specifically one on Warcraft (1) development.
Here's an interesting snippet from that one:
Later in the development process, and after many design arguments between team-members, we decided to allow players to select only four units at a time based on the idea that users would be required to pay attention to their tactical deployments rather than simply gathering a mob and sending them into the fray all at once.
It debunks the popular notion that interface limitations were a technical necessity at the time, but also indicates that the developers considered the more mechanical - speed and multitasking - aspects of an RTS very early on (basically at the dawn of modern RTS) and based their design decisions around it.
On September 10 2012 05:09 Talin wrote: The Starcraft article was amazing, and it also made me read his other articles, specifically one on Warcraft (1) development.
Later in the development process, and after many design arguments between team-members, we decided to allow players to select only four units at a time based on the idea that users would be required to pay attention to their tactical deployments rather than simply gathering a mob and sending them into the fray all at once.
It debunks the popular notion that interface limitations were a technical necessity at the time, but also indicates that the developers considered the more mechanical - speed and multitasking - aspects of an RTS very early on (basically at the dawn of modern RTS) and based their design decisions around it.
Sent this article to a friend studying game design and he cringed at all the coding and design mistakes that are outline in the article. I wonder what Patrick Wyatt thinks about the success of BW in Korea?
Great article, especially interesting since I'm a software developer myself. Usually, you only hear the artwork, creative, and/or project lead guys talk about the development of a game. Here we finally learn more about the coding challenges from the programmers themselves. Awesome to read how a classic game like SC1/BW was developed back then.
You know, it's funny and relate-able how much of a mess their process is. It's just like that at my current company. Haha... didn't Samwise joke that it's still that way? I wouldn't doubt it.
On September 08 2012 17:56 bgx wrote: I can't imagine Starcraft without technological quirks. I think ironically, in a test of time it made a multiplayer competition even "more" infinite. Air unit stacking, vulture patrol micro and few others weren't intended after all yet made people rediscover starcraft many years after release.
ya I wonder if this guy realizes that some of these "bugs" made the game so much deeper ..
Basically, all the quirks are a wonderful accident. Kind of like Street Fighter 2. A lot of later development on that franchise was because of bugs in this game that people ended up liking.
On September 10 2012 05:09 Talin wrote: The Starcraft article was amazing, and it also made me read his other articles, specifically one on Warcraft (1) development.
Later in the development process, and after many design arguments between team-members, we decided to allow players to select only four units at a time based on the idea that users would be required to pay attention to their tactical deployments rather than simply gathering a mob and sending them into the fray all at once.
It debunks the popular notion that interface limitations were a technical necessity at the time, but also indicates that the developers considered the more mechanical - speed and multitasking - aspects of an RTS very early on (basically at the dawn of modern RTS) and based their design decisions around it.
They didn't consider the ideas of hand speed factoring in. In fact they were surprised people took that approach to the game.
They've made this clear since like 1999. People complained on their forums why couldn't they just select their whole army and attack-move? It's because they intended for you to micro your units more... in other words, they wanted it to play more like Warcraft; focusing on micro. Unfortunately, they didn't count on Koreans just simply moving their hands fast enough to overcome that limitation and SC became more about macro. They never intended the unit select limit as an obstacle for the player to overcome by hand speed. Like I said they were surprised by the Korean scene when they simply just "played faster".
They also added in the "fastest" game speed as a joke.
On September 10 2012 05:09 Talin wrote: The Starcraft article was amazing, and it also made me read his other articles, specifically one on Warcraft (1) development.
Here's an interesting snippet from that one:
Later in the development process, and after many design arguments between team-members, we decided to allow players to select only four units at a time based on the idea that users would be required to pay attention to their tactical deployments rather than simply gathering a mob and sending them into the fray all at once.
It debunks the popular notion that interface limitations were a technical necessity at the time, but also indicates that the developers considered the more mechanical - speed and multitasking - aspects of an RTS very early on (basically at the dawn of modern RTS) and based their design decisions around it.
They didn't consider the ideas of hand speed factoring in. In fact they were surprised people took that approach to the game.
They've made this clear since like 1999. People complained on their forums why couldn't they just select their whole army and attack-move? It's because they intended for you to micro your units more... in other words, they wanted it to play more like Warcraft; focusing on micro. Unfortunately, they didn't count on Koreans just simply moving their hands fast enough to overcome that limitation and SC became more about macro. They never intended the unit select limit as an obstacle for the player to overcome by hand speed. Like I said they were surprised by the Korean scene when they simply just "played faster".
They also added in the "fastest" game speed as a joke.
The last part I find quite funny actually, without the fastest game speed bw would most likely became what it did. Even I can macro really well on normal speed..
Saw this on slashdot and loved it, his insight just confirms why something like Broodwar isn't possible anymore given the development environment differences such as creativity and a willingness to take risks. Blizzard should be taking notes here. I liked his take on why BW made it big in korea too.
As a stand-in, I did implement “numbered group selection”. A user would select a group of units and press the Ctrl (control) key plus a number key (1-4). Those unit-groupings would be remembered so it would be possible to later re-select those units by pressing the number key (1-4) by itself. But those units would move independently even though selected as a group.
On September 10 2012 05:09 Talin wrote: The Starcraft article was amazing, and it also made me read his other articles, specifically one on Warcraft (1) development.
Here's an interesting snippet from that one:
Later in the development process, and after many design arguments between team-members, we decided to allow players to select only four units at a time based on the idea that users would be required to pay attention to their tactical deployments rather than simply gathering a mob and sending them into the fray all at once.
It debunks the popular notion that interface limitations were a technical necessity at the time, but also indicates that the developers considered the more mechanical - speed and multitasking - aspects of an RTS very early on (basically at the dawn of modern RTS) and based their design decisions around it.
They didn't consider the ideas of hand speed factoring in. In fact they were surprised people took that approach to the game.
They've made this clear since like 1999. People complained on their forums why couldn't they just select their whole army and attack-move? It's because they intended for you to micro your units more... in other words, they wanted it to play more like Warcraft; focusing on micro. Unfortunately, they didn't count on Koreans just simply moving their hands fast enough to overcome that limitation and SC became more about macro. They never intended the unit select limit as an obstacle for the player to overcome by hand speed. Like I said they were surprised by the Korean scene when they simply just "played faster".
They also added in the "fastest" game speed as a joke.
Did you just make that up? This is completely backwards.
"Play more like warcraft?" WHAT? Warcraft 2 was a macro game.
Back then RTS was macro, spell casting and attack moving(and micro and macro didn't exist as game related terms), there wasn't any "real" micro. That's why they didn't have auto-mine and had a limited unit selection - they wanted to keep players busy, so claiming they didn't consider hand speed factoring in is ridiculous. If they didn't intend for hand speed to be a factor or wanted players to focus on micro more, they would've allowed selecting and producing from unlimited number of buildings at the same time and would have auto-mining. Warcraft 2 players even complained that adding queues and rally points made the game too noob friendly ffs!
It was the effectiveness of actual micro(i.e. not just attack moving) that was discovered and which the developers hadn't anticipated, that's why the first very famous player - Boxer was a micro oriented player. All the bugs that players like are ones that add micro to the game. The macro revolution came later, because players had to micro and macro optimally at the same time. As much as Oov is regarded as a macro player, he had top notch micro at the same time, which allowed him to take expansions earlier and survive with smaller armies until his better economy kicks in, he didn't simply click factories faster and attack move groups of 12 units faster.
On September 09 2012 07:58 Xiphos wrote: I don't know why haven't anyone thought of NOT releasing the date of the game's planned day and only release any information after the game have been complete. think about it, the crowd won't get pissed off, gives you time to fix any kinks, and plus you don't have to worry about stress but work comfortably so that your product's quality is certain to be on the top echelon.
Its kind of like giving you a nice buffer zone to not worry about it. Plus you can play around with the hype and manipulate the customer until finally they'll go "Oh, lads and gents, here is the moment you have been waiting for..." accented by the cries of millions of fans.
On September 10 2012 05:09 Talin wrote: The Starcraft article was amazing, and it also made me read his other articles, specifically one on Warcraft (1) development.
Later in the development process, and after many design arguments between team-members, we decided to allow players to select only four units at a time based on the idea that users would be required to pay attention to their tactical deployments rather than simply gathering a mob and sending them into the fray all at once.
It debunks the popular notion that interface limitations were a technical necessity at the time, but also indicates that the developers considered the more mechanical - speed and multitasking - aspects of an RTS very early on (basically at the dawn of modern RTS) and based their design decisions around it.
Wow.......
I really hope he's aware of the true extent of what their game has become
On September 11 2012 02:12 Chef wrote: Pretty sure Total Annihilation had unlimited unit selection in 1997. Pretty hilarious people think that was a hardware limitation.
C&C from 1995 had unlimited or very high limitation aswell, and Total annihilation blew up all competition in terms of technological advacement even 2 years past its release. So ye the technology "was there".
Starcraft was regarded as slightly technologically behind vs competition. By that i dont mean art, gameplay design, etc. I think the design of limited unit selection was first a homage to warcraft line, like said in Warcraft 1 you could select 4 units, in wc2 you could select 9 or 6 (cant remember) in Sc1 you can select 12.
I remember when i first played starcraft demo and was already a veteran of C&C/other RTS i simply accepted it as game distinctive design, it was a specially apparent for people who played both C&C/red alert and WC2 at times as they were releaesd because red alert and wc2 were not that far away and both were competing, and a red alert was played totally different to how wc2 was played yet both were regarded as best games of its genre, even if in Red alert you could make 50 tanks and group them with 1 mouse swing it didnt make it clearly superior (note: but generally Red Alert was a better game ^^)
I think it was part of game series defining features to put unit limitations, other games never had unit potrait, for example it enabled unit portait selection to that extent that later turned out into certain gameplay mechanic (disselection, cloning). So in fact those "limitations" (whether they were designed or was side effect of technological procceses) gave birth to total new way of playing RTS and dethroned Westwood style of RTS forever. (And i am one of the biggest C&C1 fanboys, and i said that).
I have been looking for a quote I read several years ago regarding the development of Starcraft 1. It concerns how the crew worked 24/7 to finish the game and focus on making it an esport. Since then I have not been able to find the quote but I wish I had it available when someone claims Star1 was a fluke of game design.
i laughed so hard when he talked about how they abused inheritance, and the whole section about how they hacked in their own linked list code instead of reusing the one in storm.dll
this guy should totally write a book about this. a lot of the lessons they learned "favor composition over inheritance" are commonly accepted wisdom now, but its not really taught in schools.
Great read! Was really fun and interesting! Can't believe Starcraft is the result of trying to live up to a fake demo!
Also:
Some projects were pushed onto unwilling dev team members, including projects like Games People Play (a crossword puzzle game that died because the team lead was so unmotivated),
Some projects were pushed onto unwilling dev team members, including projects like Games People Play (a crossword puzzle game that died because the team lead was so unmotivated),
I missed this the first time around. Great stuff. Funny to think how gamer expectations have changed with Blizzard's growth and success. As someone of the first page mentioned, SC1 was made in an "on the fly" style. It makes good history yet it appears like poor planning with regard to the game release deadline. I only mention this because I think a lot of the hardcore Blizz playerbase has standards for Blizzard work that assumes the capacity of a developer to "perfectly" execute a game and its release when, in fact, a good game can come out of even the most flawed and awkward of processes.
Hasn't LotV been extensively critiqued for being too "on the fly"?
On November 05 2015 05:29 skatbone wrote: I missed this the first time around. Great stuff. Funny to think how gamer expectations have changed with Blizzard's growth and success. As someone of the first page mentioned, SC1 was made in an "on the fly" style. It makes good history yet it appears like poor planning with regard to the game release deadline. I only mention this because I think a lot of the hardcore Blizz playerbase has standards for Blizzard work that assumes the capacity of a developer to "perfectly" execute a game and its release when, in fact, a good game can come out of even the most flawed and awkward of processes.
Hasn't LotV been extensively critiqued for being too "on the fly"?
sort of. it's also been criticized for not being ambitious enough with its changes.
i also think a lot of people realize that a good percentage of BW's success and outstanding design was essentially an accident, or good luck.
On September 14 2012 10:35 Falling wrote: Yeah, the second part is super technical so I don't understand it at all. I'm sure some programmers out there would really appreciate it.
For me, it was just a review of the coding knowledge I learned in school lol. Still, it's always great to read a pro's perspective on why he favors certain data structures over another. However, these days computer hardware is so good you can use the STL pretty liberally instead of having to choose a data structure for the reasons he posted. Unless your like blizzard, and try to make games like WoW still run on Win98 lol.
On November 05 2015 18:45 iloveav wrote: Its sad that the most interesting things about games nowdays is how they made the old ones instead of the new games.
its part of industry maturation...
Ford inventing the assembly line and the dawn of the mass production era was more interesting than watching GM beg governments for cash and lie about whether their cars need to be recalled
the very first console war is 1,0000 times more interesting than this PS4 v. XBOX1 thing.
EPT
![[image loading]](http://www.codeofhonor.com/blog/wp-content/uploads/2012/09/Starcraft-orcs-in-space.png)
I really enjoyed reading the 2 Warcraft blogs as well, definitely gained some insight into the early Blizzard and reasoning for how stuff ended up how it did. Look forward to more!
