A 72H MMO game, from Theme to Reality.

Posted by
December 14th, 2014 2:07 pm

Hi there,

here is an in-depth feedback about how I implemented the MMO part of  C.O.S.M.M.O.S – Cool One Screen MMO Spacegame,  in 78H : what I faced, and how I managed to get it work anyway.

A “MMO” (Massively Multiplayer Online) ?

Let me detail. The game :

  •  is online,
  • accepts any number of players at the same time,
  • allows players to interact with each other,
  • has a shared and persistent universe.

Well it’s enough to cover most of the definitions of what a MMO game is. I only have a doubt about the “Massively” because I couldn’t test with a “massive” number of players, but I’m confident than at least 100 players could be connected at the same time.

Regarding the range of interactions between players, it is of course limited to a few key points.

The game

Let me sum you up what the game is about to then understand interactions.

The game is about travelling in space and collecting symbols (letters) to establish communication with alien populations :

  • Each population has a different sentence to decode, and the players can send letters one by one to the population.
  • If there is an undiscovered letter in the sentence matching the one sent, the player earns reputation and the letter is discovered to for all players.
  • If there is no more of this letter in the sentence, the player remaining attempts diminue by 1.
  • Players start with only one letter and get random new letters when travelling.

It’s like a hangman game but there is a full sentence to guess and the letters are revealed one by one, which make player have a “stop or keep going ?” tension every time.
The ultimate goals : for one player to have the most reputation, for the server players to have all planets completed !


Interactions consist in :

  • sharing travel cost between planets to allow for faster or further moves (some planets are so far that they can only be reached by 2/3 players together),
  • using letters from other players on the same planet to communicate with the alien population.

Not much, but already a lot to implement ! Let’s see what it is about.

How big do you think the technical stuff is for the MMO part ?

Here is the list of all I faced and had to solved for the realization :

  • Communication between client of server (of course).
  • Cheat prevention.
  • Databse data model for long time storage.
  • Clients update logic for every state change on the planet they are at.
  • Setting up a production server available full time.

