If you’re working on a game or other project right now, finish it! Only by finishing a game will you actually gain valuable knowledge about the whole process. There’s something about the act of experiencing the start-to-finish cycle that launches your skill forward further than you would expect. I addressed one aspect of this in my blog “An ode to tiny games,” so check that out!
Learning to manage scope
Managing scope is hard to master. You don’t really know how to do well until you’ve done it a bunch of times. The act of managing scope isn’t just knowing how long it takes you to do things. There are many aspects of it that you just cannot see unless you reach the end of the project.
For example: It’s not enough to estimate tasks and call it a day. You need the ability to see the hidden scope that’s to come. How long will it take for two people to work together to implement their separate pieces? What kind of bugs can we expect to break this feature? How much of a rush will we be in at the end if we leave certain content until last minute?
When you are over scope, what kind of techniques should you try to manage it? What worked in the past? Where can appropriate cuts be made, and where should no cuts be made? Did your scope adjustments from early alpha phase pan out?
If you never finish a project, you have learned very little about managing scope. Very few of the problems you ran into and solutions you tried will be reliable for future projects because you never get to see how they impacted the end result. Push yourself through to the end, and all the choices you made along the way will stand out and reflect their value.
Learning to manage your time
Shipping a game -- or finishing it but hiding it away forever because you think it sucks -- gives you a huge moment of reflection on how you managed your time. Sure, you can still reflect on how you felt if you quit a game, but the real learning is seeing how adjustments to your time management affected the game and affected you in the end. By finishing your game, you’ll be able to make an accurate connection between your time management and the quality of the finished product. You’ll learn more about yourself. Without this experience to reflect on, you may be doomed to repeat the same mistakes in the future.
Showing off your portfolio
When we interview devs, we like to see finished games. Some people show off old, crappy games they made in school. Others, of course, show off successful projects they did at home or at their previous job. I still love to see them all. Even if the older games aren’t great, I still think to myself “This person has finished # games. They have some semblance of experience.” If someone has a nice portfolio of little chunks of work they did but no final game to show, I think “This person has never finished a game. They don’t know what they’re getting into.” It’s a little red flag.
Even if you’re concerned about the success and quality of the finished game you’re trying to complete, they mere act of making it all the way through will show other people that you’ve put yourself through the wringer before and have an idea of what doesn’t and doesn’t work to get a game done. The effort will get noticed even if the game itself doesn’t.
This helps me sift through design applications too. A good designer has experienced the horror of having a great design on paper, only to see it smashed to bits as production happens and their expectations are shattered. A good designer can adapt and adapt and adapt right up until the end, slowly guiding the design to its final form throughout the project. If they don’t finish the game, however, they can’t see if what they did was truly a good design or why it failed.
Learning to deal with frustration
Giving up can be a habit. If you start to feel frustrated and are uncomfortable with the pressure, it will be tempting to quit. If you quit and feel that feeling later on a different game, you might just quit again. Game development is a lot of pressure, and it’s a skill to learn to take that pressure and channel it into hard work and perseverance. When you push through the hardships and experience the joy and relief of finishing what you started, you’re teaching yourself that the pressure is a positive thing. You develop a good habit.
As a brief aside, projects tend to get more frustrating the closer you get to completing them. The thought that you are so close to being done but still aren’t finished is a killer. It’s all an illusion, though! Don’t view it as a sign that things are going wrong or the game isn’t worth finishing. It’s simply a magnified version of the natural pressure that’s been there the whole time. Push through!
If you do choose to quit . . .
. . . then give yourself a long break before you go back to it. Try something new for a while. Focus your efforts elsewhere. I wouldn’t suggest that you keep picking away at the thing you quit, because then you haven’t actually quit, you’re just working on it poorly. Give your brain a chance to reset and dabble in other things before you attempt to tackle it again. Giving up doesn’t have to be permanent.
I’m sure other people can think of more reasons why finishing a game gives you a vastly different perspective and learning experience than giving up on one. These are just the ones I’ve noticed. So don’t be too hard on yourself. Coming out the other side with a completed game will be worth the struggle.
Project in a nutshell
We ended up designing three games targeting early readers, some of whom may just be learning what letters are. The age range was 2-7 year-olds, depending on the game. Our first game was Bubbles, which asks players to find and place the letters that belong in a three-letter word to unlock the reward of a screen full of poppable bubbles wobbling around.
Physical devices have fewer limitations on interactions
When you design a digital game, you are in complete control of what the player can and can’t do at any point in time. You can disable buttons, hide pieces of information, point at things you want them to touch, etc. These are things you can’t do with a physical device, like the Square Panda tray. Kids can do anything they want with the device and letter pieces at any time, and the game can’t stop them. The digital experience needs to both clearly direct the player on what they should do with the letters and react to spontaneous actions they may do.
Because anything goes in the physical space, players can place letters incorrectly in the tray. It could be the wrong letter, it could be upside down, it could be in the wrong slot on the tray, or anything combination thereof. They could even decide to move letters or rearrange them at any point in the game. We opted to have immediate feedback that walks the players through correcting their mistakes the moment they make them. There are often visuals, text, and voice-over working together to tell the player what happened and how to fix it. We make the lights on the tray and screen blink by the letters and slots that the player should interact with to help draw their attention.
Limited number of letters
The Square Panda device only has so many letters. That means certain words are off-limits because there aren’t enough letters available. This is another limitation to a physical peripheral. All the words in the game need to be able to be written using the letters the player has access to. If the player has lost a letter, they can mark them as lost and the game will automatically fill in the missing ones for them, allowing the player to continue playing.
When you make a game with lots of pieces for a target audience of small children, you run the risk of them losing pieces. We even lost some letters somehow while playing with it in our office! Luckily, Square Panda thought ahead. All the games let you mark letter pieces as missing, meaning the game will fill them in automatically for you.
The Square Panda games use both physical and digital technology. We wanted to use each to its strength. The core gameplay focuses on the letters and tray, but a game like Bubbles will reward the player with the digital interaction of popping bubbles on the screen. Kids love the variety of interactions, and we love it because it keeps them engaged. Jiggity Jamble takes it a step further and encourages the player to stand up and do the dance moves along with the characters on the screen. We found a way to use the digital technology to affect players in the physical space.
Designing around hardware is not impossible, and in fact presents many unique interaction opportunities that only hardware can facilitate. A physical device can enhance play and open new doors for learning and interactivity. The games we created for Square Panda and its letter tray go beyond what many of our digital games have done, and players find them exciting and engaging. I look forward to trying my hand at more games that incorporate new hardware.
Coming up with an idea for a game can be hard, especially if you’re in a group and have a short time limit. The beginning of a jam can be hours of headaches, flip-flopping, and fuzzy ideas that no one can agree on. I’m going to outline a few practices that work for me when I need to push myself to come up a game pitch.
The Mind Map
Mind maps are a simple tool for quickly seeing what ideas you have if you go down different paths. You put a constraint in the middle (like a theme or game genre) and just keep branching out with ideas that relate to it, and ideas that relate to those ideas, etc. Here’s an image of a tiny one I made using Coggle as an example based on the theme “heartbeat.” We did a mind map for this very theme for a past Global Game Jam and it was an awesome way for everyone to just get their ideas out there. Our map was huge! After you fill it out pretty far, stop the process and look over what you have. Somewhere in your mind map is a winning idea.
Pulling Out Verbs
If you have your general idea but are struggling to think of actual mechanics a player could do, start listing out different verbs and actions that are associated with your theme.
For a shooter, verbs you could think of are: gather, shoot, reload, run, drag, cover, aim, guide, dodge, sneak, crawl, launch. Try to think of mechanics that other games use or that you envision the character doing and use that as a starting point. This activity is very much like a word association exercise and mind map put together.
If you wanted to make a game that’s themed around something not typically ‘gamey’, such as operating an ice cream truck, pull out verbs from the real life activity. You would have: drive, speed, plan route, make treat, serve, play music, collect money, spend money, schedule, etc. This is your starting point and can help inspire you to think of the mechanics your game should have.
Storyboarding isn’t just for communicating ideas anymore! It’s for coming up with them too. Sometimes you can trigger a lightbulb moment by trying to draw what the game could look like even if you still don’t know what it is. By seeing shapes on the paper and forcing yourself to visualize, you can look at the design you have so far from a different perspective.
I usually make doodles from different perspectives and imagine how a game like that would work. Maybe I’m making a game about managing an ant colony, so I draw a top down view of some colonies and some trees and a house. If this were an actual game, what would the player be doing? Or maybe I draw a side-view from underground and there are some stats in the HUD showing me information about the ants in the colony. How would this game work? These little doodles I just made are already making me think of what an awesome ant game could be.
Look to Existing Games
It’s rare for someone to design new game mechanics that nobody’s ever done before. Even crazy, unique games fit into a category of some sort and have similar features to other games their playerbase enjoys. What games already inspire you? Does anyone have game in mind that they already love? You can take an existing idea and twist it / add to it to turn in something new.
You can leave this as a last resort if you’re not comfortable ‘cheating’ like that, but it’s a viable strategy. Many people have designed games that are improvements on the genre / gameplay of ones that already exist. Just look at bullet hell games, for example. There are so many with such similar mechanics, and yet they’re each their own experience.
The “But Wait, There’s More!” Technique
This one is my own invention. I’ve literally said this phrase to myself when I come up with an idea that’s somewhat bland and need instant inspiration. Sometimes the first version of your gameplay appears boring or too simple. It doesn’t make anyone go “Yes, THAT is a great idea!” You can force a eureka moment to happen by pretending you’re pitching the game to someone, and when reaching the end you suddenly say “But wait, there’s more!” It works, and if it doesn’t, you’ve wasted only five seconds of your life.
Here are some other helpful phrases to have people / yourself fill in (on paper or mentally) to add some pizazz to a blah idea:
“How about instead of (current theme), you were actually trying to (hot new theme.)”
“Here’s the kicker: the player can also (crazy mechanic.)”
“If (target player) were here right now, they’d be wondering why the game doesn’t let you (verb.)”
“It’s like (common game here) except you can (verb.)”
This technique helped me transform a yawn-worthy pitch about adjectives and simple comparisons into an interesting one about monsters fighting over a meal. It helped me come up with the ridiculous and engrossing mechanics of Motion Force, which was initially just a “move your ship around and collect the things” idea with less zazz. Billy Mays would be proud.
Just Pick One Already!
People get lost inside their own heads during brainstorms and are usually trying to come up with a great game off the bat. Nobody wants to move forward on an idea until someone pitches the perfect game. That’s not how it works though. The game becomes great as you nurture it and feed it by developing its design. It often starts as an ugly duckling. If you’ve been jamming on ideas for a long time and not gotten anywhere, you need to just pick an idea that you think COULD be turned into a cool game and go with that one. Until you constrain yourself in this way, you’ll be endlessly tossing out ideas without making any forward progress.
A Final Note...
The cornerstone of advancing a design is having constraints. Constraints foster creativity. If someone limits you to making a puzzle game where you manipulate 3D spheres and it has to have a time limit, the gears in your head are already turning and coming up with ideas on how to make that work. The person whose only constraint is “puzzle game” has a longer way to go before they narrow an idea down into something they can work with. You have to learn how to use design tools, such as the ones above, to create constraints for yourself and focus your ideas into a pitch you can actually start to work on.
I love working on small games. My definition of a small game is one that can be developed in less than a year, preferably in under nine months. Larger games used to be more impressive to me before I entered the workforce. However, after being at Filament Games for as long as I have, I can say with confidence that I’m really glad to be working on the littler projects. They are quick, simple, focused, and I grow as a designer more because of them.
The top reason is that I learn from my failures faster. The more ways you can fail at something, the more ways you learn how not to do it! Working on multiple small projects throughout a year has offered me the chance to try and fail in a large number of ways. I’ve experienced different ways the scope of a project can get out of control, dealing with clients who present a variety of challenges, good and bad communication flows between teammates, right and wrong ways to write a GDD, designs that just didn’t pan out . . . the list goes on. I would never have reached this point in my career if I hadn’t been given tons of chances to perfect my approach to each aspect of game design.
The small game size gives me the opportunity to try my hand at multiple game genres. I’ve made time management games, questing games, different kinds of puzzle games, strategy games, a card game, simulations, games for toddlers and games for college students, science games, animal games, and many more. Where else can you experience such variety in a short amount of time? Getting to design a completely new game every few months is incredibly refreshing. I find new strengths and skills in myself that I otherwise would never have gotten to explore.
One of the biggest reasons that I enjoy smaller games is that the team size is smaller and I get more control as a designer. I get to think about the whole game and jam with a tight-knit group of experts to make the best product. It’s much easier to communicate with smaller teams and everyone has a massive amount of agency in their area. Smaller games appeal more to devs who like wearing multiple hats and contributing to a large percentage of a game’s development.
Having a job where I’m in charge of many smaller projects decreases the turnaround time between making a mistake, learning from it, and trying something new. I frequently have opportunities to reflect on the development, come up with a new plan, and implement it right away. Learning through experience is the best way to get better at something, and I consider myself lucky to have the chance to do this every year.
I’m going to talk about the act of intentionally twisting the facts when designing a learning game. Not exactly teaching the subject matter incorrectly, but just bending the truth to make it something that can be taught through digital play. Tailoring the experience, altering the learning, very slightly distorting reality . . . ok, let’s just call it what it is: lying. There, I said it. Sometimes we LIE in learning games.
It’s unavoidable. Sooner or later you’re going to try and teach something through a game and you’re going to hit that wall where you need to decide what part of reality needs to go on the backburner and what part actually matters. Games can only do so much, and when you’re trying to teach physics, emotions, cell function, or any sort of complicated system, you have to pick and choose what gets simulated and taught accurately and what doesn’t. Is this a bad thing? Of course not!
When we were making Motion Force, we had to tweak Newton’s laws of motion. The game lets players plan a path along a grid for their ship to go. The ship moves according to the boost forces that the player puts on a timeline. As the time scrubber moves along the timeline, it will trigger boost forces to happen.
The problem here is that this only works if force is instantaneous, which it isn’t. A ship’s rocket booster may seem to move a ship instantly, but really the ship is just accelerating very quickly. The ship is taking a small amount of time to slow down or speed up. If this happens when it makes a turn, it will create a tiny curve. If we modeled this in the game, the ship would eventually be slightly off the grid and the player would be unable to plan their trajectory.
We decided to tell the players that the boost forces happened really really fast, and secretly we programmed them to actually be instantaneous. In the end, the players were none the wiser and the physics of their ship moving around still made sense and helped them learn the laws of motion. It was a huge success built on a tiny, but important, lie.
How do you decide which part of the learning to cut when making a game? It all boils down to the learning objectives. If you know exactly what you’re trying to teach, then you’ll be able to identify which parts are irrelevant to the learning. The challenge is to not accidentally teach something incorrectly such that players walk away with the wrong idea.
In Reach for the Sun, players grow a plant by collecting three resources (starch, nutrients, and water) and spending these resources on different plant parts. Players click on different parts of a plant to gather a resource: roots give you water and nutrients, and leaves do photosynthesis to give you starch. We let the player choose which resources to collect and spend.
This is very far from how real plants work. Real plants don’t just choose a moment to absorb water, and they certainly manage more resources internally than just those three. Why did we choose to limit ourselves in that way and not model some very real aspects of plant growth? Learning objectives! We wanted players to understand that plants collect resources and use them to survive. Players should know how basic plant reproduction works. There was no need to get super realistic here because after playing the game players had as much of an understanding as they should have: plants do need starch, water, and nutrients, and they need to flower and fruit to create seeds. They game very clearly simplified the process.
When it comes to learning games, chances are that there are other resources for teaching the subject matter that players can reference. Biology and science textbooks can present tons of information in only a few minutes of reading. Games can give players a deep understanding of chunks of that information. You cannot expect to teach everything about huge topic in just one game. In the case of Reach for the Sun, players gained an understanding of plants they may not have gotten from other learning sources.
We try hard to avoid teaching incorrect things in cases where we have to bend the truth. In Molecubes, we had a heck of a time trying to teach pH accurately in a way that wasn’t incredibly confusing or boring. We ended up doing too many calculations to figure out how real acidic and basic liquids combine.
Our solution was to super-simplify it and tell the player that equal amounts of acids and bases will neutralize each other and that a mix of more acid and less base, for example, yields an acid. This is not untrue, but it doesn’t really explain much about what’s going on. If you add a base to an acid, the acid becomes less acidic. But we weren’t able to play around with degrees of acidity or alkalinity in the gameplay so we just stuck with ‘base’, ‘acid’, and ‘neutral.’ This was acceptable to us because it was true but didn’t teach the wrong thing. It left room for deeper learning elsewhere. If we had instead made up our own pH scale or pH values that resulted from the liquid interactions, then we would have definitely been teaching the wrong thing.
Fossil Forensics gives players a taste of what it’s like to analyze fossils and make conclusions about their relationships based on their physical features. That’s what we wanted players to walk away with. The fossils in the game are made up and the physical features they have are really simple, whereas the actual features one would look at in real life are much more complicated. The aspects of the learning that we chose to skip were the parts that didn’t matter in terms of the players learning about how you can draw conclusions from evidence. They get a taste the process without the complications of needing a college degree to understand it.
One of the best ways to check that a game isn’t teaching something incorrectly is to run the design by a subject matter expert. Contact a teacher or professional who deals with the topic every day and see what they say. There have been many times where we’ve bent the truth in our games only to have a teacher point out that we were making a big mistake. Through their guidance, we were able to twist the facts somewhere else in the game where it wouldn’t matter to players. It never hurts to get an outside perspective.
Sometimes at Filament Games we’ll have clients who want us to create a game on a subject we’ve already tackled before. It’s challenging because we don’t want to make the same game twice, so the themes and mechanics should be different. Making multiple games with the same objective is like getting to time travel and go in a completely different direction, answering all those what-ifs that were going through your head the first time around. This is the case with Do I Have a Right and That’s Your Right (the former was made before my time; the latter was designed by yours truly.)
Play Do I Have a Right
Play That’s Your Right
Both these games teach the ten amendments of the Bill of Rights, with DIHAR also teaching some extra amendments. That’s a tough learning objective because all the amendments are different from each other, and there are no obvious systems or mechanics associated with them -- they’re just facts to learn. I’m going to break down some of the differences in the games to show how they each ended up teaching the same thing in their own unique way.
These genres appeal to different kinds of players. DIHAR is a game of juggling client needs and beating the clock, while TYR is about strategy and maximizing your token efficiency. Both games are excellent vehicles for the same learning objective.
DIHAR dives deeper into the amendments than TYR. There are multiple scenarios for each amendment that are fleshed out and come across as conversational. It also has the player analyze the scenario text and identify parts of it that are important in determining the corresponding right. The player can also read up on the amendments their lawyers have in a reference panel. Players will get a very thorough understanding of the amendments, but it comes at the cost of there being more reading to do.
TYR’s approach is shallower, with players not doing as much reading. However, this can make the content easier to digest. Each round only has five amendments at a time that have short, easy-to-read definitions. There are multiple descriptions on cards that go along with each amendment, but they are very short and feel more disconnected from real people. This game feeds the player bite-sized bits of learning and is successful as long as players are able to think about the content themselves in order to determine the correct amendment match.
In both games we found that players are equally encouraged to remember what each amendment stands for and make correct connections as much as possible. DIHAR players can’t win at all if they just pair clients up with lawyers willy nilly, and TYR players will get creamed by their opponent / AI if they don’t power up their cards or attack opponent cards.
Each game has its own special way of dazzling the player and keeping them invested in the gameplay. In DIHAR, players get to purchase new pieces of furniture for their office that make clients wait longer and add upgrades to the lawyers. There’s also a newspaper that’s generated after every round that has a little article about how their business is doing. The player hires more lawyers and has to deal with more amendments at a time, so it becomes vital that they learn what certain amendments are by heart so they can quickly funnel clients to the correct lawyer.
TYR awards players who do well by feeding them more powerful cards over time. The game looks at each player’s progression and the number of cards they’ve correctly powered up to determine the power of cards they draw. It rewards them with special ability cards whenever they make a correct amendment match. The game gets more intense and the stakes get higher.
Both games require that players make an effort to remember what the amendments are in order to have the best experience, but their motivations for doing so are very different. Knowing the amendments becomes a vehicle for the player to do better in both cases.
Which One Did It Best?
And the winner is . . . neither. Or both. It depends! The great thing about having different games / mechanics for the same learning objective is that more players are able to enjoy the learning the content. Some people aren’t into the gameplay DIHAR has and would rather be competing in a card game, while others may be bored with TYR’s battle system and are way more entertained by running around a little law office. Some players need to play both games because they gain a different perspective on the amendments in each one. Games can’t please everyone; they’re just a tool. The more tools and types of media we can provide for learners to take in the same content, the more likely they are to retain and understand it.
I’m going to walk through my thought process leading up to balancing a game. This is the method I follow to make sure I spend most of my time knowing what values I need to tweak and less time making random adjustments to see what happens, or worse, re-doing parts of the gameplay because I realized I balanced it incorrectly.
Look to the Objectives
After opening my spreadsheets and settling down with a hot beverage, I take a moment to remind myself what the core of the game’s experience is. Is it patience and strategy? Mayhem? Do players have to become quick-fingered? Is the pace the same but the challenge is harder? As we balance, we should check our progress against the objectives to see if we’re meeting them or straying too far away.
Identify the Rigid Values
After gathering the pile of values and elements I will be messing with to balance the game, I start to sort them. Constraints encourage creativity, so I start by nailing down which values should remain the same, or mostly rigid, throughout the entire game (which includes values that only change if the player makes them change, such as through an upgrade.) I will set aside values that give me the most control over pace and difficulty over time.
Examples of rigid values could be the rate of fire from the player’s weapon, how long a day lasts in your gardening game, the max number of customers that can wait in your restaurant’s line, and the size of certain AOE effects. Some of these may actually change in response to certain player actions or events in the game, but they are not values that will automatically change over time as the game progresses according to when the designer says they will. That’s what makes these values special.
I keep these values separate from the rest and sort them again by permanent (ones that will have the same value no matter what) and variable (ones that can change during gameplay but that I will not have precise control over in terms of when it happens.) Sometimes there’s no right answer, so I just pick certain values to be permanents and constrain myself to balancing around them.
This was especially helpful in balancing Dashboard Blitz. I knew what the shortest amount of time was that I’d be comfortable with and I knew how long the longest round should be. I was able to specify how long each round should be so that they gradually went from the min time to the max. I no longer had to worry about that value. If I hadn’t done this and instead just started balancing each round in turn up til the end, I could’ve have ended up increasing the time at a such a rate that the final round was super long. All my previous balancing would then be garbage.
If you’re trying to balance something that isn’t necessarily discrete number values (such as a level layout or an AI,) this concept still applies. For anything you know will be increasing or growing or getting harder as gameplay continues, you need to consider what its ultimate state looks like so you know how to pace yourself there.
In this way, we are slowly giving ourselves constraints to work within, saving ourselves time, and making sure that any other designers who take over some of the work (including our future selves) are aware of what they can and can’t do.
Identify Value Relationships
This is something that can be a headache if not well documented from the start: values that change with each other or have some sort of connection. Maybe there’s a group of values that change proportionally with another. Maybe two have an inverse relationship. An example could be two creatures that can never appear in the the same room, or can only appear in the same room. It could also be some number that decreases as another increases. I like to figure out which values are going to have to change based on each other and make a note of them where another designer or future-me can find them.
Find a Starting Point
The first place I start when balancing for real is in the middle. I balance a level or part of gameplay to a point where it’s as though the player has been playing for a while but may not be ready for intensely hard levels. This is the ideal difficulty I have in mind when I imagine what the game is like. Playtesting this early balanced section gives me new information about the elements I can play with and how everything comes together. I then balance backwards and forwards from this point to make the really easy, introductory difficulty and the more challenging one. Sometimes I’ll balance one easy difficulty, one medium, and one hard. They can serve as markers so I know how to adjust the parts of the game between them.
There are a ton of ways to approach balancing, and this is just one of them. There are certain types of games where this method is very useful, and others where it doesn’t really apply. I use this method to quickly balance games with many levels that are similar in terms of mechanics. What does translate well to other genres, though, is the idea of taking small steps before balancing to make decisions on as many things as possible so I’m not overwhelmed or going in blind.Take some time in each of these steps and you will ultimately spend less time messing with every game value and more time adjusting the important ones.
Designers, we are not the only ones with ideas and solutions. There is a careful balance we must maintain between designing features by ourselves and gathering the developer’s ideas and feedback. A game is a bajillion times better when it’s the combination of everyone’s creativity. It’s the kind of thing that’s obvious in theory but is sometimes forgotten in practice.
I would argue that this is a skill, not just something that happens naturally when a team comes together. Scratch that, I know it’s a skill because I used to be bad at it, back when I was a wee designer. Nowadays, I’m proud to say that the teams I work with have enthusiastically shared how pleased they are with the amount of ownership and input they have with each game. It’s positive feedback they’ve given on multiple occasions, so it’s a very big deal to them.
Like any skill, there are actionable things we as designers can do to maximize our team’s creative input. These are a few of the ones I do, and I apologize if some of my action items don’t translate well to your own workplace environment. The point is that we’re actively thinking about these things!
Include team in early design discussion
Designers need to get their team member’s input early in design. A team member is pretty much everyone who will be doing development on the game (sound, interface artists, programmers, etc). They should all get a chance to see where the game is in the early stages because they may have radical ideas that steer the whole design in a better direction. Their input is valuable.
In my workplace, there is generally a period before production where most of the work falls on the designer’s shoulders. It’s usually me doing this by myself while my future team finishes up another project. I’ve found that there is a sweet spot during this time where I’ve designed enough of the features to be able to pitch the game to them but still haven’t fleshed everything out yet. It’s when I reach this magic moment that I rally the troops to get feedback before wasting my time on taking the design further.
I suggest gathering this kind of early feedback in small increments with a few team members at a time. Any more than that and you risk opening a door to a full-blown design jam situation with too many cooks in the kitchen. This is a time to probe for ideas, not to make everyone else do the design.
Leave problems for the team to solve in your designs
When you design a feature, think about what parts of the feature your team would be able to design better. If you want your game to have a system for collecting and managing inventory objects, for example, don’t come up with the specifics of exactly how the player adds, moves, shares, and deletes objects in their inventory. Let your interface designer solve that problem.
Ways to do this are to make sure your user stories and feature descriptions are worded in a way that leaves the method of implementation up to interpretation. Compare the following user stories:
“As a player, I can share an object in my inventory with another player by dragging it out of its slot and placing it over the other player’s character.”
“As a player, I can share an object in my inventory with another player.”
Which story do you think leaves room for your team to come up with creative ideas and solutions for the feature? The second one gets across the functional design of the feature without putting a solution in the story title itself. Feel free to leave suggested solutions to a feature in its description, but don’t word things in a way that immediately limits everyone’s ideas.
Don’t leave too much for team to design
This is where some balancing comes in. Don’t leave things so open that others are pretty much doing design for you. If you’re leaving certain things for a dev to design, ask yourself “Is this a unique issue that this person is more qualified to solve than I am?” If it’s not a resounding ‘yes’ then design it yourself. Remember, you can always fully design things and still leave the user stories worded in an open way so that others can step in if they feel so inclined.
Don’t leave too little for team to design
A quality team is one where everyone feels responsible for making the game great. Everyone wants opportunities for their ideas to shine, and we as designers have a lot of control over this. If your designs and demeanor all lean towards shutting others out from making decisions then the quality of the game will suffer in the end.
Approach spontaneous design discussions with solutions to the problem
If you have to involve others in solving a problem, it’s always good to come up with some solutions on your own before hand. Otherwise they may perceive you as leaving too much design up to them and as incapable of solving problems on your own.
This has happened a couple times to me where I saw my inclusion of the team in problem-solving as a useful thing, but because I left it so open and didn’t have my own ideas to pitch at the start they got worried that maybe I couldn’t handle design on my own. Total opposite of what I wanted! Nowadays I approach the team for design help when I already have some options for us to discuss, or at least I try to do it most of the time.
Be open to accepting and implementing feedback
It’s common as a designer to be approached by others who thought of something cool or had an idea they want to discuss with you. Give them your time and let them know you’re listening. Never shoot down these ideas, and be honest if you say you’ll consider it or get back to them. Then follow through. Even if I’m not sure about including someone’s idea into the design, I always write it down somewhere so that I can reference it in case it’s useful later.
Have frequent one-on-ones
If you have an open office where you sit near your team and use scrum, you’re probably already having lots of conversations with your devs. Take the time to approach them individually outside of dedicated discussion times to give them an opportunity to share with you what they’re struggling with and ask questions / share ideas. Some people won’t open up to you unless you approach them yourself and give them the opportunity to. I have found that stopping by people’s desks just to chat about what they’re currently working on has produced tons of valuable feedback and cool suggestions that otherwise would never have seen the light of day.
These are all simple things that a designer can do to make sure the team feels listened to and included. I can promise that you and your games will not be worse off for actively making sure the team has a role to play in the design of a game. I never got a whole lot of feedback from my teams early on in my career when I wasn’t so good at this, but I got a heck of a lot of positive feedback from them after I made these changes. So give it a try and see what happens!
claps hands together loudly
“Alrighty, who wants to read my 30-page GDD that I spent the last two days writing?!”
Yeah, I don’t either.
I’ve seen a number of game design documents get out of hand and become a chore to maintain and read. They end up looking more like a wall of text than a handy design guide. What the team needs is something that’s easy to navigate and takes them to the most relevant info as efficiently as possible. So obvious and yet so easy to not do.
Now, I’ve written a plethora of GDDs and probably a few hundred supporting documents for them, so I am no stranger to writing out design. I take on a new project every couple months, meaning I get to start from scratch, learn from my mistakes, and try new things often. It also means there’s a huge potential for me to be buried up to my neck in time-wasting writing when I could instead be designing the thing.
I’d like to share some things I personally do to avoid writing a soul-sucking GDD that takes over my life and wastes people’s time.
Starting the GDD
Wiki or a Word doc?
I prefer wikis for the following reasons:
Once upon a time I designed a game that had missions. It also had warp missions. Then there were levels, which was a group of three missions. Levels were also called stars. Sometimes people called levels missions, or puzzles. Whatever, I knew what they meant, no big deal.
Except that it was. By the time I got around to encouraging official terminology for everything we had wasted days going back and forth with each other to clarify what we were all talking about. Discussing design was like a real life Abbott and Costello skit.
These days I define terms right off the bat before writing anything. Does this game have levels or puzzles? Or are they called challenges, missions, stages, or worlds? Do we call a character’s history a bio or a description? What exactly is a “Turn” in this game? Pick terms and stick with them.
Behold my mantra: “I am the Keeper of the GDD, Maintainer of the Docs, and Holder of the Key to all Editing Capabilities.” To preserve order, I am the only one who edits / adds to / removes from the design docs. It keeps everything in one voice, ensures proper use of terminology, and helps me know exactly what’s in there and where it all is at all times. I serve as the funnel through which the team’s ideas flow into written form.
Same rules apply to massive teams that have multiple designers: establish who is responsible for the writing and make sure those people maintain ownership.
Maintaining the GDD during production...
Keep the GDD simple and general, letting it build up slowly as production progresses. Only fill in niggly details after it’s been determined they’ll be part of the game. The game’s design will change a million times so don’t bother wasting words at the start.
Don’t forget separate documents!
I use Google Docs a lot, which can be edited live and are always current. They have a revision history, are easily linked to from the GDD, and are often looked at more than it. The GDD doesn’t have to be the documentation’s home, it can just be the hub.
Document all the text in the game
I spent 5 hours last week procuring all the text from a couple games because we decided to have it proofread for standard English. It wasn’t all in one place, some of it wasn’t current, and a lot of text was just entered right into the game and never even lived in a document. Shame on me!
If you ever want to proofread your game’s text, do translations, record some voice-over, or if you just want to tweak things, make sure all of it is easily accessible (i.e., you can quickly give the text to someone else at a moment’s notice). Dialog, tutorial text, descriptions . . . write it all down and make it easy to find. Learn from my mistake.
As I always say, “I don’t always retro-update my docs, but when I do, I update the in-game text.”
Keep sentences short
I write mainly for the programmer, who just wants something quick and organized. I save the lengthy paragraphs for when I absolutely can’t do anything to avoid it. Use bullet points and flowcharts wherever possible.
What Not to Do
Don’t write a GDD if no one needs it
Not every game needs one. I’ve gotten by with just a one page pitch doc, a set of storyboards, and a list of user stories. Or nothing at all. GDDs are a tool to help designers do their job and provide extended reference for team members who need it. If the game’s small enough it may not be necessary.
Don’t sort features by priority in the doc
Never have I ever! Design docs are a reference source, not a task management tool. All sections are arranged in a way that makes them easy to navigate. They are never labeled by priority.
To prioritize, I turn all the features into user stories, put them in a backlog, and rearrange them periodically as production progresses. If anyone wonders what’s coming down the pipe, they look in the backlog.
The GDD is not for communicating new designs to the team
Face it, no one actually wants to read your lengthy GDD all the way through and you can’t make them. Going into a meeting, always assume nobody read it. I try to communicate the game’s design through more reasonable means instead.
I talk with my team, show off prototypes, draw on a board, and then at the very end point them to the GDD as a reference for when they need it. Everyone ends up with the same clear vision of the game. When the time comes to start making features, I direct them toward the specific sections they need to look at for each feature.
It’s a lot of paper to waste so everyone gets a copy of something that’s going to be outdated in a few hours. It's more trouble than it's worth. GDDs are living and breathing beasts, after all. I never do it and no one’s ever asked me to, so there you have it.
Hold back on retro-updating the GDD to match the current state of the game
Feeling tempted to go back and update the GDD to match what’s already implemented? I always ask myself first: is it necessary for me to document this? Is anyone on the team going to need to read this in the future? If so, do it. If not, ignore it. Let sections of the GDD die a natural death as features are added to the game, only focusing on the new and important things you need to write about.
These are just a few little philosophies of mine to keep documentation alive and useful. The best advice is to talk to your team and find out exactly what they need and be adamant about maintaining docs in a manner that meets those needs. You will end up with a nice, customized system that works for you.