Insert Coin & Press Start: A Guide to Conceptualizing Your Game
I’ve found that one of the hardest parts of game development is at the very beginning: it's the part where the team selects what kind of game we want to work on. Sometimes there’s a lightbulb moment, where someone has that one special idea that resonates with everyone else, while sometimes it’s a painful and extensive series of brainstorming sessions that end up going in circles and getting nowhere. In my experience, it’s usually a combination of both, although to what degree depends heavily on the team.
When working solo or in a small team, it’s very easy to simply do whatever you, the individual, want to do. On the other hand, a team gains productivity with each person you add, as well as a unique perspective. That unique perspective, however, comes with preferences, biases, and interests that have to be worked around to some extent. As a designer who specializes in systems and mechanics, I often find myself feeling weighed down by the semi-self-imposed burden of trying to find a magic solution to satisfy everyone.
While searching for the platonic ideal of a game is literally impossible, I do have a process for how I like to approach the process of narrowing down concepts. It's something I've come up with myself through experience, although I wouldn't be surprised if you were to find a similar but better process in an article somewhere on the internet.
A bit of a disclaimer, but you'll want to do these steps on your own in the window before brainstorming with the rest of your team. Every situation, every team, every game, and every person is different, so feel free to modify and adjust this process as needed.
Step 1: Identify the Variables
The first step is to identify certain pieces of information in order to narrow things down as much as possible. To do this I ask myself, as well as my teammates, a few questions.
How long do we have to develop this?
What are the specializations and skills of each teammate?
What kind of games does each teammate normally like to play?
Which genres would each teammate be interested in working on?
Are there any specific mechanics that a team member is interested in working on?
None of these questions should be very difficult to answer (I would hope), so start off by getting those answers. Have you gotten your answers yet? Hold onto those for just a second, we'll use them in the next step.
Step 2: Restrict Yourself
There's this idea that limitation breeds creativity, and it's something I agree with wholeheartedly. Hell, I'd argue it's possible to prove this idea true through an overwhelming amount of evidence. Instead of getting sidetracked by that, I'll give you just one iconic example: Mario's iconic character design includes his hat, mustache, and overalls due to the artistic constraints that came with making sprites for an arcade machine in 1980. There simply weren't enough pixels to give him hair, facial features, or pretty much any other outfit. I'm not going to spend too much time on this point, but I'd like to hope we can all agree that Mario is one of the most instantly recognizable characters in all of media. Long story short, the limitations imposed led to the creation of the Mario that we know and love today.
I share this anecdote about Mario to give context, since it may sound a little bit counterproductive when I say that the first step of this process was performed in order to determine which constraints I put on myself. Allow me to try and rephrase, since even I think that this wording can come off as a little eyebrow-raising without more explanation.
Something I learned over my summer internship (which I really should make a blog post about) is that a design problem becomes much easier to solve when it gets rephrased as a design question. It's like algebra; you can't find the value of x until you have several other numbers to work with. In this case, the "numbers" are the answers to the questions identified in Step 1. Let me give us a simple example of a potential situation.
You are on a small team of around six members and have six months to make a game.
The genres the team is most interested in working on are puzzle games, platformers, or first-person shooters.
The artist is particularly interested in animating non-humanoid characters.
One of the programmers has been toying around with VFX and particle systems and really wants to work on a game that allows them to work on a decent amount of those.
Given the situation presented above, could you create a concept that accounts for all, if not at least a majority of the conditions presented? With these admittedly light restrictions, there are countless solutions.
In a real-world situation, you'll have far more factors to worry about than just these four. It's quite likely that you'll have dozens of conditions to consider, even on a smaller team. Once you have thirty-something different conditions, the likelihood that you can create any one game concept that will satisfy all of them drops sharply. You may wind up with conditions that directly contradict one another, and it will become impossible to make even one game concept to serve as a cure-all. That's okay.
Step 3: The "Solution"
After writing out every constraint, it may (or may not) be impossible to find a way to check off every box. Whether that's true or not, your goal here is not to make one magic solution, but to make as many as possible. If you have 40 restrictions, go ahead and make an idea that satisfies 30 of them. Or 20. Or 10. However many you're able to fill in. Done? Make another concept! After that, make more! Continuously switch up which combinations of conditions you're addressing at any given point and you'll soon find yourself with a wide range of diverse ideas.
The ultimate, prevailing truth is that there will never be one perfect solution guaranteed to work for your team, even if you meet every single one of those countless conditions you've just imposed on yourself. It'll certainly improve the odds of that one idea making it into the further stages of discussion.
Game conceptualizing is like dating. What you do and how you prepare will always influence the results to some extent, but in the grand scheme of things, it's just a numbers game (and that's another truth for ya). In a similar sense, I can't show you how to find "the one", but I can show you how to start searching more effectively... it's just in this case, you start by making a bulleted list, which is where the dating analogy falls apart.
Step 4: Feedback
The final step is the most simple, and yet, it ends up being the most difficult one. Take the ideas that you've created and pitch them to your team during brainstorming. Bounce these ideas off of your teammates during the discussion, chipping away at the rough edges as you polish these concepts into gems.
There's no way to guarantee that your team will select your game. Again, that's fine. If your goal is to ensure that one of your ideas gets selected, you're probably not being a very good team player. This is simply a guide on how to get started with conceptualization since a lot of people find it hard to be creative without a topic, conditions, or restrictions.
So that's my process. It's not too hard, right? Alright, that's where the guide ends, so if you were just here for that, bye-bye! It's time to talk about me. I had to recently apply this method since I've just started working on my Senior Capstone with my new team. We've been sharing ideas in a Discord server I set up for us as they've popped into our heads over the course of the summer and stockpiling them for the future.
Well, the future is now. School is in session, and we had to take our favorite ideas and pare them down to decide what projects we want to begin prototyping on. It was during our early meetings where I used those questions in Step 1 to set up the restrictions from Step 2.
We have 12 weeks of the semester to make a polished vertical slice of a game. We have strict deadlines, and fully intend to focus on polish over scope.
Over half of the team expressed interest in a character action game or a roguelike, although each member has an interest in other genres.
Our artist specializes in character art, so our game needs characters to design.
Our programmer enjoys taking on big challenges and wants to do something unconventional, difficult, and/or unique. Our game needs a twist.
The designer other than myself is specializing in level design. Our game should include systems and mechanics that allow for interesting level designs.
I'm a systems/mechanics designer with an interest in QA, so it's important to me to have a game intricate enough to keep balancing, testing and improving.
Our game will not be multiplayer, since we don't want to deal with networking.
Our game will not be VR. Finding VR testers in a pandemic is nigh-impossible.
These are the main factors I considered, although I can assure you there were plenty more, like the fact that any narrative design will likely end up being my job. Using these restrictions, it made it a lot easier to trim down all of our ideas (as well as combining some ideas we had already saved up), and as a group, to build off of them, until we had several ideas that we were happy with and a few that we were really happy with.
If you're wondering what the biggest challenge of these bullet points was, I'm happy to inform you that it's the fact that we have 12 weeks. Obviously. My personal benchmark was to look at our main competitor(s) based on our mechanics and ask ourselves if that's something we think we could do better, given the time restrictions. For example, we had one idea for a shipbuilding game, but our main competitor would be an incredibly elaborate game that had more people working on it, as well as the fact that it had been in development for six years. Scratch that one off the list.
The second biggest factor I considered? The individual motivation of each team member. It's a very close second, but I have to put it second because if there was something all five of us wanted to do and it was severely out of scope, then that's simply not an option. Sorry, but five college students can't make a AAA title in 12 weeks. Scope aside, motivation is one of the highest priorities when developing any game. It impacts productivity, reduces burnout, and if you ask me, you can tell when a team is passionate about their game when you play it.
All that said, it's not my place to have the final say on what my team is interested in. During discussions, those are the factors I took into account when discussing the pros and cons of our game (as well as whether the gameplay loop would actually be fun, but that's neither here nor there).
So yeah, you can break it down into more easily digestible chunks, but it's still a really complex process when you zoom out and take it all in at once. Y'know, like algebra. I don't believe that it's possible to simplify the process down to just choosing between binary pairs of scope vs. time, your interests vs. the team's interests, or anything else like that. It's a complex, multi-dimensional process, and for a systems/mechanics designer who tries to consider every possible variable like myself... it's a pretty damn tiring process.
Speaking of tiring, I've been writing this blog post for... several hours. I got a little carried away and now it's past midnight, so I'm off to bed.
Good night, good morning, or good-whatever-time-you're-reading-this-at,