Now that the other parts are out of the way, and you have an idea, we need to see this idea in action to make sense of it. There are many reasons for a prototype, least of which is to prove that the core [gameplay] concept is feasible. Also, depending on how complex your [game] idea is, there may be a need to do multiple prototypes, which may be totally independent from one another. Let’s use an example.
Example 1: Complex
Say you want to make a MMORPG, like we were doing with Project Wish. A MMORPG is made up of a ton of elements. Many of these elements individually should be prototyped in order to make sure they are going to operate the way you want, or look the way you want.
A) Say you pick a particular art style, or type of animation, which is not common; you would want to at least put together a small prototype with your graphics engine that showed off these things. It should include enough of the elements to be worth the effort, and should meet some specific requirements which you set beforehand.
B) That’s one prototype for a MMORPG. Another could be for the mathematics. Say you were making a skill-based game, which utilized a skill tree. You would want to design these on paper (or in excel) and then start playing with the number to prove the system worked. This one item could be broken down into a bunch of smaller prototypes, which in this case could also be used as balancers (ie. tweaking skill values to balance them). One of the branched prototypes could be a combat simulator which only used numbers to show the outcome.
C) Yet another prototype for a MMORPG could involve server elements. Say you had decided to make a zoneless game. You need to choose (or contruct) an algorithm which will spatially partition your PC’s, NPC’s, items, game objects, etc. Before you went ahead and wrote the entire system, you would want to prototype it on a small scale with some sample data. You will then want to simulate the movement and interactions that can take place that may or may not effect how they are partitioned.
Those are just a few examples of some things that you might want to prototype when developing a MMORPG. There are many other possible ones.
Example 2: Simple
I will use the game I am working on for this example. I had an idea for a sandbox-style game that used physics to control some squares. The idea I had put this into 2d space. That made things considerably easier. My idea for the movement was very specific, and as I described it to a couple friends, they weren’t quite understanding what I was seeing in my mind. This was a perfect scenario for a prototype. I needed a way to show them exactly what it was that I was seeing, and I also wanted to prove that the type of movement that I was envisioning didn’t look stupid.
With a simple 2d game, a prototype can turn into your game as you go, or at least provide the building blocks to do so. The same can go for a 3d game, but it doesn’t have to. I doesn’t have to with a 2d game either, but for the most part, 2d games are much simpler, so protyping an idea could already be taking you a good part of the way toward the idea.
Showing Off (the different purposes of a prototype)
I mentioned this above, and it deserves its own section. “Showing off” can be many different things for different games, but I’ll make it simple. You could be using a prototype to pitch the idea to a prospective publisher. This is one way to show it off. You could also use it for recruiting people, to show them the idea and get them interested in it. Another possibility is that you already have a team, and you just want to show to them to show your progress, or prove the feasibility of some feature. As you can see, prototypes can serve many purposes, so make sure you know which one(s) you are aiming for.
Choosing your engine/toolset
Just like the examples above, there are varying levels of complexities that a prototype can be used for. It may make sense to make sure that you prototype using the same engine/toolset that you want to make your game with. This is very common.
It is equally common, however, for someone to use a very simple engine/toolset to prototype an idea, and then once the prototype has served its purpose, move on to something else. You need to make that decision based on the scope of your idea/game/project and also what resources you have available. This step can make or break your game, so don’t make it lightly. If you choose the wrong tool and end up wasting time, you can burn yourself out or look stupid in front of other team members, among other things. The outcome of this could be a failed project and a game that never sees the light of day.
Let’s look at the scenarios based on our examples. In example 1, say you are an individual with the idea(s). Now you want to recruit people to help you make it. It is very hard to do that based on an idea alone. Even a GDD (game design document) might not make a difference. What I commonly see is the catch-22 of recruiting:
You can’t recruit without something to show and you can’t show something until you have recruited people to help.
In programming terms, that is an infinite loop. It’s an unfortunate side-effect of having ideas while having no skills. The fix for this is to get skills and dive in. Trust me, you can know nothing and still learn *some* sort of tool and be useful.
The good news is that the engines/toolsets out there now are very easy to use. Technology has really come a LONG ways since the beginning of the modern video game. Where programming was once and absolute requirement, there are now ready-made game engines that do (almost) all of the work for you. There will never be a magic bullet, but in the case of a prototype, you can be simple and get the job done.
With a simple game, like example 2, it’s not so hard, but with either, you still do need to know something more than how to come up with an idea. Most game designers know some form of scripting, or some way to tweak the games/engines that programmers give them. This might just be editing text files, which is a common way to manipulate skill-trees in a MUD. They will rarely have some fancy GUI. If you need skills, there are plenty of ways to get them, and they are all free. Try the internet, which I can assume you know how to do if you are reading this. I will have a links page on here that can get you started in the right direction.
With example 1, you need to pick which type of prototype you will be working on, or if there are multiple, who is working on what. What are the goals and timelines of each. What technologies are going to be used for each. In example 2, it is a much smaller task, and can easily be managed by one individual. I will post later this month about my experiences prototyping my game by myself.
The next post will contain a list of your options. I would have put it in this post, but it is already fairly long as it is.
