Week 10 was our first full week working remotely as a team. (Classes were cancelled Monday and Tuesday of Week 9 to give everyone time to get things sorted.)
We started the week off with a bang. By Monday night we had the first iteration of our polished STEAMineer Adventure game for internal team playtesting. Yifan and Mia collaborated to complete the UI screens for the game and Max added the additional assets to the game. We changed the coins into crystals players collect. (The crystals serve as an energy source for Atlantis.)
The game was also modified to be playable on a keyboard. Playing the game on the keyboard not only allowed for more team playtesting (since we don’t all have the necessary Arduino Hardware), but it will also help us to participate in ETC Remote Playtest Day. We have been collaborating with the ETC Technical Support Team to host our game online to make playtesting more accessible. Simultaneously, Isabel and Marissa were collaborating on a post-game survey to send to playtesters who played the keyboard version.
To play the online version, go here: https://www.etc.cmu.edu/projects/steamineer/app/
This initial version of the game was the most polished our experience had been– especially because we would not be available to facilitate playtesting as we had in the past. However, there was still discussion amongst the team about how to make the game more compelling. We considered adding levels to the game or adding new enemies or challenges. There is also interest in strengthening the narrative portion of the game with a short animation. The idea for the helicopter interaction may have also stemmed from our inclination to make the gameplay more interesting. With the transition to remote work too, there was an inclination in the team to redirect our efforts and focus more of the project on the game. Digital work, like game programs and art assets is easier to share and collaborate on when working remotely, compared with trying to share physical hardware.
During a daily stand-up meeting that Dave attended, he encouraged us to find solutions to our gameplay problem that could be implemented without a lot of time-consuming work from the team. That way we could readily test their efficacy before investing a lot of time. It also helped us address the issue of whether or not we should refocus more of our effort on the digital game. During this meeting, Isabel and Marissa also shared an observation about the current game: the only way to lose was to not play. The penalty for getting hit by an octopus was to lose a crystal. There was no time limit, and there was a limited number of crystals to collect. The only motivation our game seemed to present was the opportunity to play a digital game with the controller. This served our original purpose, but would be harder to encourage replayability for the keyboard interaction. Realizing the game was not very competitive, and therefore, could be challenging to convince people to play with a keyboard or even play repeatedly without a keyboard, we changed the game again.
We looked at adding or adjusting the variables of time, life count, and crystal count. We debated having the win state be collecting the greatest number of crystals– either in a specified amount of time or before running out of a specific number of lives. We also considered making the win state whoever could collect a specific number of crystals (completing a specific task) the fastest. Mia raised the concern that the pressure of doing something the fastest could be disheartening to novice players, but a time limit could support exploration.
With that, our team decided to focus on crystal count as our win state. We liked that people could replay the game to try to get more crystals, and that people could compete with others to see who could get the most crystals. As a team, we even shared our highest crystal counts on slack. (Max is winning by the way, with 54 crystals. Don’t be discouraged if you don’t end up with that many, that was during a gameplay time of 3:00 minutes.) We playtested the game with a time limit of 3:00 minutes, 2:00 minutes, and 90 seconds. We were encouraged by our faculty to own the intention that we wanted the game to be replayable, so we picked a shorter time, 2:00 minutes. This also accommodated the ~30 seconds a couple teammates found that it took to get used to the gameplay. After sharing the latest version of the game with our faculty, we were encouraged not to change too much about the game– the game seemed to fulfill its purpose. It was competitive, replayable, looked good, and would allow players with Arduino controllers to test their controllers. An added benefit of the current game too, is that playing the game with the keyboard is just slightly annoying enough that there is room for playtesters making controllers to improve the interaction.
Another addition we made to our game, was one playtesters won’t see: in-game analytics. Mimi and Max have been working out what data to collect and how to store it so that we can add it to our build. While we are not entirely sure what data will be useful to collect, again, we were encouraged to go with a quick solution– that way we could test it within the team and record the gameplay to see if the data collected and our understanding of it reflect what actually happens. For now we are starting with simple metrics like number of crystals collected, number of attacks fired, number of enemy attacks, number of attacks by enemies, and battery recharging data.
As our first playtest subjects, Dave was also able to give us insight into what kind of information to provide and what kind of qualitative data we should look for. (Qualitative data from both physical playtests and keyboard game playtests.) As someone potentially facilitating the activity, Dave has repeatedly told us he is looking for thought-provoking questions to encourage his daughter.
As a team we have been compiling information for the activity into a curriculum format, but with our new direction, our “instruction guide” needs a new approach. It needs to be something that is accessible both digitally and physically as a printed copy– so pdf seems like a good approach. We also want it to be something that would be accessible to adults and kids, and older kids working with younger kids. We like the idea of a storybook approach, and something that is visually compelling to make interacting with the media better for our guests. Furthermore, it needs to include specific information about downloading the game, setting up the Arduino controller, and selecting the sensors for input. We also need resources in case the Arduino or sensors get disconnected. Another thing that needs to be taken into consideration is our strategy for player strategy. What do we want the players to strategize for and how do we support it? How can what we make support the players’ efforts to problem-solve and impact their experience? What kinds of questions do we ask players and what decisions do we set up players to make? These are just a few of the things we are trying to be mindful of, knowing that we will learn about more as we go and from our playtests.
Week 10 also saw Mia start the fabrication for the Arduino Core casing. Check back in during Week 11 to see the completed product! Week 11 also marks our first remote playtest of all the elements of our experience.