Welcome to the second in my series of game design tips. In part 1 I focused on tips for getting started; part 2 focuses on prototyping your ideas.
What is Prototyping?
You may have heard a few phrases being tossed around such as 'first playable', 'vertical slice' or 'minimum viable product' but this post focuses on what I consider to be one of the most basic building blocks of game development: prototyping.
The point of prototyping is:
- To build a working demo that explores an idea for a game, mode, level or mechanic
- To test any assumptions you made during your ideas/brainstorming phase
- To discover what is/isn't work and add/remove features where necessary
- To spend less time worrying about efficiency/presentation and more on design flaws
- To come to a decision about whether your design is actually any good
Prototyping should not be limited to the start of your development cycle. Any time you write down an untested gameplay idea you intend to work into your design that idea needs to be prototyped.
Assume Failure
The last bullet point is important: the healthiest approach to game development - I find - is to assume failure. I'm not talking about long term failure - the worry that you may never become a successful game dev (don't worry about that: worry about making good games!) - I'm talking about short term failures that should occur naturally as part of your development cycle.
As human beings we make mistakes and as game designers we get overly excited about ideas we write down on paper. The point of prototyping is to prove if those ideas are actually any good. Although we've been making videogames for decades there are no hard and fast rules as to what makes a good game - 'fun' isn't always the core goal of a game dev project and tastes are ever changing - so prototyping is essential.
Choose a Tool for Prototyping
If you're just getting started and haven't decided what engine to build your game with, try to find a package you feel comfortable in using. I love Unity as it's great for rapid prototyping, has a massive support community and is fun-to-use. If you have an idea for a FPS and are familiar with Unreal or Source then use them instead. Don't worry if you end up switching engines after this stage: the point of prototyping is to prove your core idea.
Start Building
The next step is to start building. If you're just getting started on a brand new idea it may be a while before you can properly test your design as you lay down any required systems. If you already have a game-in-progress and are prototyping a new mode/feature you'll have a good base. If you don't know how to build something - learn: or ask a friend to lend you their skills/advice. Don't be afraid to seek help where required!
Decide How Much To Build
An important question to ask yourself is "how much should I build"? My tip is to build as little as possible. This sounds quite lazy and...it really is! Build the smallest possible set of features that prove your game/mode/mechanic is worth building. Don't be afraid if your code/design is quite messy at this stage or if you have to hack certain features together to make them work: you can polish them up as you decide to move forward with your designs and engine-of-chouce. Build enough to convince yourself the idea is worth building and if you plan to extend your idea try to ensure it will work in more than one scenario.
The amount to build really depends on whatever you're trying to prove: if you're working on a brand new idea try focusing on the 'minimum viable product' - that is the smallest set of features that prove what you're trying to build is worth building. If you're building a new mode or feature then get the basic rules/mechanics down and then playtest/refine.
Separate your 'Wrapper' from your 'Design'
This is an important point (particularly for early prototypes) as it forces you to think about what features actually need to be prototyped. Your 'wrapper' encapsulates your aesthetic decisions for your game and is not necessarily important for prototyping. Your 'design' on the other hand encapsulates alot of important flow/function choices that knock onto many areas of your game. A good rule of thumb is to avoid hiding behind fancy artwork/sound for early demos. If you need final artwork/sound to prove your design you aren't necessarily paying enough attention to potential design flaws; additionally, playtest feedback may be clouded as the playtesters focused too much on how fantastic your game looks/sounds. Horror games are a slight exception but even demos like Slender: The Eight Pages prove that you can do alot with very little.
Don't Start at the Beginning
This is not a golden rule (and not applicable to all prototypes) but I find it quite useful to avoid building games from the start. As we build the start of our games we get very bogged down on how we introduce the gameplay, tutorials and story. In reality the first 10 minutes of play are the most important to keep players engaged but you don't necessarily have to start building here. You can polish your introduction right up until release and can use the results of playtesting to better improve the experience for first time players.
Playtest and Refine
Once you have your prototype you'll want to review it yourself and with a group of testers. The process of playtesting is complex and I will cover this in the next article but you should try to convince yourself that the idea you have is worthwhile and free of any major design flaws before pushing a dud idea too far. If you're looking to rapidly prototype a new game idea, try giving yourself some deadlines to work towards - weekly or fortnightly depending on your workload - and try giving your game to new testers in addition to older testers who may have given you some negative feedback to consider.
Benefits of Prototyping
Below I outline some of the major benefits of prototyping early and often:
Identifying Risks - one of the best reasons to prototype is identifying risks in your project - such as e.g. "not fun", "confusing gameplay", "story hard to follow" - early on and try to think of how to resolve them. This can help de-risk later stages of your development cycle and help you make better design decisions. If an idea just isn't working you can shelf it before spending too much time on it.
Happy Accidents - as you build you'll have a lot of happy accidents: features that arise because you accidentally combined a few elements or messed up some code/design setup somewhere. These features may become new game modes of their own or even the foundation of your current game idea.
Confidence in your Product - it's important to have confidence in any idea you are pushing and prototyping can help to underline what is/isn't working. Things that are really working can give you confidence your idea is successful in certain areas. If something isn't working, you may want to spend extra effort trying to fix what failed or make an informed decision about whether or not to cut or replace it.
Conclusion
That's it for part two of my game design tips. I hope this ramble has been useful to you. If you have any thoughts or feedback - or if there's any topic you'd like me to cover - then let me know.
I'm on twitter at @manwhoflewaway
Thanks for reading and good luck with your projects!
Clive Lawrence,
The Man Who Flew Away
Follow Observatorium development here on Indie DB
