Do Your Own Design Analysis & Critique#
Working on a feature that you’ve been given specific reference for? Don’t go running to someone else’s analysis and critique looking for their opinion. Do your own.
Why? Well, first and foremost, it’s your expertise that’s on order. Everyone has a particular, personal take on any given design and while ingesting someone else’s views can be useful as a comparison or contrast to expand your own point of view, consuming it wholesale means you will regurgitate their opinions without truly understanding them. Lacking that critical piece, you can’t possibly talk with any level of expertise about the opinion you’ve just expressed because you haven’t done the real work.
It’s also the way to develop, hone and maintain these important skills. It may sound simple to play a game and take notes, but there are almost always important layers of nuance that you miss unless you can do the deep dive yourself. You may see things that others have missed or perceive them differently. Learning to look at something with a discerning eye is not only beneficial for analyzing other games to see what they do, but also the project you’re working on as well.
Iterate, Don’t Emulate#
Following on from the point above, don’t simply replicate other established designs.
Often when a new feature is brought up, there will be a broad, high level description of the expectations. From there you might be given references to provide an example representation of what is desired. Reviewing the reference material, you’ll gain an understanding of a specific implementation, but not all of the reasons behind it, nor the journey that the team took over the course of the project to arrive at that specific shipped implementation. Every game is different, even within a genre, the decisions made need to be based on the project the feature is for.
Now, a counter-argument you might hear against this approach is “We don’t need to reinvent the wheel” and that’s true - to a point.
Perhaps the absolute core basics of a common, well-understood feature don’t need to change but what is it about this feature that makes it specific to this project? What has to change? Where can you improve on what came before? It doesn’t have to be ground breaking; it can be a small change that makes the game feel like the one you’re making and not a replication of the reference material.
Test Your Changes#
We all know this shouldn’t need to be said, but if you’ve worked in the industry for any amount of time, you’ve certainly worked with someone who didn’t test their changes before they submitted. Maybe the effect wasn’t catastrophic, or maybe it broke the build. Either way, those changes needed to be tested before they were submitted.
Even the smallest change can have a far-reaching impact; tuning one enemy’s health or a player’s weapon damage, even slightly, could throw off the balance of carefully constructed encounters. This is where having a test map (also called a gym or lab) is often very helpful. Being able to evaluate the impact of your changes in a safe environment saves time and lets you construct specific circumstances to ensure the change is good.
Remember that once you submit, the rest of the team will get your change. Taking a few extra minutes of your time could potentially save hours or days of time across the entire team.
Understand Feedback#
Getting feedback on features, tuning, gameplay and the overall feel and experience of the game is a regular, helpful process. The trick is really understanding that feedback so you can make an informed decision as to how to proceed.
Feedback is best given live. Getting a bullet-list in an e-mail is rarely particularly helpful unless it’s in preparation for an upcoming conversation. This is because the reason for the feedback is almost never given. You’ll get notes like “Reload speed is too long” or “X happened during gameplay”. Those are factual, but not particularly helpful and lack context. That means you probably can’t make a good decision based on it.
What if you can’t get the feedback live - what can you do? Well, if your project or studio captures video footage of reviews, that can be a good place to start so you can see what happened, after the fact. What was the situation that led to the feedback? How did the gameplay evolve, how could it have evolved and what was the expectation both from the player and you as the designer?
Most importantly though, is talking with the people giving the feedback to really get an idea of where they’re coming from. Listen to what they have to say, how they feel about it and what their expectations were. Ask questions, but don’t lead them to any particular answer - be open ended and let them tell you, rather than be guided. Use that to inform your decision about how to proceed and what changes to make or, sometimes, not make.
An important point here is that, especially when the team has been playing the game for a while in a specific way, changes that are otherwise beneficial can be perceived as negative. Did your game previously have infinite ammo and no reload, but those features were recently added? It’s possible they’re not being well received because they’re not tuned or balanced yet, but it’s also possible these new features are just different and that’s enough.
What If#
Sometimes answers to design problems flow naturally, clicking into place in a way that feels like magic, while other times they seize up and for the life of you, you just can’t seem to get where you feel is right.
Don’t be afraid to step outside of the established conventions of thought you have for the project. It’s not uncommon for some of the assumptions made during the course of production to change, even unexpectedly. Some of the best games have dared to explore unconventional, unexpected or straight-up strange territory.
Ask yourself, “What if…” when you’re considering how to approach a mechanic or player experience. Thinking about the player experience in a new way, divorced from currently established gameplay paradigms, can lead you to those critical “ah-hah!” moments that tip off a train of thought or conversation leading to a breakthrough.
What if the mechanic…
- Is it’s own gameplay context
- Can be stolen, taken or used by an opponent
- Is inverted
- Is a tug-of-war
- Happens as a second-order effect of other gameplay actions
These are just some examples. Creating your own list of “what if’s” to refer to and test ideas against is a helpful tool that can also lead to developing or reinforcing your own signature style of game design.
Once you think you’ve got your “ah-hah” idea, making it fit with the core vision of the game and the established gameplay in a way that enhances the experience, rather than upends or diminishes it, is the challenge. Once again, sometimes the solution to that challenge comes to you fully formed, and in others you just have to ask “What if…”.