Prototyping

Prototyping is done to quickly create a working model of your idea to see if it works. This can save you a lot of time if you find your great idea on paper does not work in actual practice. It can also communicate ideas much faster than written concepts.

You could of course jump to the next chapter on Documentation which covers getting your ideas down first before starting to make prototypes. Generally speaking you will find that you will bounce between noting ideas down and making prototypes constantly during this process. I’ve decided to add Prototyping first though cos when it comes down to it there is no point spending time on documentation and planning when the base idea isn’t as good as you think it is.

Prototyping will start to get your hands dirty. You won’t necessarily need to learn how to create 3D assets, animation, sound or anything like that just yet as we can use the ridiculous amount of resources out there already, or even very simple building blocks and a bit of imagination. It’s amazing what you can do with a couple of cubes and a keyboard. You might even find that that is the perfect version of your game!

You will probably need to use something to create a good idea of what you are trying to do in a minimum state as quickly and easily as possible. This could be a ready made game engine (Unreal, Unity, Godot, GameMaker, RPGMaker etc) or even some actual pen and paper/cardboard versions of the game! When I say prototype the fastest way in any way you can, then I really mean any way you can. If you are making an online card game, then make actual cards and play it for example.

If you must create a digital version, some game engines have templates ready to go or assets on their respective stores that aren't that expensive. Unreal and Unity have a lot of common gametypes available as templates included in the base install like a first person shooter, top down shooter etc.

If you can program (or are willing to learn) then you could program in the aforementioned game engines, or use a node based programming method like Unreal Engine blueprints, or similar tools in Unity. Other game engines are available that may suit your game better like GameMaker or RPGMaker if that is the kind of experience you are going for. Do some research and find what will get your experience up and running as soon as possible to find what core elements work and what doesn’t.

As mentioned in the Going the Distance chapter, I recommend taking the time to learn how to develop games properly by completing small, even tiny, projects first before jumping into larger ones. I know you will want to jump straight into your dream game but trust me when I say that it is hard and taking the time now to build up your skills at an achievable rate will allow you to not only develop your skills such as programming or 3D modelling but will allow you to continue developing those skills with a lot less frustration. It will save you a TON of time down the track.

The best place to start at this stage is the very fundamentals that make your game and nothing more. The basic building block or blocks such as a car, a character, a puzzle or whatever else you have in mind. Every game is different however, but if your core gameplay is not fun or interesting then it will be much easier to lose your audience to the billion other apps or games that are out there vying for their attention. Do not let them win! If you can make the prototype fun, then you are already onto a good thing. Once again, every element of your game needs to be as good as possible (within the realms of being realistic of course) to make sure it is a good experience all round. The gameplay is possibly the most important of all of them when it comes to making an actual game, so spend the time needed to make it awesome!

Note that your user will be using this base interaction for the entire game. If it is a racing game and your handling is not enjoyable, then players probably won’t stick it out to watch your amazing story. If it is a shooter and your character runs too slowly or not very intuitively then the player will get frustrated very quickly, possibly angry, furious even. And start attacking friends and family. Don’t be responsible for the death of a loved one. Make sure your base game mechanic is fun and highly replayable. These are only a couple of easy examples of how the base gameplay can seriously affect the user experience. Don’t mess it up!

No pressure though. :)

This chapter describes the general process you can use to develop a prototype that allows you to move forward in the shortest amount of time. In a way this is one of the final stages of development where you can make mistakes, evolve and grow your idea to its full potential. After this stage you have to bite the bullet and just run with the decisions you have made, or start from scratch, so more time finding the better solution now is much better than finding an even better solution down the track and having to redo a lot, or even everything, all over again...chances are you won’t have the time or resources to do so.

The Iteration Mentality

Go into the prototyping stage with the intention of failing. This will allow you to go through a fast iteration process rather than hanging onto ideas that you hold too close and are too stubborn to let go of. Even if you do find the ‘perfect’ version...make sure to keep your options open for something that is even more perfect. If you are happy with a result however, quickly move onto the next item. Basically, always keep moving forward.

