Client versioning

I’ve been a bit lazy since I came back… but I’m starting to work on alpha 2 again.

As some of you noticed, .NET 3.5 SP1 is out. That’s something out of the way.

On the coding side, I started implementing some versioning.

OCTGN is tagged with a version, alpha 2 will be

So what is this number?
First digit (0) is the major number. It will be 2 for the final release and is (hopefully) not expected to change any time soon.
Second digit (2) is the minor number. This number reflects incompatible or important changes. Two clients, which don’t share the same major.minor numbers, can’t play together. This number will change a lot during the betas, but probably not much once the final release is done.
Third digit (0) is the build. This reflects new features or any other significant change. But no compatibility is broken.
Last digit (0) is the revision build. This is used to publish bug fixes and such. No real change in the client, just a new revision to fix a few things.

This is enforced by the software, and the server refuses any connection from a client with a different major.minor version. So you can’t inadvertently run into bugs because you don’t have the same version as your opponent.

Game definitions include a required version as well. You won’t be able to import a game, which was created for a later version of OCTGN. Moreover, inside OCTGN itself is kept a backward compatibility version number. So you won’t be able to load or play a game created for a previous version, which is not compatible with the current version anymore.

You may think this is pushing a little bit too far, but it’s not. Because OCTGN is still in alpha, I know there are things I want to change. There will be a lot of breaking changes until the final release. With people creating games and me breaking the client, it will quickly become a mess if we can’t know what version a given game works with for sure.

There’s another versioning aspect I haven’t taken care of yet: games. What if a game definition changes, what happens to the patches? What if two different persons start sharing different games or patches under the same name (this happened before). I would like to tackle this issue as well before releasing alpha 2.

Let’s sum up what’s left to do, so that you don’t have to go back to older posts:

  • Create the website (others are helping for this, hopefully I’ll have news soon);
  • Prepare the deployment and auto-update feature;
  • Do something about game versioning;
  • Final tests;
  • Depending on tests, maybe some bug fixing.

Thanks for your patience!

Explore posts in the same categories:

