In this article I’m going to try and describe how I take my game design sketches into the next stage, which is prototyping.
In my previous article I described my approach for designing games. If you didn’t read it already, I would suggest you should read it because I am going to refer to it throughout this article.
After completing my designing stage and having a “worthy” design to work with, I’m moving to the next stage, which is making a proof-of-concept for my idea. I consider this step a crucial one because no matter how good you are with simulating your game-play in your head or on paper, a prototype would give you a way better understanding of how your game will be played and whether it is fun or not.
I think an important step in developing a game prototype is to establish your goals. Why are you developing this prototype? What are you trying to achieve with it? This is very important in order to assure a time efficient development. In my case, the goals of a prototype are the following:
First, this might be a piece of code that you ultimately throw away. I do not want to spend to much time on a throw-away thing.
It is true that if you don’t throw it away as it proves your game design is good, this code base can become the foundation of your next game. However, most of the times it will not as there are often fewer games than half of the prototypes you usually make, so not taking too much care about your coding style and practices is a good way to go in this case.
In order to work efficiently, it is very important to use tools you are proficient with. Don’t try to learn new tools at the same time with developing game prototypes as it will slow you a lot. You don’t even have to use the same tools as you would use to develop the final game if it comes to that, although it can help a bit if you go that way. In my case, I am proficient with Unity 3D, and I use it for quick game prototyping, as well as final game development, which gives me a slight advantage if I decide to go for the full game implementation.
As I have stated earlier, another think I do is not to worry about coding style. I don’t plan anything, I just get there and start coding. I do not worry about comments, classes, project structure, variable naming, re-usability, anything, I just write pieces of code that will give me the functionality I need in the least amount of time possible. Of course this approach would not work for those just beginning to program as they have to carefully plan everything and think about it, but if you are proficient with writing code this will get you to your goals very fast.
Your ultimate goal is to get a feeling of how your game plays, so I am going for the least amount of content that will get me there. I usually ignore all the meta-game stuff like scoring, lives, achievements and all that and focus strictly on game-play. I use the least amount of content that is usually formed of boxes and other Unity standard objects with no textures and no sounds at all. If I can, I also throw in all sorts of libraries I have developed for older projects or acquired from Unity’s asset store even if I only need 1% of their functionality, the emphasis not being on making an optimal build in terms of size and speed, but to get the game-play done.
Developing a prototype for me is not a one step process though. I always iterate a certain number of times before dropping it or deciding it will be turned into a final game. I use to drop features, add in new features, test a test again until I’m sure there is nothing left to improve. After reaching this stage I either decide to drop it if I’m unsatisfied with the general result or decide to move it forward to the next step, which is not the final game just yet, but…
getting feedback from my friends. No matter how good I am in judging my work, I’m not good enough to decide if my game would be fun for other people so I’m going ahead and ask them about it.
I think many game developers make the mistake of postpone this step for later as they don’t want to show their work to other people, but it is really important to get feedback as soon as possible. That does not mean you shouldn’t get feedback later on during the final game development process, but failing to do this now during the prototyping stage might end up badly with a lot of work and an end result that nobody enjoys but yourself.
This step might require some more work from my side because I have to clean up the visual appearance a bit, use more colors and maybe throw in a bit of lighting just to make the prototype more user friendly as many times I’m not physically near the people that test it to show them what to do.
Another thing you want to consider is educating your friends/testers about what an unfinished game looks like, what is the focus of the test and that they should expect things to not work properly, bugs and other technical issues. They are not used with unfinished products as you are so they might give you a bad feedback for these things while “pretty and perfect” was never the focus of this small application you just built.
If the general feedback about my prototype is bad, I just drop it right away. If however I get mixed feedback as in “if it would have been like this, or something would have been like that” than I just make those changes and send it again for testing. Again if after more iterations people are unsatisfied with it, the best thing for me to do (even if I don’t fee like I want to do it) is to kill the project right away and move on to the next.
Following all the steps ahead I ensure that if I decide to implement the final product of my original design is because I’m sure I like it and at least some people that I trust are liking it.
In a later article I’ll discuss the planning phase for the final development of a game.