Event storming when working on game projects

In one of my articles, I briefly talked about what event storming is. But this tool is not so simple. Few people work with it when creating games, and even fewer people use it correctly and effectively. Well. Let's figure it out.

Event Storming is a great way to break down a product, understand how it works (or should work), and also convey this to all team members so that the picture in different heads is the same (which greatly simplifies development and helps avoid errors and misunderstandings).

This is what the result of event storming on the board in Miro looks like (picture taken from the Internet as an example):

In my practice, Event Storming has been successfully used in game design, which is what I will talk about in this article.

1. Guest list

First, you need to decide who to invite to your Event Storming meeting. During game development, the obligatory guests will most likely be:

• development team – programmers implementing backend and frontend, testers

• art team – artists, animators and illustrators (everyone who works on the game visuals)

• design team – game designer, product designer, level designer, etc.

• management and analytics team – product owners, analysts and other persons responsible for the distribution of tasks and numbers

• producers – people who will publish and promote the game

In most cases, it is enough to call 1-2 representatives from each functional team. But in order to avoid the “broken phone” effect and not waste time on unnecessary questions and answers, it is better that everyone who works on the game is present at the meeting (if the team is not too large, of course).

You will also need a presenter (aka facilitator) who will guide the process, suggest what to do and help the participants in every possible way in their work. The leader’s task is only to show the way, without expressing his opinion or entering into discussions. However, often in teams this role is taken on by the product or game designer. Then statements on the topic are not prohibited, especially if they fundamentally influence the fate of the future product.

A few more words about the participants: Of course, it’s good if there are a lot of them and from different areas (there is no point in conducting Event Storming only among the art team or only among programmers). But it is still not recommended to hold such meetings with more than 10 participants, since it will simply be difficult to keep everyone’s focus and not turn the storming into a farce.

2. Preparing the board

Most often, virtual boards (for example, Miro) are used for event storming meetings. But if you prefer live communication, you can use a regular board or lay out whatman paper on the table =) Most importantly, don’t forget to take a photo of the result of your work at the end of the meeting!

Regardless of what kind of board you use (real or virtual), you will need sticky notes in different colors. The color of the sticker indicates the type of element (or block) into which your product (in this case, a game) is laid out.

Main blocks of stickers:

• Events – all game events (opening a level, opening a map, turning on the light in the castle window)

• Player action – what the player does, what buttons he presses (clicked on play, scrolled down, clicked on the lock icon)

• Game reaction – experience/money/points are awarded, the enemy's HP has decreased

• Backend – what is transmitted and stored on the backend, as well as any notes associated with it

• Constraints/conditions – conditions or restrictions under which an event will not occur

There may also be blocks for comments and questions, actors and aggregators. The system is flexible and each team uses it, adapting it to their product. But for the game the list presented above is quite enough.

3. Progress of event storming

An event storming session has a certain sequence: from general to specific, from simpler and more obvious stickers to more complex and detailed ones.

1) We describe the events of the game

To begin with, it would be nice to simply outline what is happening in the game. We take yellow sticky notes and start writing down. You don't need a clear order yet. The goal is to generate as many events as possible that occur in your game. You can agree that one of the participants writes them down, and the rest simply call them out loud. It is also possible for each meeting participant to write their own stickers (even if they are repeated – then delete the unnecessary ones), this is how convenient it is. In my practice, there were both options and they worked approximately the same.

Feel free to write down all your options, even the dumbest ones. Who knows what might come in handy. Perhaps what seems stupid at first glance will actually turn out to be a brilliant idea.

Once the events are written down, look at them, put them in order (leaving space between them for stickers of a different color), and reformulate the text if necessary to make it clear to everyone. Separately, you can mark events that you doubt (for example, with a question mark).

2) Add player actions and game reactions

In between events, we add stickers of other colors: the player’s actions and the game’s reaction. In other words, we write what led to this event and how the game reacted to it.

Remember that at each stage of Event Storming you can rearrange, delete or add stickers of previously placed types at any time. You can also leave comments if necessary. It's normal that you can't keep the whole picture in your head. This is exactly what this meeting is for =)

3) We describe the conditions and restrictions

At this stage, it is important to write down all the conditions that must be met for the event NOT to occur. What the user or the game itself should not do.

4) Add backend stickers*

I marked this stage with an asterisk, because it is often clear what data needs to be transferred to the back, and what is implemented only at the front. However, I've worked with games where this issue was controversial, so we added this in as well. Also, on stickers of this type, your backenders can make any notes on their part. It's comfortable.

5) Putting everything together

The board is almost ready. Time for refinement and discussion! Now the facilitator’s task is to go through the board from beginning to end, focus the team’s attention on all the stickers and their types, arrange relationships, write down comments (if necessary), and resolve all controversial issues. And the team’s task is to carefully look at the board and bring it to such an extent that everyone agrees with what is depicted on it and that everyone is comfortable working with it.

4. Is that all? Yes, that's all

At first glance, it may seem that this is a very complex and not particularly necessary tool. But they say it is useful. Especially if the team is large and the product is voluminous. On the board you can sort everything into sections so that you can return to it later during development. It is convenient for different team members to use. This saves time because instead of asking a question, you can simply look at the board.

I hope this material was useful to you and you will successfully apply it in your work. Good luck!