6 Prototyping Traps to Avoid for Indie Developers

Are you getting caught in them?

Prototyping is a crucial skill to cultivate as an indie game developer. Most indie devs know they should be prototyping, but struggle with the process. On top of that, the process is riddled with traps that can catch newer (and even experienced) developers off guard. Here are 6 prototyping traps to look out for and some ideas for how to navigate around them.

Trap #1: Indie Developers Plan Too Much

This is an easy trap to get caught in. Before you start prototyping your game, you spend days, weeks, months, or in extreme cases, even years planning your game. What a scope nightmare. If you are a solo developer, I would recommend keeping your planning to a single day. List a few of the game’s core features and move on.

Trap #2: Indie Developers Don’t Prototype at All

You don’t need to prototype your game idea, right? It’s flawless… in your head at least. I’m certain we’ve all fallen into this trap at some point.

You should always prototype your ideas. As a general rule, if the idea isn’t tangible, it shouldn’t even be considered as a candidate for production. Failing to follow this rule will cost you years of wasted development. I know from personal experience.

This happened to me with my game Demonlocke. My brother and I made an initial prototype, but once development started, I altered the game so much that our initial prototype didn’t represent the new game at all. I failed to realize this, and it took me nearly 2 years of floundering before I started prototyping the game I was actually making.

Even experienced game developers can fall into this trap. In a recently published GameDiscoverCo article called Lessons from a disappointing game launch: Spire Of Sorcery, Sergei, the head of the studio, discusses how they fell into this prototyping trap when starting their second game (following the success of their first game, Gremlins Inc.):

“When we started the production of Spire of Sorcery, we felt we had ‘the touch’ - we just needed to produce the game and ship it. Prototyping is for people who couldn’t make their first game work! That success bias alone cost us 2 years of development.”
— Sergei Klimov, head of studio at Charlie Oscar

My advice to avoid this trap is to create a daily habit of prototyping. If you are constantly prototyping new ideas, you won’t even have to make the choice of whether or not to prototype, it will be part of your process from the very beginning.

Trap #3: Indie Developers Commit to a Prototype Too Soon

This might be the most common trap of them all. You have an idea and then you make a prototype, assignment complete! You immediately jump into development and realize 7 months later that your game isn’t actually good despite all the fancy graphics, screen-shake, and particles.

I think this trap is tied closely with trap number 1 (planning too much). The more you plan your idea, the more you get married to it. Even if you do end up making a prototype, it isn’t for the right reasons. You’re just going through the motions so you can check off the prototyping box and start production.

To fix this, your prototyping should incorporate a “natural selection” like process. You need to have a lot of prototypes and a lot of variations on those prototypes. You need to have some method of testing the fitness of your prototype (more on this later). Creating a habit of daily prototyping is a good remedy for this trap as well. Having lots of prototypes can help prevent the distorted vision that comes from hyper focusing on one idea for too long.

Trap #4: Indie Developers Work Too Hard on Their Prototypes

It’s important to be lazy when you make your prototypes. Spending too much time on an idea you may not even keep around is a real danger and an easy trap to get caught in.

Here are some ways indie developers work too hard on their prototypes:

1. They make assets for their prototypes.

2. They write clean code.

3. They don’t start with a base template.

4. They make an in-game tutorial.

Here are some tips for avoiding all that extra work:

1. Use public domain assets, sites like Open Game Art, or Kenney Assets are great resources.

2. Consider using “no code” software like Construct, GameMaker Studio, or GDevelop (I’m a fan of GDevelop myself).

3. Find open-source templates for the genre you are prototyping in, many engines come with templates you can start using right away.

4. Make a cheat sheet page that explains the mechanics, controls, and any icons. You may also consider recording a short video tutorial that your testers can watch before playing. I’ve used this to great affect and talked about it previously in this article.

Another great tip I’ve found for avoiding this trap is to make paper prototypes. Paper is a natural constraint that can prevent your spending too much time on a prototype. It can also naturally constrain the scope, talk about a great bonus!

Trap #5: Indie Developers Don’t Finish Their Prototypes

Wait a minute, you just said indie devs work too hard on their prototypes and now you are saying they don’t finish them. How do you finish a prototype anyways? It’s not supposed to be finished, that’s the point.

Let’s start by defining “finished” in the context of a prototype. The goal of a prototype is to answer a specific question. For a solo developer, I recommend these 2 questions:

1. Is this game fun?

2. Can I actually complete it?

Your prototype will be finished only when both of these questions have been answered.

Let’s talk about the first question. Is the game fun? This question gets a lot of attention already, but it needs to be addressed. As a starting point, use your instincts to gage how fun a prototype is. If you find it fun, you should then get feedback from outside sources as well (see trap number 6). If the answer isn’t a firm “IT’S FUN!”, you should either try a variation or start a new prototype.

Now for the second question. This question is all too often ignored, leaving the prototype unfinished. Can you actually complete this game? Make sure it’s a firm “YES!” When you look at your prototype, you should be able to see the light at the end of the proverbial development tunnel.

Once you can answer both of these questions, your prototype is complete. Only then can it be considered as candidate for production.

Trap #6: Indie Developers Don’t Get Feedback on Their Prototypes

This trap is closely linked with trap number 3 (committing too soon). You finish your prototype, and you move directly into production, or maybe you have a friend or two play it first, fix a few bugs, and then move into production.

Not only should you be getting feedback, but you also need to be getting feedback on multiple prototypes. This connects us back to our process of “natural selection.” You need to have multiple prototypes competing with each other for survival. There will be games you can reasonably complete, and now you need to find which is the most fun. If it is your first game, I’d also recommend leaning into the smaller games. You need to get a win under your belt and prove to yourself you can finish a game.

Okay, so how should you get feedback and what should you look for?

I’d recommend getting at least 5 people, but no more than 10, to test your prototype. Try to find people who are somewhat interested in the genre you are targeting. You should also ask these people to record themselves while playing. A good number of people have easy access to screen recorders and microphones. Get the audio of them talking through their experience. If you can get video, that is an awesome bonus, but it isn’t required.

Now that you have your recordings, watch them, don’t pay too much attention to what the testers are saying, focus on their emotions. You’ll be able detect the emotions in the tone of their voice and the expression on their face. Their emotions won’t lie to you, no matter how nice they are with their words (and most people are pretty considerate when giving feedback). If they have strong emotions about the game, that is a good sign, even if some of them don’t like it. Remember, the opposite of love is apathy, not hate. If your testers hate your prototype, you may consider making a variation and see if you can convert that hate to love. If they are apathetic towards the prototype, you should probably just drop it.

Conclusion

If this list made you aware of a previously unconsidered prototyping trap and gave you some tools for avoiding it, then it was a success! Test my suggestions against your own experience. Find solutions that work best for you. Let me know in the comments below if you have any other prototyping tips or if there’s a prototyping trap I missed. While these 6 traps can be hard to avoid (we all fall into them now and then) I know it can be done. Good luck and get prototyping!

Thanks for reading,
Ben

If you’re new here, consider subscribing for more gamedev tips:

If you’re already subscribed, consider sharing this post with a friend: