Creating Warcraft (Part 3)

From translator

I really love Blizzard games and, having recently stumbled upon the blog of one of the creators of the Warcraft series - Patrick Wyatt, I decided to translate the third article about creating the first part of this wonderful game. Translation of the first two ( first , second ) is already on the hub
So, you are waiting for a story about the sources of funding for Blizzard, about how Stu Rose made a design revolution, about the fog of war and, most importantly, about the author’s impressions of the very first multiplayer game and its unexpected results.
For all this, welcome for habrakat.
This is my first translation, so I will be happy to receive all error messages, comments and corrections.

The very first multiplayer game in Warcraft turned into a crushing victory, a terrible defeat and a draw, all at once. But how did this become possible? There is something to tell here. This story will include a description of AI, the economics of the game, the fog of war, and much more. Read if you have a lot of free time.
This is the third part of the story. Part 1 , Part 2

After six months of development, which began in September 1993, Warcraft: Orcs vs. Humans was finally transformed from an expanded demonstration of technology into a game.

For several months, I was the only employee fully employed on this project, which greatly limited the speed of development. Fortunately, other members of the company helped me with the design, including Ron Millar, Stu Rose and others. And a few more artists who prototyped the decoration when they found time between the milestones on other projects.

There were so few people on the team, because the Warcraft development was sponsored by the company from its profits received for developing games for third-party publishers such as Interplay or SunSoft, so the company's accumulations were small.

At this time, we were developing four 16-bit console games: The Lost Vikings 2 (continuation to our well-met but poorly selling side scroller), Blackthorne (side scroller, where the protagonist runs with shotguns), Justice League Task Force (Street clone Fighter in the DC Comics universe), and Death and Return of Superman (a side scroller based on the eponymous comic book series in the DC universe).

With the money received for the development of these games and for other occasional side jobs, the company was able to pay the initial development cost.

Game Development Economics

Throughout the history of the gaming industry, independent game development studios (those studios not owned by publishing companies) usually pay for their projects by signing contracts with these publishing companies. Publishers give an "advance" to the development of the project. In addition to advance payments, publishers are responsible for public relations, marketing, manufacturing, distribution, customer support and so on.

In the 90s there were much more publishers than today, but the increase in the cost of development and, especially, the publishing of games caused a chain of bankruptcies and takeovers, which led to a large number of business associations. Therefore, today, when talking about game publishers, you most likely mean Activision-Blizzard, EA or Ubisoft instead of the myriad of medium-sized companies that existed twenty years ago.

As elsewhere, the terms of contracts are drawn up in favor of people with money. There is a golden rule: "the one who has the money sets the rules." Despite the fact that in theory these agreements are organized so that the developer is rewarded when the game sells well, just like in the music and film industries the publisher collects most of the profit, and the developer, with any luck, gets enough money to survive until the next signing a contract.

Although I mentioned the “advance” paid by the publisher, the more appropriate term would be “advance instead of royalty,” when the developer actually gets a loan that will be paid out of the game sales fee. Sounds great: develop a game, get paid for every sold copy. But the mechanism is designed so that most games will never earn as much money as is necessary to pay an advance. Since studios often have to give rights to their games and their sequels, these agreements are often hidden contractual agreements.

To obtain more favorable terms of agreements, developers usually used the following scheme: they developed the initial prototype of the game using their own funds, then used this prototype to “push through” the deal with the publisher. The longer the developer can pay for the development himself, the better the terms of the contract will be.

Perhaps the best example of this strategy is Valve Software, where Gabe Newell used the money he earned at Microsoft to pay for Half Life. Thus, he gained the necessary control over the time of release of the game: instead of rushing to release the game just to fulfill the goals for quarterly income, as Sierra Entertainment (the publisher of the game) wanted, he released the game only when it became high-quality product. More importantly, Gabe’s savings allowed him to gain distribution rights for Half Life, while digital distribution became a viable strategy for selling games, which ultimately led the studio to overwhelming success.

The disadvantage of such an independent payment for the prototype is the risk that the publisher does not sign a contract for the release of the game, which very often leads to the death of the studio.

