Recently I was flirting with the idea of creating an online game, but I got distracted by wondering how to make the back-end more flexible.
To communicate the state of the game to N connected clients I figured I needed some kind of server which would accept "join"/"quit" requests and then make changes available.
To that end I came up with the idea that a client would make requests via HTTP such as:
- http://example.com/server/game/chess/join
This would regard the originating client as part of a new chess game, for example, and return a UID identifying the "game channel".
- http://example.com/server/changes/1-2-3-4
This will retrieve a list of all events which had occurred in the game which had not already been sent.
(Here 1-2-3-4 is obviously the UID previously allocated.)
- http://example.com/server/submit/1-2-3-4/move
This would submit the move "move" to the server.
After mulling this over for a while it seemed like a great reusable solution, I'd make an initial "join" request, then repeated polling with the allocated UID would allow game moves to be observed. All using JSON over HTTP as the transport.
It was only this morning that I realised I'd have saved a lot of time if I'd just proxied requests to a private IRC server, as the functionality is essentially the same.
Still I'm sure this pattern of "join"/"poll"/"quit" could be useful for a lot of dynamic websites, even in the non-gaming world. So although the idea was mostly shelved it was an interesting thing to have experimented with.
D'oh.
ObFilm: Conan The Barbarian
Tags: doh, experiments, http, json, reinventing the wheel 3 comments