Late last year, we started working on a new game. As we move along in production, our development progress and lessons will be shared through the blog.
During interviews, we are often asked about our inspirations for certain games. Yet beyond being inspired, there is always a very important phase that people rarely ask about: prototyping.
A prototype is an early sample to test a concept or process.
Creating a new game is like trying out a new recipe: you may have great ingredients, but you’ll never know how it will turn out when you mix everything together. There’s where the prototype comes in, and that’s where the risk of losing valuable time and budget is reduced.
But what form does a game prototype take?
We have tried box levels, paper prototypes and gone with a misled idea of ‘simplified levels’. Perhaps you have more to add to the list?
However, it is easy to get caught up with what form it should take. This time, we overlooked the objectives that the prototype should communicate. The form should be one that can help in successfully communicating the game’s unique selling point.
If the game’s main feature is an addictive puzzle solving system, does the prototype make the player feel like having another go at solving the puzzles? Is it challenging enough to keep the player wanting to solve more, or is it so challenging that the player gets frustrated?
If the game’s main objective is to have the players strategize and have fun with the various upgrades, is the player looking forward to strategizing or upgrading in the prototype?
Our highlight of the game is the battle system, and we planned it to be entertaining yet simple enough for casual gamers to pick up. In fear of wasted visuals, we decided to go with a box level. The idea was to test the system first, if it worked fine we would then proceed to spruce up the visuals.
It sounded like a good plan until we realized the “entertainment” factor was not being communicated well, due to the lack of polished visuals or animation. In fact, even we did not feel compelled to strategize when the stand-in visuals did not provide immediate feedback. Even the special events in each level were not included to ‘keep it simple’ – but it was exactly because they were left out that the game felt dull.
So we reworked the prototype, finalizing sprites and minor systems that would appear in the level. In some ways, this prototype is a small-scale summary of our game. After refining, we felt more satisfied seeing that our ideas had materialized properly.
There’s still a long way to go from here on, but at least we have a confident model of what we envisioned.
Experiences and tips related to game prototyping are very welcome if you have any to share!