Get the Game Design Canvas
Game Design Canvas by Budd Royce Lam is licensed under a
Creative Commons Attribution-ShareAlike 3.0 Unported License.
Based on a work at http://www.businessmodelgeneration.com
The FILLABLE PDF version can be found here: DOWNLOAD THE GAME DESIGN CANVAS
What is the Game Design Canvas?
The Game Design Canvas is my adaptation of Alexander Osterwalder’s Business Model Canvas for game development. It was designed as a living document / tool for rapid prototyping of game ideas and as an alternative to the standard multi page Game Design Document for those that don’t like making formal GDD’s.
Game Design Canvas vs Game Design Document
The canvas does not completely replace a GDD as it does not contain all the minute details that a GDD contains. What it does do is provide you with a framework to quickly design the core elements of a game and works very well for prototyping games. It can be used as an alternative to a GDD if you or your organization don’t normally make GDDs as well as a great tool to view your game at a high level during meetings.
How do I use the canvas?
Like the Business Model Canvas that inspired this, it works best if you can draw out the boxes on something like a white board or similar. While it *CAN* work on a printed 8.5×11 sheet of paper, it’s going to feel a bit small and works best when you can use it as a canvas to brainstorm ideas on.
I did however, provide an excel file where you can just fill in the boxes. I really should just turn it into a fillable PDF form sometime as well as a larger poster sized version where you can just slap on some post-it notes on.
Do I have to fill in all the boxes?
No, but it’s best that you do. While few people think about things like Player Segment, it does help you narrow down ideas or features these player types would normally expect or want.
Can I change the boxes?
If you need change or add boxes to the canvas, you are more than welcome to do so. The canvas itself is licensed under creative commons so feel free to edit and share. Just link back to this site as reference.
What’s a Minimum Viable Prototype?
The MVP is something I coined based off the Minimum Viable Product from the Business Model Canvas. The difference here is we’re focusing on the minimum elements we need to create a prototype that’s suitable to give to a publisher or release as a public beta. This is the core of the canvas and is focused on the deliverables you need before you can say you have a finished prototype.
“EVERYTHING FOCUSES AROUND THE MVP”
This can be changed to a Minimum Viable Product once your project takes off the ground and is no longer a prototype. I’ll probably design a separate canvas to focus on games in production that are beyond the prototype stage.
Why is there a Player Segment?
This is probably one of the most important things to consider when designing a game. Who are the people that will play your game?? It’s something a lot of folks seem to over look, especially those new to game design. By defining who your target players are, you can better refine your game to suit their needs. The better defined your player segment the better refinement you get from your game. I mean to say you’re targeting casual gamers is one thing, it’s another thing to say you’re targeting female casual gamers who are into cooking(cooking mama anyone?).
The player segment is defined here so you can better define your Minimum Viable Prototype. As they’ll ultimately be the people who will be playing your game you’ll most likely need to add additional features based on the needs, wants and expectations of your player segment(s). Skipping the player segment may lead to design issues that make your game feel like it’s missing something. This is probably the hardest section on the canvas to define but well worth the 5 minutes of brain activity.
Just note that some games are actually catered towards more than one player type. For example if I were to design a MOBA similar to League of Legends or DOTA 2, I wouldn’t just say I’m designing a MOBA for the hardcore competitive gamers, I’d divide them into those that are into highly competitive skill-based gaming but also those that want to customize the look of their characters.
Once defined, I can then see what’s important to each side. On the hardcore gaming side, it’s likely they don’t want to see any Pay-To-Win kind of things. On the customizers, I need to know how much customization is necessary? Is it just aesthetics or will it affect gameplay? Do I need to build these systems?
If you know the profile of your player segment, it’ll help you define and refine the experience you want him or her to have when they play your game.
Why don’t the highlighted areas line up with the grid?
That’s really what I use as a symbolic reminder that the game concept and player experience overlap and that the Experiential Design (the gaming experience) also overlaps into the Technical Design.
Why is there both a Mechanics section as well as a Game Play section? Aren’t they the same?
Yes and no. It all depends on what you describe Mechanics and Game Play to mean. To most people mechanics is a subset of Game Play but on the Game Design Canvas, Game Play refers to the high level of game play that the player does while Mechanics are the things that make that game play happen.
For example
In your MetroidVania-style game. The game play could be described as having the player explore a procedurally/randomly generated map while hacking and slashing monsters with special wandering monsters occasionally lurking that are scaled to the players level.
Under Mechanics you’d like the things you need to engineer: Procedurally generate the map(and how much of it is procedurally generated?). A leveling system or some way for the game to know what skills the players have and give the special wandering monsters an ability or difficultly level that matches accordingly. Since it’s a MetroidVania style game, we probably need a mapping system in addition to the basics of a platformer as well as melee and possible ranged combat.
What goes under the metrics section?
This can vary from project to project. Here I basically put down anything and everything that has to be measured or kept track of. There’s two primary sub categories that I lump things into. Data for analytics and Measurements
The data for analytic are essentially the various categories you want to keep track of to improve player experience or even keep track of for monetization purposes. These things could be the # of deaths and where did the players die, favorite weapon and # of shots fired. The amount of time it took the player to do something. Basically, it’s the categories you want to collect data on.
This section is also for measurements. If you’re using a tiled game engine, how large are the tiles? How large are the characters? How far do your bullets go? How fast does everything move? If the player can jump, how far/high can they jump?