First, start to build your core idea. These are the things that fulfil your original goal and nothing more. Only complete them to the point where they get the feel for it across. You do not necessarily want a perfect prototype that represents the final game. You simply want a rough one that has room for improvement, for growth and possibly feedback from others. This could be character movement and attack practicing on dummies, a car on a track, a spaceship in an asteroid field, the list is endless, but each item is very small!

Once done, start expanding on this with variations or tweaks to the basic mechanic. Find the best way to achieve your goal. Create a simple experience where you want to keep playing over and over (because you will be playing this over and over). What happens if the car turns faster, can drift, can jump? Is the chosen camera angle the best one? What happens if it was first person or third person? Could you make a quick prototype with the current prototype to find out?

It is important to push out of your comfort zone to make sure you approach your goal from every angle. Make sure you try to achieve your goal as best you can from every possible angle. Sometimes the best ideas come from random developments. Make iterations on your core gameplay with these more unique ideas and see if any of them stick. If not, you’ve learned what doesn’t work, which is just as useful as when it does. Some of these ideas might lead to other ideas that do work however.

What happens if the car is actually a rhinoceros? Can rhinos drift? A rhino race sounds kind of interesting actually, what happens if I have them headbutt each other off the track? OK, that’s much more fun! That achieves my goal better. I’m glad I thought of racing rhinos. Car races are so yesterday!

All that said, it is very easy to continue to make prototypes for the rest of your life. Decide on how long and/or how many iterations of your ideas you will make before moving onto the next stage of the development process. Setting deadlines and reasonable timelines for your processes is important for moving forward. It’s not the end of the world if you don’t make the perfect game, if anything it is actually the opposite. Each game you complete is invaluable for the total experience. There is always room for patches, sequels, or DLC! Especially in this day and age (unfortunately).

There are generally two approaches to creating things in a reasonable timeline. Set deadlines or limit expansion. Setting deadlines is where you set a specific date and have that particular element of the game done, no matter what (give or take a day maybe). This is a good skill to have. If you ever want to get into the game biz, keeping to deadlines is very important. Limiting expansion has a little more flexibility. Once you have a gameplay element working you are allowed a maximum of X amount of time (two days for example) to improve it. This allows you the time to find a good experience, refine it to be better or develop/expand on the idea, but continue to move forward.

Pseudocoding

Pseudo coding is the true beginning of your journey into insanity...I mean, the amazing fun world of programming and game development! Yay!

Pseudo coding is a term used for creating your native language version of your code that is easy to understand. This lays down the framework to your program structure (not your programming), saves time with notation and also allows you to start thinking about the practical application of your game and overall development.

The programming side would look significantly different to pseudocode and much harder to read (unless you are fluent in C#). Using the pseudo as comments in your code also helps with looking at the code much later in the development cycle. Notation is actually extremely important for when future you, and others, need to look at your code. I can guarantee that you will look at your code in the future and have no idea who wrote it, only to remember it was you, and then future you will get very frustrated at current you for not taking the time to make the code easier to read and find what they need at the time. This is the closest thing to time travel you will ever get.

"Always code as if the guy maintaining your code is a violent psychopath who knows where you live. " - Martin Golding.

Another benefit of this stage is that for each idea that needs to happen a lot can be created as a function, or group of instructions to carry out that specific task, rather than writing it over and over. If you need to expand on or improve that particular task you can easily modify the function, rather than try to jam some extra lines into an increasingly messy and linear process. We will use OOP, or object oriented programming, which allows code to be run from different locations and at different times relatively easily. You can reuse the code over and over again, rather than rewriting the same tasks all the time.

If a lot of this doesn’t make much sense at the moment that's fine. As noted this is a bare bones introduction to programming. Think of it like skimming over a page in a book to get the gist of what’s going on, rather than understanding all the details.

Programming

Making little tests of each individual gameplay element as a unique unit will allow you to understand the basics of that particular game dynamic. It also allows you to use that code in the bigger picture if it fits nicely as it’s own unit, as well as be able to utilise that in other projects in the future. Stripping away all the external junk makes sure you focus on the goal at hand, and making sure it works the way you want.

This stage is mostly programming using basic blocks or assets. A car racing game is a box for the car, some cylinders for the wheels (optional) and a flat plane for the ground. A third person shooter can be a long upright rectangle moving around more big boxes. A puzzle game is a bunch of squares with simple textures on them. Whatever makes the basics work in the shortest amount of time. See how it plays, see how it feels. You should be able to get a feeling for the game element with just the very basics. If this is fun and hints at the idea strongly, then adding the graphics, the colours, sound, music etc. will only make that experience better. But if that first element is not fun or interesting...then you are basically building on a broken idea, and no amount of graphics, story or style will make that game an enjoyable experience after the first 5-10 minutes.

Write down a list of the basic building blocks of your game. The very basics. Each of these are the things you will need to build as test ‘playthings’. These also lay the groundwork for functions as mentioned previously in your game.

Blocking

Once you have your basic gameplay down in a basic environment and you are building a game that requires an actual world space you can start blocking that world space out. This is actually for when you are starting to create levels...but instead of creating your levels with actual assets, you are using basic building blocks for the game play and building the basic ‘flow’ of the game levels. By blocking you are creating the flow only and have no other distractions getting in the way. You are focusing on the game this way, and not relying on shiny to get you by.

Flow is nearly as important as the basic gameplay mechanics when you think about how your game is played. It affects the pacing of the game just as much as how music and the timing between action scenes affects the experience of an adventure or action movie. You can’t have a game that is always action. Players will have heart attacks and it will be your fault. And until your game is making millions you can’t afford to cover everyone's medical bills. You also can’t have a slow paced game all the time. There are of course exceptions to these rules. Short games that are basically a constant thrill ride that makes a player feel super intense, for a short period. Or a cozy game that focuses on relaxation. Once again, it all comes back to your goals.

Blocking is usually for games like 1st or 3rd person games where there is a large environment. Racing or Realtime Strategy games also benefit from this. Any game that has an environment to actually move through. You will want choke points, you want open spaces, you want cover, smooth easy curved areas to the occasional tricky section that is hard to master but improves your chances of an advantage should you pull it off. The thing is it all has to be balanced.

Too many choke points or tricky sections that are too difficult and the player gets frustrated. Too many open areas and the game gets boring. It’s all about balance, pacing, ‘fairness’ and when it comes down to it optimising the experience to be the best it can be.

Blocking out your concepts into a simple environment that displays the gameplay and pacing in action is usually enough to show if the game works as a whole. The main thing to focus on here is the minimum experience that makes it engaging and suits the goals you have laid down from the concepting phase. Get this stage right and the rest is a piece of cake...although I must admit it is a particularly difficult cake to bake, and it takes months to years to do so!

But eating the cake is amazing!

Testing

At this point you should be truly getting a feel for your game. Play your minimalistic, basic game to death, then continue through purgatory and straight past hell. Make any adjustments that might add to the experience, drop the things that don’t, keep the things that do, don’t go overboard. The core experience should be simple...this introduces the easy to play element. The fine details add the hard to master aspect and can be added later.

One thing to consider is do you get bored playing it over and over? If the answer is no then you are on the right track. If the answer is yes, then maybe continue your iterations on gameplay until you get something that you don’t get bored of playing or adjust the blocking to improve the pacing and flow to something that keeps you more interested for longer periods of time. This is especially true for games that are repeat games like fighters or racers. Players will play the same thing over and over again. If it is a one off story, then this is less important as most players will only experience the flow/environment once or twice...but even so, if you can play it several times through...even on a game that most would play through once, that is a good sign that it is a good experience.

You should always consider what a player's perspective is. It is very easy to think that a level is too easy because you've played it countless times. You may understand how to do a puzzle but a player may not. Looking at your experience as both the developer and the player will be very important to get the end result in the best shape it can be.

Once you are quite happy with it start offering people you know to play it...but take whatever they say as a grain of salt. Friends, unless they are particularly straightforward, will not really tell you the constructive criticism you need to improve.

Go to Game Jams or networking events where people of like mind meet up. Find a local gaming group that you could put your game through it’s paces. Use discord or find a community and offer a select few access to your game, or all of them, depending on how much feedback you want to get.

Watching people interact with your game is very important. Take a note pad. Write down notes. See what stages they seem to get along well with, definitely make sure you write down what issues or areas they seem to struggle through (at least where they shouldn’t be struggling). Make sure you modify your game experience to clear these issues up.

You will probably find that a large portion of players have issues with the same area...and therefore this is your priority on your next iteration. Once you get all areas to a satisfactory level you can then move onto the next phase.

Once done, take that feedback seriously by writing all of the feedback in one location, the good and the bad, and try to improve on your game. As nice as it would be to not have to answer to the droves of gamers out there, they will be your worst critic so you might as well get used to the fact you need to cater, at least in part, to what their wishes may be. They are the ones who are going to, hopefully, buy your game after all. Not all of us have the luxury of completely doing what we want and how we want it. If you keep your gamers and community happy, so too will your bank account...in theory.

Once you have made any changes to the game, play it to death once again, send it for another round of testing with players and get their feedback on the improvements. Once that levels out some, open up your player base to a new group and see what they think and repeat the process until you are happy with the results balancing between the game you want to create and the feedback you receive.

Your game will never be perfect. But it sure as hell can be improved :)