The company I worked for (at that time it was called Silicon and Synapse) paid for Warcraft along with another project called Games People Play, which was supposed to include crosswords, bogle and other similar games that can be found on shelves at the airport for the entertainment of poor travelers.
By developing two games that were aimed at completely different audiences, the owners of the company hoped to create several sources of income, which would be less risky than if the company aimed only at the core of the entertainment market (avid gamers like you or me).

Of course, the distribution of bets between different game genres also has risks, due to the fact that the prestige of a company’s brand can be blurred by products that do not meet the expectations of its audience. One of the main advantages of Blizzard today is that users will buy their game before they even play it, because they believe in the foresight and reputation of the company. It would be much harder to build such a reputation if the company released both low-budget casual crafts and high-budget games of the AAA + class, as Sierra Entertainment did, which went bankrupt after repeated attempts to find its audience.

One way or another, the creation of Games People Play was a mistake, because the development of a casual entertainment product had such a demoralizing effect on the main programmer that the project never reached a mature stage and was later canceled. Or maybe it was still not a mistake, because the combination of Warcraft and Games People Play convinced Davidson & Associates, the then second largest educational software company, to acquire Silicon & Synapse.

Our new overlords

Founded by Jane Davidson, later joined by her husband Bob, was a multilateral company whose growth was driven by the success of the Math Blaster game, in which the player solved mathematical examples to explode asteroids before they destroy the player’s ship. It was a good combination of education and entertainment, and the company received many awards for it.

Digression: When used correctly, Math Blaster might have some educational value, but I happened to see its appallingly stupid use. In high school, our journalist group wrote articles for the school newspaper in the computer room, which we shared with the classroom for the lagging behind. We watched in horror as these students played Math Blaster using calculators. When asteroids containing expressions like “3 + 5” or “2 * 3” approached, these students quickly drove these expressions into calculators and then entered the results to destroy the asteroids. They may have learned something, suggesting that they were deceiving teachers, but I’m not sure that this was the best use of the time left before their rapidly approaching adulthood.

With a good manager and aggressive leader, Math Blaster has evolved into a manufacturer (creation and packaging), a distributor (shipping to retailers and resellers), and a direct supplier of teaching materials for schools. They saw opportunities for expansion into the entertainment business, but their early assessments of creating entertainment products on their own convinced them that it was more profitable to buy an experienced development studio than to continue to develop their games with a team that knows more about training than about swords and magic .

So the financial problems that impeded the growth of the Warcraft development team were suddenly resolved by the acquisition of the company. Finances Davidson & Associates enabled Silicon & Synapse (which were renamed Blizzard after the acquisition) to focus on their own developments instead of looking for low-profit deals with other gaming publishers. And they were really unprofitable: in 1993, even after creating two highly rated games that earned the company the title of “Developer of the Year for Nintendo,” the company received no royalties.

The development was greatly accelerated, using the money from acquiring to hire new ones and attracting employees already working for the company to the project.

Design “process”

The approach to designing and building games at Blizzard in his early years can best be described as "natural." It was a chaotic process that took place during formal design meetings, but mainly during spontaneous meetings in the lobby or at lunch.

Some features came from design plans, while others were added by the programmers themselves. Some of the artworks for the game were planned and regularly created, while other works were created late at night, because the artist had a great idea or just wanted to try something else. Some elements were a complete improvisation, for example, the history of the World of Warcraft was finally formed only in the last few months before launch.

Despite the fact that the process was unpredictable, the results were impressive. Since the team consisted of fans of computer games, our games evolved during the development into something that gamers wanted to play, play and play. And Warcraft, our first own game for the IBM PC, which demonstrated the best (and sometimes even worse) features of this process, definitely turned out to be an exemplary game (at least for its own days).

How the unit creation system appeared in Warcraft

Biologists know that the evolution process included false starts when entire branches of the evolutionary tree were unsuccessful. The same thing happened during development. Since we did not have verified specifications, we had to experiment a lot and reject entities that did not work. I want to say that in each case it was a verified, meaningful process, but many times it began with accidents, disputes and conflicts.

One case that I have well remembered is related to the creation of game units. During the early phases of development, units were created using codes typed in the console because there was no other user mechanism for creating them. During the discussion of the best method for unit production, various ideas were proposed.
Ron Millar, an artist who did a lot in terms of creating ideas and design for early Blizzard games, suggested the following idea: players will have to build farms, and (like in the Populous game) these farms will periodically produce working units called peysans (for people) and peons (for orcs). The player will have the opportunity to use these units for mining gold, wood and building buildings, but they will not be as good as military units.