12 Comments on “Client versioning”

  1. Joesnuffy Says:

    Glad to hea rit 🙂 Cant wait for the release. 😛

  2. Kirb Says:

    Was wondering where you’d gone!

    Keep up the good work.

  3. Goryion Says:

    Man, the screenshots are making me drool. I don’t care if it is alpha it looks GREAT! Waiting on pins and needles!

  4. Fork Says:

    [quote]What if two different persons start sharing different games or patches under the same name (this happened before)[/quote]

    You mean: if those two patches have 2 different filenames? MWS community has pretty much established standard for the patches (masterbase): the “official” one, is downloadable straight from, the other one, more “feature rich” masterbase (patches) is downloadable from

    Don’t get me wrong, those 2 “databases” have the same structure, the slightlymagic one just has more cards.

    Would it be possible to cut the patch hassle so that octgn2’s magic plugin just supported those 2 masterbases? That would solve the patch hassle as
    1) MWS-community has already established one wide spread naming scheme for the files (allthough I don’t like it)
    2) more importantly, they’re already doing all the distribution + the patches are well spread/known by the magic players.

    Offering support for MWS’s database in the magic-plugin of octgn2 would solve the patch issues: if our system doesn’t work, there always this “backup” patch system available.

  5. Kempeth Says:

    @Fork: I think jods means that two people make two game modules with the same name (i.e. Pokemon) and the modules themself are different in their game definitions… For example one person makes a quick port of the OCTGN 1 patch and the other person accurately models the game with the capabilities of OCTGN 2. The two game modules won’t be able to play together so there is the need to differentiate them.

    Your “2 databases” approach doesn’t solve this problem as nothing prevents an interested person from creating a second set of databases for the same game which are incompatible with the first two…

    One way to solve it would be a central module registry. This would allow to uniquely identify any game module. On the downside this is bureaucratic and easy to bring down.

    A realtively easy and robust way could revolve around hashes of the game modules. If the client produces a quick MD5 of SHA hash of the module and that hash, the module name and version of both players match then there should be a good chance that it is indeed the same module…

  6. roblethal Says:

    He means not just game modules, but patches (i.e. card sets) as well. We have had problems in the past with poorly done card patches being released in a hurry. Such rogue patches end up full of errors such as database information does not match the information on the card (spelling, symbols, etc.).

    I somewhat like Fork’s idea, although I am a bit torn on it. I’ll have to think about it a bit more before I comment further.

  7. jods Says:

    Kempeth, roblethal, you are both right on spot. That’s exactly what I was talking about.

    Fork, I like the idea of being able to leverage work already done, card set-wise. O2 data is quite open, so although it has its own game and set format, I like the idea of being able to create a custom set creator/import tool. This way we would be able to import existing O1 sets, or even other software like MWS.

    Of course the idea of a central repository would solve many issues. But unfortunately we know that there will be patches spread outside this repository. So it’s no solution.

  8. Cuken Says:

    The MD5 hash technique seems to be a viable solution to me. If Kempeth and I both make a game called “Pokemon” but our rules are slightly different, the md5 has won’t match up. A quick check on the hash values could determine version computability.

  9. Kempeth Says:

    The only real problem I see with card sets is when two sets define different cardnames and images to the same id. Unfortunately this is very tricky to check because there are a lot of possible reasons for the data of a specific id to be different.

    Different ordering (Incompatible)
    Set 1: [First Creature] [Second Creature] [First Spell] [Second Spell]
    Set 2: [First Creature] [First Spell] [Second Creature] [Second Spell]

    Corrected Typo (Compatible)
    Set 1: [Fistr Creature] [Second Creature] [First Spell] [Second Spell]
    Set 2: [First Creature] [Second Creature] [First Spell] [Second Spell]

    Translated Cards: (Compatible)
    Set EN: [First Creature] [Second Creature] [First Spell] [Second Spell]
    Set DE: [Erste Kreatur] [Zweite Kreatur] [Erster Zauber] [Zweiter Zauber]

    The easiest but most restrictive way would be to again run a hashing algorithm over the card set. But even a simple corrected typo or higher image resolution will make the sets appear incompatible even if they are not…

  10. Kempeth Says:

    One idea could be to require a special field for every card containing the official card id or collector number that uniquely identifies the card. Running a comparison over the internal octgn id -> official id assignments should allow to determine if the patches are compatible.

    As for cardset-module compatibility the cardset could simply reference the name, version and checksum of the module it was made for and the module contains a list of module versions who’s cardsets it can use…

  11. Colin Says:


    I see your point about the change in resolution etc, however this can easily be overcome. When you run the md5 hash alogthrim you have to pass the fields you wanted hashed into it. Certain files like Image Size, Image File, Flavor text, etc could be intentionally skipped. Each card set would have to follow a predetermined format when the creators make them.

    I.E you could do something like the format must be;

    [Card Name] [Card Type] [Abilities] etc.

    This method could even be designated by the creator, making the first line in the document the identifier for the load file.

    A quick example would be;

    Line 1: [Card Name] [Mana Cost] [Color]
    Line 2: [Forest] [Nil] [Green]
    Line 3: [Tundra Wolves] [1W] [White]

    The only immediate problem i see would be the order the algorithm tackles the card list. In this example if I did my cards out of alphabetical order, and you did an identical card set in alphabetical order, our md5 has value would differ.

    This could be remedied with the antilogarithm loading all fields into memory and then hashing them in alpha numeric order.

  12. Kempeth Says:

    From what I remember from the alpha, the game module defines what fields the cards have and the card sets merely fill those fields. This is all done in xml so you can’t go and define your own format… What you could do is specify inside the game module which of those fields are to be considered important for checking the compatibility.

    What I always forget on this issue is that there are 3 compatibility problems:
    * Between the game modules on different computers/clients (are the same decks, sections, piles and actions defined?)
    * Between the game module and the sets on the same computer (does the set contain all the data the module needs?)
    * Between the sets on different computer/clients (does the octgn internal representation correspond to the same card on both clients?)

    The second problem imo is mostly a case of backward compatibility. You have a game with 3 sets. Set two and three both introduced a new field. With an installed game module for set two the following is possible:
    * a file for set “one” does not define every field the module expects
    * a file for set “three” defines more fields that the module expects
    * a set-file from another game module defines different fields than the module expects

    The first option should most likely be regarded as compatible or else the poor devil who has to adapt X sets just because set X+1 defines a new field has my pity. The options two and three can only be detected if they define field that are unexpected or if the game module can mark fields optional/required.

    The last compatibility problem is the most tricky because there are so many things that can be different with or without breaking actual compatibility and the need to compare it over network instead of locally. A pragmatic solution would be to say: If the fans of a game can’t organize themself enough to play with the same patches then that’s their problem…

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: