ERA is a top-down 2D online role play game originally created by members of former dutch gamestudio and community for RPG game creation "Solarsoft". Built in Visual Studio on top of XNA, MongoDB and Scriptmonkey. The rpg can only be played online and is also a tech demo for the programmers. We built a distributed server system (eventually consistent) with rich world system such as global weather and extensive AI. The abstract: In a world where two major powers involved into a comprehensive battle, where magic and technology strike each other with what they got, you try to find a way to wealth, power or happiness. Alva, a world immersed in chaos, awaits the arrival of a new hero; it's savior. Will you lead your followers to a glorious victory or profit from the knowledge left by the ancients? Your future awaits...

ERA is more about game mechanics and as a tech demo than it is about graphics.

  • View media
  • View media
  • View media
  • View media
  • View media
  • View media
Post article RSS Articles

Instant Play


Today I would like to tell you something about one of our features called instant play. Analogous to the flash games, we provide the possibility to play the game without registration. As a matter of fact, no registration is required to play or to continue playing. Starting over can be as easy as pressing instant play, yet the possibility to load an already existing journey remains.

Below I will elaborate on the mechanisms between instant play, the limitations and how the registration process takes place. Specifications are provided so one can learn and continue from and on this article as he or she likes.


Press a button and start playing. This mode is activated when you launch the game and press (instant) play. You will spawn in the world with your character randomized. Later in the game you have the possibility to restyle yourself. However, if you are unsatisfied with your looks, you can always start anew. The story is not directly introduced, but will be presented gradually. As for game play, a short tutorial guided by a sequence of images will provide all the necessary knowledge to freely roam the world. This way a more comprehensive tutorial (but also invasive as to freely roaming) is not mandatory each time you start a new session, with the side note that some players just don’t like tutorials.


To explain how the feature works internally I first need to explain how authentication works in the first place because the feature is a special case of this authentication. Please remember that we use distributed servers that are eventually consistent, but for the sake of this post, assume that we only deal with once server and one database on that server.

The MD5 approach

In the time we didn't knew any collisions for the md5 hash algorithm it was practice to hash the password - preferably salted - and save this password in combination with the username in a remote database. Even though this was already bad practice, rainbow tables where not used that much. A simple select statement would yield the validity of the credentials and the account. Nowadays we know that there is much wrong with this approach in the first place and that it is easily compromised. Using a rainbow table, this method is the same as saving passwords as plain text and that is not a very good thing to do. Read about these methods and their strengths here.

Apart from the fact that a rainbow table reveals all short passwords if the database would have been hacked, a man in the middle attack - where someone poses as the destination server but in fact records everything that is said or in our case sent. Sometimes data is modified as well. To deal with this problem, SSL uses a third-party (certificate authority CA) to authenticate the endpoint(s). This third-party connection is something we can't afford in terms of speed and complexity, at least not every connection, so we had to come up with another approach. In fact, we would like to look at the following 6 points (taken from the section security analysis of the SRPP paper):

  1. Prevent an attacker from being able to guess and verify password P based on exchanged messages.
  2. No useful information about the session key K is revealed to an eavesdropper during a successful run.
  3. The protocol should prevent the intruder from gaining access to the host or learning any information about passwords or session keys, even if an intruder has the ability to alter or create his own messages and forge the origin.
  4. If the host's password file is captured and the intruder learns the value of v (password equivalent such as a compute(P) value saved on the server), it should still not allow the intruder to impersonate the user without an expensive dictionary search.
  5. If the session key K of any past session is compromised, it should not help the intruder guess at or otherwise deduce the user's password P.
  6. If the user's password P itself is compromised, it should not allow the intruder to determine the session key K for past or present sessions and decrypt them.

The secure remote password protocol

A guy from Stanford (could have easily been a girl) called Thomas Wu came up with a secure way of handshakes to make a third-party redundant while also obscuring passwords in such way that the password is never sent over the network and not saved in the database. All the six points from above are covered. I would suggest, if you are interested to read about it because it's a pretty good read. Here is a link to the paper itself.


So the method of authenticating is secure, but we have no way yet to insert verifiers into the database (password equivalent such as a computation on P. We don't like to send the password over the network so instead we do it a little bit different. This time we have to make sure that:

  1. The password is not transferred over the network.
  2. The registration server is valid (we don't want any man in the middle attack).
  3. The connection is secure.

The specifications of the authentication algorithm are open to anyone and it doesn't break with that property. This means that calculating the value of verifier v can be done by anyone, if you know password P. We use this to eliminate point one. If you read the paper you realize that even if some client knows v, but not P, any authentication attempt will fail because this client will not be able to compute any verification code as this client misses the value of P. All this means is that capturing v while registering will not directly compromise the password without some extensive dictionary search.

But we rather not have it being captured, so we have device some contraption in terms of code to make sure that the road on which the information travels is a private road and that the destination is ... well us and not some third-party. Right now we didn't see any other solution than setting up a one way secure connection since we only need to send information towards the server, which will record this information. And what better way to use a SSL connection? What we need is a SSL certificate on the server end which will be able to decrypt the information it was send - this is the private key. Which each client (or web-server) we include a copy of a way to encrypt the information - this is the public key and voilà, we keep the connection secure and validate the endpoint by using SSL.

Anonymous registration

Ok, we can now register new members in a secure way and authenticate them too. How do we go from that to instant play? All we need is a unique anonymous registration. So what we do is call up the registration service sending "Anonymous" and no password. The server generates an unused username (just some numbers and letters) and sends these back to the client. We don't mind it being unsecured, the username U is publicly exposed during SRPP. The client now generates a password P and stores this with the username in a key-file on the computer. The client now calculates the value v and sends this - encrypted - back to the server to complete registration.

The key-file is used when hitting instant play (continue) and destroyed when choosing instant play (new). We don't mind someone not being registered, since would still be able to block IP's and hostnames as we would when someone is registered.


Storing the anonymous values as plain text in a key-file itself is insecure. If this file was stolen, the player would lose his or her account. However, this is just one of the downsides of playing with this method. What we could do is provide the capability to encrypt the key file with a password which one must enter to play, but that would defeat some of the beauty of just pressing enter and playing directly.

Since the usernames are generated we don't allow players to add friends to their profile. Friends don't go per avatar but per user. Furthermore, support tickets can't be requested by instant play users, since we don't have any clue who this person is and we don't have an e-mail address that goes with the account. In case of security questions we would never be able to verify that this person is actually the original owner of the key-file, so we simply don't allow it.

You can only play the instant play session on the computer you created the session. However we do provide the ability to save the key-file and thus making it possible to import the session on another computer. This also means that you could have various session stored on one computer, but this is all much more work to maintain.

moonmansmeme - - 261 comments

Looks Great !!

Reply Good karma Bad karma+2 votes
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.