mca blog

over the last couple weeks, i've been chipping away at a side project that involves implementing a classic adventure game while relying on the Fielding's hypermedia constraint.

hypermedia

this app is not all that important - in fact, it's quite simple. and that is one of the best aspects of this experience. since the app is simple, i don't get tied up on the details of application flow, etc. instead i get to focus on what it takes to implement the app using hypermedia as the engine of state change. it is hypermedia that i'm learning, not the unique aspects of the app.

as the engine

another great beneift of working with the adventure game application model is that it is, essentially, a state engine. all adventure games are. there is a set of commands the player can use. each command gets interpreted by the app and, based on where the player is in the game, what things are available to the player (in their 'kit'), what items are nearby (monsters, treasures, etc.) and so on, the game computes the results, displays the info and returns for another command from the user.

this is very close to the way REST-ful implementations work. it is also an ideal environment for implementing REST-ful client applications. think about it, the browser is a state engine, too. again, this makes adventure games very 'friendly' to both server and client apps that know the Web. i don't have to deal with odd features or requirements here, either.

of application state

and here's the real fun. each player has their own copy of the application state in an adventure game. the server keeps track of that player's data and, on each "turn," sends that state to the client in a representation (HTML, XML, JSON, etc.) that the client understands and prefers. so now i get to relate the game state to the client - an essential step in REST-ful apps - and the server can manage the app state as the client moves along in the app.

this has had some enlightening moments, too. i store the application data on the server in a format tha allows easy transformation into any representation the client wants. so now i have a clear storage place for application state. this is not the place where application processing takes place - there's a clear separation here. instead i use the server script to compute any random values, increment moves, decrement strength and all the other important variables. then i update the application state for this user and pass the updates state to the transform tool to produce the representation for the client. very clean. very REST-ful.

and the winner is...

in the actual work of implementing the game as a #HATEOAS-driven app, i have almost all the work done including actions like picking up found objects, interacting with supplies (buy, sell, etc.), and moving about in the game space. my last big work is dealing with 'fighting' monsters in the game. this is a bit more involved interaction and i've just not gotten around to it yet. but once that's done, i'll have covered all the processes in a simple text-based adventure game.

next, i'll need helpers

the next big work will be cleaning up the representations for the common media types (XHTML, XML, Atom, JSON) and tightening up the server code. then it's on to the client implementations. when that comes, i'll be looking for folks interested in doing common clients such as browser, RIA, hand-held, etc.