Scope-Creep and the Minimalist's Question: Devlog #4

The Return

         With the game jam finished, I have regained enough free time to devote to uploading these essays again. This week, I'll be writing about something a little bit different, but still something that is essential to the early development process for my game and everyone else's: scope management. I'm sure you've been told many times over about the dangers of scope creep, but I don't think people tend to give the most universally-applicable advice for avoiding it. Long-time developers will often tell new developers to make detailed plans for everything before it gets implemented.  This can absolutely work... sometimes. For me, however, my plans with a game tend to change often during the development process, as I've mentioned here before. My likeliness to revising and changing doesn't usually work too well with the hard deadlines and concrete plans that developers are often encouraged to make. I do still think planning is an important part of the development process, and scope creep is a very clear threat to the continued development of many game demos. So, I want to write about what I plan to do to limit the scope of Enchanterland and avoid the compelling game-developer-to-insanity pipeline.

Starting Off

         One thing has to be mentioned first: I am, just like essentially every indie game developer who has ever lived, a victim of the scope creep beast. My first game project was going to be a 2D fighting game with a diverse set of characters and a high-speed netcode. This may be a step up in attainability from the immersive open-world action RPG everyone seemed to want to make, but it still wasn't the best place to start for a beginner. However, even if this project never turned into a game, it still turned into a valuable learning experience in the end. Every time I started a new project, which definitely did NOT happen that much, I had demonstrated growth that I had taken away from the last project sitting on the shelf. Even still... growth isn't something that can be published on Steam. The main problem was always scope creep, as it usually is. Scope creep is simply defined as the extremely widespread epidemic where artists (game developers in particular) overestimate the amount of content they are capable of making within a project and burn themselves out during production. Demonstrating resistance towards scope creep can only be done by actually finishing something. Even though Thousand Millimeter Climb is extremely small and has been shown to cause depressive disorders, it's still a finished game that is publicly available. Having something finished made it much easier to take small steps up, and now I have two projects up on itch, the second being much bigger and much less unplayable than the first. It doesn't matter how many people end up downloading them, it just matters that I have finished projects to hold on to for motivation.

         The first step I'm taking to avoid scope creep has already been taken, and I don't think there is any better advice for new developers than starting small. It sounds like really cliche advice, because it is, but it often works. It's a little bit easier to take accountability for finishing a short and sweet platformer than it is to take accountability for finishing the next Elder Scrolls installment. Still, it's difficult to gauge what constitutes a small-enough scope, which is part of why new developers are encouraged to set strict deadlines for themselves. You can do this if you think it will help. If you don't, just keep in mind that the chance of you having to cut some large chunks of content later down the line of your project is nowhere near zero. Release something small that you can be proud of, and then start on something just a tiny bit bigger than that. Perhaps, however, cutting content isn't such a bad thing in the grand scheme of things...

The Minimalist's Question

         I'd like to imagine that the designers of the games that eventually evolved into European Chess actually wanted to add way more arbitrary rules and pieces, but ran out of time and resources. All of this imaginary bonus content would have been cut, but in the end, we probably would prefer to have the Chess we do now than a version with health bars and volumetric fog. Scope creep likely predates video games and art as a whole, but nobody who had completely fallen into it had published anything historically significant--- or anything, for that matter. This thought is both funny and interesting to me, because every person who makes games typically has to cut a lot out from their final product.

         I think that the need to make cuts gets too much stigma. When we make cuts, it can often feel like we're giving up something. It feels as if we have to make a difficult sacrifice in content and quality for the sake of time management. I don't believe this is the case. At the risk of making every devlog I write slowly devolve into Skyrim banter, Skyrim (and the open-world RPG genre in general) makes up a good example of what happens when too much content is added. If you've played Skyrim, you know exactly what I am talking about. The problem isn't the size of the world or the amount of dungeons, the problem is the side mechanics that have nothing to do with the core gameplay loop and seem to exist for no reason. The wood-chopping process and the marriage mechanic come to mind for me immediately. The marriage mechanic in particular is completely irrelevant to anything else going on in the world of Skyrim, and seems to appease an entirely different audience than the one the game was intended for. The main problem here is that unnecessary added mechanics don't actually add value to the gameplay loop, and instead simply contribute to the player's sense of decision-making paralysis. What's more, they have to be manually programmed in by typically underpaid developers. It would seem like nobody wins here.

         I'd like to propose a way of development that is by no means new to the industry, but seems to pass by a lot of people within it anyways. The question many game developers seem to ask themselves when they're developing a game is "What can I add?" This habit makes a lot of sense; developers want to expand upon their ideas and make the best, most content-diverse game they possibly can. With this mindset, making cuts seems like an objectively cruel fact of development. I'll call it the Maximalist's Question, along with the other questions that provoke a desire to expand content and do as much as possible to make a good game. Quality is by no means a result of quantity, although I will admit that having more of a quality thing is better. However, as you might have inferred from context clues, the question I ask myself is the exact opposite one to the maximalist's question. When "expanding" upon a game idea, I will always first ask myself, "What can I remove?" I'll call this the Minimalist's Question, along with the other questions that provoke a desire to make a product with the highest possible quality and the lowest possible production effort. I'm not perfect at doing this, but it's also not stretch to assume that genuinely asking yourself the minimalist's question during the development process is a lot harder than asking the maximalist's question. I do still think that it results in better games at the end of the day; Chess doesn't need ray-tracing, after all.

         I've already talked about some of the content I decided to cut from my plan for Enchanterland, but that doesn't nearly scratch the surface. I've placed many tight constraints on myself- not in terms of time, but in terms of the product itself. I already mentioned in previous devlogs that the movement mechanics in Enchanterland will be very limited, and that the "enchantment" system will likely be deceptively simple. The ideas for shops, inventory menus, immersive storytelling, and diverse NPCs were all cut in the early planning process as well. This will not only result in a game that is likely to actually be released at some point, but it will result in a game that is extremely focused on the core gameplay loop that was the reason I wanted to make it in the first place. With these cuts, I can put more time and effort into fleshing out the combat, enchantments, and all the other things that will make Enchanterland a unique game that people would play/have sitting idly in their Steam library.

         My dad always calls himself a "fundamentally lazy person", which isn't exactly saying what it seems to be saying. What he means is that he's a minimalist on the front of production. He writes books, but you'd likely be surprised how many broad artistic conventions apply to both writers and game developers.  Being "fundamentally lazy" is synonymous with only producing what is necessary to get the ideas you want to convey across in your work. It's making a quality product with the lowest possible amount of production effort. Writers don't want to spend years working on their educational book for the sake of adding every bit of information they thought was remotely relevant to the topic. On the other hand, readers don't want to read a thousand page educational book that's filled to the brim with content that the author "thought would be really cool". They want a clear and concise experience, and that can only happen if the author revises the work and makes cuts. But there's no way that could possibly apply to any other art forms...

Au Revoir

         Pardon the French, I needed to artificially inflate my credibility. I definitely have to ease back into the habit of putting these out, especially since I wasn't necessarily "into" that habit to begin with. Nothing else is going on for me next week, so you should expect a devlog like this with more images and more references to the game I'm actually making a devlog for. Until then, I'll be here on the other side of the computer screen. Fare-thee-well.

P.S: The game I released for the game jam wasn't posted on this account, so you can click the following link to get to the page for it if you're interested:

https://serelcode.itch.io/momotaro