Game Design with Event Modeling
Matt Eland
Originally published at
killalldefects.com
on
ă»12 min read
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.
OpenID Connect + SPA + BACKEND API - Authentication in modern webapps
Patryk Jeziorowski -
WSL2 Issue: Rolling back from Build 19555 to resolve issue
Erik Guzman -
Tutorial: Instalando o VS Code no Linux (Ubuntu/Mint/distros derivadas do Debian) pelo terminal
ăăăšăȘ -














81
37


Trending on
The Dark Side of Microservices
Using a Raspberry Pi as Your Development Server
Introduction to the HTML Dialog Element
Getting Started with Expo Web
Learn how YOU can add CI/CD to your app
5 tips to make your Angular application more accessible