2004: HTTP multiplayer technology
Making games on mobile is somewhat diverting: on one hand you have a very limited platform to work on — which is extremely demanding as you lack almost everything: memory space, speed performance — and on another you have to make people play to your game despite all these limitations.
You find yourself being back in time, while programming `80s systems: ZX-81, TO7, etc…
But things have changed: playing gorgeous titles on PlayStation and Xbox is common. How could people play '80s titles nowadays?
Trying to answer this question leads you to a less common question: what makes a mobile phone the unique play station when compared to others?
Connectivity! In space — you connect to others players — and in time — you "wear" your phone almost 24/7.
Connecting players
Connecting players in 2004 was something challenging. You want people play altogether, regardless of their actual handset technology — java, Brew, Symbian, etc. — and also regardless their operator.
Most of the available system widely supports HTTP connections. Sockets were not always available: for example with java, only MIDP2 defines a TCP support, but unfortunately, implementation was optional.
The system had to use HTTP support then. Unfortunately, performances of HTTP connections are not really impressive. Though HTTP is an applicative protocol that lies on top of TCP/IP, it only defines a peer-to-peer connections.
HTTP is a peer-to-peer protocol
Peer-to-peer basically means that for connecting from one end to the other end, intermediate routers or servers can relay the connection to the next "hop" by choosing what type of HTTP connection is the best suited for it.
All these "hops" are time consuming. Each per creating a new socket to the next hop, and potentially check and rewrite HTTP headers.
As a result, roundtrips performance drops dramatically when compared to direct TCP connection.
Radio to Internet connection
Another issue of importance is certainly the radio to internet part of the connection.
On the operator side, you don't really have access to the infrastructure. The only thing you know is that your connection is routed by a special equipment called an APN. It is the connection to the Internet, think of it as an HTTP proxy.
Behind it, on the operator side, IPs are local. When on the internet, you basically have the operator's public IP.
Some operators block packets that would get to "unknown" server IP, and in that case, you have to deal with the operator in order it lets you pass through the APN, down to your server.
How to authenticate players on your server
When HTTP connections arrives to your front server, IPs are usually not a mean to authenticate the player. At most, you can know from what operator he comes from, if you recorded all possible APN IPs somewhere in a database.
Some APN, gently add an HTTP header extension which tells what IMEI number the mobile has; but you shouldn't count on it, as this is the exception.
You have to rely on a custom, different mechanism of your own, such as a login/password system or a smarter thing.
What type of game to expect?
HTTP connection usually gives you an average roundtrip on GPRS networks of about 2400ms. Yes, you read it right: 2 and a half second to send a small message and get a response from the server.
If you tell me you can't do any game with such a latency, well my answer is: you're wrong.
Of course, you cannot design a racing car game, where you expect realtime collision detection over the network. 2400ms of roundtrip is of oder of magnitude to make such a game.
But if you design a game that do not offers high sensibility to latency you really can make funny games.
For example, we designed a multi-player version of the Microsoft/Rare Mr. Pants license.
Mr Pants and Battle Bubble Multiplayer
Basically, Mr Pants is an action puzzle game where you have to make rectangular blocks with the pieces you get form the game by rotating them appropriately in a limited time.
Every time you complete a block, the surface it takes is cleared and you collect bonuses and points.
Adapting the game to the above-mentioned constraints, the team designed a game play that wouldn't suffer from very high latency.
First, the screen of the opponent is also displayed on the player's screen in the top right corner, in order for you to look at his progression.
Second, when you complete a block, the game send a malus to the opponent, making its time limit to shrink a little bit, thus increasing the match pressure.
This way, it does not that matter wether the malus is coming "in-time" or not. What it counts is that it arrives!
As a result, the multiplayer version is really funny, and maintains the interest over time.