On top of that, what you could face for any game :

  • Graphics.
  • Client development.
  • Procedural World Generation : planets (name, visual, sentences, coordinates), alien (visual), and players (ship visual).
  • [Musics and sounds] (didn’t have time for that :()

You love technical stuff and want details ? Here you go !

Game architecture overview

The game architecture itself is pretty simple : One database, One server, Several clients :

Lythom - COSMMOS - diagramm

Here’s how it works :

Communication between client of server

The client is a flash client compiled for version 12 using haXe and openfl.
The server is a nekoVM server compiled using haXe and openfl as well.
The machine is a dedicated windows server at online.net. (This kind of machine, it’s really affordable.)

Flash Policy File

Why am I insisting on the LOCAL part ? Well because you guessed it, when it came live on the machine, it didnt work anymore. The Flash client, when trying to connect to an external server, asks the server for a policy file. Since flash 10, it is required that the server answers the policy request to allow the connection. It didn’t took me a while to understand how it works and to set up the server (quik’n’dirty way) but we all now how much 1 hour is during a jam.

Transmitting data

About data themselves, I had the choice between setting up a low level protocol to send row bytes and using a serialization system. I believed with a low level protocol it would have taken me a lot of time to cut my data into protocoled messages. In exemple, a protocoled message could be : INT32(length of the message)-INT16(Type of message). Then depending on the message : -INT32(length of playername string)-CHAR[n](playername data)-INT32(current reputation) etc.
It’s the best choice when you seek high network performences (ie. to achieve 20 networked messages / second).

As I didn’t need frequent transfers I prefered another solution : serialization. I defined a very simple NetMessage class to handle the data that contains a MessageType (enum), and the message (Dynamic object). The haXe serialization do the magic :

  • Server :
// "allPlanetData" is a complex object : list of players and planets with visuals etc.
var sending:String = Serializer.run(new NetMessage(NetMessageType.Welcome, allPlanetData);
  • Client :
 var fromServer:String = socket.readUTFBytes(socket.bytesAvailable);
 var message:NetMessage = Unserializer.run(fromServer);
 switch(message.type) {
     case NetMessageType.Welcome:
     CockpitScene.instance.welcome(message.data); // the data is the "allPlanetData" object
     // ...

Can it be more simple ?
Don’t get tricked, serialization cannot serialize anything even if the support of serialization in haXe is wide. Ie. I can’t just send my Flash BitmapData from server to client for the good reason that openfl serverside implementation of BitmapData is different from Flash implementation and it contains a lot of complex and useless data to transfer. As a workaround : I transform the BitmapData into Array<UInt> using the getVector method (neko side), transfer the array, then use setVector on a new BitmapData (client side).

The package overflow

It was not planned. I thought some flash low level network library would handle it for me but no : when the data is too big to fit in one TCP packet, it goes in several. Each packet triggers a “hey here’s what I got” callback with only a part of the message which can’t be used (because the Serializer needs the full message to work).
How to get by that ?

  • The good way : have an Int32 as first data in your package that indicate the message length. While the received data doesn’t match this length, keep listening and concatenate messages until you got it all.
  • My (dirty time is precious) way : try to Unserialize every time and concatenate while it doesn’t work. As long as it doesn’t unserialize, it means the message is not full.

Really, if you have to do that, use the Int way. My method uses extra CPU and If it happened that the message unserializes while uncomplete, it would crash the client. (Not the server, there is no long messages client->server so the server will ignore any input longer than one packet :p).

Cheat prevention

Now that the data goes, I have to care about WHAT data goes.
It’s really simple : every client action is checked by the server, if it’s allowed it will be ok, if not it will either send back an “action failed” answer or just do nothing. This can happen if, for exemple, several clients connects with the same account on the server (there is no protection against that, please be fairplay !). What will happen : the two players will have inconsistent data, depending on other player actions, because the server will only answer to client that asked for the action. Mostly, one of the player will ruin the experience of the second one without getting any advantage of it.

You might ask why I chose to set no password system ? I have good reasons for this :

  • Having a proper password system is time consuming : proper hashing with salt and pepper, password retreival (because people forget their passwords), using an SSL connection (https) to secure the transfer.
  • Because I didn’t have that time, I would have been forced to store passwords unsecurely.
  • I don’t want to be the cause of accounts hacks in case player used the same password for this game than elsewhere.

Storing password is not something I refuse to do in general, I have the knowledge to take this responsibility. But NOT in jam conditions, I don’t mess with security.

Setting up the machine

As mentionned earlier, the machine is a dedicated windows server at online.net.
It has to be a dedicated server : the choice of making a MMO have a constraint : server administration.

So that people can play my game :

  • it must be on a fulltime up server,
  • I need to frequently check for crashes (It happened 4~5 times since last week but I could reboot it without damages and finally have a patch),
  • I need to check if there is no errors in the database (especially after a crash).

If the server is not live, then people can’t play. For this reason, I have to full time watch out after the server to be sure it is running fine in order to deliver the best experience.

How can you achieve THAT in 72H ?

The answer is preparation, preparation and preparation. But more exactly…

Proof of Concept

Before the project, I set up POC (proof of concept) in my Ludum Dare template. It allows me to send data from a LOCAL server to a LOCAL client and vice versa on a TCP socket connection. By data I mean Bytes and Integers, low level stuff.  It took me several hours to build it up, this development wouldn’t have fit in the jam time.


In one word : practice !

I’m not new to networked games since I wrote my last year study dissertation on the topic. I knew what to expect and what not to expect, I could be reasonable about the network features thanks to this experience.

I’m not new to game jams either (it’s my 13nth or 14th). I knew what to expect and what not to expect, I could be reasonable about the gameplay features thanks to this experience. Trivia : the whole hangman gameplay system (sending letters, checking result, sending answer, recording data) was made in less than 2 hours whereas it took me more than 6 hours to get the travel system working.


I used the same technology for client and server. Data writing / reading can be a real headache if you don’t master the low level storage of your data (number of bytes for each data type for each system / language etc.). Thanks to haXe and openfl, I just used the same classes and enums server side for my data, big time saving for transferring and a bit for coding too.

 A last word

Thank you for reading this ! There is probably more to say about the topic, but I think I covered the key points.  Yet, if you have any question, feel free to ask !

Finally, because the game worth playing together more than alone, I’ll invite you soon in a “play together” session. I’ll post a message on the ludum dare site and tweet the date very soon, stay tuned !

2 Responses to “A 72H MMO game, from Theme to Reality.”

  1. gltovar says:

    Awesome, thanks for sharing. I was wondering if you could have a variety of clients targets, such as mobile.

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]