Tag: Prototyping

Remembering to play my own game

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?


Learning From Prototypes

Coming up with a good game idea is hard. Especially when you want to get a whole team of people from different disciplines excited about it. This semester I joined a 16 person team consisting of seven developers, three designers, four artists, and two sound designers. After months of developing countless prototypes and taking part in almost weekly brainstorming sessions I have experienced some very successful strategies and some very disruptive mistakes. I want to share some of the things that I have learned during this ongoing project.

When your goal is to find a golden idea, the first thing that you have to accept is that every idea is flawed, and you cannot get attached to your personal favorite. Getting into this mindset is essential to making sure you are working efficiently. If every idea is flawed then your first priority should be to find out what the flaws of each idea are so that you know the hurdles you are going to face in the future before spending countless hours of valuable time on an idea that may not be fun or even possible.

There isn’t a universal way to prototype an idea. Each one is going to require a different approach. What is important is that you find the easiest way to create the core experience of the idea as quickly as possible. This could take the form of a quick example made in a pre-made engine like Unity, a paper prototype, or even a simple visualization of an example segment of gameplay. It is very easy to want to create a more holistic experience from the get go but in the end your energy would have been better spend moving on to the next idea and discovering what its flaws and potential gems are. I liked the way Kevin Sheehan, a DigiPen alumni, put it: If you are working on a prototype for more than four hours, you have moved on to its development stage not pre-production. This is because you should not be prototyping what you know you can make. You should be trying to build a sample of what you are unsure will work, so you can learn early if you are going to have to work around an issue or simply move on to a different idea.

At some point you have to stop prototyping ideas and select one to move on to development. You might find that one of the prototypes instantly stands out as “The One” and the choice is simple. But if you are working with a group of people, it might be more difficult to choose an idea that everyone will be happy with. This is where all the work you did prototyping comes in very handy. Now that you know which ideas have the most challenges to overcome you can narrow the choices down to the most realistic candidates. From there you can discuss each ideas potential and choose the one you are most excited to work on. Every group dynamic is different so how your team goes about this decision may be unique, however, there are some mistakes that I have made which are best to avoid.

The biggest mistake to make when deciding between multiple different game concepts is to break the idea down into chunks. We tried to drill controversial ideas down to singular mechanics or themes in order to see if we could merge the ones we liked or incorporate them into a different idea. This turns out to be catastrophic. The problem is that individual mechanics are rarely appealing when out of context. Talking about an idea’s individual aspects without the bigger picture will make it unappealing even to the original advocate and can really degrade the creative flow of the team.

If it comes down to a vote, what we found to be successful has been to vote for your top few out of the total and eliminating the idea with the least votes, then repeating the process. The reason why this tends to work well is because people are voting for the ideas they want to work on. If your favorite idea was eliminated, you still have the chance to vote for your second favorite in the next round.

Once an idea is selected, you have nailed down what the core experience you are trying to deliver is. It may not end up looking exactly like what you initially intended for, but everything you do from now on can focus on delivering what was promising about that initial concept. This not the end of prototypes for the project. Instead of prototyping overall game concepts, the same strategy can now be used for experimenting with individual mechanics within your game.