As I work with my team to wrap up and ship Among the Clouds, I want to share something I learned over these last few months.
Summary: I made the mistake of not playing my own game once the development cycle shifted from prototyping to full development. I learned the importance of finding and maintaining the fun of my game at all stages of development. The benefits include having a more accurate picture of where the game needs to go next, receiving better playtest data since you are not getting bogged down with surface level feedback, and allowing for more meaningful polish when reaching the end of development.
There is a big difference between testing your game while you are working on implementation and actually sitting down to play your own game with the goal of having fun. One of the many things I have learned this semester is to ensure that the fun I found during the pre-production stage is not forgotten over the course of development. This is what happened this last year when, after deciding on the vision of our game, my team and I stopped playing our own game until it a few weeks ago when it was nearly complete.
During pre-production, when working on finding the original vision for the game, one of the things I was in charge of was to have every member of the team play the game for a few minutes a week and provide feedback as to if they liked the direction the game was going and what they would like to see in the future. However, this stopped being a priority once we transitioned over from the prototyping stage to the implementation stage. The difference was in my mentality. My priority from that point on was to get the prototype from Unity transferred over to our new custom engine as quickly as possible (before deadlines). It was not until recent weeks where I noticed that I had not actually played my own game in months.
What triggered this realization was that we were having trouble getting good feedback from playtesting because the game was basically unplayable. I attributed this to all the game’s missing features and it being incomplete. I was wrong. The problem was that I was building the mechanics we knew had potential from our prototype and immediately moving on to implementing the next part of the game. The missing step there was not taking a day to play with that feature and make sure the usability was out of the way so we could test how fun it was.
What surprised me the most once I started playing my own game was how many of the issues blocking the player from having fun were simple fixes that took no more than 10 minutes a piece. So many of the things stopping the robot player, who’s goal is to blend in to the crowd, from hiding were little bugs or tweeks such as the movement speed and misplaced AI waypoints. Those quick little changes were what had been holding back the playtesting data to the surface level feedback rather than the more crucial feedback about what was actually fun or not fun in the game. It is the difference between having to explain away the state of the game and search through a lot of bug reports in my playtesting notes and being able to actually put our game in front of players and see how people interact with the game.
What I found most helpful when playing the game was to constantly ask myself, what is stopping me from beating my fellow designers and developers. If we can get the game to the point where I can legitimately blend in and trick the other devs, then we can rest assured our playtesters have a chance at doing so as well.
One of my biggest takeaway from this year is that I should be in this mentality during every step of the process. It is so important to have the game I am working on remain playable at all stages of development. The best way to ensure my players have a chance at having fun is to play my own game, because if I cannot enjoy my own game, how can I expect my players to?
Eduardo Gorinstein 