Summary:

In this article I challenge the notion of scope creep, saying that those that “warn” about it are incompetent and inexperienced morons that have no idea what they are doing and causing harm by stifling innovation, making people needlessly demotivated and misinformed about what they should do.

I suggest to people make their dream games as their first game right away and to do something I call Scope Maximization, where the game designer is actually encouraged to embrace scope creep to their hearts content right from the start. It may sound paradoxical, but there's a cool trick to it.

–

What is a scope creep in game design?:

Scope creep (sometimes known as “feature creep”) is when an incompetent game developer is trying to actively “design” their game while already fully building it with code, writing, art and sounds.

Usually the developer has either:

1. Entirely skipped, disregarded, downplayed and ignored doing a proper design phase.
2. Rushed, half-assed, half-baked or otherwise did their design phase carelessly and superficially.

…and then went straight to building it as a full game, not even as a test case prototype!

It's essentially the equivalent of someone trying to build a house on the go and writing the blueprint afterwards or writing it while they’re actively building the house.

It is the epitome of stupidity and incompetence and results in bullshit equivalent to this:

Imagine the same as those but with game projects.

I hope you can see why I'm upset by people that do this stupidity and why I use such harsh language. If people mess up their game design in this way, nobody benefits in the end.

How does scope creep happen?:

What happens is that the developer notices design issues with their game as they are building it and they come up with quick half-assed solutions in an attempt to fix them.

They also come across new exciting ideas they hadn't thought about previously and try to forcibly add them into the current project, regardless if it conflicts with its existing systems, mechanics, features or content.

In the process they may forget about the purpose of the project or fail to even have one at all, causing them to coast on a vague blurry thought of what their game should be. In other words, they don’t really know what the fuck they’re making.

More accurately, there is no real game design in their project; they’re just attempting to brute force their game into something “good” by working hard - be it in a:

• Stubborn way (“maybe it’ll eventually get better if I keep pushing it!”)
  
  
• Desperate way (“I must get this done as fast as possible, the deadline is crushing me!”)
  
  
• Ignorant way (“Haha video game go brrrr, who needs design anyway?”)

Or in an otherwise careless way - often being hypnotized too deeply by their current momentum/flow/work streak to stop, sit their ass down, pick up the pen and paper and actually take game design seriously.

This results in:

• The game becomes more convoluted in its mechanics, the opposite of being streamlined.
• The game gets bloated with incohesive features that don’t play well together.
• The overall direction of the project becomes aimless, harming motivation long term.
• User Interface and User Experience (UI/UX) becomes a clumsy disjointed mess that constantly has to be redone and reworked to adapt to the new features, sometimes requiring major overhauls and tons of extra work, while flushing down old efforts down the toilet because that work had become worthless. Worst case scenario the developer just leaves the UI/UX as is, with all its faults and awful organization, just layering more and more stuff until it becomes completely unusable.
• It becomes progressively more difficult to add new things into the game due to the feature creep causing asset requirements to grow out of proportion due to lack of standardization.
• The project becomes harder to maintain when something inevitably breaks due to said incohesive features and aimless direction.
• The code will often begin to contradict itself. This means weird hacks are required to awkwardly glue together different elements to make the game even work, making the project more unstable as time goes on.

Scope creep has become a false boogeyman that makes the entire games industry worse:

As you see this results in a total mess, the project often fails in some form or another and the incompetent dev goes online to cry about how feature creep is a bad thing. Sometimes the failure isn’t about the project not gaining popularity, but about the wasted potential it fails to subsequently capture that was there in its core, even if just conceptually.

This has resulted in the common narrative which says that "scope creep or feature creep is bad and you should avoid it, keep your games limited, small and highly restricted".

The problem with that is now we get games that have no ambition, no expansion potential, no longevity and no innovation because everyone has been scared shitless by this manufactured scope creep boogeyman.

At no point did anyone who said this come out and just say that they’re actually incompetent and inexperienced because that would make them look bad, so they chose to tell a lie to save their face.

Both old and new aspiring game developers and game designers are essentially discouraged from making their dream game as their first game - which, motivation wise, IS the main fucking reason why they entered the games industry to begin with - outright telling them to not work on it, but wait until some unknown time in the future (when? maybe never?), telling them to first make copies of existing and old games as “training”.

Not only this is demotivating, but I advocate the very opposite of this; if you’re new to the industry and you came here because you wanted to make your dream game then that should be the first project you work on, with the caveat of figuring it out how to make a scaled-down version of your dream game that is feasible for your skill level and knowledge.

You learn to make the dream game by making the fucking dream game. You figure it out, you use your head, you adapt and investigate, finding a path to make some kind of version of it that is feasible/possible.

