In the game development world, a lot of beginners have a rather intense hatred for game prototyping. After all, it usually produces a rushed product that’s full of bugs and crappy graphics – a far cry from the uber-sweet, kill-yo-kitten-with-an-axe MMORPG system that they had in mind with all the coolest items, characters and groundbreaking gameplay that they had envisioned themselves making instead.
But the fact remains that prototyping is one of the best ways to quickly – and efficiently – test out game concepts and see which ones work. Not every idea that emerges from your noggin is going to be a gem. In fact, it may well turn out that very few of them will be any good at all. Some developers make dozens of quick game prototypes before settling on a project that they like, and the end product usually reflects all of the pre-work that went into it.
In this piece, you’ll be taken step-by-step through a typical prototyping process which, by the end of a few hours, will hopefully be yielding a playable and interesting game.
Starting point: game concept and springboarding
Development time so far: 0 minutes
It’s a bit difficult to suggest how one should start on any given prototype. Some people like to engage in freewriting/thinking exercises, clawing all sorts of random ideas from the back of their heads and putting it onto paper so that they can get a better look at their own thought processes. Others favour looking at good and interesting games for inspiration. The remainder probably just sit in a dark room and think really, really hard about stuff for a while.
I favour the idea of what I like to oh-so-snobbishly call “consistent prototyping” – I constantly have a little notepad doccie open on my desktop that I’ll jot random words and ideas into whenever something that I’ve seen, heard or done inspires some game development thought processes deep inside my crazy little noggin.
These ideas are rarely put to use right away: in fact, I like to mature them like a good wine. They could sit inside that document for weeks, months – even years – without me paying them the slightest bit of attention. Then, when I feel like getting a cool prototype out, I look to this mess of notes for inspiration.
In this case, I have a little note somewhere that basically goes along the lines of “Make a typing tutor that’s actually FUN”. I scribbled this a short while back after reviewing a few tutor programs for an SACMarticle.
Somewhere further up the page there’s a bit of a scrawl entitled “Overkill. Hideously long powerups/big explosions/ridiculous stuff”. This probably stemmed from a discussion about Dragonball Z or something.
A little to the side is a note that simply says “Ninjas”. I can’t remember where this comes from, but it sounds cool anyway.
These concepts have inspired me to create an over-the-top typing trainer that has the player fight enemies using a series of cool “powerups” – in proud anime tradition, the effectiveness of these powerups is determined exclusively by how long it takes to charge up, and how impressive the attack’s name sounds when your character belts it out. It’s up to you to make sure that the attack name is delivered properly.
Now to lay down some groundworks. Your sources of inspiration may differ, but I’d suggest trying this method as it often gives me fairly nice results and ideas.
Groundworks and further brainstorming
Development time so far: 5 minutes
Because I want to prototype, I want to use a program that I’m not only comfortable with, but can truly do some rapid game creation with. With prototyping, speed is essential. Not in the way that you should totally stress out about racing against the clock – it’s a dev session, not a competition – but you should constantly be on the look-out for shortcuts and ways to streamline your dev process to make sure that the raw ideas get onto the screen with as little fuss as possible.
In this case, I’m opting to use Game Maker. For me, it’s one of the best general-purpose rapid development toolkits out there. I could work with another dev kit, sure: I’d probably get the same results after hacking out some code in Delphi or Flash. But neither of those tools could churn out my proto even half as quickly as GM would. In the average prototyping environment, the question of “What can generate this stuff the fastest?” is the crux of your development approach.
After firing up GM, I gave some thought to a few of the basic actors and objects that I’d need to put into my game environment. I’d obviously need my ninja avatar so that the player has something to control. I’d also need to create a few enemies, some basic building blocks for the level environment and one or two simple projectiles (shurikens, fireballs, etc) so that I have a meaningful combat experience.
The aforementioned objects need not be complex in any way: in fact, simple coloured squares will usually suffice as a graphical representation, as you can always overlay them with a nicer skin later. If you really want to be fancier or quirkier, rather don’t generate overly complicated sprites on your own: grab a free tileset from the Internet, or recycle sprites from your previous projects. I, for one, have a tendency to repeatedly use friends’ heads as sprites in my own projects (much to their dismay), and have a special secret folder full of embarrassing pictures that I use at will for my in-game characters.
After creating these placeholder sprites, I needed to think about the game a bit more and what I wanted to do to make it fun and different. The core issue in this case was avoiding the pitfalls common to many typing tutor games: superficial interaction and a basic “cinema” experience that was dictated by nothing but the player’s ability to type words on the screen.
I wanted action. I wanted running and jumping and dodging and strategising that only partially involved throwing text onto the screen. I decided that the best way to do this was to have the game play like a standard run-and-jump platformer, with the exception that the “attack” button would actually be a trigger requiring the player to type out a random phrase to charge up the attack. If the player was fast (or daring), they’d be able to type the entire phrase and release a fully-powered attack without getting hit by an enemy shuriken. Players who erred on the side of caution (or were simply slower typists) could type part of the phrase, then “break out” of the attack and dodge enemy projectiles while releasing a slightly less powerful attack of their own. Neato, right? Well, hopefully.
Laying down the rules
Development time so far: 1 hour 30 minutes
The first work that you’re going to do with any prototype is a load of grunt chores (unless you have the foresight to save code stubs for generic projects). Since my game is essentially going to be an action platformer, I’m going to have to make sure that my character is able to run, jump, fall and collide properly with walls before I continue.
Unfortunately, I’ve always hated Game Maker for its default collision code when it comes to platforming. This is a chink in its armour which seems to have survived through seven major iterations of the product, and I really wish that it would be polished up. Like, right-effing-now. If it wasn’t for the fact that GM streamlines so many other processes, I would drop the tool right here and continue with something else for this prototyping. But given the fact that I’ll need it later for other chores, I decided to bite the bullet and code my own bare-bones collision system.
This took a lot longer than I wanted (time that shouldn’t have been wasted, I’ll confess), but I eventually got the framework down and I now have a functional game where I can wander about and do all the standard platform-ish things.
Now I’ll be moving on to the heart of the matter: the typing interface. There’re a lot of ideas that can be implemented, but what I really want is to figure out which ideas will be most important for my prototype – those which embody the core of the game – and get those into place. The rest can come later if it turns out that this is a nice idea.
Development time so far: 3 hours 50 minutes
So, a few hours have passed. The ground rules for the game have been laid down, some sandwiches have been eaten and me and two other devs have gathered to check each other’s protos, comment on the results and suggest ideas for expansion.
This part of the project is what could be considered the crux of the prototyping process: deciding which ideas are going to go into the game first. Considering the time frame that we’ve enforced upon ourselves, what we really want to do is get a good balance of things which can (A) be implemented quickly and (B) enhance the game for maximum fun.
At the moment, my chat with the others has left me with a whole host of fantastic ideas, all of which I want to put into the proto. Not all of these can be implemented quickly enough, so I need to figure out which ones are the most important.
It has been suggested that the enemies, for example, have various attacks: some do direct damage to you, some increase the amount of words you have to type to pull off an attack, others can screw up your letters or have you type more abstract symbols.
Conversely, there could be powerups available to give you enhanced abilities temporarily. The idea was that when you picked these up, they would require you to type in a key phrase and trigger some extra effect when done properly.
Then there was the concept of having a typing duel with bosses – that is, typing words at a constant rate and trying to “outspeed” the boss enemy’s own typing to deal damage or avoid death.
These and a lot more concepts abound, but I’ve decided for now to stick to one basic enemy type (perhaps with variants that have more / less health and slightly different AI), a single powerup type and an additional medpack pickup which will require the player to “freestyle” and gain health with a bit of fun button-mashing.
An additional dynamic may come in with the boss character, but we’ll have to see how the proto develops in the meantime. I’ll move on to implement these extra features now, as well as engage in some level design.
The final package
Development time so far: 6 hours 10 minutes
The levels are done, the core mechanics are in place and I’ve effectively got myself a fully-playable game prototype to fiddle about with. This is where the learning comes in: has this game risen to my expectations, and have I met my original goals? If not, can the game be changed to meet said goals, or is it best to discard this proto in favour of another project?
In the case of my belovedly-named Ninja Typist, I feel that I have achieved my original goals to a certain extent. While it’s not even remotely perfect, the basic level design has already shown me the potential for integrating action, puzzles and typing in a meaningful and engaging way for the player. Not only was there a suitable amount of running and jumping, but the game started incorporating elements of planning that I didn’t even anticipate: I found myself hiding in corners to raise a typed-out shield before charging into the midst of enemies, and made use of my ultra type-blast attack to strategically take out enemies through walls or in critical positions before diving in to clean up the rest.
The game was becoming remarkably cerebral and multi-dimensional even with the crude mechanics in place, and a player’s typing speed became only part of the experience: they still needed to depend on their reflexes, cunning and careful use of the resources given to them.
At this stage, I would be able to flesh out a few more ideas, get a design document going and maybe even have a shot at making a proper game using this core concept (as it stands, it would be generous to label the gameplay as “average”).
And of course, the true beauty lies in the fact that this prototype can be discarded entirely: because it only took a few hours to build, I can abandon it with a clean conscience and start from scratch on a more refined system with a more carefully dictated set of goals and features. Therein lies the strength of prototyping! The ability to create an easily discardable system with the potential to produce some striking ideas as opposed to wasting time on a full-on project that has the potential to break is something that can be of use to any game developer.
I learned a lot from this prototype: not only did it allow me to flex my game development muscles, but it actually yielded a playable result which I could show to people. I now also have a neat concept for a future game. All of this started and finished within a lazy Sunday afternoon.
EXTRA: adding a few bells and whistles
Prototyping is typically a private matter – you know, the sort of stuff that you do alone in your room when you think that nobody is looking. But if you’re an active member in your local game development community, then it sometimes pays to show these protos to some other developers for some additional feedback.
Now, while prototypes should essentially be simple and quick, I tend to add a few extra features to my work before showing it to anybody else. I justify this decision with the argument that more people are likely to play through your game – and offer feedback – if you polish it just enough to make it worth their time and interest. Ideally, testers should look past a clumsy implementation and persevere with your project to give it the attention it deserves, but even enthusiastic developers are only human and they’ll generally give your game more attention if it’s friendly and entertaining.
You don’t need to add much. In fact, you shouldn’t (hey, it’s still a prototype, after all). But you can focus on one or two features that you think will enhance the fun or accessibility of your project enough to garner some attention.
I eventually decided to add two features to my project: first, I threw in a few tutorial stages. They aren’t great (in fact, “wall of text” comes to mind when introducing players to the controls) but they do a much better job of familiarising the player with key concepts than simple “what-does-this-button-do” exploration would.
I also added sound to the game. This was a purely aesthetic choice and didn’t take too much effort: I had fun making the noises, and I’m hoping that anybody who plays the prototype will have fun listening to them.
The final prototype is available for download over here. Play it while bearing in mind the lessons of this article: most importantly, note its simplicity and incredible crappiness. You don’t have to go overboard to have something playable and intriguing. Ninja Typist is a crude game that’s far from complete in any respect, but it focuses on the core gameplay and gives players a taste of what can be done with a basic idea. Great for showing people that you’re actually doing stuff, and it grants an opportunity for basic gameplay feedback.
Whether or not you give it a whirl, this little dev diary has hopefully given you some good ideas with regards to the prototyping process. If you have even just an hour or two to kill one afternoon, give prototyping a shot: it’s fun, it’s easy and it will always be a win-win scenario. At worst, you’ll hit a dud and lose a little bit of spare time. Ideally, however, you’ll stumble upon the next big game idea and prime yourself for a full-scale project.