I'm starting a new job tomorrow, and am no longer the lead programmer for Eon Altar. For those who follow me on Twitter, this won't come as a surprise, but given I've been semi-documenting my indie dev journey, I figured I'd talk about it here. As to why, we completed and shipped the entirety of Eon Altar Season 1. From start to finish it was an incredibly ambitious project, and the fact that we finished and shipped it is, frankly, massive. Add to that a 92% positive rating on Steam, and I can say without equivocation that I am proud of what we shipped. That said, it was 4 years of my life, and, among other reasons, I figured it was time to get some other industry experience. Looking Back If someone tells you that they want to build an RPG in a year, then says it's also going to have a completely unique game mechanic/control style, laugh at them. Seriously, just shake your head and laugh. Our original schedule was stupid, for the lack of a better term. It left no room or time for iteration, and at the end of the process we used up over 3.5 years total to get it out the door in its entirety. That said, I don't regret it--at all. What it did mean, though, was going from a team of 25+ people to a team of 4-5 people for the latter 2 years, and that's hard.
The extra time was necessary. It allowed us to polish up a lot of features, add missing bits and pieces, and actually iterate on the combat and gameplay formulas. You'd be impressed at the amount of work so few people can do. It also helps that the core team was mostly on the same page as to the direction of the game, which meant very little communication overhead. Sure, diversity of viewpoints is super useful (and when our team was bigger, it WAS useful), but I found it was more useful early in the process rather than late. Once you're in the polish phase, it's mostly mechanical work. User feedback, bug fixes, small adjustments because you can't afford rewrites.
But having so few people also meant we were stuck wearing a lot of hats. By the end, I was our tech support, forum moderator/community manager, lead programmer, project manager, QA Lead, QA Tester, copy writer, copy editor, IT administrator, build and deployment engineer. The list goes on. It was a little overwhelming at times, though I got an immense amount of experience doing it. But even for just the engineering, working on Eon was an amazing process of learning something entirely different every day, and immediately applying it. One day I might be working on the combat engine. The next, code optimizations. On day 3, save games. Day 4, Steam integration. Day 5, animation bugs. I was never bored, because I was constantly learning. It was also exhausting, because I never got to revel in what I learned; I was always on the edge. But damn, did we ever pull it out. Nobody--nobody--in the industry was doing what we did. Light role-playing meets local co-op video game was a unique mix, and the mobile controllers went far and beyond what JackBox did (though JackBox is amazing and I love it to bits), so we didn't have anyone to copy from. I even got to do a talk at PAX DEV about the process, which was fantastic. Such a great experience, and people apparently got some useful information out of the talk which was icing on the cake.
And that gameplay resonated with a fair number of people. Our reviews are generally extremely positive about the unique play that Eon Altar brought to the table. We even had an unintended but amazing audience segment: spouses. The number of reviews that talk about people playing with their significant others--many of them non-gamers, no less--and how much fun they had was so mind-blowing. We had made an RPG-lite that was approachable and fun, with enough depth that even hardcore players could have some fun min-maxing.
So what's next for Eon Altar? I can't say. That's up to the remaining team, and I wish them all the luck in the future. Eon is a fantastic project, a fascinating method of gameplay, and a great property. Yeah, we made mistakes, and the game itself is far from perfect, but I don't regret the project whatsoever. It will always be my dream project. Moving Forward So what's next for me? I've been hired as a Senior Engineer for an independent studio here in Vancouver, BC. The studio is large enough that I'll be able to focus on engineering almost exclusively, and been around long enough that they have a stable business plan to support those employees. I can't talk about my next project within the studio, but I am excited to work in an office again, with other programmers.
While I can learn a lot about gamedev on my own, improving one's programming and software engineering is difficult to in what's effectively a vacuum. Basically, when given a specific problem, it's relatively easy to learn or deduce how to solve it, but things like programming tools, style, practices, etc. are difficult to learn because you don't necessarily need them to complete your work. Your work becomes better with said knowledge, but it's not strictly necessary. I'll be keeping an eye out for my former coworkers though, and see how Eon Altar fares moving forward. Eon Altar is a high bar to meet in terms of interesting engineering/design projects, and I'm not sure anything I work on in the near future will meet that bar, but that doesn't mean I won't be giving my new projects my all--I've far too much professional pride to do otherwise. But being able to focus primarily on engineering also frees up brain cycles for other things, like maybe blog posts? We'll see, I definitely miss blogging about game design stuff! But tomorrow, new job!
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.
"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, 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?
"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
