Why Most Game Ideas Will Never Be Good Games—and How to Avoid This Fate
It’s not just you. As evidenced by an abundance of articles, videos and Tweets about staying motivated and working hard on game projects, countless game developers struggle with completing their projects and converting even their best ideas into good games. As it turns out, there are many reasons for this. Some developers have trouble coming up with original, fun ideas, some forget why they were inspired to work on the game in the first place and most of them lack long-term motivation. As a student who often struggles to find the time to work on his game project (and sometimes even loses interest), I’ve been all of these developers more times than I can remember. I decided I’d do a little research on the causes of these struggles, and, ultimately, these failures, in hope that you might benefit from understanding how to prevent them.
Unmarketable game ideas
Too often I am months into a game project before I discover that my game idea won’t be marketable, or at least that it has major issues, and this is sometimes enough to cause motivation to plummet, bringing me to quit the project and go back to the drawing board. Even worse, sometimes developers don’t realize their ideas won’t sell until they hit the marketplace, causing a sinking feeling that countless hours and boundless work have been for naught. Wouldn’t it be nicer if you could tell if your ideas had issues before you started working on the development? Well, you can. There are some checks you can put your ideas through to tell.
I’ve made some changes here to recognize that games that don’t perform well in the marketplace are not guaranteed to be bad games. Creating a game you’re proud of is just as important as, if not more important than, creating a game that sells. I’d like to thank Reddit user scrollbreak for pointing this out.
1. Verbally define the idea
Give the idea a chance. In “How to Discover if Your Game Idea is Good or Bad,” Jan Bo at Indie Game Buzz recommends first fully developing your game idea and mapping out on paper. Jot down basic mechanics and map out how they might work together.
At this point, it’s also a good idea to define some other aspects of this game idea. Pluralsight, a self-labeled “technology learning platform,” recommends defining the scope of this idea as best you can. How large is the world? How many characters will the game have? How difficult will balancing be? Understanding how each element of the idea will add complexity is crucial to defining the core aspects of the game; you should be careful not to add mechanics that don’t directly relate to the core of the idea itself.
If you’re having trouble determining whether a mechanic or concept directly relates to the core of your game idea, think of your audience. Who are you selling this game to, and on what platform will they play? Do they want to be submerged in a highly complex world, a fighting game with countless combinations, or a casual game with just one or two basic mechanics?
Then mock up your game visually, on paper, with the dimensions of the platform(s) you ultimately want to ship your game idea to. If your idea still seems cohesive and exciting, you can take it a step further and share your concept with some friends and family. Try not to bias them, though—Bo recommends the sentence “I want your honest feedback so I can make this idea better.” If you show them your excitement, you could be fooling yourself should they give a positive response. Then review the feedback you collected and decide if you’d like to move on to prototyping, Bo’s next and final test for determining whether your idea’s a good one. Simply build out the core mechanic and then collect feedback (Pluralsight also notes that this feedback can sometimes provide a much-needed invigoration and reassurance that you’re moving in the right direction). Make sure you’re not adding any more at this phase: your prototype should have one or two mechanics; you’ll need to keep the scope very small. Remember, this isn’t the game, it’s a prototype you’re using to see if a potential game will be feasible.
Lack of long-term motivation
Game developers aren’t the only folks who struggle from a lack of long-term motivation. Many disciplines and mediums require participants to spend lengthy periods of time working on projects. In “Making Games 101: How to Stay Motivated”, Tiana Crump writes for game developers; in “How to stay motivated while working on long-term projects,” author Nela Dunato generalizes her experience writing a book; and in “How to Stay Motivated in Long Projects”, Scott Young writes from the perspective of having many large projects, including books and software, under his belt–but these articles provide startlingly similar strategies for staying motivated, suggesting there are some universal tips you can follow to keep on track.
A schedule can help motivation, or, perhaps better yet, remove spontaneous motivation as a factor, by encouraging work at specific times on specific days. Crump suggests sorting tasks by level of fun and making daily or weekly appointments to work on your game with designated (and spread apart) levels of funness for each; this could help against not wanting to work on parts of the project that are difficult or less exciting. In my own experience, creating a schedule for myself has helped me “make it official,” increasing personal accountability. If I had worked on it, I would feel productive, and if I had missed the deadline, I’d felt I’d lost something. Remember, Dunato says, when you don’t work on your project, you’re only cheating yourself.
Similarly, Young recommends a strategy he calls “building a baseline,” arguing that with this magical technique, motivation is not even necessary, as working on the project simply becomes a habit. Young achieves this by determining when he wants to finish the project and then dividing the amount of work by day until that point. So get an idea of a deadline in your head!
A baseline, as Young describes it, is notably much easier to quantify with novels, where a writer can attempt a number of words per day, than with software or games, where lines of code are not a good quantifier of progress. Specifying a number of hours per day won’t work, Young says, because “that’s just a recipe to procrastinate while watching the clock tick away the day.” Instead, break your game into logical chunks, like “create the basic player controller” and “add double jumping to the player controller.” Make sure the chunks are manageable and reasonable to complete in amount of time you set out for it. If you run into difficulties (like not having enough time), you’ll need to either shrink your game or elongate the deadline; avoid the temptation to pack more work into a goal, because the second you notice you aren’t able to complete a goal in the time you set out for it, you risk losing motivation and your established baseline.
2. Join support and inspiration groups
Crump and Dunato both endorse the idea of joining and actively participating in group of other developers and any people interested in following the developer’s journey. Such groups can include posters to Twitter hashtags like “#gamedev” and “#indiedev”, game development forums and Discord chat channels, and in-person game developer friendships. Connecting with others and sharing my goals can be a good way to keep up long-term motivation for two reasons: it helps keep me accountable to your goals; if I share when I want to have part of a game project finished by with, say, my Twitter followers, I may be more likely to stay motivated while trying to complete them.
Be careful to make sure those goals are attainable, though! Peter Shallard, psychology expert and former therapist, warns that when you tell people your ideas, your brains have a positive response, creating a reward before we’ve even done the thing. If your brain is satisfied with this, you might struggle to link motivation to telling people your goals.
From my personal experience in the Twitterverse, telling people about my progress seems to be much more helpful than telling people about my goals. When I’ve told people my goals, I indeed get a satisfaction from telling them, which has rarely resulted in my actual completion of the thing at hand. It’s been far more helpful to tell people what I’ve actually accomplished: there is still a little bit of a rush (and a little bit of accountability) that comes from my audience’s understanding of an end product I’m working toward, but the bigger part of the satisfaction comes from reporting the progress toward that I’ve actually made. Some people have proposed ideas I could implement in my games, and it’s even more exciting when my progress inspires people to work on their own games! This kind of engagement and interaction can sometimes be far more motivating than accountability, and it makes me want to come back for more (and in order to do so, I need to spend more time working on my game)!
I’ve touched on documentation already: this is certainly related to many other problems developers face, so this section will be brief and based largely on my own experience. It’s no secret that thorough and fully-developed documentation is necessary when large groups work together on games; for communication purposes all group members must fully understand the project at hand. But it might be surprising that thorough documentation is just as necessary for independent, ‘solo’ developers. Why? Because you need to be able to communicate with your future self.
I have had many game ideas fall through the cracks in my brain simply because I never fully explained them to myself. Day one, I’ll sit at my desk, think of an incredible, never-done-before idea, and immediately get to work developing it in a game engine. At first, my progress seems promising, almost unreal: within just a few days, I’d have some decent assets, a basic character controller, and maybe even the start of some interesting mechanic. This will continue for a few days, maybe even weeks; the rush of having an awesome idea will be my only real motivator, but eventually my progress will plateau. Where should I go next? So many parts of the idea will float around in my brain, existing but totally undeveloped, and I’ll have no idea which one to pick to implement (or how to implement a less-than-fleshed-out idea), so I will simply polish what I had already added. A few days later, I’ll forget why the idea was ever so interesting in the first place and drop it entirely, left with nothing more than an unexceptional character controller.
Thus, having good, thorough documentation is doubly important: it helps you clarify ideas and build a schedule, and it allows you to go back and reference your awesome ideas when motivation inevitably starts to dip. For this reason, in this phase, much like in the prototyping phase, you must elaborate thoroughly on your ideas; leave nothing vague or abstract as these loosely-defined areas can be huge stumbling blocks for future you.
For example, rather than writing, “character can jump,” explain that “the character can jump much higher than would be realistic, and gravity should cause the player to accelerate quickly toward the ground after they jump. A jump animation should show the character’s legs move in a spring-like manner while arms move close to the body, and the arms should float slightly away from the character’s torso as they fall.”
Be careful, though: a massive game design document can be somewhat intimidating when it’s time for you to actually ‘do the thing.’ To avoid this intimidation, remember to tackle the project in small chunks and keep the scope of the document to the scope of your current objective (if you’re building a prototype, limit the document to your prototype).
Next time a marvelous, never-before-seen idea pops into your head that you’re sure will make you rich, you won’t let its tempting excitement consume you. Rather, you’ll proceed methodically and cautiously, treating the idea like it’s guilty-until-proven-innocent.
First, you’ll fully flesh out and develop the idea into a documented mock-up. Upon determining whether it pleases you and seems feasible, you’ll share your ideas. If you get a positive response, you’ll then build that documentation for a prototype, work toward a regular schedule and habit for developing the prototype, and if you’re still satisfied with the idea, you’ll complete your game design document for the full game and get cracking, sharing progress updates with friends and followers along the way.
Otherwise, remember that failure is learning experience and not something to be ashamed of. If you realize an idea isn’t a good one before publication, you’ve saved yourself so much time and disappointment in the long run (and learned a whole lot from the experience)! Don’t hate on yourself for what can make you a better, more cautious and level-headed developer in the future.
Sources and Further Reading
Crump, Tiana. “Making Games 101: How to Stay Motivated.” Buildbox, 14 May 2018, www.buildbox.com/making-games-how-to-stay-motivated/.
Dunato, Nela. “How to Stay Motivated While Working on Long-term Projects.” Nela Dunato Art & Design, 28 June 2018, neladunato.com/blog/stay-motivated-longterm-projects/.
Jan, Bo. “How to Discover if Your Game Idea is Good or Bad.” Indie Game Buzz, 14 Mar. 2015, indiegamebuzz.com/how-to-discover-if-your-game-idea-is-good-or-bad/.
Pluralsight. “Creating a Game Concept: The First Step in Getting Your Game off the Ground.” Pluralsight, 26 June 2014, www.pluralsight.com/blog/film-games/creating-game-concept-first-step-getting-game-ground.
Pluralsight. “Why Your Game Idea Sucks and How to Make It Better.” Pluralsight, 9 Apr. 2015, www.pluralsight.com/blog/film-games/game-idea-sucks-make-better.
Young, Scott H. “How to Stay Motivated in Long Projects.” Scott H Young, 3 Apr. 2018, www.scotthyoung.com/blog/2008/07/15/how-to-stay-motivated-in-long-projects/.