As with every person who is extremely passionate about doing a creative project, it is extremely easy to think big at the beginning. It’s fun to let your mind wander over exciting ideas and around intertwining possibilities. We are taught that brainstorming is the first step to solving open ended problems. And we reinforce the concept of brainstorming on nearly a daily basis. For example: I’m hungry - what should I eat? Burgers? Pizza? Chinese? Go out to a restaurant or stay in and cook? You could probably come up with a dozen options. The thing is, this is actually a pretty large “chunk” of a decision that is based on only your desires at that moment in time. Once you’ve chosen “Let’s order in pizza,” it’s a pretty simple process of ordering your favorite style online, paying with a credit card, and waiting 45 minutes for it to arrive at your door. It’s easy to whittle down the decision because 1) you know your audience and 2) you’ve done it before. It’s easy to make decisions when they are black and white.
It’s much harder to make decisions when every option is a shade of grey with sometimes nebulous pros and cons. And we - as creatures of habit - psychologically steer away from those hard choices. And those choices are even harder when you have no experience and when you’re trying to satisfy hundreds if not thousands of people. No one leads you by the hand on how to make a smash hit video game. No one has all the game dev answers. On the other hand, that pizza company’s mobile app will happily guide you through the purchase of that large, pepperoni, deep dish pizza...for about 20 bucks. All the anxiety and hard parts of food selection removed for a bit of your hard earned cash. I’m sure you’ve seen publishers and tutorial makers do the same thing. But there are always parts that you can’t pay others to do (on any realistic budget).
So what am I getting at here and what does this have to do with huge game scopes? Game scopes are a function of a few things: 1) Intent to please an audience, 2) inexperience in understanding resource planning and 3) the avoidance of hard ideas and decisions. Each of these pieces builds part of a “scope snowball.” And each new piece of the game you actually implement melts just a little bit of that snowball. We want to make sure we are only putting energy into the parts that either make it to the final product or teach us something useful for the next iteration.
Intent to Please the Audience
A game developer’s end goal is always to have gamers play their project, enjoy it, and come back to it again. No one makes a game to have people play for 1-2 minutes, get bored and then go back to swiping through Facebook. One way to combat this is to pack more features into a game. You know - just to have it. If there are more things to do, at least the player will have more aspects that may pique their interest and prolong their play time. In the same vein, when developing a game, you think back on other games that you’ve played and said “if only my favorite game, X, had mechanic Y.” RIght there. You’re adding scope. I get it - you’re excited. You have this perfect vision of a game in your head. But this is the initial ball of snow to your scope. I’ve been there, too. My first game was an ARPG with a crafting system, modular worlds, dynamic storylines, and cell shaded art. Spoiler: It never got finished. But, who can really blame us for wanting to give as much content as we can to our players? The loudest of the gaming audiences are asking for more from the get-go and aggressive content updates. AAA companies are doing it - why can’t you? Literally not having enough time in a day even at sweatshop production conditions is the main reason. Us hobby game devs aren’t machines!! But, again, that’s the *loudest* gamers - the vocal minority - not the majority of gamers. Yes, they might be the most engaged, but that shouldn’t distract you from the fact that there are plenty of others out there who might be enjoying your game just the way it is (bugs and exploits excluded).
Inexperience in Resource Planning
After the snowball is formed, it starts to roll and pick up more scope. What gets it moving? Not understanding the breakdown of time and resources for each part of the original scope as well as the desire to take every piece of feedback as gospel. As a developer, the learning never ends. Especially when first starting out, it’s a whole world of new skills to learn. How long is making your 2D pixel art main character going to take? Seems simple enough. Maybe two hours, you say to yourself. But then you realize you don’t know what program to use - Photoshop? GIMP? Krita? Then you need to download it, figure out the interface, figure out the workflow, figure out the color palette, figure out the animation process. Then you still have to decide how many animations you’re going to have and how to intelligently import that into your game engine. The list goes on. What should have been a 2 hour exercise is a weekend long, probably grueling trial and error tutorial. And it’s like this for every tiny detail of your game. You know how there was a pizza company willing to give you perfect pie for 20 bucks? That’s because they smooth over every little bump in the road for a piece of your hard earned money. Well, there is no direct equivalent for every cog in your game system. Sure, maybe you get pay for a couple assets, but unless you’re extremely well off in the first place, you’re going to have to get down and dirty, learn the programs, research the best workflows, and do the time yourself. Say you have 10 major mechanics to your game and each mechanic has 5 smaller workflows. If each workflow takes (an extremely generous) 2 hours, that’s 100 hours just to learn the process. And if you only get (another generous) 10 hours of hobby time a week to make your game, that’s 10 weeks of work. I’m not trying to discourage you to doing this. In fact, I say revel in it. Part of being a hobby game dev is being a lifelong learner. Development technology and game mechanics are constantly evolving. If you can embrace the change, it makes it much easier to tackle each obstacle. Again - not trying to discourage anyone. It’s just to make you aware that as a hobbyist, to get a final product out the door, you’re going to have to understand the amount of time and effort your project will take if you try to create the next MMO.
Aversion to Hard Facts and Decisions
The aversion to hard facts and decisions is the hill that your huge ball of snow is now traveling down at near terminal velocity. The hill can transform into being completely flat...but you’re probably going to have to kill parts of your baby to hammer down the slope. It’s not pleasant, it rarely gets much easier, but something’s gotta give and it’s that character upgrade mechanic or the dynamic dialog system or something equally as precious. In my opinion, this is by far the hardest of the three scope snowball aspects to overcome. Loss aversion shown that people dislike losing something more than gaining that same thing. And killing that awesome mechanic is no different. Also, let’s examine the Project Management Triangle, below.
The Project Management Triangle
You have time, quality, and cost..and you have to choose two. This is something project managers have to deal with daily. As someone who has worked at multiple big companies, even 20-30 year veterans get it wrong a good amount of the time. In our case, we have limited resources and it’s better to have a small, polished and completed project than to have a quarter built MOBA.
Minimizing the Snowball
So, how do you mitigate making a snowball rolling down a hill situation?
My advice on “Intent to Please the Audience” - Know who your audience actually is. Is it the inventory management lovers? The twitch-reaction geeks? The story aficionados? If your audience is “any gamer” then you’re bound to try to include a bit of everything in your scope to try to satisfy them. Figure out the detailed audience profile and build a game based around one mechanic only. Why just one mechanic? Because with the release of a full game, there are so many other moving parts that you have to also build - ones that aren’t even game related! That one mechanic probably won’t be your biggest win by the end of the project. The most important “aha! Moment” will probably be understanding how all the cogs fit together. Things like UI/UX, player data saves, deploying to multiple devices, uploading to various websites and servers, customer feedback, and advertising. You’re not going to please everyone with your first game, but get the experience of going through the motions of a full release. That way, you know exactly where your weak points are to focus on in the next game. And I don’t mean “one mechanic” as “make your player able to jump” - it’s more of a way to encapsulate the smallest core gameplay loop you can and discard the chaff.
On “Inexperience In Resource Planning” - This is the “you don’t know what you don’t know” section. The short answer is, fail fast and iterate on small projects. The more you go through the whole process, the better you will become at determining how long specific mechanics or art take to develop. If you keep creating huge, partially made games with no polish, you won’t be able to get a feel for what the polish step looks like or how pushing the build to a live server feels. Alternatively, going into a project where prototyping mechanics for the experience of just learning that system is also worthwhile. The important aspect of the prototype phase is to not build those extraneous features. If you want to practice making an FPS movement system, I’d suggest not making a level editor at the same time. In fact, if you can polish the mechanic so that it’s drag and droppable into a wider ecosystem/game, that’s even better. I’ve done a lot of reinventing the wheel (I’m looking at you Input Systems) and after the 10th time of making that wheel, I’ve finally put together a halfway decent one that fits most use cases.
On “Making the Hard Decisions” - I think understanding the Sunk Cost Fallacy is an important turning point to this aspect. Know that some things aren’t worth the time to salvage even if you’ve put 100+ hours into it. And not to get too Earth Mother on you, but it’s also a lot of introspection and understanding your own weaknesses. You’ve put yourself out there and in today’s society, sometimes it’s all out there on the internet. You might publicly fail and that’s scary - so you keep on grinding out the project hoping it will turn around. That’s why starting out with small stakes - a single mechanic game is important. It’s all about setting expectations. If you set out to make the next Mario game, you’re putting that much pressure on yourself. It’s suppose to be fun! That type of pressure squashes the enjoyment right out of a project. If you make a single mechanic game, it’s much easier to shelve it because you’ve only put 20-30 hours into it instead of hundreds. It takes courage to be candid with yourself and say “This isn’t working.” You can’t attribute it to you being a failure and telling yourself you aren’t good enough. It needs to be reframed as it being a learning process and that it’s OK to have not understood or mis-planned. When you’re reading through the Unity documentation and you’re feeling frustrated and getting a slight headache, that needs to be mentally transformed into “this is what learning feels like. This is me bettering myself.” Just like working out makes your muscles ache, learning makes your brain ache. And at that point, you have to pat yourself on the back and say - I’m doing the heavy lifting right now. Every time you do it, it gets a little bit easier. The more you can forgive yourself, the easier it is to let go of all those mechanics that you’re trying to impress people with. This enables you to kill off extra scope and put something out that a specific audience can enjoy. And this is important because an audience of one for your completed, simple game is better than a complex game with no audience. And throughout the process of that simple game, you’ve gained valuable skills for the next game...with two mechanics.