two game studios behind two highly anticipated games announced those games' cancellations within the last couple weeks, those being indie studio Tendershoot's Dreamsettler, the ambitious sequel to interactive fiction/internet simulator masterpiece Hypnospace Outlaw, and Riot-funded Hypixel's Hytale, a Minecraftlike that was in development for over seven years. the major problem both of these studios cited was unchecked ambition (a desire to make the best game ever) and thus building these giant, untenable concepts and systems that ultimately demanded too much from the people working on them. the Vision can be so intoxicating it destroys any chance of a person actually making it real.
I want to give an extended answer to this question my friend asked me:
do you get scope creep feelings? how do you process them if so?
to quickly outline the term: scope creep is a process by which the hugeness of a project grows and grows out of control, until it is no longer workable, as the people on the project are repeatedly struck with an insidious brainworm: "the project would be way cooler if we just added this one thing...". eventually the project becomes a clusterfuck of mostly cool new things that suffocate a now unrecognizable Core Vision, and often it is never finished. this has happened to you.
this article makes a lot of assumptions. one is that you are or you know a game developer or some kind of artist or craftsman or architect who works in a medium that requires a lot of time and effort to produce a single finished work, and you do care that these works generally get finished and maybe even shared with the world. if you're someone who is cool with taking your time, not worried about the finished product, and just making yourself happy adding a bunch of little things to a big thing, keep doing that. ignore any advice you know doesn't apply to you.
do you get scope creep feelings?
I get scope creep feelings. I deal with them all the time, for every project. I don't think they are avoidable. obviously we all want to make the best game ever. but the game in your head will never exist, so you have to compromise with reality.
there's always stuff that gets cut in the idea stage, stuff I'll rip out of a game fully finished, and, in-between, a whole spectrum of scaling back cool ideas that are unjustified uses of time and effort, time and effort which could be better spent realizing the Core Vision.
how do you process them if so?
most games are about killing dudes. Given the right context, killing dudes is very cathartic. why shouldn't that be true for killing ideas, assets, code, features, etc?
throwing things out doesn't have to be a bad thing. it's a part of life. when I started learning in adulthood how to cook, I threw tons of food away. maybe because i made something inedible, or i bought too much and it went bad. over time I began to develop a positive relationship with throwing food away, because it meant I was cooking.
after a short period of grieving the cool new thing I won't be using in a game anymore, I find it easy to focus on the positives. there are plenty of advantages to cutting out a feature in a game. the most obvious and practical thing is that you reduce the workload for yourself. lower workload means you can spend more time on the stuff that really matters. consider all the loads of clusterfuck games that did release and still suck because they couldn't reign it in and focus on the Core Vision.
I have developed this mindset over years and years of fatally overscoping. I started programming in 2015 with the goal of making games. each project was ridiculous. one of my first projects wanted to be similar to Cataclysm DDA. a 2018 project was supposed to be a Smash Bros—like. there are so many examples like this. I didn't finish my first game until 2021 (six years of nothing!!!) when I began working with PICO-8, a game development environment that intentionally imposes very strict limitations on the developer, and it forced me to keep my scope reasonable. I finished that game in about a month.
some people feel like their time is wasted when they reach a dead end and they have to backtrack, that it is a negative outcome to be avoided. many are led to a scarily prevalent sunk-cost feeling and grow attached to bad ideas just because they fear scaling back so much. I just don't think this is right. backward progress is still progress. it's surely not as efficient as realizing your vision of the game perfectly from start to finish, but nobody can actually do that. realizing you've scope crept and scaling it back is a natural part of working on a complex system. it is just a thick branch in a tree of mistakes—you don't keep a wrong algorithm in your code, you take it out and replace it with something else or nothing at all. you don't leave in typos.
when scope creep happens you just have to focus on what you can get out it. what assets can you reuse? what ideas can you extract? if nothing else, what did you learn? I don't remember a time when the answer to all these questions was "nothing", so I posit that it's never truly a waste. the Hytale developers will move on having if nothing else learned a very important lesson.
It is important to note that I'm not against adding easter eggs and fun stuff just because. that's what games are made of. I just think a game designer can benefit from weighing the time and effort cost of adding (or keeping) a feature with the amount of substance it adds to the game, how much it helps to complement and complete the Vision.
the process
recently I posted this to bsky:
I followed up with:
> don't make a big game until for you it's a small game
and I want to elaborate a little bit.
first off, I think if you know what you want to do, you should do that. if you are willing to do what it takes, and you can afford to do it, then you should make the ambitious game of your dreams. I'm only asking people to consider what they want, if they haven't already, and if they are willing to really work for it, and if they really know that they truly are willing, and so on. but I know I don't really need to say that to them, because the people who know what they want don't need me to tell them what they want. that leaves the rest of you suckers. especially those devs in question burning themselves out on big games—I only want to suggest an alternative that can be just as fun and much lower stakes. I have outlined a 2 step process:
step 1. when you are deciding on a game concept, it can be difficult to know how big of a game you can make. I have a radical solution: look way, WAY smaller than you think you need to. unless you are an absolute newbie, there is definitely something you know you can make without question. maybe that's pong, or even breakout. something of which you can envision the entire structure before starting any work. 100% confidence only. make that thing. if you are an absolute newbie, or you otherwise don't have 100% confidence in pong, skip to step 2.
step 2. when you are done making that thing, it's time to do something completely antithetical to this blog post so far: start up a project with a big vague idea, experiment, add whatever you want without any thought to maintainability or even finishing the game. if you are the aforementioned absolute newbie, this is where you make pong instead. you (probably) will not finish the game, but I think this is the best way to safely push yourself without heartbreak. it will give you an idea of what you are capable of, so when you return to step 1, you will notice that you are able to envision a slightly bigger entire game than you were last time. maybe substantially bigger. that's it. return to step 1.
this is the process I have come up with accidentally over the last few years. accidentally because step 2 was always supposed to be step 1. it was always a feeling of, "okay, enough with these little projects, I'm going to make my opus, my Real Game. this time I can really do it." then I noodle around for months and drop the thing because either it's just too hard to implement the big ideas by myself or I just don't have a cohesive enough idea to hold together such a big scope. subsequently, when I go back to making small games, I realize that the biggest game I'm 100% confident in making just got a little bigger.
I have been, entirely by mistake, employing what I now believe to be a highly effective strategy for self-learning and improving my skills, and maybe even for eventually getting to making that big game my kid self always wanted to make. I present it, modified to reduce suffering, for anyone to try.
ethics of the opus
something i feel is important and kind of overlooked is that games take a really long time to make, when compared to most other forms of art. the barrier to entry is already really high. a 3 month timeline is on the low end for a finished game, outside of time-constrained game jam challenges which don't really work as a real development strategy for "full size" games. I estimate most indie devs working on long term (non-gamejam/tutorial) projects are spending about a year or two. imagine if it took that long to write a single song, or paint a single picture. we are at a disadvantage in that way to composers or painters, because we only get so many two-year periods we can make games before we die or otherwise lose the ability. I suggest that it is inhumane to expect each other to meet a standard like that. life is very short for a game developer. we have to be much more picky about how we spend our time than a painter or a songwriter. we have much fewer chances to find our voices. this is, I think, maybe the most important reason for one to consider making smaller games.
bottom line: check out PICO-8