I'm working in a free MMORPG and I have a problem.

I'm (with other people) developing a video recording system for the game. The idea is basically: we record all the packages sent & received with timestamps, plus some local data from the client, and then dump it in a file. For playing the video, we just emulate everything that's on the file. We also have an option to export the video to avi with ffmpeg.

The problem is: when we change between versions of the game, it is hard to maintain backwards compatibility for the video (commands added / removed, function changes, etc). Is there a good way to handle this problem? instead of having a bunch of different players and choose the right one for each version of the video file?

It would be helpful to know how does other games handle this situation.

Thanks for the help, sorry for my english.

  • \$\begingroup\$ Just as a some more food for googling/researching: The way you do it is exactly how id's Quake Games recorded Demos, by capturing Server Packages. As far as I am aware they simply never resolved the compatibility issues. \$\endgroup\$ Commented Nov 10, 2010 at 18:42
  • \$\begingroup\$ I've changed the title of this question- it's not really about MMOs, except that MMOs are the most frequently changing games. \$\endgroup\$
    – user744
    Commented Dec 2, 2010 at 16:31

3 Answers 3


Our basic rule is to never change an existing packet type. Everything is either added at the end of an existing one, or a new command. This also makes it far less likely for two people to stomp on each other's work.

  • \$\begingroup\$ In this game it happens.. Packets are added, removed, moved (for example, some time ago, we've decided to move all GM-Commands related packets to an "extended packet", this would probably happen again when we rewrite the guilds system.. Editing commands/functions (changing its functionality) is less likely, but that isn't the point. You say that from now on, we shouldn't remove any package, delete commands just let them unreacheable server side? Thanks for your answer! \$\endgroup\$
    – Marco
    Commented Nov 10, 2010 at 17:45
  • 1
    \$\begingroup\$ Yep, deprecate and leave them there. Eventually old stuff can be removed, but that is usually after a year or two. \$\endgroup\$
    – coderanger
    Commented Nov 10, 2010 at 18:36
  • 1
    \$\begingroup\$ Also, some extra planning would help. The better you plan out your packets now, the fewer changes you'll need to make in future. \$\endgroup\$
    – Kylotan
    Commented Nov 11, 2010 at 1:00
  • \$\begingroup\$ The problem is that the game is always changing. We add a new packet almost every month (we add new features). And yet, we have to do a lot of changes to the old packets rewriting features and so.. But I guess we can leave the methods there and wait a year to remove them. \$\endgroup\$
    – Marco
    Commented Nov 11, 2010 at 16:51
  • 3
    \$\begingroup\$ Using more generic packet types would help you a lot here. You shouldn't need to add new messages for every new feature you implement. \$\endgroup\$
    – Kylotan
    Commented Dec 2, 2010 at 18:11

It's not inconceiveable, especially on a PC, that they just version the gameplay code and bump the version when they make a change that affects the replay system. If replay file is tagged with the version of the gameplay code it was created with and the client still has access to that version that it should work fine.

  • \$\begingroup\$ That's how I've seen this done in practice, store the version number with the game log. Then of course you also have to keep previous software versions around to replay previous logs, e.g. in a source code repository, but you should probably be doing that anyway. \$\endgroup\$ Commented Dec 2, 2010 at 17:18
  • \$\begingroup\$ Thanks for your answer, the game is free (GPL licenced), so anybody can access to old game versions, and even compile the client so it isn't a problem to have all the different versions of it. This is very used, not all the alternative servers use the latests versions, there are servers that run versions from 2004.. \$\endgroup\$
    – Marco
    Commented Dec 5, 2010 at 7:30
  • \$\begingroup\$ @Marco: I suspect how SC2 works is that it puts almost all of the code in a DLL. When it loads a replay, it checks the version, and loads the DLL for that version, and runs. It's quite a bit more complicated, but the user only needs one install, and one exe can run all the old replays. \$\endgroup\$ Commented Oct 21, 2014 at 17:28

One way of tackling this is along the lines of a game called "Heroes of Newerth." (which changes every +/- 2 weeks) From what I can tell they:

  1. Use diff patching for the game and replays.
  2. All replays are stored on the cloud. They eventually expire.
  3. If the user wants to watch an old downloaded replay they need to use the "Compatize" button first.
  4. It looks like this either remote diffs to the latest version; or in the event that the replay is no longer stored, uploads it and then does the remote diff.

Because I don't work at S2 I clearly can't say that is definitely how it works. However, I have noticed a marked download size trend associated with the age of the replay.

Either that, or they add entity patches to the replay (e.g. spell X has Y effect instead of Z effect). If packet-related information is also stored in the entity configuration this entity hot-patching would allow you to understand older packets as well.

I definitely wouldn't store historical behaviour on the client because that can get enormous very quickly. Especially when the client is updating from e.g. 10.1.0 to 10.2.0 (as they need to download every patch between the two versions, instead of the final patch).

Google Protobuf is a good idea as a serialization layer because it supports stuff like this by design.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .