I have a number of “tools” to help find this middle ground, but above all, I've found user stories to be the most valuable in achieving balance.
What is a user story?
“User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
“A true user story is a metaphor for the work being done. It is not a highly documented requirement but rather a reminder to collaborate about the topic of the user story”
I suppose we should replace “system” with “gameplay” to make this more applicable to our needs.
User stories are often associated with agile development methodologies like Scrum, but no matter what methodology you use, describing your goals in terms of how they affect your target user is a great way to achieve direction for both your team and your game.
The prime alternative to user stories is breaking your game development into tasks. While tasks can be derived from user stories, they rigidly confine and constrict your goals. This may be useful for engineering a defined structure like a bridge, but can actually be detrimental to a project as nebulous as a game.
Let’s take a look at some ways that user stories can improve the design and development process for a game:
The vagueness of a user story is also an advantage because it prompts discussion early on in the process. If you encourage the completion of one user story before moving on to the next, you will also derive two benefits: dark matter management and follow through.
What not to do
Each layer of this pyramid can align with the layers of your organization: from senior managers, through leads, to individuals. At each layer, the more senior person takes on the what and can delegate the how to the person or persons below him. This structure gets everyone thinking about and solving problems in the same way. In turn, this also allows each team member to consider the big picture and their own upward mobility, as well as the scalability of the organization as a whole.
You’ll also (hopefully) find that your team is generating great ideas throughout the entirety of the project, and user stories allow you to incorporate these ideas much more easily into your work. In contrast to task-based schedules, unflinchingly rigid as they are, user stories leave the team plenty of agency with regards to their objectives. The trick with user stories then becomes choosing which ones to follow, and which to leave behind. This decision is made easier if you have your user story hierarchy, because you can rule out anything that can’t be easily integrated into the structure.
This management style of course has drawbacks, mainly the risk of losing precise control. I’ve worked on my fair share of games tried very hard to make task-based management work, but more often than not, games end up as the sum of their parts. Focusing on the end result grants your team much more freedom, and can be hugely beneficial as long as your approach is thorough and each step is solvable. In my opinion, user stories accomplish this better than following a rigorous series of tasks. The way I see it, describing games as tasks is a little like describing a painting by the color of the paint, it just doesn’t quite cut it.
- Jason Woodward