Newbies that directly start with their dream game are the ones that make the coolest, freshest and most fun games, even if they’re badly put together or have lesser audiovisual presentation compared to someone with more experience. Do not rob them away from their dreams and don’t rob me from being able to enjoy their early amateur stuff, no matter how initially scrappy it might be.

A dream game is often a dream game because there was something really inspiring and exciting enough about it to consider jumping into the unknown to pursue it. That shit needs to be nurtured, not stomped down dismissively.

I don't like this scope creep fear mongering trend at all. My hope with this article is to let you see an alternative perspective on the issue. I’ll do my best to explain how to master it as concisely as possible.

This won’t be a comprehensive deep dive, but something quick to give you an overview of how it looks in general. In future articles I may show what the design phase of a project looks like with examples and more detail.

Do not fear scope creep, master it instead:

In the beginning of a project - during the very initial stages of it - everything starts off with nothing more than just an idea or a vision.

Stop, do not immediately open up the game engine and start building anything yet.

Instead, you must begin by charting out the maximum range of possibilities the game project could potentially have during its entire lifespan. Don’t rush it, spend plenty of time on this and write your musings down in whichever way is most comfortable to you - either pen and paper, a notepad txt file or a rich text document.

The act of doing this is incredibly cheap and quick in itself; writing or typing out words to get your thoughts and doodles down onto paper or documents is the fastest, easiest thing that you can humanly do without needing to construct anything, pay for anything or put any amount of considerable effort. Use this to your advantage.

Most commonly you’ll have your pen and paper but then hit a gap in knowledge and don’t know how to continue; that’s your cue to hit the internet, go outside, check the library (of any kind, anywhere, online and offline), draw doodles, play games, watch movies, go on adventures, go experience something inspiring, do something fun or anything else that might relate to what you’re doing. By “procrastinating”, going on walks or searching information actively, you’ll eventually bump into something that is just good enough to give you the next step in advancing your design.

During this phase of initial design work, use whatever means to gather information, test out theories, build throwaway quick prototypes or ponder the viability of certain content and features. You must also explore the limits, restrictions and quirks of the technology you'd theoretically want to use for your project to identify if anything you've planned is viable or not for you to implement once it comes time to build the game according to the designs you've created.

I can not stress this enough; spend time here and do not rush it, the time and patience invested here will pay itself back many times over. It's also cheaper to do it here than it will be later; you may appear slow at first, but with a good design, the pace of your work will be blazingly fast compared to if you’re trying to just brute force it.

Do not begin development of the actual game until a great degree of confidence and cohesion is achieved within this so-called “scope maximization phase”. Do not write meticulous details for final content or systems! Keep things general and flexible to change, yet still cohesive (the final feature may somewhat look different in the finished product, but its original core intent will remain the same).

Once satisfied with the full potential of the project, you can begin developing the game in its absolute minimal, easiest, cheapest and quickest form.

The maximum scope figured out previously will serve as a clear roadmap for the entire future of the project, giving you a clear idea how to expand it after you’re done with the minimal skeleton version of it. The maximized scope will also keep you organized in having a better idea in what order each component of the project should be done and how.

You’ll be able to have foresight when building UI/UX stuff, knowing to leave room for things that you know will be implemented in the future, making the final result much more cohesive, elegant and standardized. Your players will thank you for it.

This "flexible generalized plan" of sorts helps you build out the game up to its ultimate full potential without neither overwhelming you, neither ending up in a dead-end which would require a full restart (for design reasons at least, technical implementation reasons are a different story), neither feeling terribly frustrating where you don't know where the project begins and where it ends.

You also will know confidently that your project has solid foundations to depend on which will give you a peace of mind. You will feel motivated, knowing your project is worthy of development and worth taking to its ultimate completion with great certainty. And best of all; you ARE working on your dream already.

Good design is immune to technical and other obstacles that you may encounter:

During development, problems will not arise from the game design itself if you did your preparational scope work correctly.

If you spend enough time and patience testing out your theories in limited prototypes, papercraft/tabletop/logical mind simulations and ensure your designs are mostly agnostic of any specific technology or platform you're supposed to use, the game design will remain flexible and adaptable without losing its core identity. Well crafted rules are immutable and universal; they’ll work great no matter where they are.

Instead, often issues and obstacles will originate from the technologies, platforms or other quirks that game design cannot account for, such as obscure limitations/bugs/quirks of the game engine you're using, the uncertain/limited amount of funding/time you can spend on building the project, legislative landmines that may state that certain parts of your game are against some arbitrary terms of service or contrived rules that were meant to stop other kinds of misuse. It happens. Whatever can go wrong, might go wrong.

In the event of these obstacles, the game design itself wouldn't need major changes; you'd only need to change how something is implemented.

