I’ve written an article that discusses a method you can use to help avoid making bad decisions:
The entire article is pasted below for the link averse:
A sound decision-making methodology is the most vital key to success.
I’m going to outline a decision-making template that game developers can use. The intended audience is indie developers who intend to finish and publish games on a schedule.
My decision-making model is influenced by military decision-making models - the Operational Risk Management model being a major one. Of course, it is refined by my own personal experience and predilections.
The purpose of a decision-making template is to help mitigate the risk associated with making bad decisions. A bad decision is one made from incomplete thought or insufficient data and results in wasted time and/or unpredicted results.
A major benefit to using a decision-making template is that it helps reduce mental and emotional fatigue. It helps keep your momentum going from steady productivity. Spend more time creating meaningful results and less time in non-productive limbo.
There is your purpose, now let’s talk about the task.
Let’s work with an example decision and go through the process step by step.
I am using a question that somebody asked on the Unity Game Design forums. They wanted second opinions about, “should I use floating damage numbers in a shooting game?”
The first thing I’ll do is plug that decision into my Decisions List. This is a running tab you can keep on Trello or whatever project management tool you like. It is important to actually write your decisions down for several reasons. Just do it - don’t hold things in your brain, it is not reliable.
In the middle, yellow colored, we have our Decision List. Before we get into the nitty-gritty of making this decision, the first question is, “Should we make this decision right now?”
We need to determine a Priority Level.
How do we determine the Priority Level of this decision? We need to consider the Severity and Urgency. With severity and urgency defined, we can meaningfully compare this decision against others in the Decision List.
First let’s focus on Severity.
We ask: What is the predicted Outcome Impact for this decision? Best Possible and Worst Possible?
Outcome Impact means, if the outcome of this decision I make comes true, what is the impact that it will make.
It is important to be realistic and pedantic here. Go broad and deep. For a non-trivial decision, you might write several pages here. “Game is better/Game sucks” is not an outcome impact!
It is also important to note that this is guesswork at this point. The assumption that we are making is that you know enough about your game genre and audience to at least make semi-useful educated guesses.
We’ll talk about research later, but for now, to get started, we make our best guess.
With our Outcome Impact’s defined, we have a sense of the Severity of this decision. In this case, it seems like the best and worst case outcomes have limited effects, so I’d define the Severity as low. Not negligible, but low.
Now we want to figure out the Urgency.
Figuring out the Urgency requires a broad perspective. We aren’t focused only on the impact of this single decision. We consider the entire production and try to figure out where this decision best fits into the puzzle.
With our decision written down in a checklist, life is easy. Just look - all the problems sitting there like fish in a barrel. Now we can compare this decision against others - and most importantly - consider in light of our goals:
I prefer to keep my Decisions List always within one eyeball’s reach of my Goals list.
The Goals list is where you have defined you short-term and long-term goals. I highly advise that you never make a decision without reviewing your Goals list. Even a tiny trivial decision like, “what color should this tertiary character’s lip gloss be?” should never be made in isolation.
All decisions must consider your short-term and long-term Goals.
As an example, thinking about the Urgency of the Damage Numbers decision, take a look at the Goals.
Our most immediate goal is to publish a play test by a certain date. Does that play test require the Damage Numbers? If not, does the next goal require it? And the final goal?
We may say, “Gotta have the Damage Numbers ready for the playtest.”
To answer the Why, we need more knowledge. We may never be able to determine an absolute answer, but with enough knowledge we can at least place this decision into the puzzle in a strategic way.
Let’s think through this carefully. I’ve got a checklist of common considerations that I never want to forget when making a decision:
First, list all the possible ways we could solve this problem. The decision is, “Should we include floating damage numbers?” After some thought, I came up with four possible choices:
Listing possible choices is just a fail-safe. Taking the time to actually write them down helps ensure that you don’t miss something. This is a time when more than one brain can come in handy.
Other factors to consider: You may not need to answer all of these questions, but you should consider each, and also think carefully if your own project has additional considerations worth adding to the list.
Dependencies ask whether or not this decision requires something else to be done first. For instance, if these Damage Floating Numbers depend on a HUD system that you haven’t built yet, now you know that in order to test this system out, it will require some more setup time.
Measurable Result ask if there is a way that we can measure the result that our decision might produce. In this case, I have said "Imprecise”, which amounts to a shrug of the shoulders. Can we really measure what effect the damage numbers might have?
Realistically for an indie developer, I think an educated guess after much play testing and studying our target audience’s interaction with the game would be as much measurement as we could get. It’s something, but let’s not fool ourselves.
Methods to Measure Result ask what would be required to measure the result, if at all possible?
Backstop is important for the solo developer!
Without peers to help keep you on track, you must guard yourself against the danger of wasteful noodling (aka procrastination stemming from vague insecurities/uncertainties.)
Before you start work, know what the end-state is and don’t go beyond that! For example, if you implement the Floating Damage Numbers and then suddenly realize you want to add some other particle effects, you must add that to the decision list and consider it as its own decision! This is akin to infantry grunts calling to higher command before making big decisions that affect the entire battalion.
Time cost for research/production ask how long it might take to do the work necessary to figure out how implement our Floating Damage Numbers, and actually produce the results.
Time cost to measure results ask how long it would take to measure the results, if possible.
Now that we have considered all of these factors, we have a better sense of what is going to happen after we make this decision.
We probably have enough information to now determine the Urgency of this decision. In some cases, more research may be necessary.
In this case, I will define the Urgency for this decision is non-Urgent. Since nothing else depends on this decision to be made and it has a low Severity, I see no reason to prioritize this decision ahead of others.
Considering the Severity and Urgency together, we can define a Determined Priority and write that in our Decision list.
I’ll write “Later,” which is just my way of saying it is something that will be done, but I have more important decisions to handle for now. At the point I do my next reassessment I’ll see if it’s time to move the decision to “Now” or “Next.”
We can write our Final Decision now or later. Maybe you feel a need to test all the possibilities and have determined that you have the time and resources to do so. Maybe you know which one you want already. Does not matter - the important thing is that you have determined the Priority for this decision so that you can set aside the right amount of time at the right point in your production to do whatever work is necessary to come up with the best solution.
I’ll go with the option to include the feature, default it to be on, but let players have the option to turn it off. My reasoning is that I’d expect the type of people to be fussy about immersion to also be the type who go into options menus and tinker around, whereas more casual types who never open settings menus probably also like instant gratification GUI stuff, or at least aren’t bothered by it.
Just my hunch, but for a decision that I’ve defined as Low Severity I am comfortable going on that in this theoretical example.
Finally, Method of Decision is an integrity check. It is a way of asking yourself if you did due diligence.
Well, I hope this is useful for you. It seems like an awful lot of trouble to go through, but truth is that it’s a lot less trouble than developing without a decision-making methodology.
You will of course develop your own criterions by which you make decisions, but this template may help you get started if, so far, you’ve just been winging it.
If you are a developer who has been tinkering for years but with little to show for it - but you want something to show - the biggest step you can make towards getting serious is to develop a habit of implementing a decision-making model for every decision that you make. It may be possible to make trivial projects while flying by the seat of your pants - and that may be all you care to do which is fine - but it you take on a high commitment project you’ll be incurring significant risk if you choose to operate without a methodical decision-making process.