Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Game Dev and Scope

I have a story to tell. A story you’ve all heard before. A story you’ll all hear again.

A young person from some other creative field gets curious about game dev. They decide to give it a try. They download a popular engine and start playing around. Their artistic instincts serve them well and they make something really neat. They show it to a few friends or a niche community online to positive but modest reception.

As they continue work on the project, they acquire an informal mentor — someone with some game dev experience. They start sending updates to the mentor regularly, partly to solicit advice but mostly to show off. The mentor supplies the praise the new game dev craves. The mentor also provides some small bits of advice, some of which are ignored, rightly or wrongly, and some of which blow the young dev’s mind and cause an immediate spike in productivity, quality, or both.

Production continues along for some time, but the new dev notices that the mentor is getting a bit anxious. The mentor keeps talking about “scope” and “focus.” The new dev understands these are important concerns – or at least assumes they must be, since the mentor brings them up more often then they offer praise at this point – but the new dev is still flexing their muscles and exploring the landscape of what they can do. Innocuously, the new dev mentions adding a new piece of dialogue that “foreshadows something that will happen later on, in Act III or IV.” The mentor seems to grow pale at this (which seems odd, because the twist in Act III is going to be amazing). The mentor sheepishly asks what act the game dev has worked up to. “Well, I’m still working on Act I of course. This is all just the beginning!”

The mentor again, politely but forcefully, brings up “scope.” They point out that the speed of production has slowed lately. “Well, sure, it’s slowed down a bit. I’ve been busy with other things.” The mentor asks if that’s the only reason things have slowed down. “I suppose it’s getting harder to track down all the if statements I need to modify to make a change.” The mentor doesn’t seem surprised by this, as if they somehow magically know what the code base looks like without ever having looked at it. It seems like they weren’t even asking to learn the answer, but like they were trying to get the new game dev to admit something to themself.

The new game dev doesn’t get what the big deal is. The mentor again, exasperatedly, emphasizes the problems of scope. Despite trying to avoid jargon, they let slip the term “technical debt.” They talk about it like it’s a real, physical danger — like it’s a monster the new dev needs to avoid and not a bizarre mangle of terminology from finance and engineering, two disciplines that could not be of less interest to the new dev.

The new dev understands there must be some issue here, but is mostly reacting to the urgency with which their mentor is speaking rather than to a problem they perceive. They make an honest promise to reduce the scope. They omit specific details in this promise. Privately, they imagine that they’ll have to move the twist up to the beginning of Act III, or perhaps even the middle of Act II, given how bad this “scope” thing sounds.

Weeks go by. Production slows to a crawl. The mentor starts checking in with the new dev on their progress, rather than waiting for the dev to chime in with something to brag about. It becomes something of a sore point between the two of them — the mentor isn’t the dev’s boss, after all, and they both know this. Besides, it’s just a hobby project — there’s nothing wrong with dropping the whole thing. Still, the new dev seems to find less and less time to work on their game. It used to be fun, but now it’s tedious and, somehow, scary. They fear making a change that will break all the work they’ve done before. At the beginning of the project, this was no big deal — in fact, it was kind of exciting. They were making a game! They were doing things! Now, they don’t have a game yet. Not really. But they have enough of a game that they’re afraid of losing what they do have.

Yet more weeks go by. When the dev and the mentor talk, they talk about the game only in the abstract. Mostly, they don’t talk about it at all. The dev has been avoiding working on it, and at this point it’s too painful to even open the project. The only thing that might be more painful is losing the game altogether. Finally, in a fit of either inspiration or desperation, the dev takes a look at the game they were working on. Their eyes widen. Their heart palpitates. They don’t understand a single thing in this project anymore.

Oh, they remember the game — they know what happens in it. They know how to play. They rediscover some little details they added that they’re still proud of. They like the way the game makes them feel, and they like to imagine how it will make other people feel when they play it.

But they don’t understand a single thing in their project. They don’t know how to make a single change. They don’t remember where anything is — what anything is. When they started, it was like learning how to use a forge to make a sword. Now, it’s like they’re using an active volcano to melt a handful of iron shavings. They face an impossible decision — wade into battle with the complexity they’ve created in the hope of eking out some meager progress, or start the whole project over, and slowly, painfully, thanklessly recreate the whole thing just to get back to where they were. Now, they see the monster. Now, they have to choose whether to face it.

Tragically, friends, the story ends here. The fate of that game, and countless like it, remains undetermined. Perhaps, one day, it will be rescued from its terrible predicament. But perhaps the monster will claim another victim.

Based on a true story that has played out too many times.

Support this post

Did you like this post? Tell us