Dev Log 10: Planning and Implementation
Introduction
This is a continuation of last week's dev log which you can find HERE. I mainly spoke about the great strides we've made over the course of the previous half-a-month in unearthing issues in our design and setting up the process in which we'll combat these issues. I'll be exploring our progress in this dev log and detail the fast decision making process that my team and I went through. Our decisions so far seem very promising, but our true metric of success will come in the following week with the newest playtest.
Rules and Retention
One of our main issues from the last few tests was the fact that our rulebook took too long to read and was not enjoyable. Players appeared to be lacking excitement from reading through the rules. This appeared to dampen the overall experience out of the gate. It's one thing to make a set of rules comprehensive, but to make it concise and entertaining is another thing entirely. We took some time to research other rulebooks to see what we could draw up as comparisons for where ours had failed. We found that players would often read until they had the steps of "How-To-Play" and then ignore all other content in the rulebooks. This observation came from two different methods of research: watching YouTube videos of people setting up board games for the first time, and having our testers speak out their thoughts during their playtest.
In order to combat the issue, my team and I decided to reorder and reword the crucial segments and leave in supplementary information in later sections. This cut down on the fluff present in the existing rules but also provided necessary details upfront with diagrams. Since players were keen on getting the rules understood first, they'd have to go through the informative diagrams and then read the rules. Anything they would be unsure about from that point on would be in the later sections and easy to jump straight to, thanks to them already having a clean understanding of the major details.
Attack of the Attack Tile
In the first 6 spaces of the board, players would have a 1 in 3 chance to land on a attack tile. Naturally, more than half of the players would hit an attack tile in the first turn. This showed us that we can't solely account for chance in our design and we needed to take some lessons from other multilateral competitive games. Our board game is structured as a race (first to the end wins), so we took a look at other games that functioned similarly to see how they managed to get over the initial hump to keep the ball rolling. We examined the Mario Kart series as a game with similar game loop. Their style of progression on a given race usually has no obstacles for the first few beats. Players can start off strong and start driving down the track before they have to worry about dealing with obstacles; they focus more on gathering items to help get them ahead quicker. We can immediately compare the items to benefactor tiles, and the obstacles to attack tiles.
Our solution was to remove the attack tiles in the first stretch of the journey, giving players a chance to get off the ground and engage with each other easier. While hitting the attack tiles didn't prevent players from making it to the end, it did reduce the amount of fun they were experiencing and made the starting moments of the game a slog to get through. With that in mind, the freedom to move forward and not be hampered (potentially multiple times by the same obstacle) should speed up the game and improve fun.
Whose turn is it anyway?
Players had a tough time figuring out how to get their turn order worked out. This seemed to be mostly due to the wording of the rule in the book. But even before they read the rules, they chose to pick their CEO card ahead of their turn and essentially broke the cycle. While improving the state of the rules should help with understanding them, it won't help with eager players who just want to grab a card and start playing. Little research was done in this direction, as the answer was right there in front of us. We could already see that players enjoyed the CEO cards for reasons beyond their statistics, so letting them pick their cards right away shouldn't be an issue. But the turn order still needs to be laid out and explained.
The proposed solution for this one is to just state that the player that chose their card last goes first. Have anyone unsure roll a 6-sided die and take the highest to resolve any placement confusion. It's simple and can be stated in 2 short sentences. This assist with rule comprehension but also fast-tracks players into completing setup for the game. This helps maintain their initial excitement of choosing their card, improving upon the initial fun of the game.
It's a sabotage
Players interacting with one another has lead to the highest instances of fun across all playtests. All interactions between players stem from the use of sabotage cards. A consistent issue we've had through playtesting was players getting a sabotage card and then sitting on it until the last stretch of the game. We would have instances where players would end the game with one or two cards still in their hand and not being able to stop the person in the lead from winning with them. Just to briefly comment on the strategy aspect of the game, this wouldn't be the case if anyone used them earlier before their security tier was high enough to hold off the effects of the cards. Thus, we've identified the big picture issue. There's very little player engagement with one another in the early stretch of the game because of two factors: (1) The player doesn't think they need to use them earlier, and (2) there's not enough sabotage cards in the early game to make use of.
In order to offer players a reason to want to use it earlier, we've decided to offer a reward for using a sabotage card. Right now we're in between two options and further playtesting will decide which is the better solution. The first option is to have the amount of resources deducted from a target be transferred to the person who played the sabotage card. This one may turn into a balancing nightmare, as far less resources are going to be lost of the course of play. Second would be to give the player a single Money token for each sabotage card they play. A sub-goal of the first option is to give players more reasons to target other players, not just the one in first. A player can be in the lead, but they might have no resources that the sabotaging player would want. We're testing this one first because of how promising it sounds in improving player interaction, increasing overall fun as a result.
Conclusion
With most of our changes under way, we're looking at a reformed design that may turn out to be a very fun experience. So far with just testing systems between the team and I, we've had a few controlled instances of fun; we need more public playtests to gauge unfamiliar players' reactions. We're in a very good place right now for our game and these improvements should get us closer to our goal.
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 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 3: Beat MappingOct 22, 2021
- Dev Log 2: Project ProposalSep 30, 2021
Leave a comment
Log in with itch.io to leave a comment.