Paper design is a necessary first step. I believe this so strongly that I chose to speak about it to the UNICEF Global Game Jam participants last year. The kids needed to hear this: we should know who we’re making the system for, what skills we want them to express, why the system we’re making fits in the context of our game, and how we’ll know if we’ve been successful, before ever touching a game engine.

And a system, of course, is a gameplay experience comprised by a set of mechanics that the player uses to express themselves in our game. Each mechanic is made up of the “levers “ we pull as designers to define how it works, things that can’t be broken down further like “speed” or “resource cost”.

The answers to these questions, and a 2d bubble map of the system broken down into mechanics and levers, should be documented before proceeding. My favorite device is Confluence.

Once we have a GDD that explains how our system and mechanics work, then it’s time for prototyping: using the bare minimum to learn the most. I’ve grown my technical toolkit in Unreal, Unity, and Ubisoft’s Snowdrop Engine enough to scope out and prototype new systems largely on my own, and I also have years of experience driving cross-disciplinary implementation as a designer. I break down the work that needs to be done by discipline (UI, audio, animation, art, programming, level design, etc), as if we were tasking things out for all of those disciplines.

Then, I determine what I can take on myself given my abilities and current workload, and participate in team tasking to ensure all aspects of the system’s design are accounted for and headed for the same level of quality. At this stage, I’m always reminding myself and others that increasing scope and polish isn’t the point right now. Prototyping systems is for validating the rules that content design will follow. We make it fun before we make it pretty, or make tools for it.

Another non-negotiable for me is consistent, constant playtesting. We shouId be playing the game ourselves throughtout the day and giving clear, constructive design feedback amongst the team, both in regular  1-1 communication and as a group. I love leading these discussions, as well as regular design postmortems.

I also have experience from all of my projects with onboarding new players and delivering playtest questions/surveys that I’ve written to gain trackable metrics (data). I’ve also helped many other designers create playtest questions for their game features. These questions should gain the player’s holistic perspective of the system, as well as their experience with the individual mechanics. We want to use data to prove that our design is successful, and can only be improved upon by “lever” pulls. If the data doesn’t, it should be clear from our results where changes should be made.

We parse our feedback and design data in the context of our paper design’s assumptions and definitions of success, then decide how to move forward from this version of the prototype towards our goal. No one has any personal attachment to this work, especially because we kept the scope down, so we can go as far as completely scrapping the system and leaving feeling grateful for what we learned from it.

But if our playtest feedback and data proves that our prototype accomplishes the goals we set out to, then it’s on to full iterative cross-disciplinary development and tools development to support the system.