mca blog

as mentioned in a previous post, i have started a side project to implement a simple text-based adventure game using the HATEOAS principle described in Fielding, 2000. and it's been interesting so far.

application state

my first enlightenment came when i needed to convert this simple adventure game written in BASIC into a Web app. the app depends on a set of state values available for each 'move' of the game. a set of variables for the number of moves, the diminishing energy of the player, the content of the player's satchel, etc. since the server uses this state information to determine appropriate responses to moves, i decided to store this as application state on the server. in fact, it's application state for this particular game run.

keeping track of the state and making sure it's available for the player on each 'move' was easy; i use a URI pattern that includes the name of the state file (for this game run) on the server: /asimov/games/{game-id}/{room-id}. now each pass in the game can easily find the proper application state for that game run.

hyperlinking the moves

you proly also noticed the {room-id} reference in the URI pattern above. each move in the game takes you from one room to the next. currently these are simply numbers (room 1, 2, 3, etc.). rooms are represented by a URI; that URI returns a resource representation with descriptive text ("You are in the main cabin") along with some application state information ("You have 10 units of oxygen left") and a set of links that tell the player the possible moves available at this time (up, down, north, south, east, west).

handling moves via links is great. it's simple and clear. but there's a serious drawback to this URI pattern. players can see the room ids and once they find the room that has the exit they can copy this room id and pass it along to friends, etc. ha! there's a limit to the value in clear URIs, eh?

to solve this problem, i plan to obfuscate the room data in the URI using a hash of the player name and game id. this will be completely consistent for each game instance, but different between games. since URIs can be opaque, this change will not adversely affect the game play at all.

next up - actions

no adventure game is any good if you just move around in the space. you need the ability to take actions such as engage monsters, pick up treasure, trade with supply bots, etc. this is my current focus. i need to implement these activities as resources and representations that support the standard HTTP methods.

i'll continue to post my progress as i work (sproadically) on this very fun side project.