The Making of Warcraft's Multiplayer
November 12, 2012 Page 3 of 4
The First Multiplayer Game of Warcraft
In June 1994, after 10 months of development, the game engine was nearly ready for multiplayer. It was with a growing sense of excitement that I integrated the code changes that would make it possible to play the first-ever multiplayer game of Warcraft. While I had been busy building the core game logic (event loop, unit-dispatcher, pathfinding, tactical unit-AI, status bar, in-game user-interface, high-level network code) to play, other programmers had been working on related components required to create a multiplayer game.
Jesse McReynolds, a graduate of Caltech, had finished coding a low-level network library to send IPX packets over a local-area network. The code was written based on knowledge gleaned from the source code to Quake, which had been recently open-sourced by John Carmack at id software. While the IPX interface layer was only several hundred lines of C code, it was the portion of the code that interfaced with the network card driver to ensure that messages created on one game client would be sent to the other player.
And Bob Fitch, who was earning his master's degree from Cal State Fullerton, developed the initial "glue screens" that enabled players to create and join multiplayer games. My office was next to Bob's, which was mighty convenient, since it was necessary for us to collaborate closely to integrate his game join-or-create logic to my game-event loop.
After incorporating the changes, I compiled the game client and copied it to a network drive while Bob raced back to his office to join the game. In what was a minor miracle, the code we'd written actually worked, and we were able to start playing the very first multiplayer game of Warcraft.
As we started the game I felt a greater sense of excitement than I'd ever known playing any other game. Part of the thrill was in knowing that I had helped to write the code, but even more so were two factors that created a sense of terror: playing against a human opponent instead of a mere computer AI, and more especially, not knowing what he was up to because of the fog of war.
The Fog of War
One of the ideas drawn from earlier games was that of hiding enemy units from sight of the opposing player. A black graphic overlay hid areas of the game map unless a friendly unit explored the area, which is designed to mimic the imperfect information known by a general about enemy operations and troop movements during real battles.
Empire, a multiplayer turn-based strategy game written almost seventeen years before by the brilliant Walter Bright (creator the "D" programming language), used fog of war for that same purpose. Once an area of the map was "discovered" (uncovered) it would remain visible forever afterwards, so an important consideration when playing was to explore enough of the map early in the game so as to receive advance warning of enemy troop movements before their incursions could cause damage to critical infrastructure or economic capability.
The psychological terror created by not knowing what the enemy is doing has been the demise of many generals throughout history, and adding this element to the RTS genre is a great way to add to the excitement (and fear) level. Thank Walter and the folks at Westwood who created Dune II for their savvy!
As many gamers know, computer-controlled "Artificial Intelligence" (AI) players in strategy games are often weak. It's common for human players to discover exploits that the computer AI is not programmed to defend against that can be used destroy the AI with little difficulty, so computer AI players usually rely upon a numeric troop advantage, positional advantage, or "asymmetric rules" in order to give players a good challenge.
In most Warcraft missions, the enemy computer players are given entire cities and armies to start with when battling human players. Moreover, Warcraft contains several asymmetric rules that make it easier for the AI player to compete, though most players would perhaps call these rules outright cheating.
One rule we created to help the computer AI was to reduce the amount of gold removed from gold mines to prevent them from being mined-out. When a human player's workers emerge from a gold mine, those workers remove 100 units of ore from the mine and deliver it back to the player's town hall on each trip, and eventually the gold mine is exhausted by these mining efforts. However, when an AI-controlled worker makes the same trip, the worker only removes eight units of ore from the mine, while still delivering 100 units into the AI treasury.
This asymmetric rule actually makes the game more fun in two respects: it prevents humans from "turtling", which is to say building an unassailable defense and using their superior strategic skills to overcome the computer AI. Turtling is a doomed strategy against computer AIs, because the human player's gold mines will run dry long before those of the computer.
Secondarily, when the human player eventually does destroy the computer encampment, there will still be gold left for the player to harvest, which makes the game run faster and is more fun than grinding out a victory with limited resources.
Most players are aware of a more serious violation of the spirit of fair competition: the computer AI cheats because it can see through the fog of war; the AI knows exactly what the player is doing from moment to moment. In practice, this wasn't a huge advantage for the computer, and merely served to prevent it from appearing completely stupid.
Interestingly, with the long popularity of StarCraft (over 14 years since launch and still played), a group of AI programmers has risen to the challenge of building non-cheating AIs. Aided by a library called BWAPI, these programmers write code that can inject commands directly into the StarCraft engine to play the game. Programmers enter their AIs in competitions with each other to determine the victor. While these BWAPI AI players are good, the best of them are handily beaten by skilled human opponents.
Page 3 of 4