“Creativity is always a leap of faith. You’re faced with a blank page, blank easel, or an empty stage.” – Julia Cameron
The beginning of a game project is always fraught. Sometimes you have a completely blank page with an idea. Sometimes you have to build off another work to make a sequel or something that affirms a genre. Regardless of your base assumptions, you have to start somewhere. Often, that presents a chicken-egg paradox where you don’t feel comfortable starting Feature B until Feature A is done, but you really don’t know how Feature A should work until you feel out Feature B.
These problems are common in professional game development, but there have only been ad-hoc ways to address them that can be contradictory when combined. This paper attempts to give tools to the starting game team that will help them understand and prioritize their early game and prototype features.
There are two common frameworks that already exist for this problem, but both tend to lie in opposition to each other. The first is what could be called functionally-wide prototyping. In this, teams build the most foundational features first in order to have a robust testing bed in which to experiment with new features.
A major drawback method to this is that it is slow to get to the unique features of the game you want to make. For instance, if your plan is to make a groundbreaking take on American Football that aims to dethrone the Madden franchise, you first have to make a game that simulates American Football, which has a complicated rule-set, the need for multiple player types each with their own AIs based on selected plays or other assignments, and an expectation of an animation system that allows players to understand their options in real time. That’s a tough sell, and may be why we don’t see a lot of challengers to the crown. Just building the playground where you could add your own unique selling points would take a long time.
Another method would be to create a robust vertical slice. In doing this, you ignore the wider requirements of the final game and instead focus on making a short-duration sample of what the game would be, usually picking the set of features to feature in the sample that would best show your unique selling points.
The drawback with this is that the vertical slice is fragile. What happens if the features you choose to focus on turn out to be too complicated, not fun, or not representative of the experience you wish to make? Since you are only building the scaffolding to support your chosen set of features, it is likely you have to go back and rebuild for whatever your playtesting reveals needs to change. If you already perfectly understand what you are going to make, a vertical slice can be very helpful. But if you are facing a blank page, it doesn’t lend itself to experimentation.
What we need is a framework that allows a team to best prioritize the game features they plan on making while allowing for the experimentation and iteration necessary in games, but that also allows teams to be cost-effective and agile. This framework is an attempt to bridge the gap. We desire a system that both allows us to plan effectively and react creatively.
Normally, this kind of longer-term planning is seen as a task for producers, not designers. However, what we are proposing must be reactive to how the design unfolds in practice. The people making the prioritization calls must be knowledgeable both on the relative costs and benefits of features and the impact those features would have on future experimentation. This is knowledge that only designers can effectively juggle, usually with help from the other disciplines on the team.
Hopefully, the framework we present below will allow designers new tools to consider the relative importance of the tradeoffs in early prototyping allowing for a more flexible, a more transparent, and ultimately, a more effective game development process.
This framework allows the user to organize their design work and prioritize the efforts through lenses agreed upon by the team. There are 4 steps to this framework. Each step is crucial to informing the subsequent step.
This is the easy part. List out all the design features needed for your game. Think deeply about each feature and list out all subfeatures as well. Ex: You need a combat system, that means that you’ll need the following systems as well: damage, death, hit react, knockback, etc…
Make sure to break apart any feature that is not distinctly linked to another, and to note any dependencies.
It’s very unlikely that you’ll get this right on the first pass. You’ll likely need to break down features into smaller features as you go, and will also likely revisit this list as you remember more items that you require.
After completing the list of all intended features, we can analyze and categorize them. The categories defined in this step help you organize your features into clear categories to help you rank them in the next step.
This is the key step in determining the priority of each feature. You need to describe how you will organize and prioritize your game features. For each of your features you’ll need to label them with one of the categories listed below.
Next step is to order your Feature Categories within their Importance Buckets (or tiers,) to help you understand how meaningful your Feature Categories are relative to each other. There are three importance buckets:
Each Feature Category is conveniently categorized within these buckets like so:
These are fixed classifications that must be adhered to, however the Feature Categories within each bucket may be placed either above, below, or alongside each other within their respective Importance Bucket. Below you’ll find a few examples of how this can differ from project to project:
In this step you will stack rank each feature against each other, then assign each of them a risk factor.
With each of your features classified to a Feature Category, we can now begin stack ranking the features.
With each of your features you will then assign a Risk Level. Label each risk with a letter A through D.
Typically all features in the Essential bucket will get assigned a Terminal (A) label.
The Safe to Cut (D) label will most often be applied to features in the Accessories bucket. However, Accessories may also be labeled with Safe Implementation (C) labels.
Some examples:
Above are a set of guidelines to help prioritize your implementation efforts. However there are many other factors that may influence your priorities throughout development. It is important to keep each of these in mind.
Congratulations, you now have a list of features prioritized by your design needs. This list will now help your team spend their time and effort where it matters most, to mitigate design risk and reach your project-specific targets as efficiently as possible.
Note that this is a guideline to create early prototypes and development states. Priorities will change during the course of development according to new findings and new constraints that will appear and it is normal to have to reprioritize in cycles with the team.
This paper was produced by a workgroup of senior game designers at the 2023 Polaris conference. The non-profit Polaris Game Design conference seeks to gather the industry’s top designers in order to first, discuss our toughest problems and second, share this deep wellspring for the benefit of game teams everywhere.
In 2023, this work was made possible in part by our sponsor Xsolla and others.