Dev Log 3: Beat Mapping
Introduction
It's time again for another Devlog of stuff I've been working on and what I've learned. It's been a while since the last one; 3 weeks in fact. Let's jump right into what I'm discussing this time. Beat Mapping. This is something of a challenging topic to discuss as beat maps are semi-enigmatic in nature depending on what you're working on. For a breakdown of levels/sequences in a game, they're fairly straight forward. However, my beat mapping experience lately has been for my team Board Game Baboons. As you might guess from the name, we're making a board game.
Issues
There's a few problems to tackle when it comes to making a board game beat map, and they largely revolve around the sequences of play for players. So what can we consider to be the sequences of play?
The first would be the turn order:
- How does your turn start?
- What actions do you take in your turn?
- What are the results of your actions?
- How does your turn end?
Second, we want to consider the effects of objects in gameplay. For our game in particular, these were the relevant elements:
- Positive Cards - Cards that would give some sort of benefit through increased resources or movement forward.
- Negative Cards - Cards that would impose some sort of penalty that decreases resources or moves your piece backwards.
- Conflict Cards - Cards that would allow a player to target another, usually the person in the lead with effects similar to Negative Cards.
Third, we will consider the actual game space. The board consists of 40 tiles. It's a race to the end. So, the active of moving is a sequence of play:
- Rolling the die to move forward
- Landing on a tile
- Revealing the tile's effects
- Resolving the tile's effects
And finally, the victory condition:
- Arriving at the end first
What to do with all of this?
Well, our first beat map was an okay start, but it was just a statement of places on the board, and the board would do the same thing. It was literally a table that divided the spaces into each side of the board, then listed the spaces off in order. This beat map wasn't a tool for us to use as designers, which is what it should be. We were still trying to think of this board game in sequences of 'levels/areas' instead of their actual components.
Our second attempt took into account all of the information spoken about in the issues section. Being able to see each of these elements in play and bouncing off of each other actually helped us with the design. We were able to point out the different resources the player has, the value of said resources, and even display the turn sequence structure in an interactive way. We used a site called machinations.io that helped us map the elements of play. These weren't beats yet, they were just the mechanics in action. You can see the first iteration using machinations HERE. It's a fun little tool to play through a single round by yourself and can be used to track or maintain elements, even balance the economy of resources, but it's not what we're looking for to help structure the board as a whole.
Analyze and Iterate
As of writing this, we are in the process of making a new beat map that incorporates all of the elements of play into a digestible interactive diagram. The goal is to use it to keep tabs on what can happen and how likely it is through different rounds of gameplay. We want to analyze the possible tiles to land on from any starting position, the effects that tile will impose, and how player choices can stop, improve, or reduce the effects in that way. On top of this, there's also the element of Conflict Cards and how any player can affect you no matter what part of the board you're on. There are many variables that come into play and need to be considered for a fully fleshed out beat map that will give us a tool to analyze each element of gameplay.
Conclusion
We've been through a fun sprint to find the best way to break down the beats of our board game and it really does feel like we're approaching a truly effective outcome. I'm going to put in the time to write a devlog about this next week to further examine our process, any more iterations that were required, more details about the game, what's changed since now, and more. It has been a fun experience so far and it feels good to actually use my skills as a designer. We know what we want in the beat diagram now, we just need to make it concise. That's the name of the game when it comes to designs.
Game Practice Dev Logs
A recap and debriefing on game design lessons I've learned in this week.
Status | Prototype |
Category | Other |
Author | MisterSpectre |
Tags | design-practice, development-log, dev-log, game-practice, info, information, journal, solo |
More posts
- Dev Log 11: Post-ProductionApr 04, 2022
- Dev Log 10: Planning and ImplementationMar 21, 2022
- Dev Log 9: Playtesting and Production IIMar 11, 2022
- Dev Log 8: Playtesting and ProductionFeb 15, 2022
- Dev Log 7: Pre-Production PrinciplesJan 30, 2022
- Dev Log 6: Learning Reflection - How will this prepare me for next semester?Nov 26, 2021
- Dev Log 5: Scheduling My WorkNov 19, 2021
- Dev Log 4: User Centered DesignNov 13, 2021
- Dev Log 2: Project ProposalSep 30, 2021
Leave a comment
Log in with itch.io to leave a comment.