Last month I wrote the first in a series of articles, aimed to help budding game developers found their own studios and avoid being developed, trained, integrated, educated and moulded by the mainstream until all creative spark has been utterly extinguished. Last time we looked at ideas and I tried to gently provide some guidance on what is a bad game idea and this time I want to talk about the prototype.
It is important to note that I have not written – How to get funding for a prototype – because it is virtually impossible to secure money before you have something to show. Even if you have the most fantastic idea in the world, you have a much, much better chance of getting somewhere if you have an actual tangible game then if you only have a few scribbles on paper (even if those scribbles do include some amazing concept art and a ton of design work). Now I’m sure that there are people in the world who have managed to get development money for a prototype (and there are grants out there to give you some funding), however these people are few and far between and my view is that you have a much better chance of getting funding for principle development if you have a prototype worked up. So if we assume that you and your mates are going to have to work in the evenings, weekends, during lectures and on the tube we’d better start to look at what you are trying to achieve.
There are two main objectives for the prototype, the first is internal, the second external. Once you have a game design (or even just an idea in your head) it is necessary to start experimenting with bringing that design into the real world. The major challenge with game design is that the end product must be fun to play and sadly it is very easy to take the fun out of the game. You can produce an incredible game that looks stunning, includes an amazing back story, has great game-play mechanics, but if you get the control mechanism wrong the whole thing will collapse before your eyes. Of course in different games different aspects are more important (the story is perhaps less important in Half life than in Mass Effect), but you may not be able to determine this at the start. The point is that until you actually have the game in front of you then you do not necessarily know which areas of the design work, which need tweaking and which are fundamentally flawed. This is where you prototype comes in.
At introversion we loosely adhere to a spiral software engineering paradigm and I would recommend this approach for developing a prototype. The first stage is to sit down and determine the scope of the project. Whether you are aiming to produce one complete level or small area of your game world or perhaps a large area with only some elements included you need to understand and stay focussed on achieving this objective. When you choose the scope you need to try to deal with the most uncertain part of your design, which areas are you least confident in? Which areas are of most importance to the player? Where are the technical challenges? Asking yourself questions like these should help you determine what to include in your prototype and what to leave until later.
Once you have determined the scope I would recommend a quick first pass to get something playable as soon as possible. Try to avoid getting bogged down with detail, at this stage you should not be making the game look great or worrying about implementing your maps perfectly just get something working. Once you have completed your very raw first version, you can then complete a second pass where you start to deal with the next layer of detail and finally (if there is time) you may want to do a final pass for polish.
The above approach provides a good deal of momentum for your initial work. It enables you to tackle the hard problems first and not get caught up in something that might ultimately prove impossible. If you get stuck, try to solve the problem for a couple of days and if you don’t make progress just move onto the next problem and worry about it in the next phase. It’ll inform you about the quality of the game design and enable you to make massive global changes without having to go back and re-do all the detail. The method has served us well in the past and if you have been reading Chris’ subversion development blog you’ll see that he is constantly switching between different aspects of the game whist he proves his design.
I also mentioned that prototypes have an external (secondary) objective and that is to convince someone (publisher, invester, government body etc) to give you some money. If you find yourself in a position to use your prototype in this manner then you need to bear in mind one fact. The publisher will run your exe once and once only. If it doesn’t work, game over. If it is non obvious what he needs to do, game over. If it crashes in the opening few minutes, game over. In short do not expect any slack what so ever – you will not get it. This means you must test your prototype fix the bugs and make 100% sure it will run. This sounds simple, but I once told a developer that I was off to see Microsoft and I would show them his prototype if he could get it to me. He sent me three e-mails each with a different build (he kept fixing last minute bugs) and none of them worked. Sadly that was his chance blown for an XBLA deal. I’m not going to deal with testing in this column, because there are a ton of books out there on the subject, but I leave you with this thought: If Uplink had crashed when Keiron Gillen put it in his PC, where would Introversion be now?
Thanks to Mark Morris of Introversion.
Loading ...