Examples:

• Problem: Turns out the game engine can handle much less characters and items on screen than originally intended.

Solution: Reduce expectations and work with what you have; set a lower maximum amount of characters and items.
–

• Problem: Colliders on objects start behaving badly if they are too wide or too narrow.

Solution: Work around it; shorten objects or split them into connected segments.
–

• Problem: Spawning and removing objects from the game is causing a lot of lag that makes the game unplayable.

Solution: Look into solutions that work natively better within the engine, such as using "object pooling spawns" or other technical workarounds.
–

• Problem: A storefront declared that AI generated art is against terms of service.

Solution: Look for a better storefront that does allow AI art or replace the AI generated art with a cost effective solution so it meets those arbitrary requirements.
–

• Problem: My design relied on this third party plugin that got discontinued, deleted and is no longer supported.

Solution: You fucked up, this was something you needed to take into account during the scoping of your project to make sure either it could be done without it or that you could rely on the existing version from start to end even if something like that would have happened to it.

Obviously it's not your fault that something outside your control suddenly broke down, but you do have a responsibility for mitigating risks and to anticipate things to collapse abruptly and unexpectedly. Have insurance.

Always have a plan B and a backup. It's healthy to be paranoid about game engines, plugins, technologies, people and companies you rely on; more often than not, they are not there for you, they are there mostly for themselves. If you have an option to use downloadable installed offline systems, prefer those over the ones that operate in the cloud online.

Remember: Anything that can go wrong may go wrong, so plan around that and do risk mitigation as much as you can. The world isn’t as perfect or as safe as we’d like it to be, humanity still has a long road ahead before it can get there and I don’t think it's gonna be anytime soon. This is a part of being a talented game designer, a necessary skill to learn.

The lazy "Everyone has a plan until they get punched in the face lol?" argument:

I hear this particular tired argument very often when anyone tries to suggest preparation and planning for a project; it's honestly exhausting and naive to see it each time.

While the sentiment of "everyone has a plan until they get punched in the face" might hold some truth in unpredictable situations, dismissing the value of preparation altogether is shortsighted. Planning is not about predicting every possible outcome, but rather about building resilience and adaptability in the face of challenges.

Acknowledging that unexpected setbacks can occur is essential, but it doesn't diminish the importance of having a well-thought-out plan. A plan provides a roadmap, helps identify potential obstacles, and allows for the development of contingency strategies. It's a tool for understanding the terrain before entering the battlefield, enabling a more informed and strategic approach.

The key is to balance planning with flexibility. Recognizing that plans may need adjustment in response to unforeseen circumstances is part of the process. It's not about adhering rigidly to a preconceived notion but rather having a framework that can be adjusted based on real-time feedback and changing conditions.

In essence, the saying about plans and punches emphasizes the need for adaptability and resilience, not the abandonment of planning itself. A well-prepared individual or team is better equipped to navigate uncertainties, learn from unexpected challenges, and make informed decisions on the fly. So, instead of dismissing planning outright, it might be more constructive to emphasize the importance of a dynamic and adaptive approach that integrates both preparation and responsiveness.

This is why I adamantly stress the importance of not setting in stone the meticulous details of a game design but only working to define the general points to maintain the flexibility when obstacles with technology, storefront or other places occur. In a way, good design is paranoid design.

Creating unique characters, specific level layouts and other such final details only make sense after you have the framework and content creation workflow built around the limitations and quirks of the tech you're relying on.

In other words, the final form of the in-game content, systems, mechanics, features and auxiliary components in the fully completed game project always depend on the mutual dance between of the intended (yet flexible) game design scope you’ve created and the platform/tech/workflow you're relying on.

It’s a puzzle where you need to find a solution where both your game design and the tech you use is in good harmony.

–

Closing words:

My hope is to spark your mind to see beyond what is currently available.

Currently most tutorials or schools don't teach you this stuff. Even the folks that sincerely try their best will often still fall victim to traditions, hierarchies, narrow mindsets or lack of knowledge.

My patreon blog will keep talking about more of advanced game design topics in the future so be sure to bookmark or subscribe to it to be notified when a new one is released.

I can accept suggestions for topics in the comments and eventually those can be voted on in polls for order of priority as an exclusive perk for paid subscriptions.

Likes and comments on this article’s Patreon page will let me know that people actually read my stuff and would be intrigued to see more.

If you ended up here directly somehow, check out my free Patreon blog for articles and other cool stuff:

patreon.com/ReactorcoreGames

You can also discuss this article among other readers in my Discord channel:

https://discord.gg/UdRavGhj47

(Reactorcore Games Discord)

For contact, this is my email address:

reactorcoregames@gmail.com

Thank you and enjoy!