5 ms·

I've thought about it a bunch over the years and my advice is to follow a few principles: procedural elements should almost always impact how the player plays,

I've thought about it a bunch over the years and my advice is to follow a few principles: procedural elements should almost always impact how the player plays, procedural elements should cross-interact with each other as much as possible, and procedural elements should be understandable to the player. As an example in No Man's Sky the player immediately starts with a jetpack. It makes it so the terrain is approached the same way every time: you just jetpack over it. Very rarely something is tall enough to require you to walk around. Legend of Zelda: Breath of the Wild is a positive counter example. You have stamina so you're constantly thinking about the height of cliff faces, you can glide so you're thinking about height points and straight lines through the world, cliff faces cannot be climbed in rain so you think about the weather, slopes can be slid down on a shield, etc. There are a bunch of systems that may you think about the topology of the terrain, so even just varying the height map becomes interesting. Similarly in No Man's Sky there are different resources but they work the same way on each planet and the player interacts with them pretty much the same way everywhere. When I say elements should be "understandable" what I mean is that a trap, which Dwarf Fortress falls into, is to add a vast simulation which the player feels they can never really grasp. Simulations should not be a black box because then they begin to feel like a random number generator. The aim shouldn't be to make an "infinite" game but to make a very interesting system for the player to slowly understand and master. The developer shouldn't just add stuff, but they should think about the long journey (and eventual mastery) a player might take as they spend significant time with the systems.

meowface 9d ago
Very good points. Weird question: do you have any tips on how one might apply these principles to a semi-stochastic synth plugin for musicians? (I have several ideas, but I'd be curious to hear yours, independently.)
- kettlecorn 8d ago
  I'm far outside the music creation space so you're basically asking me to spitball something, but I'll try! I think "make it observable" is a good principle for a lot of software, but also is useful here. Like if you have something changing in how it operates think about perceptual clues that are unobtrusive but give the user a sense of what's going on. Think a car engine sounding weird, a laptop getting hot, or a water bottle being filled up rising in pitch. Being able to rapidly clue in to how something is running in a bunch of different ways is useful. In synth plugin systems I've seen with node graphs I think having some sort of perception of data traveling that you can assess at a glance could be useful. I can see both color and perhaps the "texture" (dotted, dashed, etc.) of the connections being mapped to some important property of what's being transmitted. On the "cross interactions" thing perhaps there's a design opportunity to find interesting properties of different components you wouldn't normally expose that you can feed into other systems. Perhaps if audio were to clip that is both something you don't want but also a control signal that can feed into something that self-corrects, or even entirely changes the composition. With that you might have some sort of dynamic gain that as it approaches clipping it steps into a new composition creating a strange "ecosystem" of sound. In general there's some interesting opportunities to try to create real systemic components that try to make mechanisms with interesting properties rather than precisely controlled things. Perhaps you add an input that pulls the current moon phase, astrological signs, time of day, or weather. Then your composition could change and be a sort of live work each time, but not in a totally arbitrary way. If you wanted to extend the idea of "observability" all the way to the user you could by convention add some brief narration at the start describing the conditions of the composition "It is Wednesday. Rain is forecasted. The following composition has been changed accordingly." It also may be interesting to weave in more sophisticated mathematical systems, or physics simulations, and then feed them into other components. It'd be quite odd but I can imagine like a bunch of balls on ice floating around and when they touch that creates a signal output, but you could have an input that's like "table shake". It'd be fun to see a program triggering these sort of rube goldberg-esque chain of things to create some sort of interesting sound scape. No idea if that's helpful!
  - meowface 8d ago
    Very helpful, thank you. Great ideas. Some of those exact things I've actually already planned or implemented, for the exact purposes you describe, and some are things I haven't at all thought of but which are definitely worth looking into.

meowface 9d ago

Very good points. Weird question: do you have any tips on how one might apply these principles to a semi-stochastic synth plugin for musicians? (I have several ideas, but I'd be curious to hear yours, independently.)

kettlecorn 8d ago
I'm far outside the music creation space so you're basically asking me to spitball something, but I'll try! I think "make it observable" is a good principle for a lot of software, but also is useful here. Like if you have something changing in how it operates think about perceptual clues that are unobtrusive but give the user a sense of what's going on. Think a car engine sounding weird, a laptop getting hot, or a water bottle being filled up rising in pitch. Being able to rapidly clue in to how something is running in a bunch of different ways is useful. In synth plugin systems I've seen with node graphs I think having some sort of perception of data traveling that you can assess at a glance could be useful. I can see both color and perhaps the "texture" (dotted, dashed, etc.) of the connections being mapped to some important property of what's being transmitted. On the "cross interactions" thing perhaps there's a design opportunity to find interesting properties of different components you wouldn't normally expose that you can feed into other systems. Perhaps if audio were to clip that is both something you don't want but also a control signal that can feed into something that self-corrects, or even entirely changes the composition. With that you might have some sort of dynamic gain that as it approaches clipping it steps into a new composition creating a strange "ecosystem" of sound. In general there's some interesting opportunities to try to create real systemic components that try to make mechanisms with interesting properties rather than precisely controlled things. Perhaps you add an input that pulls the current moon phase, astrological signs, time of day, or weather. Then your composition could change and be a sort of live work each time, but not in a totally arbitrary way. If you wanted to extend the idea of "observability" all the way to the user you could by convention add some brief narration at the start describing the conditions of the composition "It is Wednesday. Rain is forecasted. The following composition has been changed accordingly." It also may be interesting to weave in more sophisticated mathematical systems, or physics simulations, and then feed them into other components. It'd be quite odd but I can imagine like a bunch of balls on ice floating around and when they touch that creates a signal output, but you could have an input that's like "table shake". It'd be fun to see a program triggering these sort of rube goldberg-esque chain of things to create some sort of interesting sound scape. No idea if that's helpful!
- meowface 8d ago
  Very helpful, thank you. Great ideas. Some of those exact things I've actually already planned or implemented, for the exact purposes you describe, and some are things I haven't at all thought of but which are definitely worth looking into.