Mischiefblog
I make apps for other people

Thoughts about mobile and multiple client type gaming

Posted by Chris Jones
On December 27th, 2007 at 15:52

Permalink | Trackback | Links In |

Comments (2) |
Posted in Design Journal

I identified several components as being critical to enabling mobile multiuser gaming through an HTTP interface (such as an iPhone). I assume the mobile device is capable of CSS and Javascript/AJAX and presents a standard DOM.

Based on my experience with T-Mobile’s GPRS system in Seattle, I assume that HTTP over GPRS, EDGE, or 3G is unreliable. My wife’s experience with AT&T’s EDGE service with her iPhone has been much more positive, but this could be because of the flexibility and reliability of Safari over Windows Mobile’s Internet Explorer. In any case, I have to assume the worst.

Simple Retransmission Protocol
Message IDs between the server and client are independent and sequential. If a message arrives out of order and the missing messages have timed out on receipt by the client or server, either side should be able to issue a resend request for message IDs.

Implications
On both the server and client side, a message buffer must be implemented. On the client side, the message buffer should discard in-order received and processed messages, such that only out of order messages are held before processing and the queue gets a chance to refill.

On the server side, cumulative world state changes, messages, etc., need to be stored for the client between batch updates. Some reasonable (10-30 seconds) window of state changes need to be stored in case of retransmission.

Both the client and server keep track of IDs.

Client Actions
When the user performs an action in the client, the action request is stored for the next update polling request. Some actions may force an immediate update polling request. The update request may have one or more actions performed by the user.

Update Polling
Every n-seconds, the client sends an update request which contains recent client actions, which causes the server to send an update batch in return. Each update batch should be of minimal size, using IDs where possible (both for graphical and text resources, if appropriate). A batch contains one or more identifiable update blocks, which contain:

  • system messages
  • broadcast or tell messages from other users
  • movement updates within the client’s viewport
  • state updates on mobiles within the client’s viewport

Additional update blocks may be included in the batch to fill in missing updates. The batch may also includes a list of missing client message IDs that the server never received. The client may, if designed appropriately, resend recent, missing messages.

Message Queues
In short, message queues (MQ) allow sharing of messages in a generic way between system components. The upshot is that it allows for translation of messages between client and service types allowing a single MQ to serve and synchronize world state between multiple representations (browser, 3D client, text).

A message is as detailed as the component which uses the finest detail, where possible. It’s up to the interface to the client to translate these messages appropriately, such that a user of a text-only client might have to enter “walk to Soandso” in order to move his avatar around the room or zone in a way that 2D and 3D clients could see. Likewise, a 3D client walking around the room would have to be translated into text terms (“Soandso meanders until he stands beside Alice.”).

MQ multi client high-level view

2 Responses to “Thoughts about mobile and multiple client type gaming”

  1. Chas Says:

    Interesting. Any thoughts on how many of the mobile platforms available are CSS+ Javascript/AJAX capable?

    IIRC, as late as “windows mobile 5″, its browsers weren’t very CSS friendly, let alone AJAX. I haven’t been following it too closely, but about a year ago, a client was all excited about porting some of our learning content to be playable on mobile devices. Ends up that, outside of the executive class (who wouldn’t be using it) less than 7% of the potential learners that HAD at least one mobile device had something that could display html4 or do more than very basic javascript.

    Interested in seeing how the market’s shaping up

  2. Chris Says:

    Gizmodo claims the iPhone has 0.10% penetration over all browsers. In Q3 2007, the iPhone had 27% of the mobile browser market.

    I’m not targeting exclusively to the iPhone (it’s a hard platform to monetize without a subscription or micropayment model–aka, small screen, small ads). I consider the iPhone to be a “bonus platform” with the majority of browser-based play done on PCs with serious screen real-estate and bandwidth to spare. I’ll put up a blog post later with my thoughts on the iPhone as a platform and a mock-up of what a mobile browser-based game could look like.