Game Design with Event Modeling

And now for something completely different: I’m going to take event modeling, a modern approach to systems design, and try to combine it with a game genre that lived its best life in the 1980’s. Specifically, I’ll be applying Event Modeling techniques to design an Interactive Fiction (IF) game about a dog terrorizing its home when its owners are away.

What is Event Modeling?

Event Modeling is a newer technique popularized by Adam Dymitruk. The goal is to provide an extremely simple view of a system under design that adheres to the Given / When / Then style syntax used by Cucumber and other behavior driven development (BDD) tools.

This simplicity makes it easy to understand, learn, and use. Its compatibility with Given / When / Then syntax makes it easy to test and identify requirements.

---

At its core, Event Modeling revolves around 3 types of entities: Events, Commands, and Views. I’ll explain each briefly here, but it’ll make sense later on in the article once we get into concrete examples from game design.

Events are things that have happened within the context of the system. In an online shopping system, an event might be “User Signed In” or “Item(s) Added to Cart”

Commands are user actions. The user is telling the system that they want it to take some form of action and expect a response. In a shopping system a command might be clicking a button to add an item to the user’s shopping cart.

Views are how the system presents information to the user about the current state of the system. In a shopping system this might be the “Confirm Purchase?” screen displaying the details of an order about to be placed.

We’ll see how this works for our example later on.

What is Interactive Fiction?

Interactive Fiction was popularized in the 70’s to early 90’s as a form of turn-based adventure game where the player was given a text description of an area and situation and could type in what they’d like to do. The system would then interpret their input and respond accordingly.

Here’s an example transcript from a made up game:

Game: You are in a small dimly lit room filled with empty pizza boxes and soft drink cans. A laptop sits open on a desk in front of you, displaying some code and an error message.

Player: Sit at desk

Game: You are now sitting at the desk in front of the laptop

Player: Read the error message

Game: The message says "Unable to allocate value to non-zero index"

Player: Debug error

Game: I don't know what a debug is.

Player: Fix error

Game: You don't see an error here.

Needless to say, early 80’s text parsers frustrated a lot of players, but the promise of these games was interesting and some of them had extremely involving and immersive stories that made up for the lack of graphics.

Introducing “Doggo Quest”

In this article, we’ll be designing the flow of a small text-based game called “Doggo Quest”. This game is set in a suburban home with the player controlling a small dog in its cage. You get out of the cage and then chaos ensues as the player causes disaster after disaster until a fixed timer expires and the owners arrive back home.

It’s a simple concept, fun, and easy enough to explain and jump in at a moment’s notice, which makes it perfect to use as the backdrop of a technical talk (why I picked the topic to begin with).

For context, the game world looks like this:

This is a standard interactive fiction map, generated in Trizbort, illustrating a series of rooms (squares) with some notable items highlighted in each room.

You could also think of this map as a state machine with the player’s current room as being a state:

Some design considerations:

• You can get out of your crate by pushing it with your nose or pawing at it
• In order to be able to try to open the door, the player has to first look at it
• If the player hasn’t looked at the door within 5 turns, the game will prompt them that the door looks different or unusual
• The game ends 30 turns after you open the crate door
• Each room has something interesting to interact with
• Some rooms have windows. What you see out the window depends on which turn it is since you opened your crate
• There is a score system and you get points for making a mess or barking at things outside

Notable verbs the system will support (including synonyms):

• Go / Walk to / Run to
• Bark at
• Think about
• Smell / Sniff
• Chew / Lick / Eat
• Paw / Tap / Bop / Hit / Kick / Punch / Push
• Grab / Pull / Pick up / Get
• Jump on

These verbs are different than many other adventure games due to the player being a dog.

Game Design with Event Modeling

Now that we’ve roughly described the game and its world, I’m going to try to apply event modeling to describe the game logic.

For this, we’ll follow the multi-step approach recommended by the folks behind Event Modeling.

_ Disclaimer: My initial attempt does not go well and I will revisit it this later on in the article. For now, pay attention to the steps and concepts and less on what I’m trying to do specifically with this story because it does not work out. If you’d like to skip ahead to the final product, skip ahead to the “Redoing the Experiment” section below._

1. Identify Events

In this step, we identify all of the events that can happen in the game world. While we could (and probably should) constrain this to things such as “The player typed in words that the system understood”, it’s a lot more fun to say things like “Trash can knocked over”.

So, given my game world, here are the significant actions that I envision occurring:

• Got out of crate (marks the beginning of the timed part of the game)
• Knocked over trash can
• Killed a Fly
• Ate a Fly
• Ripped up Papers
• Ate crumbs
• Knocked over a drink
• Tore the curtain
• Peed on the carpet
• Destroyed a shoe
• Rolled in the trash
• Barked at a squirrel
• Barked at a stroller
• Barked at a dog
• Garage door opened (when owners about to return)
• Owners returned (marks the end of the game)

2. Plotting Events over Time

Next we’ll create a card for each event we identified and arrange it in a horizontal line with oldest events on the left and newest events on the right.

If you’re using colors for your cards, event modeling illustrations typically use orange, but you could also simply write “Event” or “E” on each card to illustrate the type.

In Doggo’s quest, the earliest event is getting out of the crate and the last event is the owners returning home. A few events must occur after their predecessors, but otherwise, events are fairly independent and I can arbitrarily order them based on a fictitious playthrough.

Here is the ordering of events I identified:

Ordinarily you’d only have a single row of cards but I split these into two rows for the purposes of this article.

3. Wireframing

For visual based systems, you would then draw user interfaces that correspond to the individual events. For Doggo Quest, we really only have one view:

We can then include this wireframe at the top of the diagram and illustrate where commands originate and where events impact the displayed view. Since everything I’ve identified comes out of typing into the box at the bottom and updates the text box at the top, I do not choose to represent these things in the UI with arrows everywhere for cleanliness.

4. Identifying Commands

Next, for each event we’ve identified, we’ll see if we can identify a command that can cause it.

Since we’re looking at a text based game, this is actually extremely easy – we just need a simplified version of what the player might type. Examples include Push door or Eat the fly.

We’ll represent these commands as blue on our diagram and add arrows from each command to the event it causes. In some cases we’ll also add arrows from events to commands indicating those events are pre-requisites.

Here is a subsection of the game design diagram with commands and events present.

Note that unlike most interactive fiction games, this one isn’t really intended to be a puzzle as much as a place to play and have fun with the mechanics. Because of that, there aren’t many dependencies between commands, though there are a few events that chain together.

5. Identifying Views

In a traditional systems modeling experiment, we’d identify concrete views associated with each state. Since this is interactive fiction, our only meaningful view is the text on the screen. Furthermore, we can assume that every action outputs text of some sort, making modeling this largely redundant.

Still, to illustrate the points of this exercise, I’ll model score increases as views by adding green rectangles and arrows leading from events to those views.

6. Introduce Boundaries

Next we need to apply Conway’s Law and separate out related events into their own “swimlanes”.

In a larger system we’d partition off related items into their own subsystems or even individual applications / services. Since we’re working on a simple game, we’ll pick a more natural boundary: regions of the game world.

Event Modeling advocates for moving only the events into swimlanes, however the dependencies involved with events in this system make that somewhat unappealing as pictured below:

Instead, we’ll deviate a bit from event modeling norms by including commands in the swimlanes as well. This makes sense since commands are location-specific.

The result of that is cleaner:

Note: These results would have been clearer / simpler if I had tried to represent events at an engine level instead of at a game design / story level. Partitions here would be things like the parser, story data, and user interface. This also would have adhered to the purpose of partitioning things by making it easier to hand off one module of code to a different team.

7. Elaborate Scenarios

Next we step back and look at the results of our modeling experiment and see if we can identify any cases not covered by the model, and if so, add them.

Looking at the results of the diagram and the ways I deviated for neatness, I am dissatisfied with the result. I can also clearly identify some cases that are not covered:

• Restarting the game
• Typing in something the game doesn’t recognize
• Looking at objects

As a result, instead of choosing to add in missed cases, I choose to redo the experiment focusing instead on the engine.

