Rapid Prototyping, test often and fail early

As the creator of games, it is often hard to see or judge if the core idea is fun to play and within the realms of reasonable complexity. Prototypes and playtests will allow you to dodge bullets and maybe even pull the plug before it is too late.

Why Prototypes and ‘Proofs of Concept’ (PoCs) matter?

A Proof of Concept with new toys

We recently evaluated VueJS for our company projects and no amount of reading reviews and documentation would have given us the same level of insight as simply building a small mini web app with it and finding out how to solve the same problems we know with a new tool.

Most libraries and frameworks have easy to follow tutorials that will allow you to create something simple in no time and expand on what you have learned by adding more features after finishing the original lessons.

Not sure if two things work well together? Maybe don’t try to shoehorn both into an existing codebase at the same time and instead build a fresh app/tool/program using both on a clean slate. A good example of this? Try setting up a React Project using typescript exclusively with redux, routing, local storage and full linting for your workflow.

Bonus Points: By using clean slate projects, it is easy to share some or all of your code online when asking for help from the community, which is a big factor and really appreciated by those kind souls taking on your beginner questions. No need to delete sensitive client data or in-house code.

A Proof of Concept with new challenges

Create a dirty mockup in any tool you are familiar with and develop the known user journey required for the new feature. This will allow you to identify UX/UI issues early on, give you something to share between devs, art/concept and customer to develop the final solution and prevent communication issues when description and understanding of the tasks at hand do not match.

A/B Testing

Running a quick A/B test with a PoC of your change before you develop the final assets, start translations and run your full QA can save you a lot of time and in some cases even money.

Photo by Alvaro Reyes on Unsplash

How does this translate into game development?

This is an issue I’ve seen a lot with both young novel authors and inexperienced game developers. Their ideas, concepts and characters sound great in their heads but when presenting them to critics or consumers, those ideas often fall short for a variety of reasons.

Oftentimes, the problem is that taking two or more ideas from different games and simply glueing them together might not be as fun as it seems on paper. Even a full-on copy of a successful game can fall short for a variety of reasons.

What is fun

Take me for example. I’m a person that has fun writing spreadsheets with costs, values and production time to maximise the output of a little fantasy store on my smartphone. The game itself might be fun but the metagame of finding more efficient ways to do something is fun for me all the more while the next person might see this as tedious and cumbersome or downright boring.

When you are trying to find a “fun” concept for a game, you should test this basic concept as soon as possible and in the most simple way possible.

Keep It Simple

Try to find the most basic, simple and easy to use tool and level of abstraction and see if it works. For games that don’t depend on 3d graphics, platformer action or anything like that to work, try to completely ignore the design part and make a text-based version. This works well for most RPGs, strategy games, idle games, sim/management games and their likes.

If you don’t plan to make your prototype public in any way and plan to use it solely for internal tests but your game absolutely needs graphics/assets, it’s even ok in my book to use copyrighted or unlicensed material/assets from other games. Just make sure to never use any of those in any form in a published piece of work, be it commercial, open-source or freeware.

I happen to know that some board game developers used other existing board games during their early planning and testing phase and simply stuck small slips of paper to the miniatures with labels or values.

Photo by Jaciel Melnik on Unsplash

Play, Watch and Ask

Having other people play your game comes with two benefits. Feedback, as previously mentioned, and also the bonus of feeling good about your work when they sincerely enjoyed it. This can be really rewarding as a developer/game maker.

What should you test?

  1. Only because you like the concept or maybe even enjoy the execution, this does not need to hold true for a larger audience.
  2. A feature that is fun in one game can fall short in another. Context, context, context.

While a crafting system might be really engaging in one game, it might not be solemnly the crafting itself but the setting, the environment, how it is tied into the game, the lore and the interaction with other players or other aspects of the game itself.

When you try a variation of an existing concept or, even better, a very rare and completely original idea, it might take you countless iterations until you “feel” the idea and enjoy it. I can only recommend to you to search the web for some Game Post Mortem articles or videos and watch closely.

Changing and finding the right theme can make a feature “click” with the player. Switching the setting, premise or end goal (even if it is only affecting the visuals, wording etc. and not touching any of the game mechanics) can make or break a game.

Photo by Nika Benedictova on Unsplash

Is the basic idea fun?

Is the basic idea fun repeatedly?

Does the fun evolve vertically?

Does the fun evolve horizontally?

What if early prototyping is hard to do

In some of those cases, modding is a good way to bridge this gap. Take an existing game with similar gameplay that is moddable and try to add your twist/idea/feature to it. Keep in mind that if you publish the mod, your own brainchild is out there and issues with copyright and ownership can follow (always a hot topic with the big game publishers) but as long as you only use it in-house… no harm’s done, eh?

What if early prototyping is impossible

Just keep in mind that prototypes and Proofs of Concept are not limited to early testing. You should definitely use them later on as well when the core mechanics of your project are already implemented. In many cases, small variations can make a large difference in the feel of the game and respectively its user experience.

Wrapping Up

The mantra of “fail fast, fail often” might be a terribly overused and beaten-to-death buzzword term but my advice is to “try fast and try often”. You will most likely fail with some of those attempts but the earlier you find out via a prototype that an idea does not work, the faster you can pull the plug or make critical changes and change your path.

If a prototype fails or reaches the end of its life cycle, salvage it, take notes of your learning and discard the rest.

Some words about me:

I’m also currently working on other series covering complex React Native Setups using Typescript and scalable apps with Redux, where I’ll go into details about how and why I do stuff the way I do as well as some articles on my experience in building games for web and mobile with React.

Here are some of my recent topics:
- React Quick Start with Typescript, Redux and Router
- Linting/Prettier with Typescript
- Redux + Toolkit with Typescript
- Spread & Rest Syntax in Javascript
- clean and simple Redux, explained
- Game Theory behind Incremental Games
- Custom and flexible UI Frames in React Native

And if you feel really supportive right now, you can always support me on patreon, thus allowing me to continue to write tutorials and offer support in the comments section.

I’m a Web / App Developer & father 👨‍👩‍👧 doing freelance and part-time agency work since 2003, 💻 building stuff on the side 🕹 and attending conferences 🎟