Hi, I'm Chris Wilson.

Since I started doing this whole  youtube thing, I've received a lot  

of emails asking about the feasibility of  developers releasing classic versions of  

their online RPGs. I promised a few people  I'd record a video with my perspective on  

this topic, based on my own experience  developing and running an online RPG.

People often think that releasing a classic  server is as simple as checking out an old  

version of the game from version control  and just putting it online. In reality,  

getting an old build running is the  easy part. Making it secure, compatible,  

supportable and legally compliant as a  modern live service is the hard part.

So what do I mean when I refer to a classic  release of an online game? Well imagine you've  

been running a game for many years, and over the  course of that time, the game has changed. You've  

released expansions, you've rebalanced everything  many times, you've updated the graphics engine,  

you've completely disabled or changed features  that were in the base game. And the current  

version of the game plays quite differently to  how the original did back in the day. Players are  

missing the original version. They petition you  to re-release the old one as a classic server, so  

they can get a nostalgia fix or even potentially  make this version the dominant way they play.

Now, this could be attractive for business  reasons. Not only does it make players happier,  

but it's potentially a nice value-add if you  currently charge them a monthly subscription.  

You've already incurred the costs of  developing that old version of the game,  

so maybe this strategy lets you essentially  have two games for the price of one? Both World  

of Warcraft and Runescape have gone through this  process and they've been quite successful with it.

Well getting to that outcome  is a whole lot of work,  

and today I'm going to break  down what could be involved.

The first question you'll need to answer is  which version of your game you want to release  

on the classic server. Sometimes it's obvious.  For example, for games that have a traditional  

release schedule, you might pick the first  fully-released version of the original game, after  

early stability and bugfix patches were deployed  but before significant balance changes were done. 

But for more live-servicey games that evolved over  time without necessarily having paid expansion  

releases, the decision of which version to use  might be more difficult. I suspect if you asked,  

say, Warframe players what they view to be  "classic" Warframe, they'd all have different  

answers, which may be swayed by the nostalgia  of when they personally started playing.

So once you've decided which version  you're releasing, how do you actually  

get that old version of the game? Well, you do it  through the magic of version control. Developers  

in the audience will notice that this explanation  I'm giving is an oversimplification to the point  

of absurdity, but basically a version control  system is a repository where developers check  

in their work. It not only maintains the current  version of every game file for people to work on,  

but also all past versions. It's a permanent  snapshot of every moment of a game's development  

history. And game developers have been using  this as a commonplace tool since the late 90s,  

so pretty much every currently-running online game  probably has its full version history available.

Here's a terrible visual representation of  this. The raw source files are maintained  

for every version of the game, all the way  back to start. You can scroll back through  

time to find the exact version  you want to get access to. Note  

that in reality there are probably multiple  repositories, branches, tags and sometimes  

complex external binary file stores, but  we're keeping things super simple here.

So in this hypothetical example, we go to our  version repository, select the 1.0 launch version  

of the game, and ask it to check out that version.  A few minutes, or hours, later, we have all the  

source materials of the game on our computer ready  to go. It's like we were back there on the day.

But before we can try it out, we need to get the  game to build. This means putting it through the  

process that turns it from a pile of source  code and art assets into a packaged game that  

we can install and run on a computer. This may be  harder than it sounds, for a number of reasons.

Firstly, it's possible that your build  scripts might not have been stored in the  

version control repository alongside  the game. If you made this mistake,  

then good luck recreating them. Secondly, the  operating system and environment you're using  

now in 2026 may be entirely different than what  was commonplace back in 2004 or whenever this  

version is from. What worked just fine on Windows  XP might not be exactly the same on Windows 11.  

You might need to find old versions of your  compiler, libraries, database, runtimes,  

art tools, potentially even the operating  system itself, all to get the game to build.

But you can start the slow process of getting  all of this to work with your modern toolchain.  

Eventually, with some work, you'll get it to  build and run, and then you'll have an exact  

version of your game from the past running  on your modern computer. Congratulations.

So once you're at this stage, you'll have  an old version of your game playable,  

complete with whatever server backend and  tooling existed back then. And as this was  

a version you had live and had released at  the time, it would theoretically work if you  

deployed it onto some servers on the internet  and gave the download link out to your players.

