Remember, the more times you can iterate on your idea, the better the final game will be. Once you have a basic idea, the next step is to get it in playable form as quickly and cheaply as possible. That will leave you with as much time as possible to playtest and iterate.<\/p>\n
As mentioned last time, iteration is the most critical for those parts of your game that have high\u00a0design risk<\/strong>. For \u201cclone-and-tweak\u201d games where you are mostly lifting gameplay from an existing game, rapid prototyping is less important. This does not mean that \u201cclone\u201d games do not benefit from iteration, but simply that you should use it selectively in those areas where you\u00a0are<\/em> innovating.<\/p>\n \u201cLaws\u201d of Prototyping<\/strong><\/p>\n Remember that the entire purpose of prototyping is to maximize the number of iterative cycles. Corollary: do everything you can to reduce the time required in each iteration. Now, consider that each iterative cycle consists generally of four steps: design, prototyping, playtesting, and evaluation. Of these steps, where can you save time?<\/p>\n\n Some things to keep in mind when building a playable prototype:<\/p>\n\n All of these guidelines push designers towards one inevitable direction\u2026<\/p>\n Prototyping in Paper<\/strong><\/p>\n You can call it \u201cpaper\u201d or \u201ccardboard\u201d or \u201cnon-digital\u201d or \u201canalog\u201d or any number of things, but the idea is to have a physical, tabletop game that is playable without computers (or at least, without requiring programming code). Programming is wonderful and powerful but it is also slow and expensive in comparison to paper prototypes. Here are some advantages of paper prototyping:<\/p>\n\n Limitations of Paper<\/strong><\/p>\n Paper prototypes do have some limitations that you should be aware of:<\/p>\n\n Prototyping Realtime Systems<\/strong><\/p>\n For a turn-based game like\u00a0Battleship<\/em>, a non-digital prototype is easy enough to put together. What if you wanted to prototype a First-Person Shooter video game like\u00a0Halo<\/em>? Is there any\u00a0possible<\/em>\u00a0way to do that on paper, when most of the game is running around and shooting things in real time? The answer is yes, absolutely. Here are some hints:<\/p>\n\n A Short Note about Grids<\/strong><\/p>\n There are many ways to make a game board, but here are three common ways to get you started:<\/p>\n\n Adding Features versus Keeping It Simple<\/strong><\/p>\n Many early prototypes are simply begging for extra features, such as health and ammo and various other resources. Why not start with all of these extra systems already in place, as opposed to starting with just the simple core system? There are a few reasons to start with a simple, core rule set and then add on one rule at a time, instead of trying to design the entire game in one big effort:<\/p>\n\n Early on in a design process, it\u2019s generally better to keep things as simple as possible. For every rule or mechanic or object or resource that you want to include, ask yourself: is this\u00a0really<\/em>\u00a0necessary\u00a0right now<\/em>? At this point, let your laziness override your creativity. It is far easier to add something to your design than to take it away, so add the minimum possible to have a working, playable game.<\/p>\n If you have trouble with this, try writing down a list of all of the ideas you have that you want to include in the game, and then cross off as many as you can. Ask if whatever items are left on your list would make a complete, playable game. If so, try to cross off more, until you absolutely can\u2019t anymore.<\/p>\n It may also help to run your idea by another designer who is not personally and emotionally attached to your pet idea. Invite them to be merciless in deciding which of your rules can be trashed. For the purposes of this course, you can offer a trade with any colleagues in your area: you look at my prototype, I\u2019ll look at yours!<\/p>\n Moving Forward<\/strong><\/p>\n Once you have the core gameplay, and it\u00a0works<\/em>, then you can add new features. The temptation at this point is to add everything you originally thought of. Resist this temptation. Instead, add\u00a0one<\/em>\u00a0new feature, and playtest again until the new feature works, or you have decided that it doesn\u2019t work and it needs to be abandoned.<\/p>\n Why not add everything at once? Because every new thing you add may have some problems with it. If you only add one new rule and a critical game system becomes broken in playtesting, you know\u00a0exactly\u00a0<\/em>where the problem is, because you only changed one thing. If you add ten new rules and something breaks, it\u2019s harder to isolate which rule (or combination of rules) caused the problem. Incidentally, this part is similar to programming: if you write code in small chunks and then unit test, it\u2019s easier to find bugs than if you write ten thousand lines of code between tests.<\/p>\n Yes, this is tedious. You have to playtest, then change one rule, then playtest again, then change another rule, and keep doing this dozens (or even hundreds) of times. The first few playtests are fun, but you will quickly become sick of the whole business. This is part of the process of design. Sometimes, game design is hard work that is not particularly fun. This is something you need to accept if you have aspirations to become a professional designer. Just remember that the purpose of this is to make a game that\u00a0is<\/em>\u00a0fun, and if it\u2019s not there yet, that should be your incentive to change something and playtest again until you reach your goal.<\/p>\nThis chapter was adapted from Level 4<\/a><\/span> of Ian Schreiber's Game Design Concepts<\/em> course.<\/span>","rendered":" Remember, the more times you can iterate on your idea, the better the final game will be. Once you have a basic idea, the next step is to get it in playable form as quickly and cheaply as possible. That will leave you with as much time as possible to playtest and iterate.<\/p>\n As mentioned last time, iteration is the most critical for those parts of your game that have high\u00a0design risk<\/strong>. For \u201cclone-and-tweak\u201d games where you are mostly lifting gameplay from an existing game, rapid prototyping is less important. This does not mean that \u201cclone\u201d games do not benefit from iteration, but simply that you should use it selectively in those areas where you\u00a0are<\/em> innovating.<\/p>\n \u201cLaws\u201d of Prototyping<\/strong><\/p>\n Remember that the entire purpose of prototyping is to maximize the number of iterative cycles. Corollary: do everything you can to reduce the time required in each iteration. Now, consider that each iterative cycle consists generally of four steps: design, prototyping, playtesting, and evaluation. Of these steps, where can you save time?<\/p>\n Some things to keep in mind when building a playable prototype:<\/p>\n All of these guidelines push designers towards one inevitable direction\u2026<\/p>\n Prototyping in Paper<\/strong><\/p>\n You can call it \u201cpaper\u201d or \u201ccardboard\u201d or \u201cnon-digital\u201d or \u201canalog\u201d or any number of things, but the idea is to have a physical, tabletop game that is playable without computers (or at least, without requiring programming code). Programming is wonderful and powerful but it is also slow and expensive in comparison to paper prototypes. Here are some advantages of paper prototyping:<\/p>\n Limitations of Paper<\/strong><\/p>\n Paper prototypes do have some limitations that you should be aware of:<\/p>\n As you can see, the advantages of paper prototyping are very general and the limitations are specific, so the ability to prototype in paper is an important skill for any game designer to develop, whether they work in video games or board games or anything in between.<\/p>\n Prototyping Realtime Systems<\/strong><\/p>\n For a turn-based game like\u00a0Battleship<\/em>, a non-digital prototype is easy enough to put together. What if you wanted to prototype a First-Person Shooter video game like\u00a0Halo<\/em>? Is there any\u00a0possible<\/em>\u00a0way to do that on paper, when most of the game is running around and shooting things in real time? The answer is yes, absolutely. Here are some hints:<\/p>\n A Short Note about Grids<\/strong><\/p>\n There are many ways to make a game board, but here are three common ways to get you started:<\/p>\n Adding Features versus Keeping It Simple<\/strong><\/p>\n Many early prototypes are simply begging for extra features, such as health and ammo and various other resources. Why not start with all of these extra systems already in place, as opposed to starting with just the simple core system? There are a few reasons to start with a simple, core rule set and then add on one rule at a time, instead of trying to design the entire game in one big effort:<\/p>\n Early on in a design process, it\u2019s generally better to keep things as simple as possible. For every rule or mechanic or object or resource that you want to include, ask yourself: is this\u00a0really<\/em>\u00a0necessary\u00a0right now<\/em>? At this point, let your laziness override your creativity. It is far easier to add something to your design than to take it away, so add the minimum possible to have a working, playable game.<\/p>\n If you have trouble with this, try writing down a list of all of the ideas you have that you want to include in the game, and then cross off as many as you can. Ask if whatever items are left on your list would make a complete, playable game. If so, try to cross off more, until you absolutely can\u2019t anymore.<\/p>\n It may also help to run your idea by another designer who is not personally and emotionally attached to your pet idea. Invite them to be merciless in deciding which of your rules can be trashed. For the purposes of this course, you can offer a trade with any colleagues in your area: you look at my prototype, I\u2019ll look at yours!<\/p>\n Moving Forward<\/strong><\/p>\n Once you have the core gameplay, and it\u00a0works<\/em>, then you can add new features. The temptation at this point is to add everything you originally thought of. Resist this temptation. Instead, add\u00a0one<\/em>\u00a0new feature, and playtest again until the new feature works, or you have decided that it doesn\u2019t work and it needs to be abandoned.<\/p>\n Why not add everything at once? Because every new thing you add may have some problems with it. If you only add one new rule and a critical game system becomes broken in playtesting, you know\u00a0exactly\u00a0<\/em>where the problem is, because you only changed one thing. If you add ten new rules and something breaks, it\u2019s harder to isolate which rule (or combination of rules) caused the problem. Incidentally, this part is similar to programming: if you write code in small chunks and then unit test, it\u2019s easier to find bugs than if you write ten thousand lines of code between tests.<\/p>\n Yes, this is tedious. You have to playtest, then change one rule, then playtest again, then change another rule, and keep doing this dozens (or even hundreds) of times. The first few playtests are fun, but you will quickly become sick of the whole business. This is part of the process of design. Sometimes, game design is hard work that is not particularly fun. This is something you need to accept if you have aspirations to become a professional designer. Just remember that the purpose of this is to make a game that\u00a0is<\/em>\u00a0fun, and if it\u2019s not there yet, that should be your incentive to change something and playtest again until you reach your goal.<\/p>\n\n \t
\n \t
\n \t
\n \t
\n \t
\n \t
\n \t
\n
\n
\n
\n
\n
\n
\n