Modeling game state using a Marble Diagram
There’s a little concept I’m playing around with, and I’m not sure if it’s going to work. The story behind it will take up a post of its own, but suffice it to say that it all started when I read Daniel Cazzulino’s recent blog post on finding key business value by leveraging domain events and reactive extensions, and I immediately thought to myself “this is crazy sweet” and immediately started wondering how well it would work if you could apply the concepts of using Reactive Extensions with XNA. The possibilities seemed compelling. A rough week later (the grisly details of which will also be covered shortly), I took a step back to do some more research and get the figurative ink off my nose and integrate my new findings into the concept’s architecture. One thing I’d found out is that it can be incredibly useful to create a Marble Diagram to represent and model different sequences of events, and their interactions and effects on one another. The material(PDF) I came across discussed the diagrams only in context of the Rx, but I thought it would be useful in modeling gameplay too: a game is a giant state machine (technically it would be a simulation of a state machine. I think.), and a hallmark of a state machine is that subjects raise events and observers listen for events, so there’s my connection!
The following marble diagram represents the entirety of a simple game I contrived as part of the proof-of-concept that I’ve been spiking out. The shaded red lines over part of the diagram represent the user dragging their finger (free drag) across the screen, then releasing (drag complete). The first column is grouped by concern and represents a particular thing that can happen in the game. The top horizontal column is a timeline both in seconds and in rendered frames. There are a couple of jumps in scale to avoid making it wider than a house, and those are noted by their floral pastel shades. The colored dots represent with their color a specific state for that event at that particular time in this particular scenario. Check out the key above the chart for more info on the specific colors, but a few moments of simple reasoning should be enough to form a picture of the game from both a technical and a gameplay perspective. It’s synergy in a totally Domain-Driven-Design fashion! Well, hopefully. It fails as a conveyance mechanism if someone can’t understand the game play just by looking at the diagram and no lengthy explanation, so feel free to chime in if – no, where - flaws exist in comprehension!
Essentially, this diagram allows me to see at a glance that, for example, a player ceases to earn points while the princess is being grabbed (dragged). The insight into the interactions between objects and the immediacy of the domain make for a rich picture that I think could add a whole lot of value when applied to the analysis of business process or system processes on a less granular level than this one depicts.
I have started creating an Excel template to help speed this diagramming process, if there's any interest in it let me know and I'll share it.