But this would be a big mistake.

This old version of the game you got running  is really far from being actually releasable.

For a start, while players love the idea of  playing an old prehistoric version of the game,  

they're probably viewing what that version  was like through pretty-heavy rose-tinted  

glasses. You've applied a decade of quality  of life improvements to the game since then,  

and those are all going to be absent. Now,  while I'm not suggesting that you go through  

and reimplement all of these features,  because that undermines the purpose of  

the classic version, you're going to have  to at least evaluate which changes the  

important ones are to players and the ones  they're going to refuse to live without.

Without a doubt, the old version will contain  bugs that you've actually fixed since then.  

All of these bugs will be back, and fixing them is  sometimes not as simple as just applying the same  

fix as before, because the exact order of changes  to the code will differ in the two timelines.  

Some of these bugs will be exploitable by players,  so you'd better hope you fix them all fully,  

because people are going to try  to profit from them on day one.

Speaking of profiting from exploits, all of  your anti-bot and hack detection tools will  

be reset back to the stone age, whatever  you had built for your initial release.  

These are unlikely to be able to deal with the  toolkit of modern automation that your players  

will throw at this version of the game. After  all, they've been working on improving this  

for like ten or fifteen years, so you'd need  to backport all of that stuff across as well.

But it's not just your contemporary anti-bot  tools that need to be made compatible,  

but every single piece of your customer  support and operational tooling. After all,  

your customer support staff are going to need to  immediately start fixing problems with accounts  

and purchases, and they will need the modern  tools that they are trained on and are able  

to use efficiently for this. Don't forget  that all of your game activity and retention  

reporting tools need to be updated as well. Your  stakeholders are going to want to know how well  

the classic version is doing in just as much  detail as you provide for your modern version.

Speaking of tooling integration, there's  also the issue that the old version just  

won't be compatible with your modern  notion of what a player account even  

is. In order to have it tied into the same  billing system, you'll need to integrate it  

with your current account system, and that  involves a decade of modernisation to any  

code that touches player accounts. And that  has to be done Carefully with a capital C.

But the nightmare doesn't end there. In  2018, the European Union introduced the GDPR,  

an extensive data protection framework  that requires significant legal compliance  

work on your end. Your pre-2018 game  almost certainly won't be compliant,  

and it must be. And that's just the start of the  regulation compliance quest you're going to be  

going on. Every single aspect of user generated  content, child safety, loot box disclosure, and  

whatever else people are regulating will need to  get modernised in the classic version of the game.

If you somehow duplicate all of  this work into the classic version,  

you then have to keep doing it every time the  modern version changes. You essentially have  

two versions you have to update side by side,  and this is very hard to sustain in practice.

As you can see, for this classic version, you  want the really old version of the game content,  

but you don't want the really  old version of the game code  

and infrastructure as you have to fully  update that to the modern one anyway.

Rather than going back in time and  grabbing the old snapshot of everything,  

you probably need to grab just the classic game  content and port it to a modern copy of the game  

engine and infrastructure. This means that all  of your hard work on bug fixes, bot detection,  

legal compliance, and operational tools  can be immediately leveraged. With one  

game backend running two different versions of  the game, it's more trivial for infrastructure  

improvements made to the modern game  to benefit the classic one immediately.

So this becomes a content porting exercise,  trying to get the old art, gameplay, balance,  

quests and so on to work with the  modern engine, as faithfully as  

possible. Depending on how you have architected  your game, this could be a whole lot of work.  

You may have to emulate old rendering  behaviour, or even old gameplay behaviour,  

to make it feel like it used to. But in order  to be able to practically run this classic game  

as a serious ongoing service rather than just  a toy, it's the best path for most studios.

Overall, I'd only recommend doing this  whole process and creating a classic  

server for your game if you feel there's  an extremely strong business case for it.  

One of the concerns is that a lot of the  players who enjoyed the early days of the  

game rather than the current version have long  left, and it's a really expensive and difficult  

marketing proposition to get them all back to  play the classic version. Strategically, it has  

worked out really well for Blizzard and Jagex with  their classic servers, but then World of Warcraft  

and Runescape are two incredibly popular,  enduring games with passionate communities.

If you enjoyed this video, please  like it and consider subscribing.  

Thanks very much, and see you next time!