Its time to wrap up Sea Of Mutiny:
What Went Right:
MDA – Mechanics Dynamics Aesthetics
The way that the rules of Sea Of Mutiny created very interesting game play and player experiences.
As the book ‘The Kobold Guide To Board Game Design’ says in its early pages, games/board games don’t need to have overly complicated rules or systems in place to create interesting dynamics. Sea Of Mutiny’s simple rules and how they interact together are what caused the desired dynamic and aesthetics. The dynamic being that the players have to deal with anonymity and causing conflict based on choices of whom to benefit or impair. The major aesthetic was to create conflict between players. Leaving them feeling joyful for causing chaos to any or specific players, saddened when they know hurtful things are coming their way or determined to win or just cause more conflict between players.
Cause: Focusing on not creating overly complicated mechanics but assuring they interact in ways that are always aiming towards a player experience.
Recommendation: Keep the desired player experience in mind when designing systems.
Working With Collaborators
Working with collaborators went swimmingly well.
This was the first time that I had been working on any form of game that required collaborators to reach a result that I alone could not achieve. The two graphic designers that we were paired with catered to our every request. To be fair, our requests weren’t anything that couldn’t be achieved. There was a constant communication between the Sea Of Mutiny team and the Graphic designers. Conversations took place over Facebook messenger almost daily. With updates on what work had been done and the new thoughts and feelings towards the new work. Almost every time the work presented was an accurate depiction of what we wanted the cards to look like, and even the board in its work in progress phase. The only problems that we ever had with the cards or board were minor details – such as image positioning & size, text size, colour and minor layout changes. The end of discussions often resulted in a task list for changes to be made to the cards and board. Those task’s would be completed by the graphic designers and start the loop of – present progress – thoughts – discuss – make decision – iterate – present progress.
Working with the animators had the same conclusion. Set them a ‘desired’ finished product – perform weekly checkups – thoughts – discuss – make decisions – iterate – present progress. Both animators made the deadline well before we stopped working Sea Of Mutiny.
Cause: Constant communication through an online media platform and weekly face to face meetings. Clear Deadlines in the schedule that had been shared with collaborators. Collaborators being willing and wanting to work on Sea Of Mutiny and achieve the desired result. The collaborators skill set were able to meet the needs of the visual aesthetic of Sea Of Mutiny.
Recommendation: Continue to use a communication medium that works for everyone. Even if this means having multiple different communication platforms for individual groups or people. Continue to appreciate the collaborators work and let them know that what they do is valuable. Set multiple specific times each week to reach out to everyone working on the project for progress updates. Continue to not be afraid to voice concerns or ideas. Everyone has an opinion, and not that any opinion is more valid that others but people may take a stance or form an opinion for a reason. Listen to every suggestion, reason and look at all the possibilities from every angle.
Team Communication was constant.
Having technology at our fingertips that allowed us to communicate with ease. We wanted to make Sea Of Mutiny the best it could be, which pushed us to wanting to talk on a frequent basis and collaborate as a team. We also always set particular times that worked within everyone’s schedules for us to talk as a group outside of Uni. This wasn’t documented in a professional form, but more of a side note and a metal note. From start to finish – each discussion was to always progress or make changes based on feedback or play testing results. Like in the early stages of creating a board game, brainstorming exactly what the game will be and all of the components that combine to make it what we wanted. Or in the later stages of the project that starts to refine the nitty-gritty of mechanics or visual aesthetics. The results of the conversations were tasks that needed to be implemented into our board game. Whether it be to now go and refresh the collaborators on the new changes, fix up some of the mechanics and implement them and document them, etc. When we weren’t together as a group we would use Discord or Facebook messenger. Discord worked well because it was a completely separate application that had voice chat and typing chat without the added distraction of being a click away from watching a funny cat video like Facebook. Facebook also worked well because it’s such a common platform.
Cause: Technology has allowed each of us to leave messages and communicate on multiple platforms (with GREAT ease) for each other to see. Thank you technology. The motivation behind wanting to come together and communicate so often was through team collaboration of creating a game that we were all particularly interested in and wanted to see the best possible result.
Recommendation: Continue to take advantage of the technology available to us that easily enables us to communicate on a want to / need to / instantaneous basis. Set scheduled times that are a must attend sessions (that works for everyone). Continue to make the teams’ members that we work in feel that their opinions and contributions matter that should boost self-esteem and raise team morale levels.
What Went Wrong:
Wrong Card Printing
For two play test sessions – Having accidentally printed 15 of the yellow cards onto blue cards making a total of 30 yellow cards, 15 red and 0 blue. The cards were still blue, but the actions were yellow.
Cause: So this is a tricky one. But to be REALLY blunt – We didn’t take action. I remember this particular situation, now more so than those particular days because I’ve had many days to reflect upon this. It was a Monday morning and it was the one of the first play testing sessions for the second round of play testing. Before this particular day it had been discussed within the SOM (Sea Of Mutiny) team that a particular team member would be in charge of getting the cards ready for this round. They went to the effort to go out and buy some proper card paper in the colours that we needed for our board game. They printed off all of the actions onto cards and cut them out etc. But on this particular day – whether they realized before we arrived together or afterwards, they spoke up when we were setting up the board. “I think I accidentally printed some of the cards onto the wrong colour”. All three of us heard it – but our brains almost didn’t comprehend it? It was just kind of like an ‘eh’ moment. Even throughout the next few hours of play testing and then the next day after, it didn’t specifically click in our brains ‘THIS IS WRONG’ and this will drastically change the game.
Recommendation: I can’t just blatantly say ‘Just do better’, but what I will suggest is that when a problem occurs – no matter the size, pay it attention and resolve it. Because in this instance, it seemed that the colour of the card was overwriting what our brains were comprehending. Colour over Text. It would have taken about 3 sheets of A4 paper, and a pen to fix this mistake and not lose two sessions worth of play testing.
This was the first board game I’d ever made and it was a lot different that creating a video game. Instead of having a computer tell me there’s something wrong it was completely human operated.
Sticking To My Guns
Ultimately this boils down to not trying out many different options.
I’m at university in a safe learning environment where making something that isn’t cool, isn’t a bad thing, because there no major repercussions to it. Because this was a physical board game, if a change needed to be made there wasn’t any major loopholes to jump unlike digital games. In order to make the change, it’s as simple as doing it, not rewriting or re-arranging a system of code. The amount of iterations that could have possibly been made in such a short amount of time could have been taken advantage of, but it wasn’t. There were multiple occasions when suggestions were made to explore the options of original board game we were designing. Many were great suggestions, and many – in my opinion, weren’t so great. Instead of making a 2v1 anonymity based card playing race game we could have explored other areas like Guess Who or Cluedo.
Not that they’re bad games and they definitely have interesting elements, but they weren’t games I was trying to take elements from or replicate. But in a safe risk free environment what’s the worst that could have happened? We implemented some changes that we didn’t originally intend on and they have a good or bad result? Something we could take away from trying something different?
Cause: I was holding on too tightly to an idea and was afraid to let it go or let it change to a degree that was out of my comfort zone.
Recommendation: While in a safe environment don’t be so afraid to take a risk or make a change.
Not keeping a change log of when thing’s were changed and why.
So when it comes to remembering when certain changes were made and why, especially when coming to write a blog about it, it was extremely difficult to recall the entire change process that SOM went through. In this particular instance there was no drastic repercussion to knowing when changes were made, but in order to find out, I had to sift through a lot of older versions of our documentation. This was a pain in the
Cause: I didn’t think remembering changes would have been important for a board game.
Recommendation: Keep a documented changed log with dates – what was changed – and why.
I can almost guarantee that this will be helpful in the future for something game creating related. Whether its knowing what was changed in a certain part of creating a game that caused something to go wrong and completely break the system. Or eventually when I work on a team bigger than 3 people and on a game that takes longer than 5 weeks to prototype, it would be important to document when the game had undergone certain changes.
Prevention Is Better Than Cure
It didn’t end catastrophically in this case but this is for future lessons. Within the SOM team it was a ‘play it by ear’ type of scenario.
The game went from:
- Receive Brief
- Generate Game Ideas
- Pitch Idea
- Iterate Idea
- Pitch Idea
- Iterate Idea
- Start To Make The Thing
- Play <——|
- Iterate >—-|
And somewhere in between playing and iterating, give some instructions and deadlines to collaborators on what we want things to look like.
Recommendation: Create a task breakdown list for the team to contribute to that will create a guided plan rather than just a play it by ear scenario.
Majority of the conversations throughout the creation of SOM was done over Facebook messenger, especially with the graphic design collaborators and their progress updates. This worked in this instance, but sometimes we were all getting distracted because of the ease of access to entertainment material rather than sticking strictly to work related material. Some of the progress updates and the communication surrounding the updates were lost in the flow of non work related discussion.
Recommendation: Find a platform that is accessible and preferable to everyone that isn’t Facebook or doesn’t have impending distractions. A platform that will also be specifically work related talk only.
Now if you’ll excuse me, my rum bottle seems to be empty.
Until next time –