Back before the dawn of time, which is to say when PC games were written for the DOS operating system, I got to work on a game called Warcraft.
I get to lead a project!
While I had developed several PC games, a couple of Mac games, and seven console titles for the Super Nintendo and Sega Genesis, I was either in a junior role on those projects, or the projects were game “ports” rather than original development work. A game “port” is the process of moving a game from one platform, like the Amiga, and converting the code, design, artwork and other game assets to make them work on another, like the Nintendo.
My role encompassed two jobs: leading the development team as Producer – a game industry term for project manager, designer, evangelist, and cat herder – and writing the majority of the game code as Lead Programmer. This was perhaps less daunting then, when a game project might employ 10 or 20 developers, than it is now, with development teams tipping the scales at two-hundred or more developers.
The source of Warcraft
The developers at the startup I worked for – then named Silicon & Synapse but later renamed Blizzard in a nod towards our tempestuous development methodology – played a great many games during our free time. And from that game-playing came the spark to create Warcraft.
We were inspired to create Warcraft after playing (and replaying and replaying) a game called Dune 2, by Westwood Studios. Dune 2 was arguably the first modern real-time strategy (RTS) game with a scrolling world map, real-time unit construction and movement, and individual unit combat. It isn’t that much different in design than a modern RTS like Starcraft 2, excepting perhaps a certain scale and graphics quality.
Its predecessor, Dune 1 – a very worthy game itself – shared some of the same elements, but its semi-real-time unit combat was wrapped inside an adventure game. Dune 2 stripped its predecessors’ idea of the player representing a character inside the game-world and focused exclusively on the modern RTS mechanics: harvesting resources, building a base, harvesting more resources, building an army, and finally, finding and conquering the enemy.
![dune 2](https://www.kotaku.com.au/wp-content/uploads/sites/3/2021/09/05/dune-2-rts-1.jpg)
Along with the other folks at Blizzard I exhaustively played Dune 2 during lunch breaks and after work, playing each of the three competing races to determine their strengths and weaknesses; and afterward comparing play-styles, strategies and tactics with others in the office.
While the game was great fun, it suffered from several obvious defects that called out (nay, screamed) to be fixed. Most notably, the only way that my friends and I could play the game was against the computer. It was obvious that this gaming style would be ideal as a multiplayer game. Unlike turn-based games, where each player must wait for all opponents to issue unit movement orders, a real-time game would enable all players to give orders simultaneously, placing a premium on rapid, decisive tactical movements over long, drawn-out strategic planning.
And with that singular goal in mind, development of the game began without any serious effort to plan the game design, evaluate the technical requirements, build the schedule, or budget for the required staff. Not even on a napkin. Back at Blizzard we called this the “business plan du jour”, which was or standard operating methodology.
Initial development
As the sole developer on the project, and lacking an art team during the initial phase, I screen-captured the artwork of Dune 2 to use until such time as my forward progress warranted an artist or two. The artists were tied up working on any number of other pressing deadlines and didn’t need distractions at this point – we were always pressed for time.
My early programming efforts developing the game engine included creating a tile-based scrolling map renderer, a sprite renderer to draw game units and other bitmaps, a sprite-sequencing engine to animate game units, an event-dispatcher to post mouse and keyboard events, a game-dispatcher to control unit-behaviour, and a great deal of user-interface code to control application behaviour. With this subset of the project completed in the first few weeks it became possible to “play” a solo game, though I didn’t implement unit-construction until sometime later; early play required using typed commands to spawn units on screen.
Each day I’d build upon the previous efforts in organic fashion. Without schedule milestones or an external driver for the project, I was in the enviable position of choosing which features to build next, which made me incredibly motivated. I already enjoyed game development, and getting to do this green-field programming was like a drug. Even now, some 22 years after getting into the game industry, I still love the creative aspects of programming.
The first unique feature: multi-unit selection
![](https://www.kotaku.com.au/wp-content/uploads/sites/3/2021/09/05/warcraft-multi-unit-selection-1.jpg)
One feature of which I was particularly proud was unit-selection. Unlike Dune 2, which only allowed the user to select a single unit at a time, and which necessitated frenzied mouse-clicking to initiate joint-unit tactical combat, it was obvious that enabling players to select more than one unit would speed task-force deployment and dramatically improve game combat.
Before I started in the game industry I had worked extensively with several low-end “Computer Assisted Design” (CAD) programs like MacDraw and MacDraft to design wine-cellars for my dad’s wine cellar business, so it seemed natural to use the “click & drag” rectangle-selection metaphor to round up a group of units to command.
I believe that Warcraft was the first game to use this user-interface metaphor. When I first implemented the feature it was possible to select and control large numbers of units at a time; there was no upper limit on the number of units that could be selected.
While selecting and controlling one hundred units at a time demonstrated terrible weaknesses in the simple path-finding algorithm I had implemented, after I got the basic algorithms working I nevertheless spent hours selecting units and dispatching game units to destinations around the map instead of writing more code; it was the coolest feature I had ever created in my programming career up to that time!
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. We later increased this number to nine in Warcraft II. Command and Conquer, the spiritual successor to Dune 2, didn’t have any upper bound on the number of units that could be selected. It’s worth another article to talk about the design ramifications, for sure.
Apart from the ability to control multiple units at one time, at this phase Warcraft resembled nothing so much as a stripped-down version of Dune 2, so much so that I defensively joked that, while Warcraft was certainly inspired by Dune 2, the game was radically different – our radar minimap was in the upper-left corner of the screen, whereas theirs was in the lower-right corner.
The formation of the fellowship
By early 1994, I had made enough progress to warrant additional help on the project. I was joined by Ron Millar, Sam Didier, Stu Rose, Bob Fitch, Jesse McReynolds, Mike Morhaime, Mickey Nielsen, and others. Many of these folks started work on the game after our company was acquired by Davidson & Associates in February 1994.
Ron Millar, who, with his long blond hair, strong build, and bar-fighting skills that he regularly saw fit to utilise (I saw him fight three times), was obviously the progeny of Viking warriors. He was originally hired on as an artist based on his skill in creating artwork for Gameboy titles at Virgin Games, but his amazing creativity and design sensibilities led to his taking on a design role in many Blizzard projects, and he stepped into a similar role for Warcraft.
Sam Didier, a strong, stocky and stalwart character who resembled nothing so much as a bear scaled down to human proportions, and whose heroic characters and epic drawings are now the definitive art style for Blizzard games, had honed his computer drawing skills on sixteen-bit console titles, but his penchant for drawing fantasy artwork during meetings and at any other spare moment demonstrated his capability to lead the art direction for this new title.
Stu Rose – whose background as an illustrator led to his design of the Blizzard logo still used today – initially contributed to the background tile-map artwork, but he would later take on a critical role in the ultimate design of Warcraft. Stu is quite memorable as a voice actor in the role of Human Peon, where his rendition of a downtrodden brute-labourer was comedic genius.
Bob Fitch had started work as a programmer and project lead on another title at the same time I started development of Warcraft. Allen Adham, the president of Blizzard, had assigned Bob the task of building a word game called “Games People Play” that would include crossword, scramble, boggle, and other similar diversions. Bob’s notable lack of enthusiasm for the project resulted in his making little progress on the title for many months; with Warcraft showing well Bob was released to assist me, and his enthusiasm for the game helped move the project forward more rapidly.
Jesse, a Caltech graduate, started work on building a network driver for the IPX network protocol so the game could be played on a Local Area Network (LAN). Mike Morhaime, one of the two co-founders of Blizzard, later took on the significantly more difficult task of writing a “mixed-mode” modem driver. While Warcraft was a DOS “Protected Mode” game, the modem driver could be called from both Protected Mode and Real Mode due to quirks in the DOS operating system and the 80386 chip-architecture it ran on, so he could regularly be found in his office staring at screens full of diagnostic numbers as he worked through the complicated timing issues related to re-entrant code. At the end of the day, the modem code was rock-solid, quite an achievement given the primitive toolset we had at the time.
Warcraft art
Allen Adham hoped to obtain a licence to the Warhammer universe to try to increase sales by brand recognition. Warhammer was a huge inspiration for the art-style of Warcraft, but a combination of factors, including a lack of traction on business terms and a fervent desire on the part of virtually everyone else on the development team (myself included) to control our own universe nixed any potential for a deal. We had already had terrible experiences working with DC Comics on “Death and Return of Superman” and “Justice League Task Force”, and wanted no similar issues for our new game.
It’s surprising now to think what might have happened had Blizzard not controlled the intellectual property rights for the Warcraft universe – it’s highly unlikely Blizzard would be such a dominant player in the game industry today.
Years after the launch of Warcraft my dad, upon returning from a trip to Asia, gave me a present of a set of Warhammer miniatures in the form of a skeleton charioteer and horses with the comment: “I found these cool toys on my trip and they reminded me a lot of your game; you might want to have your legal department contact them because I think they’re ripping you off.” Hmmm!
Blockers to game development
One interesting facet of the early development process was that, while I was building a game that would be playable using modems or a local area network, the company had no office LAN. Because we developed console titles, which would easily fit on a floppy disk, it wasn’t something that was necessary, though it would certainly have simplified making backups.
So when I started collaborating with other artists and programmers, we used the “sneaker network”, carrying floppy disks back and forth between offices to integrate source code revisions and artwork.
Bob Fitch was the second programmer on the project, and he and I would regularly copy files and code-changes back and forth. Periodically we’d make integration mistakes and a bug we fixed would re-appear. We’d track it down and discover that – during file-copying while integrating changes – we had accidentally overwritten the bug fix, and we’d have to remember how we had fixed it previously.
This happened more than a few times because of the rapidity with which we developed code and our lack of any processes to handle code-integration other than “remembering” which files we had worked on. I was somewhat luckier in this regard in that my computer was the “master” system upon which we performed all the integrations, so my changes were less likely to get lost. These days we use source-control to avoid such stupidities, but back then we didn’t even know what it was!
With more programmers, designers and artists working on the title progress increased substantially, but we also discovered a big blocker to our progress. The game was initially developed in DOS “Real Mode”, which meant that only 640K of memory was available, less about 120K for the operating system. Can you believe how crap computers were back then!?!
As the art team started creating game units, backgrounds and user-interface artwork, we rapidly burned through all of the memory and started looking for alternatives. A first attempt at a solution was to use EMS “paged memory” mapping and store art resources “above” the 640K memory barrier.
Stories programmers tell about EMS memory are like those that old folks tell about walking uphill to school, barefoot, in the snow, both ways, except that EMS stories are even more horrible, and actually true.
In any event the EMS solution quite fortunately didn’t work; it turned out there was a better solution. A company called Watcom released a C compiler which included a DOS-mode “extender” that allowed programs to be written in “Protected Mode” with access to linear 32-bit memory, something every programmer takes for granted today when they write 32-bit (or even 64-bit applications). While it required a couple of days to update the source code, the DOS-mode extender worked perfectly, and we were back in business, now with access to substantially more memory.
As a game developer with more than 22 years in the industry Patrick has helped build small companies into big ones (VP of Blizzard, Founder of ArenaNet, COO of En Masse Entertainment); lead the design and development efforts for best-selling game series (Warcraft, Diablo, Starcraft, Guild Wars); written code for virtually every aspect of game development (networking, graphics, AI, pathing, sound, tools, installers, servers, databases, ecommerce, analytics, crypto, dev-ops, etc.); designed many aspects of the games he’s shipped; run platform services teams (data center operations, customer support, billing/accounts, security, analytics); and developed state-of-the-art technologies required to compete in the AAA+ game publishing business. Patrick is currently the founder of the Seattle-based studio One More Game.
He blogs over on Code of Honour, which is where this story originally appeared and was republished with permission.
Leave a Reply