With the Touch the Stars Game Jam deadline creeping up (less than two weeks!) you probably already did all your rapid prototyping to test if certain parts of your game worked... but how DO you Rapid Prototype?
You’re under a time crunch, and an ugly one at that. You’ve only got a few weeks (or days) to get out something related to your game. Or, you’ve got a team, but they don’t have any solid direction, and walls of text just won’t convey your idea (they really won’t, by the way).
A prototype of your game, a “vertical slice” that showcases what the finished game will play like, is your answer. Prototypes can be made very quickly and do more than anything else to give people an idea of the final game-play.. Listed below are 5 ways to rapidly create such a slice of your game.
The biggest mistake that new developers make is that they think a prototype needs to be a part of the finished game. Nothing could be further from the truth. While it’s acceptable if your prototype has pieces that get used in your Gold Release, you should design it with the sole intent of showing a small slice of what the final game will be like. If you’re trying to recreate a part of your end vision, you’re going to take forever. That’s not a prototype.
In the game industry, the term vertical slice means comes from this model: You take every aspect of your game, the features, the gameplay loop, the flow of a moment, and stack them on top of each other. Then you slice down the middle and take that “piece” out, showing everything. If your game uses a turn based battle system where the characters draw magic from the environment, include that. If it uses a wall-run and wall-jump system, include that. If it allows for switching characters on the map, each with their own puzzle-solving element, include that. Your prototype needs to showcase everything that the final version of your game will be able to do.
This needs to be said: So many new developers, especially in the RPG Maker Community, make their prototypes (and demos, but that’s another article), way too long. We understand that you are proud of your game, and you should be; however, you want to convey how the game will function (not look) when completed. Design it over a very short and simple area, like escaping from a collapsing tunnel into a cavern, then riding a geyser to the surface. It should be completed in ten minutes or less, with shorter being better. Make sure that is little to no downtime, so no vast open areas to explore without action. Keep it short and to the point.
Unless you’ve got a model or sprite sheet of your hero lying around, don’t focus on the visual and aural details, just the gameplay. Use placeholders or default graphics. Use system or free sound collections. You need be focusing on showing what the game can do, not what it will look like. (Please note: We’re talking about a rapid, team-centric prototype, not a professional vertical slice for a potential investor.)
This may seem counter-intuitive to the “ways to avoid burnout” post, but prototypes are meant to be rapidly made over a short period of time. Work on it and only it until completed. Depending on how much custom stuff your game has, aim to finish between 24 hours and a week. In fact, as an interesting side note, think of the prototype of your game of as the entry into a 24-hour Game Jam. So, think on that level, you must create your prototype super-quick because someone else is going to judge it really soon.
Once your Prototype is finished, use it to create the rest of your game. Your systems and features will already be made. All you need to do is transport them to your actual game project. With that completed, you’ll find that creation of your Alpha will be significantly easier.