This trimester in Studio 1, we as a class turned the original Up Ship Creek board game, into a hex based exploration game. Along with that, the class was divided up into teams to each create a new scenario as well as common items, hazards and condition cards. This post mortem will focus on both working as a class, and working in the smaller team.
The most significant problem with the project, was time management. Tasks as a team were done only days, if not the night before they were due. This didn't directly affect the quality of work, although most certainly it would have been better if the time was spread across the week. It did in a way make the team feel kind of disconnected. We only ever really done work on a Sunday or Tuesday night outside of class, clumping all that needed to be done in just one night. In the end we did get the required work done (most of the time), yet leaving such a tight time margin, did remove the ability to alter the project in a major way. For me, this isn't new. Time management is something that I have struggled with in many past assignments. I always just say "i'll just do it tomorrow". The work only really gets done though, when tomorrow is the day it's due. In previous post mortems, a paragraph similar to this one has been said, yet nothing really seems to be changing. One thing I have noticed though, is that when HacknPlan tasks are assigned and timed at the start of the week, the work will generally be done across the week. In the case for this project though, HacknPlan tasks were written out in the middle of the week, or when the tasks were being done.
So, how can this problem be fixed? Like I said above, in some previous projects where HacknPlan tasks were assigned at the start of the week, work was done properly. This is probably because if you have an empty HacknPlan milestone and only create tasks once they've been done, it looks as if there isn't any work to do, or that the work is flexible. On the other hand, if the tasks are there and set for the week, you can see the amount of work you need to do. The exact hours it will take, so you can chip away at it throughout the week. Having someone (most likely the project leader) organise all the tasks for the week and plot them out in the HacknPlan milestone, this will not only make things more organised, but it will set an objective. People will see what they've done and what they haven't done. Thinking in your head that you have to do ten hours of work on a Sunday night, compared to thinking that you need to do this and that Sunday night, is much more daunting.
Playtesting the game was both great and terrible. Since Up Ship Creek has so many systems in play and the fact that we were making a totally new way to play the game, playtesting it was hard. Not setting it up and getting people to play the game. Or even having them understand the rules. In my mind, what was hard was getting the playtesters to play the game from a perspective of an average player. Early on in playtests, my team would get the testers in and explain the rules to them verbally. Even at times, during explaining the rules, we would say something like; "you'd want to avoid that though", or "this is what you want to get". In a way, we were telling them how they should be playing the game, not how they could be playing the game. This would make their experience different from an average player who goes and buys the game from the shop. Even during play we would say stuff about saving items or good strategies for later on. We were playing the game from a developers perspective, when we should have been playing the game from the testers perspective. Later on, when a rule book was being produced, playtesting still had this effect in a way. As a team we kept on telling the testers to "refer to the rule book" when they asked a question about a system, yet still when playing the game casually, we slipped. It creates impressions in the testers mind, removing the aspect of "should I do this, or this?" a bit.
The obvious solution would be to not say anything. For when we didn't have the rule book, we needed to talk, so the rules could be explained. Even when we did have it, casual talk and strategising in-game, allowed these "developer perspectives" to seep in. Not talking at all or very minimal during play would not be ideal. The entire point of the game is to talk with each other and stratagise about what to do. A solution would be to "think as the tester". Going in and only really talking about what the tester knows so far. If they are confused, don't tell them what to do. Tell them to refer to the rule book. Not only does it simulate a real playing of the game, it puts your rule book to the test. If there isn't one though, then explain the rules as passive as possible, trying not to give away any possible strategies or indication of how bad/good the system is to the player. While playing, still talk to the testers as after all, it is a cooperative game - just play of their knowledge and don't play the game by yourself. By that I mean, allow the testers to make the decisions. If you are the one choosing where to go and acting as the "captain", then the entire point of the playtest is kind of ruined. Having the testers take lead in a way, and direct the flow of the game, puts tension on the systems. Will these things work? Will they integrate seamlessly with the rest of the game? Will they not be too harsh/too easy for the players? The only way to test these hypothesis', is by having testers with open minds, who are not persuaded by the developers. In some cases where we kept telling the testers to "read the rule book", it sunk in more and made them talk between each other on what to do. Compared to when we told them the rules, with some bias mixed in, they would just follow what we said, not strategising.
Working as a Class
Something that I was a bit concerned about at the start of the project, which turned out to be quite a surprise, was working as a class. By this I mean coming up with new ideas and iterating upon existing ones. Someone would come up with an idea, the class would talk about it, then we would write it down and get it ready for playtesting. Even outside of class, we had a Discord server, where the whole class could come together to collaborate, ask questions and even have a few meetings. Later on when we had a rule book to work on, sections were done usually by an individual person, then the class would go over them. I recon this behaviour came from the class not really having anyone be a control freak. Of course there were individuals at time who would take charge when things got slow or out of hand, but no one ever had total control of the project. This can be both a good and bad thing. In one case when our lecturer wasn't in class, there was a debate over hazard tokens vs hazard tiles. Since there was no "leader", a final decision was only decided after some time and vote of hands. If there was a leader in that case, they could make the final decision so that the class could get onto the next point at hand.
As mentioned above, the main reason I think the class worked well as a dynamic, was because there was no one in total control. Arguments were rare as generally once a suggestion was made, it was talked about, then agreed upon and set for playtesting. In practice, this may not be possible. There may be people who view their opinion as greater than others. To combat this, it's the class' responsibility to view everyone's opinion as equal. You need to allow different people to talk and listen to their suggestions and reasoning behind ideas. This not only creates an equal work space, but a civil one. Outside of class, Discord was a necessity for us. Setting up a server allows you to not only share ideas and images, but also have voice meetings. You can see who's online, allowing for members to gather the class for meetings and discussions at anytime. This needs to be done at the start of the project. Because it sets a standard means of communication outside of class. If it is set up half way through, people will view it as just something to the side. Yet if it's integrated into the class workflow from the beginning, people will be more inclined to use it. Just like with time management above. Setting a standard from the beginning for me and probably others, cements in place a pillar, holding up the project.
To conclude, the project overall went quite well. A part from time management issues and changing perspectives for playtesting, the final product was a solid "new" board game, with a fairly solid scenario from my team. Working as a class was better than expected as a lot of the time, working with more people is a challenging. Yet it seems in the end it worked out pretty good.