The player can send these “peons” to military training in the hut, where they disappear from the map for a while and, in the end, appear as trained fighters. Other training areas will be used to create more advanced military units such as catapults or wizards.

The idea was not completely ready, which was one of the main shortcomings of our design process: there was no final documentation that was supposed to explain how the idea should be implemented. So it was discussed by the entire design team (which included the majority of the company's employees) before we started coding (programming) the implementation.

Before we started working on the code, Ron went to a trade show (possibly the winter CES - Consumer Electronics Show) with Allen Adam, the company's president. And during their absence, an event occurred that set the direction for the entire Warcraft series, an event that I call "success in designing Warcraft."

Stu Rose, another artist who joined the company at the very beginning (worker # 6, I suppose) came to my office one afternoon to propose a different approach. Stu felt that the unit-building mechanism proposed by Ron had many unresolved implementation difficulties. Moreover, this approach is the exact opposite of the type of control that we must give players in RTS.

In this new genre, the requirements for players were much stricter than in others and the attention of players cannot be focused on one place for a long time. This is due to the fact that there are many tasks: planning a tree of buildings / improvements, monitoring the development of the economy, creating units, placing buildings, reconnaissance maps, controlling the battle and applying the abilities of each unit. In RTS, the most limited resource is the player’s attention, so adding an indirect unit-building mechanism will increase the attention deficit and game complexity.

To build a “grant” - the main combat unit of the game, you will need to select an idle worker and send him to train. Such a process without any need (according to Stu) adds complexity to the game.

I was a grateful listener for such thoughts, since I had similar (albeit less thoughtful) worries, and I did not think that creating units was an area where we should come up with serious changes. Dune 2, the game from which the game mechanics of Warcraft was inherited, had a much simpler mechanism for creating units: just click on the button in the panel of the factory building, and the unit appears after a while. This was not their innovation - the idea was copied from even older games, but it worked.

Stu insisted that we should use this approach and, instead of further discussions, just take it and make it. So over the next couple of days and evenings, I expanded the game code and user interface to implement the unit creation mechanism, so our idea became a fait accompli. By the time Ron and Allan returned, the game could already be played in single-player mode, if you did not take into account the fact that the AI ​​was extremely far from complete.

Now Warcraft has become a game that is easy, and more importantly, fun to play. We never looked back.

The first multiplayer game in Warcraft

In June 1994, after ten months of development, the game engine was ready for multiplayer. With an ever-growing sense of excitement, I made changes to the code that allowed me to play the first multiplayer game in Warcraft. While I was writing the core of game logic (event loop, unit control, finding a way, tactical AI for units, status bar, inside the game interface, high-level network code), other programmers worked on components for a network game.

Jesse McReynolds, a Caltech graduate, has written a low-level network library for forwarding IPX packets over a local network. The code was written using the knowledge gained from the Doom source code, which was later opened by John Carmack of idSoftware. Although the IPX interface layer consisted of only a few hundred lines of syssh code, it was code that interacted with the network card driver to ensure that messages created in one client of the game would be sent to another player.

And Bob Flitch, who received his master's degree at Cal State Fullerton, designed screens for creating and connecting to a multiplayer game. My office was directly opposite Bob’s office, which was very convenient, since it was necessary to work closely to integrate his code into mine.

After making the changes, I compiled the game client and copied it to the network drive, while Bob ran back to his office to start the game. This was a small miracle: the code we just wrote worked and we had the opportunity to play the very first network game in Warcraft.

When we started playing, I felt a strong excitement, which I never experienced when playing other games. Part of the excitement was caused by the fact that I wrote this code myself, but there were also factors that created a feeling of fear: the fact that I played against a living person, and not against computer AI, and that because of the fog of war I didn’t knew what the enemy was doing.

Fog of war

One idea taken from earlier games was the idea of ​​hiding units and buildings from the gaze of an enemy player. Dark fog hid the areas of the game map until a friendly unit scouted these areas, which was designed to emulate the fragmentation of information that the general receives about enemy operations and troops during real battles.
Empire, a turn-based multiplayer strategy game written almost seventeen years before by the magnificent Walter Bright (creator of the “D” programming language), used the fog of war for the same purpose. When the map area was explored, it remained visible forever, so an important part of the strategy was to scout a large enough piece of the map early enough to get information about the movement of enemy troops before they could damage an important infrastructure or economy.

The horror caused by the ignorance of the actions of the enemy, caused the death of many generals in history. Adding such an element to the RTS genre is a great way to increase your level of passion (and fear). Thanks to Walter and the creators of Dune II, the Westwood guys, for their inventiveness.

Computer AI

As many gamers know, in strategies a player under the control of computer artificial intelligence (AI) is often weak. Players are used to finding strategies to counter which AI was not programmed and this allowed them to destroy a computer player without any problems. So in order to present a serious adversary to a player, AI usually relies on superiority in troops, positions, or “asymmetric rules”.

At the start of most missions in Warcraft, computer players are given entire cities and armies. Moreover, Warcraft contains several asymmetric rules that make it easier for computer players to battle, although perhaps most players will find these rules a direct deception.

One of the rules we introduced to help computer AI is to reduce the amount of gold that is withdrawn from the mines. When a player’s workers exit the gold mine, these workers take 100 units of ore from it and deliver it to the player’s town hall, obviously such walkers deplete the mine. However, when a working computer player makes such a trip, he takes only 8 units of ore from the mine, and the AI ​​delivers the same 100 units to his treasury.

This asymmetric rule makes the game more fun in two aspects at once: it prevents the player from “sticking up” in defense, the tactic is to build impenetrable defense and then use his excellent strategic skills to surpass the computer player. Obviously, this tactic is doomed to failure, as the player’s gold will end much earlier than the computer.

Secondly, when the player destroys the computer base, there still remains gold that can be collected. This makes the game faster and more interesting than if you had to earn a victory with a limited number of resources.

Most players are aware of more serious violations of the spirit of fair competition: computer AI can see through the fog of war, AI knows exactly what the player is doing at a particular moment. In fact, this is not such a big advantage for the computer and, basically, served to ensure that it does not look too stupid.

Interestingly, over the long time Starcraft’s popularity (released over 14 years ago and is still being played in it), a group of AI programmers staged a contest to write a non-fraudulent AI. Using the BWAPI library , these programmers wrote code that can embed commands directly into the StarCraft engine. Programmers staged a competition between their AIs to determine the winner. Despite the fact that these AIs are good, an experienced player easily defeats the best of them.

Game against man

As the person who played many (very many) strategic games before the development of Warcraft, I was well aware of all the limitations of the computer AI of that era. While I fought with computer AI, sometimes losing, winning much more often, I was never afraid of the power of AI. Even when I played against the terrifying armada of Russians in Chris Crawford’s Eastern Front game, which I played with my Atari 800 friend, until the audio cassette (!) With the game stopped reading due to old age.

These games were fun, exciting, and definitely intense, but not scary. But something changed when I played the first multiplayer game in Warcraft.

The realization that my opponent was a man, not only in terms of skill and strategy, but also in terms of reaction speed, and the fact that I was limited in the evaluation of his actions by the fog of war, was both stimulating and terrifying. Throughout my career, I have not felt such excitement, playing a single player game, which I felt, the first time playing Warcraft, when it was impossible to know whether I won or lost.

My blood received a large injection of adrenaline, I did everything I could to efficiently collect gold and wood, build farms and barracks, increase offensive capabilities, explore the map and, most importantly, to crush Bob’s army before he can do the same with me.

It was not just a match for testing the game engine, I knew that he felt the same desire to get the title of winner of the first ever multiplayer game in Warcraft. Moreover, earlier, when we played in the office in Doom together, I gained some fame after at the end of a rather intense game, Bob was so angry with me for the fact that I often killed him from a rocket that he promised never to play with me again . I knew that he was eager to recoup.

When our armies met in battle, we redoubled our efforts to build units. When I discovered his base and launched the attack, I felt hope. Bob's actions seemed disorganized and it looked like I could crush his strength, but I did not want to leave him the slightest chance, so I continued to attack his units and buildings in a frantic rhythm wherever I found.

And then ... crash:

Any programmer knows that the likelihood that the new code will work correctly the first time is close to zero, so it was not surprising that the game crashed. The graphics of the game slipped to the top of the screen and was replaced by the DOS4GW text of the “screen of death", so familiar to gamers of the era before Windows. Now we have a much more sophisticated Windows error dialog that allows the player to send a report, although sometimes players can still see the terrifying “blue screen of death”, which is strikingly similar to the old one.

After a mistake, I jumped up from my chair and ran into Bob’s office, shouting: “It was soooooooooooooooooo!”, And then immediately: “... I did you!”. I was very surprised when I immediately heard Bob refute: on the contrary, it was Bob who defeated me.

It took our inflated nerves a few minutes to return to normal, but soon we realized that we had not only an error with the program crashing, but also a problem with state synchronization, what I called a “synchronization error”: two computers showed completely different battles. Those. despite the fact that the games started the same way, they took place in completely different universes.

Those who haven’t worked on the network code may suggest that two Warcraft clients forward the full state of the game back and forth every step of the game. Those. at each step, computers send positions and actions for each unit in the game. In leisurely games, with a small number of possible positions, such as chess or checkers, this might work, but in games like Warcraft, where up to 600 units can take part at a time, it was impossible to send such an amount of information via the network.

We assumed that many would play with 2400 baud modems, which could transmit up to several hundred characters per second. Young gamers who have never used modems should read about this technology, which is not far from smoke signals and was only slightly more advanced than the knock of stones against each other. Understand that this was before Amazon, Google and Netflix, we are talking about the dark ages.

Porting before that Battle Chess with DOS on Windows, I got acquainted with how games can communicate through a modem. I knew that due to the modem’s limited bandwidth, it would be impossible to send the game state over the network, so my solution was to send only the commands of each player, and then make both clients execute these commands at the same time.

I knew that this solution would work because computers perfectly do exactly what they are told. Unfortunately, it turned out that we, the people who program them, are not so good at telling them what to do, and this is the main source of errors. When two computers must do the same thing, but due to an error, desynchronization occurs - this is a problem.

A synchronization error occurs when two computers simulating a game choose different answers to the same question and thus diverge further and further. In time travel films such as Back to the Future, the small changes made by time travelers in the past lead to completely different futures. Similarly, games diverge when playing Warcraft. On my computer, my elven archer will see your orc peon and attack, while on your computer the peon will not notice the attack and go to collect wood. Without a mechanism to detect and correct such discrepancies, our two games will quickly become completely different.

So the first game in Warcraft ended in a draw, but at the same time it was a huge victory for the whole team - it was incredibly interesting! Soon, the rest of the team played it on the net and found it to be like “Blue Sky” - the purest methamphetamine that Walter White produced from the Breaking Bad series. After people became addicted to the multiplayer game, nothing else could be compared with him. Even despite regular departures, we knew that we were doing something grand.

All we needed was to complete the game.

Soon we made an even more unpleasant discovery: we had not only countless synchronization errors, but these errors also had numerous causes. If all such errors were caused by similar conditions, we would try to eliminate the only source of problems. Instead, it appears that we have a huge number of different types of problems, each of which is a type of error, and each requires a separate decision.

Why do synchronization errors occur?

While I was developing Warcraft, I designed solutions to minimize the amount of data that needs to be transmitted over the network, sending only the commands that the user called, such as “choose unit # 5”, “move to 650.1224”, “attack unit 53”. Many programmers independently designed similar systems, this is an obvious solution to the problem of synchronizing two computers without sending the entire state of the game every turn.

Digression: Now, probably, there are several patents that are trying to claim the rights to this approach. Over time, I came to the conclusion that it is impossible to patent software, because almost every idea in software is something that a programmer with average experience can come up with, and the definition of a patent requires that the patent is not obvious. But enough about that.

I have not yet implemented a mechanism for controlling synchronization between computers, so any mistake in the game code, due to which computers make different choices, will cause the game to “split”, i.e. split into two loosely connected worlds that will continue to exchange information, but move away from each other with an ever increasing speed.

Obviously, creating a system to detect desynchronization situations was the next task in my long list of things that need to be done to release the game.

You know the end of the story: Warcraft came out only five months later. It seemed like an eternity because we worked so many hours every day, overcome so many obstacles, overcome so many trials, and created something that we cared for so anxiously. I will continue to review these remaining months in the following articles of my blog, since so many things have fit into this time that it is impossible to cram these memories into this already too long article.