In talking with other Event Modelers, it’s not unusual to take some time to get used to applying event modeling and as such, my decision to redo my exercise is a result of this learning process.

Redoing the Experiment

So, redoing the experiment, but focusing instead on game engine events, my set of events looks like this (in chronological order):

• Game Started
• Command Entered
• Sentence Tokenized (Broken down into individual words)
• Unknown Word Encountered (e.g. FooBarBaz)
• Unsupported Verb Encountered (e.g. Yodel)
• Object Not Detected (e.g. Eat Stroller when no stroller present)
• Sentence Validated
• Command Executed
• Timer Started (When the player gets out of the cage)
• Timer Incremented
• Game Ended

This time around I’m going to represent more actors in the system as well, so I include the user interface wireframe as well as major subsystems to interpret and execute the player’s intent:

Adding in Commands and Views

Next I’ll add in relevant commands and outputted views. Keep in mind here that commands don’t necessarily have to be user originated, so individual subsystems can execute commands to trigger events.

Here’s my new model with commands, views, and events:

Note that I also identified a new wireframe as part of this exercise. The game over user interface is different than the normal user interface because the user cannot enter a command.

Ultimately, it’s fairly clear that representing the system in terms of system events instead of story events is the way to go, and this is already.

---

While I could follow the recommendations and partition into swimlanes to follow Conway’s law, several things are already clear to me:

• I will be the only person working on the project, so I’d only need 1 swimlane
• If I did want to scale up, I’d split the project along vertical lines with one person getting the UI, one person getting the story content, another person getting the lexer / parser, and another person getting the story engine.

Since I expect that splitting the diagram into swimlanes is going to muddy the waters more than help, I’m declining to follow this step the second time around.

---

Finally, reviewing the model reveals some missing commands around the end of the game. Revising that section reveals the following:

Evaluating the Experiment

After some final cleanup, the finished event modeling diagram looks like this:

Let’s take a step back and evaluate how this exercise worked.

True, got things wrong on which events to model the first time around, but the end result is a clear and readable sequential event model of the flow of the game. This final result can be used when considering the architecture and structure of the application I’ll be building.

Event Modeling as a Test Blueprint

Not only can Event Modeling help us capture requirements and communicate them effectively to new team members, but it can give us a good outline of what to test.

Let’s take a look at a sample command from inside the event model:

Here the Tokenize / Lex command is triggered by the Command Entered event and will either trigger a Sentence Tokenized event or an Unknown Word Detected that produces an I don’t know what X is view.

We can write this as a pair of testing criteria:

Given a command with an unknown word inside of it

When I feed the command into the tokenizer / lexer

Then I should get an Unknown Word Detected event

With an I don’t know what X is response

and:

Given a command with only known words inside of it

When I feed the command into the tokenizer / lexer

Then I should get a Sentence Tokenized event

Taking a step back, we can look at our entire event model and generate a good starting list of core tests for the overall application without a significant amount of effort at all!

Event Modeling and Doggo Quest

So, using Event Modeling, I’ve now got a good plan of attack for structuring and testing an application. That in itself is a win.

However, I set out to model the events inside of the story and I had to abort that attempt with event modeling. This suggests to me that event modeling is more suited towards system modeling than modeling the internal state of an application. That’s okay, not all tools should solve all types of problems.

It turns out, however, that there’s a fairly standard way of representing story flows in interactive fiction: Puzzle Dependency Diagrams.

Since the purpose of this article is not to discuss that technique, I’ll spare you an explanation of it, but the makers of Day of the Tentacle provided an excellent primer I’d encourage you to check out if you’re curious.

Doggo Quest’s puzzle dependency diagram is included below for those curious:

What’s Next?

Well, there we go. Now we have both the engine and the story events modeled.

This month I’ll be building this game engine and writing the story in preparation for several talks I plan to give this year on building the application.

This will be the last I explore event modeling for the game, but it met its purpose.

If you want to learn more about event modeling and how it can help you in your application development, I strongly recommend you check out the Event Modeling web site. It has a comprehensive article and information on learning more via Slack, Twitter, and various events.

Thanks for reading and stay tuned!

The post Game Design with Event Modeling appeared first on Kill All Defects.