Note that a lot of ‘players’ do not understand how to envision what you do with your creation. You may play your barebones game and see the finished game in your mind's eye. You could even feel the end result while playing a simpler version. Others do not have your insight however. If anything it is quite opposite. Keep this in mind when you are getting your feedback. Don’t be surprised if you get comments like ‘There’s no colour!’ or ‘Why does the character look like a box that you added as a basic primitive from Unity?’. Be careful with who you ask to test, or at least, give them as much warning as possible with what they are there for, and then take their feedback as you see fit.

They may not be able to ‘get it’ like you do, but you will usually find that at least some of the feedback will be useful and open up your mind to things you hadn’t thought of before.

If you need to convince someone your idea is amazing, then make sure it checks all of the boxes to make it do so from a perspective that has no clue what you have in mind...basically, if you have to explain it, it’s not good enough yet.

Feature Creep

Watch out for feature creep, even at this early stage. A simple idea added now may end up being a complete month or more added to your development time with all aspects considered like modelling, texturing, animation, sound effects, programming, debugging the new feature itself and then debugging in regards to its interactions with the game. The prototyping and blocking stage is not a time for feature creep unless it is an element that is fundamental to achieving the game development goals significantly. Prototyping is focused on the development of the minimum elements to get a game that fulfills the goals outlined in the concepting stage. Once the minimum is done, maybe then you can test the waters for some of the better ideas you have in your Feature creep section. But only at your own peril!

Adding cool ideas for cool ideas sake is not an option at this stage. Or ever, actually. Adding ideas that make the game achieve its goal better however is another matter. Most of the skill here is realising which is which.

My main argument for adding a feature into a game in comparison to leaving it out for later is simply the following : Value to the game * time needed = Worthwhile?

The catch, however, is understanding how much ‘significant’ is. Think practically and logically. If you are not attached to your ideas too much this should be easy. If you are attached to your ideas then good luck to you!

If you find it difficult to not add every single ‘fantastic’ idea that you have then I recommend the following to try and temper your enthusiasm. Keep all your key ideas in a single location. Perhaps make a board for ‘Features’ in Trello so you can easily arrange them by order of importance and/or awesomeness. You should do this anyway. Once you have your great idea written down, do not implement it. Feel free to think the core idea through but don’t worry about the details. Then sleep on it. For a few days at least. If you can come back to this idea and still feel it should be at the top of your list then it can stay, but you will probably find that in many cases you will be able to send it down the list, perhaps even get rid of it completely.

You actually want to find reasons to reduce your project size. You do not want to add all the features you can think of to make your game the best thing in the universe. I can pretty much guarantee you will fail if you go into a game with that mentality. This comes down to your limitations. As a small indie developer, you probably do not have the luxury of adding whatever you like depending on your mood that day.

The reality is that you want to make a game that makes your project achievable, focused and to the point. If your game is a success, then and only then can you look at your extended feature list with serious intent as downloadable content, expansions or simply updates to your game...and everybody loves free updates to your game. So utilise the nature of the online universe and keep it tight and achievable, and then focus on your feature creep elements when you know you are onto a good thing after you have released your core game.