Why is quick and easy prototyping important?
Especially in GameDev, you need to make sure that something is fun before you go the extra mile to implement it and flesh it out with production-ready assets and all the bells and whistles of a new feature.
If it’s not fun and not 100% even necessary for your game for some arbitrary reason, get rid of it!
Some elements might sound fun while scribbling down your idea but as soon as you see it in action, you realise that it doesn’t feel as good as when it was growing in your imagination. Other concepts might be entertaining for you but your target audience doesn’t even like the concept. And last but not least, you might realise during development that your simple concept has far-reaching consequences and requirements you didn’t see at first glance.
Prototyping can help you identify some of those issues early on and save you a lot of time. Either use a tool you are familiar with (like a game maker for example) to create a small version of what you have in mind with crappy art, stock and placeholder texts or if you are like me, whip something up in a language or engine you can use well.
I’ve made myself a small “quick prototyping kit” build on React Native, Expo and Redux that has a basic setup with a splash screen, main menu and game loop and I can simply clone that kit from GitHub (you can follow the process of building it in my tutorial series and I’ll make the final product available, when the series comes to an end) and immediately start hacking away. I use this both for trying out new ideas and experimenting with new language features or programming patterns.
Sometimes you can’t start fresh and need to work with the real deal.
When working on bigger projects, I simply branch from the current stable develop version via GIT (always use GIT or another versioning software, if possible) and simply build a rough an uncut simplified version of the new feature. You will find placeholder text and art all over my /prototype branches and as a personal rule, I never merge /prototype branches to develop. If something works, I try to understand my final prototype version and jot down the way to get there either in my notebook or as a flow chart, depending on the project. At that point, I’ll start a new /feature branch from develop and start fresh, using proper design patterns, tests and other best practices.
Fail fast and fail often! The important rule is to not get overly attached to your prototype.
This rule doesn’t solely apply to game development. Prototyping is useful for all kinds of programming tasks and trying out many different things with nothing to hold you back will get you a long way. If you start with game design documents and implementation plans, fully-fledged feature lists and all, you might end up with heaps of documentation and paperwork for a feature that gets scratched anyway because it didn’t work out in the end. This shall in no way encourage you to go about your projects without a plan, documentation and such! Don’t get me wrong here, propper planning is really important for most projects! BUT… maybe it’s ok to build a small prototype to test out some ideas before you go all out with making plans for multiplayer, monetisation, cross-platform distribution and marketing campaigns. Build a small version, give it a try and see if it’s fun. Maybe even make a paper prototype or something. It might save you a lot of work in the long run.
There is a caveat…
Some things can’t be prevented with a prototype and some projects are harder to prototype than others.
There are cases where you can’t easily build a prototype from scratch. When working on games that rely a lot on player emotions or where the key mechanic of the game isn’t something based in math or logic but in art, colours, motion or music, building a prototype might still be a good idea but you need to put more work into it. This doesn’t mean that prototyping won’t help you in those cases but building them will require the work of both designers, developers and artists. What you will end up is more like a Proof of Concept than a real quick and dirty prototype but your team will soon reap the benefits of all the work put into the PoC.
You will also inevitably run into issues you didn’t foresee or experience in your prototype. Integration problems, as I mentioned earlier, side effects (changes in the meta of your game) or simply things like feature creep or technical issues… Not to discourage anyone here but there are so many things that can go wrong. So why not reduce that number a bit with prototyping.
Bonus Advice for new and hobby game developers:
Don’t start with your dream project right of the bat!
If you plan to build the next AwesomeExistingGameWithSomeNewTwist (no judgement here, just as an example) and you are new to development — especially game development — start with something small. Like really small! Take JUST ONE aspect of that game you have in mind and build a mini-game as a practice exercise. Maybe even just a prototype for one super simple feature. For example, if you plan to build a turn-based strategy game with units, spells, equipment, crafting, shops, events, PvP, Arena… maybe start with a simple battle with static units and equipment and auto-attack. No controls, no extra jazz, just the basics to get you started. (I did that for fun a while back when experimenting with React/Redux. It’s just a prototype/fun experiment, nothing I would put on a store.)
Building something that runs and that’s playable in some way will be a great motivation boost. Finishing something is an excellent experience if you are just getting started. Heed my words, build small things and finish them. Discard them (or link them in your blog posts for general amusement) and start the next thing. Don’t build a monolith and don’t start a project that’s doomed to die of old age without ever being finished because the scope was too large for your first project.
- Build simple prototypes
- Rinse and Repeat!
Some words about me:
If you want to see more of my work and progress, feel free to check out my series on building a React Native Web App with Hooks, Bells, and Whistles with Expo SDK33 or my Straight Forward Redux tutorials. I’m also currently working on a new series about building more complex and scalable apps using React/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. So stay tuned for future updates.
Feel free to support me on patreon, thus allowing me to continue to write tutorials and offer support for others.