How Might Blizzard Engineer WoW Classic?

So, that happened. I'll be honest in that I definitely wasn't expecting Blizzard to actually work on a Vanilla server, given the sheer engineering difficulties. I'm also not convinced still that there's as much money in it as some folks posit, but some number cruncher at Blizzard must've decided that it was worth it. Perhaps even just as a marketing tool for WoW Current.

But that aside, it seems Blizzard is at least entertaining it seriously, given the BlizzCon announcement. The company's been gun-shy about announcing products that might not ship in more recent years (Titan vs. Ghost, Warcraft Adventures), so I expect this effort to come to fruition eventually.

 So, as per my linked blog post above, there's a lot of engineering problems:

• Old (possibly lost) Assets
• Old (possibly lost) Codebase
• Old Hardware Dependencies
• OS Updates
• Security Fixes for both Client and Service
• Build Pipeline
• Battle Net Integration
• Authentication Updates
• Customer Computer Updates (Graphics APIs/Cards)
• Network Optimization
• Server Crash Fixes
• etc.

The list is extensive. But there's a few hints laying about Twitter and the Engineering Panels, and a little shower thinking I came up with a potential solution that they may be working towards.

In the BlizzCon Opening Ceremony, J Allen Brack said (around 1:02:00ish):

"This is a larger endeavor than you might imagine, but we are committed to making an authentic, Blizzard quality classic experience. We want to reproduce the game experience we all enjoyed from classic WoW, not the actual launch experience."

They're couching this in careful language to suggest that the experience won't be identical, that they're not just shipping the old client. They're also suggesting that it's a huge engineering/design effort.

With all that in mind I think their solution is not to use an old client and re-engineer the old servers, but get the old content working in current server/client codebases.


New Codebase

The neat thing about that conclusion is it handily solves nearly every single engineering issue that I brought up above. All the code for security, network protocols, database access, authentication, build pipelines, optimization, graphical display, server hardware-specific optimizations, and so on could be shared code. And what better way to handle shared code than a WoW Shared Infrastructure team?

Something exciting is happening: on Nov 20th I'm moving off the Server Team to the (newish) WoW Shared Technology team. (1/?)

— Kurtis McCathern (@kurtismcc) November 7, 2017

Kurtis McCathern, a prominent WoW Server dev, is moving to the "newish" WoW Shared Technology Team. Why bother making a shared tech team unless you were planning on versioning or forking your product? And of course, this shared tech will need client and server developers.

In the first engineering panel at BlizzCon (link requires Virtual Ticket) the WoW engineer Omar Gonzalez talked about how much divide there was between the infrastructure code and the LUA scripting the designers do, and it's pretty stark how much feature work lives in scripting land. With that kind of divide, it makes it easier to envision a shared C++ codebase, and a much smaller subset of code for feature specific work that's almost entirely LUA with maybe some C++. Like reputations, weapon skills, etc.

Refactoring a current in-production codebase into smaller shared chunks is not a fast process, nor an easy one. I went through a similar process when I worked at Microsoft Office. It took 3-4 engineers over 3 years to get a bunch of the 30+ year old shared code into smaller shared libraries that could be built and modified independently. Now, Office is a (much) bigger, older codebase than WoW likely is (I can certainly guarantee older), so it's not quite the same. But the types of tasks are certainly parallel. I imagine that some of the work, especially around Battle.Net integration, has already been done though.


Old Content

So what about the old content? Lost assets? Item drops? Boss fights?

The WoW Client contains the assets for rendering the world, rendering enemies, quest text, music, etc. The WoW Servers contains the information for where to spawn things, AI scripts, instancing, item drops, quest triggers, etc. The WoW Servers also host the databases that contains the data for running the game and running player characters.

Recreating the Client assets is "simple". Assuming they don't just have a versioned set of assets laying around, they find the version they want in an old client, grab the MPQs, rewrite their MPQ-cracking algorithms (because the format has changed significantly over the years), and extract the data. They could then repackage it in current WoW formats such that the current Client could actually read them. That assumes the current tech can even render that data, it's possible that the data may need to be massaged to be renderable in today's technology.

Recreating the Server assets is harder. Much harder. Private servers have generally had to reverse engineer that data, from their personal memories, Thottbot data, etc. We don't know what kind of data Blizzard has in the backend--assuming they have a copy at all--and it's quite possible that they'd have to manually re-enter that data into a current-style database anyhow. But AI logic, instancing, quest tech, etc. can be shared with Current WoW, rather than be recreated.

The other aspect to all this is recreating old features and deprecating current ones. Weapon skills, hit cap, old talent trees, resistances, MP5, spell ranks, and much, much more will need to be recreated. I imagine a lot of this will be designer feature work in LUA, but it'll still require some code support. How much of that will be via memory, and how much will they be able to stare at old code for?

EDIT: There's a Job Posting for a Senior Software Engineer position for Classic WoW. The description is as follows:

"Responsibilities include building gameplay systems, transforming database data, building UI elements, repackaging binary distributions, and working closely with designers to revive the classic game elements."

Transforming database data suggests they DO have the old server data and need to transform it into the newer database format. Repackaging binary distributions also suggests my thoughts about getting the old client data may be on the ball.




A Massive Effort

As Brack mentioned, this is a larger endeavor than you might imagine. I've probably missed things in my analysis. And I imagine the engineering teams are bigger than the 5 people I suggested for financial solvency in my original blog post, which suggested a layout of about $2M USD over a year. The cost and timeline is probably going to be bigger than that. Possibly significantly bigger.

But using current technology solves a lot of engineering hurdles and actually brings this into the realm of logistical possibility. However, it also means that Classic WoW will likely feel a lot more modern than Vanilla WoW did. I'm expecting Battle.Net integration, LFD, and phasing for overloaded servers, because those will "come for free" with a shared infrastructure team (it's not really free, but certainly a lot less work). We also may not see Vanilla-era bugs or system quirks like debuff limits. Depends on how faithful they want to be to the original game, and how much time they're willing to invest to get those details correct, and how many systems they want to diverge vs. utilizing the shared infrastructure.

It's going to be fascinating from an engineering perspective, and what I would do to be a fly on those walls right now. #WoWClassic, #Engineering