With BAMF! 1.7.1 finally out the door, Double Stallion Games is taking its very first break in development to begin focusing on our next big thing. The big problem is that we don't have a clear idea of what that is yet! The team has discussed many designs internally, and last week was our first chance to test those ideas out with prototypes.

This is the first time I tackle the prototyping process as a full-time game dev. It's definitely a different experience. When we started Big Action Mega Fight, I was on vacation after the development of Party of Sin, ready to move on from that project. We hadn't found an office yet and the team wasn't full time, so it was difficult to schedule meetings. We were exchanging emails about game concepts and having design meetings in our homes. When we got together for a game jam, it was a short and focused two-day affair. In the office, there seems to be more pressure to "be productive" and it changes the process quite a bit. We now have a live game that is also demanding attention, and we spend more time together.

You'll find a lot of advice online about prototyping in games. How failing early and failing often is important, and how everyone should be prototyping before entering production. However, despite everyone discussing it, there is no specific methodology for prototyping. Do you just start building the first thing that comes to mind? Do you work as individuals or as a team? How do you gather feedback, and when do you decide to kill an idea which isn't working out? These are questions that few people answer, but they definitely came up last week.

Prototyping Individually

We started out the week with an individual approach. Everyone figured that working individually would be the best way to explore different ideas and come up with a diverse set of prototypes to play. There were no constraints, and everyone worked off their hunches. We each grabbed different technologies, came up with an idea of what we wanted to make, then went at it.

After a day of prototyping, we had some basic games done. One exploring a slingshot mechanic, another inspired by the shock rifle in Unreal Tournament, and finally a deep-space platformer. A few of these ideas were killed, and some developed a little more with feedback from the other developers. The notable trend in these games though, was that none of them followed any of the designs we had discussed as a team beforehand, and every one of them was being built as a local-multiplayer game, à la TowerFall. We continued down this path for two more days.

Here is a a screenshot of the slingshot game, one of our individual prototypes.

We found ourselves getting discouraged though. The quality of the ideas we were having was deteriorating, and my motivation was dropping fast. The games we were pumping out were okay, but many of them didn't explore the ideas we found interesting in the designs we already had. We were learning things, but without very much context, and the exercise felt unfocused. The goal was to find fun quickly, but the extra thinking required to make it to a full product wasn't happening.

The trend of local-multiplayer is kind of telling here. Local-multiplayer is a staple of game-jam games and small projects where you want to avoid working on AI and make something hastily. Local-multiplayer games are also pretty fun by default, without much work from the designers. We were avoiding the truly difficult parts of our designs instead of testing them. You should prototype the least obvious part of your design, because that's where the unknowns are.

I explained my concern to the team, and after a drawn out discussion we agreed to try a different approach.

Refocusing

Next, we tried a more structured approach to prototyping. Instead of working individually, we would begin working as a team on a shared idea. Instead of working on the first thing that came into our minds, we would ask questions, form hypotheses, and test the unknowns with a prototype. The goal was to figure out if an idea could be made into a successful product as quickly as possible.

This approach required something that the other process we tried just didn't have: design up front. Over-designing a game is usually regarded as a mistake, but without up-front design, you are left with a shallow product. A toy instead of a full game. Reaching the next level requires deep exploration of the idea, and I can think and discuss much faster than I can code.

You could argue that this resulted in less creative freedom for the members of our team, and I think a few of us were concerned about this. However, focusing on a single concept meant that we could be creative in our approach to the problem, and actually get things done. Interesting discussions were had about each idea, and if one of them proved to be less fun in reality than in our minds, we would move on to the next. Creativity blossoms when a few constraints are imposed. So far, this approach is working out much better for us.

More Than The Sum of Our Parts

If there is anything this exercise has highlighted for me, it's that as a team, we are more than the sum of our parts. With the three of us working individually, the results were mediocre, but by working together, we can more thoroughly and deeply explore a game concept. We can take advantage of each other's strengths and build a prototype which will actually teach us something . One of the reasons we thought that an individual approach could be advantageous was by having unbiased feedback from someone outside your project, but the benefits of working together outweigh that, in my mind.

Takeaways

Game jams don't always make the best prototypes, and design docs aren't just for managers!

Open Question

We're still looking to refine our prototyping process, and this may not be the optimal solution. How does prototyping happen in your team or company? I'd love to hear about alternative approaches and methodologies.