quantum creativity and fixed-parameter design
this blog post further develops ideas I've explored previously, such as in "what if we don't need to write flexible game code?" and "project modeling"
I realized at some point in the last year or two that I conceptualize creativity as a sort of quantum possibility space. I, right now, have the potential to make conceivably billions of different games--I have sketchpads packed with game ideas stretching back over a decade. but there's only so much of that I'll be able to make in my life. but regardless, that potential only exists in the now: when we observe my life in retrospect, there will only be so many projects I actually made. sometimes I find that fact crushing, though it also helps remind me to focus on what really matters to me.
in the same way, crafting something itself requires collapsing that figurative waveform of possibility. in order to take something from imaginary to real, you have to turn a possibility space into a set of discrete choices.
maybe this is why so many games get stuck in that transitional space between "concept" and "finished game", as turning a game into those discrete choices is risky and often-delayed, leading to a project that may become unfocused or unwieldy. the longer collapsing the possibility space is delayed, the more one is driven to engineer their game in a generic and flexible way. and the more that happens, the more the engineering scope of the project expands, and one may becomes drawn into a "sunk-cost fallacy" of sorts leading to more perfectionism: more indecision, more revision, and ever-more drawn out development.
lately I began developing an NES-style game in homage to Dragon Quest 1. I'm making the game in C and Raylib, where I get to have a balance of an easy-to-use framework set against C's low-level demands. within it, I programmed graphical and memory limitations to reflect the constraints of the NES. I decided at the outset to constrain the game to a 16x16 tilemap, set a fixed size and quantity of maps, set a sprite limit and handled tilemap rendering through a tilebuffer. all together, this gives a light touch of the feel of making an NES game, a somewhat similar idiom. for example, since all drawing is state-based, I can create sub-game loops for menus and events rather than write any kind of state machine to handle such things. there's even a simple pre-specified set of behaviors NPCs can respond to interaction with.
though I do feel proud of it and I'm enjoying this sort of engineering, the true purpose of this approach is to focus all my possibility narrowing to the beginning of my project. with as many parameters set up front as possible, it will keep my scope constrained and my design space discrete as I continue through the middle and late stages of the project. it gets me designing the game in a thorough, albeit challenging way right from the offset. I'm creating a set of tools that will let me create a game, and committing to fit the game into those limitations upfront. one might compare this approach to choosing to make a game in RPG Maker or Bitsy, except creating the tool themselves along the way.
playing Dragon Quest 1 recently enchanted me with both its own thoughtful minimalism and with the constraints of the NES. it made me think again: is there something about these old computers that lends to good game design? "limitations breed creativity" is often said, but I want to take it further... what if limitations are creativity? in that "collapsing the possibility space" sort of sense. what if the fixed parameters of the NES and other retro computers wasn't just a creativity-inspiring limitation, but a piece of design already complete for you.
if every tool has an idiom (thank you Ghosty for introducing me to this concept!), a language it speaks that lends it and anything made with it a unique character, then a computer must be a tool with its own idiom. and so is the programming language you use, any IDE, engine or library used, any art, sound or planning tools, and all the systems you write to make up the game. all these things narrow the possibilities of what you create, but they aren't just a limitation, they are the means through which creation happens at all. these tools are all themselves the result of a successfully collapsed possibility space.
I want to make games in a way that's clear, efficient and honest to the craft. it may feel easier to keep parameters open or delay narrowing one's possibility space, but in my own experience at least I've found this to only leads to difficulties. everything that's ever been created is imperfect, because we only ever have all the answers in retrospect. so my answer to myself is this: keep moving forward, do what's possible, be clear with my means and intentions as much as I can, and embrace the generational iteration that all of art and life is part of.