Monday, 10 March 2014

Malifaux Rankings

Rankings have become a way of life within various gaming communities and Malifaux is no different so with the recent demise of Rankings HQ it was obvious that something would step into the breach (pun certainly intended) and fill that void.  It wasn't so obvious that I would end up doing it but there you go!

What this has meant is that over the last couple of weeks I have been working on and off on the replacement and its now ready to go.  Its not very pretty, as I am an engineer, not a UI specialist but its functional.  Take a look for yourself at 

The point of this blog post isn't to just say look at the new shiny though but more to talk about the underlying functionality that hopefully folks will be able to build on.  What this means is that there are a series of API functions that I have built the UI on top of, that are freely accessible by any other developer who wants to build something on top.  For instance I am working with a friend on building an iOS application.

So what APIs are available - note all responses are in JSON and if you send an invalid request you should get a 404

Rankings -You can get the current list of ranked players with positions etc.  The endpoint for this is

Player Record - This returns all of the requested players events (current and older).  Endpoint is<playernamewithnospaces>  e.g.

Event Record - This returns all of the players who where at an event.  Endpoint is<year>/<eventnamewithnospaces>   e.g.

You'll notice that everything is in a nice REST format - I had to go and learn mod_rewrite for this so that was fun.

I'm sure I will be adding more to this as I go - makes sense to me to add an API to handle the scheme generation that @malifauxschemes uses but if you have any requests just let me know in the comments.


  1. How do you plan to handle this when you have more than one player with the same name?

    Surely it would be better to use the player's database key.

  2. Folks hate using and remembering numbers though, eventually it will end up using email as a key

  3. Don't you think there's a bit of a privacy issue exposing people's email addresses via the api though? It's one thing using a name, quite another an email address that can be used to spam a person or worse

  4. Not really TBH, but if folks are concerned about it i will use something else