Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Blizzard's Diablo II
arrowPress Releases
March 4, 2021
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Postmortem: Blizzard's Diablo II

October 25, 2000 Article Start Previous Page 3 of 3

1.Developing the new We have always been very proud that our company launched with the original Diablo. Just a couple of months after Diablo shipped, was the largest online game service in the world. At Diablo II's launch, had more than 6 million unique active users.

Despite the original Diablo's success online, we knew as we began development that to create the type of multiplayer experience that we wanted to achieve in Diablo II, we would need to fundamentally change the game network. And, as we expected, this became one of our biggest challenges during development. We had to reinvent's structure by melding existing technology with new programming and feature sets. This had implications across the board. We had to rethink everything - programming, hardware, bandwidth, staffing, online support, and how we could financially support this model while keeping it free.

Although the original had been further modified to support Starcraft as a chat and matchmaking service, for Diablo II we needed much more: game servers where the Realm games would actually be played, secure character-data servers, and game tracking systems. Trying to shoehorn these elements in the existing system proved very difficult. For instance, we planned to have character names represent players in, but it was designed to handle chatting between account names. It took a lot of design and implementation time to arrive at our final system, where users see character names but have to send remote messages to account names.

We initially believed that working with the existing would save us time, but in retrospect, we learned that melding technologies is a difficult process, and in some cases, recoding instead of integrating is the better course of action.

2. Launching the new The success of after Diablo's launch created a new challenge for us. When Diablo was released, was a new online service. Basically, we were able to ramp up as more customers joined the service. When Diablo II shipped, had millions of users. The level of anticipation was higher than for any of our other games. We were well aware of the expectations, and we knew that no other company had ever attempted to create and sustain an online service that could support the type of usage Diablo II would experience right out of the chute.

Some of the many locales in Act II: The Sand-Maggot lair (top), Jerhyn's Palace (middle), and the Sewers (bottom). Background elements were created and rendered in 3D Studio Max. The rendered files were cut into tiles and assembled into modular "rooms" with an in-house tile-editing tool. The game engine reassembles the rooms to provide a randomized game environment.

We spent countless hours preparing for's Diablo II debut. We teamed with the best ISPs in the word, and conducted months of internal and external beta testing. We ramped up bandwidth and hardware. We beefed up the, quality assurance, and support service teams.

Although we had more than 100,000 people testing the Diablo II Realms, having more than one million customers in just three weeks proved to be very different from beta testing. The beta test was very successful in uncovering many stability issues that were addressed before the launch. After the game shipped, we faced bugs that only appeared at much higher usage rates. The issues that we faced at launch were ones that could not have been simulated in a beta test of 100,000 people. It took a much larger influx of players to trigger certain situations.

Knowing the massive scope of what we were trying to achieve with, we had measures in place at launch to help us deal with issues that arose as usage increased. For instance, we maintained both a team of programmers and the entire quality assurance department to solve problems as they appeared, and had our support team working overtime. We also had an action plan in place to increase hardware and bandwidth as needed.

In some respects, we are victims of our own success. We underestimated sales, but we also underestimated the allure of playing on the Realms. By solving the cheating problem in Diablo and enhancing with new features - such as the ability to see everyone's characters in the chat room - we seem to have attracted a larger share of players than with any of our previous titles.

3. Graphics. Shortly before Diablo II shipped, we began noticing some feedback from customers about the resolution of the graphics in the game. They were frequently labeled "outdated" or "pixellated." The shame is that the technology choices we made eclipsed the recognition of the fantastic job the artists did. We put a lot of effort into creating characters, monsters, and landscapes with a lot of unique character. The game displays an incredible amount of action happening on-screen in an easy-to-follow manner. Still, with all the negative reaction, we probably should have done it differently.

When we began producing art for Diablo II in mid-1997, we investigated a lot of options. We mocked up a 3D engine and checked out voxel systems. It didn't take us long to go back to what we used in Diablo: 2D graphics at 640¥480 resolution with 8-bit color depth. At that time it was still the only way to get eight characters, upwards of 30 monsters, and upwards of 100 missiles all interacting on the screen at one time without sacrificing detail and atmosphere.

The graphics criticism caught us by surprise. We thought (and still think) that the game looked great. We probably should have built in a scaling technology to take advantage of hardware that could display the same graphics at higher resolutions. In any case, Diablo II will probably be our last 2D game.

4. Tools. We developed the original Diablo with almost no proprietary tools at all. We cut out all the background tiles by hand and used commercial software to process the character art. Spells and monsters were balanced by verbal estimates ("Hey, lets make the lightning about ten percent weaker."). Diablo II's vastly increased scale required much better tools, and we made some, but not enough.

In many cases we created tools to speed up content creation, but then abandoned them. Too often, we decided to keep using inferior tools because we thought we were almost done with the game, and didn't want to take the time to improve them. Unfortunately, in most of these cases, we were not really almost done with the game, and in retrospect a couple of weeks' worth of work would have helped in the year or more of development remaining.

The greatest deficiency of our tools was that they did not operate within our game engine. We could not preview how monsters would look in the environments they would inhabit. We couldn't even watch them move around until a programmer took the time to implement an AI. Even after that, an artist would have to hassle someone to get a current working build of the game to see his creation in action. Our sound effects engineers ended up painstakingly creating .AVI movie versions of animations in order to synch sounds with actions. Our lack of tools created long turnaround times, where artists would end up having to re-animate monsters or make missing background tiles months after the initial work was completed.

We should have made tools that let us create content within the game engine. Instead of just handing off a set of animations and hoping they looked all right when dropped into the game, artists should have had the ability to position and orchestrate their creations themselves. The extra tool development time would have been more than offset by increased efficiency and higher-quality work.

5. Save-game methodology. As much as we tried to make a frustration-free game, we seem to have failed some people with our save-game scheme. Eschewing the common save-game feature we used in the original Diablo's single-player mode, where every facet of the game state can be saved to files and reloaded at will, we opted to make all modes behave more like Diablo's multiplayer game. In Diablo II, we do not save the world state. Reloading the game resets the location of monsters and treasures every time. The character is placed in the town he or she last visited, not in the wilderness or a dungeon.

Although this choice was slightly controversial around the office, it had a lot of advantages. For one, players could not get stuck, unable to progress further. At any time you can restart in town, refight the same monsters for more experience and loot, and return to a difficult area when ready. We created a waypoint system that allows characters in new games to return quickly somewhere close to where they quit the previous game. Finding new waypoints is a rewarding mini-goal during play. We also wanted to discourage the type of play where players feel they must always save the game right before a difficult section, then constantly die and reload until they get lucky and make it through. Finally, it was just easier to make single-player games and multiplayer games work the same way, and multiplayer requires the method we used.

Monsters have 14 possible classifications of animation, from basics such as Walk, Attack 1, and Death, to the seldom-used Block, Run, and four Special modes, reserved for miscellaneous animations. Diablo is the only monster who uses every animation category available.

A lot of players don't like our decision. They feel it is too inconvenient to have to fight their way back though the same areas and monsters. Many also want the opportunity to experiment with skill choices and equipment purchases, then later revert the game back to an earlier state if they don't like the results. There are good points on both sides, and we probably didn't spend enough time developing alternatives.

The Final Word

Many more things "went right" than could fit in that section. Our internally controversial plan to tell a separate but parallel story through our cinematic sequences seems to have succeeded, and the workmanship and quality of these sequences has set a new standard. Our marketing and PR departments did a fantastic job building customer awareness and creating a frenzy of interest. Diablo II's music is outstanding, and along with an amazing array of sound effects, contributes hugely to the atmosphere of the game.

The development of Diablo II is a remarkable success story. We got the opportunity to make the game we wanted to make - and the game we wanted to play. Diablo II turned out to be a great game, one that many of us still play every day. Initial sales figures are phenomenal, and reviews have tended to be better than those of its predecessor. We have gained a lot of experience that should help us make even better games in the future.

The only major downside to Diablo II's development was the inhuman amount of work it required. A yearlong crunch period puts a huge burden on people's relationships and quality of life. Our biggest challenge for the future is figuring out how to keep making giant games like Diablo II without burning out. As a start, we are hoping our experience will help us do a better job scheduling and managing the workload. We also believe that taking the time to make better tools will make things easier at the end of projects.

Although I tried to avoid personalizing this article, I am extraordinarily proud of the entire development team. Diablo II could not have happened without all the superb individual efforts, the incredible creativity, and the whole team's dedication to the project, for which they have earned my gratitude, and no doubt that of the legions of players who enjoy the game.

Game Data

Diablo II
Blizzard Entertainment

Publisher: Blizzard Entertainment

Full-Time Developers: 40

Length of Development: 3 years.

Release Date: June 28, 2000.

Platforms: PC and Macintosh.

Hardware Used: Typical programmer workstation: 500 MHz Pentium II running Windows NT with 128MB RAM and 9GB hard drive. Typical artist workstation: dual 500 MHz Pentium IIs running Windows NT with 256MB RAM and 14GB hard drive.

Software Used: 3D Studio Max, Photoshop, Microsoft Developer Studio/Visual Studio and SourceSafe

Notable Technologies: Glide, Direct3D, RAD Game Tools' Bink, DirectSound3D, and Creative Labs' EAX.



Article Start Previous Page 3 of 3

Related Jobs

Airship Syndicate
Airship Syndicate — Austin, Texas, United States

Gameplay Programmer
Airship Syndicate
Airship Syndicate — Austin, Texas, United States

Senior Gameplay Programmer
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States

innogames — Hamburg, Germany

PHP Game Developer - Grepolis

Loading Comments

loader image