Skip to content

Creative Phases in Game Development: Why release a Prototype?

Featured Image Creative Phases in Game Development

Thus far, I have created my games following a game design document rather strictly. It is time to shake things up – and release the Wildsilver prototype way ahead of the full game. Isn’t player feedback the most valuable when there is actually time to incorporate it?

Creativity can take many forms. It thrives under conditions that differ from person to person. And thus, there are many approaches to creative work. One person may find it invigorating to work at their laptop in a noisy café. They may say that all the hustle and bustle around inspires new ideas. Another, however, won’t be able to concentrate at all in such an environment.

Working in a crowded café isn’t for everyone.

Not only external factors matter, though. Some people create a regular mess while working on their project and won’t do anything more than ‘sweeping it under the rug’ when they wrap up. Developing a game, they create database items and variables that end up unused, but still remain in the code. Why bother finding and removing such elements if nobody is going to see the internal structure anyway? It would be a waste of time!

Other developers try to keep their project as clean as possible, and be it for the sake of it. This kind of perfectionism is a blessing and a curse: It can lead to a more polished product, but can also make the process of getting there much harder.

A perfectionist game developer may be inclined to constantly re-think methods and change elements that are already working just fine, but ‘need’ to follow exactly the same rules as similar elements. Sometimes this requires the developer to go through the whole project again and make ‘internal cosmetic changes’ that no player will ever experience.

Is this the most efficient way of handling it?

And after he’s done updating the project, he may still spend an hour wondering whether there would have been an even more efficient alternative to the code he has just copypasted a hundred times.

Not without my GDD!

There has always been a phase of thorough planning before ‘actually’ working on Game Master, Game Master Plus and LV99: Final Fortress. I mentioned before (in this article) that I had prepared a 60-page game design document (GDD) for Game Master Plus before RPG Maker MV was released. For LV99: Final Fortress, the GDD was much shorter, but still, I spent a lot of time brooding over some hand-written notes concerning the battle mechanics (which you can see on my Instagram channel).

Game Master Plus GDD

Having a detailed plan, but also the readiness to deviate from it and make major changes even midway through the project led to many phases of revision. This included monotonous adjustments to code, for example due to database IDs being altered with their references not being updated automatically. While a lot can be accomplished with search & replace and regular expressions in JSON files, many things had to be taken care of at least semi-manually. But no matter how time-consuming the cleanup, my perfectionist mind wouldn’t rest until everything was well-structured again, even, as I said, the things no player could possibly notice.

All Work and no Play

In addition to instances of revision that could have been avoided with a more iterative approach to game design, there’s another problem with planning everything and then creating it in ‘one go’: Strictly following a plan starts getting old after a certain time. Fun is for the players, one might say, the developer has work. But as a creative person, keeping up your motivation is much easier when there’s actually some creativity involved. On rare occasions, you will sit back and think about a specific problem again. Or make some adjustments to game elements on the fly. But most of the time, you have the GDD and the game itself open on separate monitors, copypasting texts and values or setting up events according to something that is basically a blueprint. It is straight-forward execution instead of mysterious-to-oneself artistic expression. In other words: It’s work that I would gladly leave to some artificial intelligence if it was possible.

The blind Painter

There’s not only the creative aspect missing if you’re working non-stop bringing a vision to life. There is also the problem of accurately evaluating the game. A vision is a very unclear picture of the final product. Up until the very last weeks of development, you basically have no idea what it actually is that you are building. You can’t be sure if the finished game will actually work in terms of fun and player motivation. In your mind, it sure does. You have been very careful in the planning process. You have been following all the game design rules. And still, it remains theory until you playtest the game from start to end.

Screenshot from Hades, the newest game made by Supergiant Games (who also made Bastion, Transistor and Pyre). The developers said something about the final phase of designing a game in this Noclip documentary.

It is the same with many other products of art: You only really know what you are creating shortly before the release. This is the time I, personally, enjoy the most. With the product basically done, you spend your time fine-tuning specific elements with a clear idea what it will accomplish. Sometimes it makes a big impact and changes the whole experience. Sometimes it is just a detail that one or two people may notice. (You might still spend a day on it!) This phase exists for music — songs/pieces and albums —, for literature, paintings, sculptures, movies and so on.

A Game can have a Demo. And it should!

A game is not a novel, however, which should only be read once it’s finished and which should never be changed except for fixing some typos where they are spotted. It’s not a piece of music, either, which can’t be put out there with instruments or melodies missing. It’s not a film or a painting with some scenes or colours missing.

Games are easily patchable nowadays, and with continuous updates, you can extend the ‘tweaking phase’. Even chunks of content can be published after release. It makes sense from a marketing perspective as well, since it gives you a good reason to talk about your game again. Players are accustomed to patches and expansions, and while some would like to return to the ‘good old days’ where games were released as the definitive edition, so to speak, others actually love it when a game they enjoyed receives a content update, especially if it’s for free. It reignited their excitement. And so, it’s up to you, really, if you want to release your game one way or the other.

You need to be careful, though: The goal should still be to deliver a viable product with the release version. Do not expect players to return to your game at a later point! Most of them have a whole stack or digital library of other games to play. Therefore, the content you absolutely want them to see should be in version 1.0.0.

The Wildsilver Prototype

With the release of RPG Maker MZ, I began working on my next title:

The Wildsilver logo.

While the approach to game development that I had taken thus far seemed to make sense and fit my personality as a developer (arguably an important factor when you work alone), my Wildsilver GDD and many additional notes convinced me that this project will take even longer than Game Master Plus and will have even more content — content, I thought, which maybe should be tested thoroughly in an MVP (minimum viable product) or prototype before actually committing to create the full game with all the story stuff (cutscenes, NPCs, quests etc.).

And so, I decided to try something completely new with Wildsilver.

With this project, I am going to involve the community as early as possible. There will be a prototype of the game, released for everyone to play. It will include all battle-related elements: skills, items, equipment and enemies. You can see some of it on my Instagram channel already! There will be no story, no puzzles and no quests, and I’m not sure yet which of the maps, if any, will be present in the final game. Still, this approach ensures that the game systems are actually functional — and, more importantly, fun! A pre-release version of the game also allows me to spread out the creative phases over a longer period of time, while meaningful changes to the game, based not on intuition, but on player feedback, are always possible.

I hope for this prototype to be popular with different player groups who will provide valuable feedback. Feedback that I can use to create an awesome game. I also hope that this approach is effective in reaching a broader audience.

Just like before, this sounds great in theory. Let us see if it is in practice!


What do you think: Would you like more games to release prototypes before the actual release and be part of the development? Or do you prefer to be surprised with the full game and go into it as blind as possible, maybe even avoiding any trailers or reviews?

Leave a Reply

Your email address will not be published. Required fields are marked *