Game versioning

As I said last time, I did some work on the game versioning. The previous post has created a bit of discussion in the comments and some of you devised clever checks of MD5 sums.

In the end I took another way. Doing checksums is a bit too restrictive, since it prevents any changes. What if I want to correct a typo in my set? What if want to translate the set in French? Does it mean we can’t play together anymore? Better not.

What I did is that I used Globally Unique ID (GUID) to identify objects. As the name implies, those numbers are quite unique. So even if I create a game called “Pokemon” and you do the same, unless one of us copies the GUID of the other game, there’s no chance our games share the same id.

Then every set contains a gameId, indicating which game the set is for. So if I have my Pokemon game installed and I try to install a set for your Pokemon game, OCTGN will simply refuse and say this isn’t the correct game for the set. Moreover, each set also has a GUID. So again a set is uniquely identified, even if two sets share the same name. But I still can translate the set and keep the GUID if I want to.

This should have been a simple change, but due to the way cards IDs are built, everything broke down quite fast. In the end I choose to go the simple way: each card also receives a GUID. This made me rewrite part of the secure protocol and took me a lot more time than I expected. But now it’s working.

In addition to uniquely identifying every object in OCTGN, I introduced version numbers on games. They have the format: major.minor.build. Changing a build number simply keeps track of newer game definitions, but is still compatible in every respect. Changing the minor number means the patches format aren’t compatible anymore (e.g. because I removed/added a card property). You can still play against someone who has a different minor version, though (because the actual sets data is never shared by clients, only IDs are). Finally changing the major number means the game broke compatibility and you can’t play against someone with a different major version (e.g. because I added a group to the game definition). Every set indicates which version of the game it was created for.

All this is enforced by OCTGN, so you can’t really go wrong by accident.

A related feature, which won’t be in alpha 2, is digitally signed games and sets. I want to make it clear when you load a set if it is an “official” set, created by the same team as the game itself, or some “rogue” patch created by a fan. Of course I will never prevent you from loading a set, but at least you will know.

So, what’s left to do?

  • Set up the website (by OCTGN admins team)
  • Prepare auto updates (should be a relatively free feature)
  • Final tests and possibly bug fixes

Have a nice week!

Advertisements
Explore posts in the same categories: OCTGN.net

7 Comments on “Game versioning”

  1. Elratauru Says:

    Awesome, This is going better and better, love the way it will assign a GUID to each card/set/game/thing. I have to say, its an awesome idea the display of “digitally signed” set and things, this way will know what set people is using, etc… I remember when using mws the “shadowmoor matchs” where people used some cards from other sets and that things ._. ….well, I think now it will not happen.

    I’m looking forward to play Magic the gathering with 2.0!, you did a awesome interface, a nice libraries, and a nice playground… Im lovin’ it (And its not mcdonald’s xD)

  2. Jorbes Says:

    Hey Jods!

    Great idea on the GUIDs. One thing that comes to mind though…
    What if 2 different cards do have the same GUID? Maybe someone creates a patch from an existing patch or edits the patch in a plain text editor?
    Will the other player simply see the card matching the GUID in his patch or will there be some error? Or what happens when a GUID of a certain card changes, due to patch fixes or whatnot?

  3. Kempeth Says:

    Cool Idea with the GUID’s, jods. Much easier…

    A guid does not change unless you make it change. It is something the author of the element defines. He will use a random guid generator to do so. But once a module or set is written you can change as many typos or fields as you want. As long you leave the guid the same OCTGN will regard it as the same object.

    Now if some newb takes a set from a game and overwrites everything except the guids with the data of another set for the same game then we have a problem. But such things should hopefully be rare. They are also easily corrected by assigning new guids.

    only thee to go! I’m looking forward to the end of the countdown.

  4. Dr. Horrible Says:

    Who is working on the website. And I wonder why it’s taking so long.

  5. Jorbes Says:

    hmm, you really need to turn off the “processing of html” in your blog….
    i could potentially really screw you over with some nasty meta tags / javascript.
    (above message was actually just html code…. for a website)

  6. Kempeth Says:

    Any chance we could get a look at the game and set definition formats? From what I see in the blog there shouldn’t be that many changes to it anymore now that the versioning has been solved.

    This would allow the patch creators among us to get started before the actual release…


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: