NOAH HOLMES

Every solution can be traced backwards through six key concepts.

• Property – Words that define what an object is. It’s stone, heavy, wet, flammable, buoyant. Properties are intrinsic to the object.
• Affordance – What a Property permits. Something rigid and long like a tree can be climbed or used to span a gap. Something flammable can be set alight. A heavy boulder can roll down a hill.
• Opportunity – An Affordance made relevant by context. This particular object, here, can be used this way right now.
• Approach – The category a cluster of Opportunities serves, often a play style. Stealth, force, traversal, environmental manipulation, and so on.
• Constraint – What stands in the way of the Objective (the goal of the encounter). A guard, a hazard, a barrier, or a continuous pressure like limited ammo or oxygen. It is the problem an enabler resolves, and the next section covers both kinds of Constraints, Placed and Standing, in detail.
• Enabler – The specific Opportunity that resolves a Constraint. It is the thing that actually resolves the problem. For example, water poured on a fire that is lighting the area removes the light, creating a shadow the player can use to slip past a guard unseen.

An object has a Property, the Property gives it an Affordance, context turns that Affordance into an Opportunity, and an Opportunity that resolves a Constraint is an Enabler. When grouped by the kind of solution they offer, those Opportunities form an Approach.

The player brings the other half, a set of Verbs, basic abilities afforded to the player from the start, like jump, attack or climb. The intersection where a player’s Verb meets an object’s Affordance is where the interaction rules define the outcome. Most of the system is fancy machinery for turning out a wide variety of fun, randomized Enablers.

My first approach to the design began at the intersection of Verbs and Properties where I started to explore various interactions. I quickly realized the sheer size of the Possibility Space as I started to mentally build encounters one-by-one as a thought exercise. I started by placing useful objects nearby encounters or enemies and then visualizing myself walking through their use and how gameplay might play out or evolve. Placing a fungal puffball or a pod of spores that bursts when hit provoked questions. What does it do? Why is it here? I started realizing that everything in the world that a player can interact with must have at least two uses to be viable in this design. I gave the puffball a cloud of spores that creates short-term stealth. Spores are hard to breathe, so they can also stun a character standing in the cloud. Maybe they’re also flammable, so you could toss the puffball near an enemy to stun them, then ignite the cloud.

While interesting in a vacuum, sticking these near an enemy had some limitations conceptually. The first is that they often train a player to use a single object to solve an encounter, where a synergy might be more interesting. Also, players love to pattern match, so if a design places just the puffball near an enemy, that becomes the meta gameplay approach which flattens the overall experience. You train them that the puffball is the rock to the NPC scissors. The other problem is that these puffballs need an in-world reason with correct context to exist near the encounter the player is meant to solve. I call this Diegetic Fit and it was the next big ‘ah-hah!’ moment for me.

After this realization, I knew I had to flip this around and work from the goal first and out to the Possibility Space because a clear, single goal was far more concrete than trying to solve for exponential growth with Verbs and object Properties. The idea was to first visualize the goal, say, in this case it’s Sneak Past the Sleeping Guard. Easy enough, create a narrow pathway, stick a cot and a sleeping NPC on it. What grew out of that was thinking about what pieces need to be placed to allow for player success without hand-authoring any solutions, while also ensuring Diegetic Fit. In this example, we would need things like a crackling campfire set to a timed interval which the player would have to notice and move at the same cadence, objects nearby they could move behind to block line of sight, objects that can be quietly moved to allow for an alternate route, rocks they can throw to distract the guard and so on. All of these would need to appear nearby as Opportunities, any one of which the player could turn into the Enabler that gets them past the guard, without sticking out as obvious solutions or overly guiding the player and stripping away agency.

With the idea of placement needing authority, I knew that PCG without guidance is disorganized chaos and there would be no Diegetic Fit. I had to then figure out how things in the game would exist as impediments to success, which I called Constraints. Players working towards the Objective would find themselves challenged by two forms of Constraints: the first are Placed Constraints, ones added to the game world by the system to serve as the various challenges players needed to overcome. This includes the surface-level assets such as a guard, a laser tripwire, a special creature that can see through stealth, or simply an environmental hazard like a pool of lava.

The second and less visible are Standing Constraints, gameplay elements that limit player Verbs such as air (a breath meter), any form of ammunition or armor durability, which can change during moment-to-moment play. These can influence play and alter the player’s Approach each playthrough. While sneaking past the sleeping guard is one Approach, and depending on how the Objective is qualified, players could potentially attempt to complete the goal through a completely different Approach, such as using brute force or traversal, which is the point of the system.

Something else I learned throughout this, is that the broader the Objective, the larger the Possibility Space gets when coupled with the Verb and Enablers in the game. So if a goal is written as ‘Sneak past the Sleeping Guard’ the implication there is stealth and finding a discreet method of Approach to complete the Objective. If you tweak this goal slightly to ‘Get past the Sleeping Guard’ you immediately open up the player’s Approach, giving them much more agency. Now you can simply run past the guard, blow up the guard, sneak past the guard, distract the guard away, throw a skunk at the guard (which sends them away) and so on.

So, now that I felt placement was clearly identified as a core systems need after having worked through some mental scenarios, how would this work? What are the nuts & bolts of this approach and how do we embrace PCG while still telling the game what sort of logic to use when placing assets into the game in a coherent fashion? I thought a bit about how the game would be able to know what something is and what Properties it carries. Both of these are critical for two major pieces of the system, the outcome of interactions between objects and their world placement. I needed something that was low overhead, easy to maintain, scaled well and conceptually made sense to everyone working on this design. These needs drove me to using tags as a potential solution. Since I needed the game to know both what an object is and where it can go, each object would have carry two tag types, Property tags for what it is, spanning families like size and opacity, and Placement tags for how it is placed. Tags allow for a simple way to quickly get basic information about an object without requiring every gameplay system to know about every object type. These systems can just check the relevant tags and behave accordingly, allowing for new objects to seamlessly integrate into the existing mechanics without new code. This scales exceptionally well because the number of potential interactions grows naturally as new objects and systems are added, versus an inefficient system of trying to code unique logic for every possible combination. These Property tags, combined with physics and numeric values such as weight, durability, or fuel duration (burn time), become an incredibly flexible piece of data-driven architecture that reduces complexity, allowing for the rich emergent gameplay this system is based on.

Placement tags are used by the system to determine logical placement and to provide the appropriate context used when checking for Diegetic Fit. As I dug into this, I realized that I needed to break the Placement tags into two sub-categories otherwise placement would still be too broad. First I created the concept of a Placement:Container tag, which would define what’s allowed to appear inside them. Now they’re not literal containers, they’re tags used by design to mark areas of the world where certain things were allowed to appear. This is where the fine line between complete hand-authoring and random PCG requires some guardrails to create coherent gameplay spaces. Design would “paint” areas with these tags like #camp, #forest, #shoreline, and so on. The other part of these placement tags are the Placement:Role tag, a family used by the system to know what purpose the object itself serves in the world. These are limited to three types: #prop, #challenge and #solution. A prop can be anything typically in the background such as a simple tree, a bench, or a boulder. A challenge tag belongs on anything that can obstruct an Objective, like a wall, a barricade or a pool of lava. Lastly a solution tag is added to anything that can resolve an Objective such as water that can extinguish fire. So to tie it all together: A Challenge is the problem placed in the world, a Solution is a piece that can answer a specific Challenge, and Props are everything else that makes the scene believable and keeps the Solution from being obvious. The key move is that these Roles are not exclusive, a single object can carry one, two, or all three at once. A plain tent is only a Prop. Reeds at the water’s edge are a Prop that reads as natural shoreline and a Solution:Sightline that breaks a lookout’s line, and being flammable they can also feed a fire Approach, a second Solution type on the same object. And a wild beehive in a tree can be all three, a Prop that is just believable wilderness, a Challenge when its swarm denies an area, and a Solution when you knock it down to turn that same swarm against a guard. Prop, Challenge, and Solution in one object. The more Roles a single object carries, the more the Possibility Space multiplies, because every added Role is another path that object can open.

I realized that while I had tags generally defined, I had left something critical still on the table. Though I had hierarchy tag containers defined and designers painting them down onto the terrain, there was still a disconnect between the #camp tag that was painted onto the terrain and everything that can exist within a camp. How would I account for a campfire? How about a barrel? Sleeping cots? I felt that a simple organizational hierarchy would not only keep things nested logically, it would also allow for loose context to tie into elements of Diegetic Fit. Starting at the highest level, #camp, the next tier down would be smaller zones such as #supply, #sleeping, #resting, and #guards. Each tier down becomes more granular, allowing for objects with supporting tags to appear in each area. This is enforced so that an object can only appear where every container tag is nested to allow for it, and Diegetic Fit chooses among the allowed locations in the world. This clean hierarchy would only need to be authored once and updated as new tags are introduced so the objects are given the necessary context for placement. This structure prevents random objects from appearing in places that don’t make sense, creating a cohesive world when generating encounters.

As I kept going down this object placement rabbit hole, I discovered yet another interesting unanswered question in the design. So far, I had objects with tags, tags painted onto the ground for scoping, a tag hierarchy to give objects placement context, and a “Property interaction matrix” loosely defined, but what I didn’t have was a clean way to handle asset themes.

A feature I felt I needed here is the ability to call a single explicit or randomized theme tag or what I’m calling a ‘Modifier‘ for filtering gameplay assets. This way, as assets were created based on a theme or group like #goblin, #magicbased, or #simpletech, the team could tag them with one appropriate Modifier tag which would get called based on design needs during PCG selection. For this to work, a base set of assets would need to be created that would always load when a particular asset was missing for the matching Modifier. So for example, say you need a #goblin #camp but there isn’t a #campfire for this group yet. When the game loads it would load a generic campfire until one was added later, which would quietly appear in-game next time that Modifier tag was called. When the Modifier tag is loaded, it gets appended to the tag hierarchy at runtime, so all the cascading assets are loaded into the game.

Knowing that this system is meant to work inside a world that’s constantly changing, and we’re giving players the keys to success through their Verbs and a wide Possibility Space, the one thing this system had to support was an absolute guarantee that no matter how the player Approached an encounter, there would always be a path through it without the need of anything other than what they started with. You cannot set a player up to fail by asking them to shoot something, chop something, or start a fire when they don’t have a means to do so. You build your puzzles around the floor, the bare-bones tools everyone has, and then everything else is layers of enrichment to the Possibility Space.

I call this the Golden Path.

Without it, your game will be riddled with unplanned failure states where players cannot progress, which is unforgivable in design.

It seemed like, depending on the size of the tagged gameplay area, the system should read the size of the available wall assets and calculate whether they fit and how many. This system also needs corners and walls of varying sizes, starting with the widest first, so it wouldn’t build a series of mismatched walls that would look strange. With the real estate figured out, the system draws top-down onto the terrain and traces the boundary, integrating any world feature already in the tagged area and leaving room for the gate. The system also permits authored gaps, regions where walls are intentionally not snapped together, if needed. With the walls placed, the system pathfinds through the playspace to confirm there is a legitimate path in, and if there is not, it rebuilds. Then it validates the result. The only way in should be through the gate, unless you go over or through a wall.

This design stops short of generating actual rooms. The point of this is more for open-world, exploration-type sandbox games where detailed interior spaces do not need to be generated by an algorithm. For something like a dungeon, you would either want hand-authored spaces with changing population and environmental hazards, or level instancing with snap-together kit pieces that form the layout.

A sample encounter I originally designed was lacking sufficient PCG elements and as I kept interating to expand the design, I realized that while I was building a fun puzzle game, it was completely hand-authored. The better I made the encounter and the deeper I got into the design, the more I stripped away object Properties, which gave it a very narrow Possibility Space and flattened the experience and overall replay value.

I had designed a resource-driven underwater traversal puzzle where the player must descend beyond a single breath’s limit by uncovering buried air pockets, then chasing each escaping bubble upward to replenish oxygen at the cost of hard-earned depth. Reaching a hidden mermaid at the bottom grants permanent underwater breathing, turning the puzzle’s central limitation into a lasting progression reward.

I had to cut this because the core loop, while fun, wasn’t taking advantage of the widest Possibility Space available with its basically flat gameplay and approach. It was outside the scope of this system design, so I decided to cut it from my list of examples.

PCG geometry placement using hard-coded rules solves the functional part of the problem, where it can guarantee a perimeter that’s coherent and place a lookout NPC in a spot that makes sense, sure. The biggest gap here is that systemic generation of playspaces isn’t guaranteed to be fun. The problem space is striking the right balance, because if a designer’s hand controls PCG output too heavily, the output starts reading same-y, which causes players to pattern match and lose interest. Striking that balance is what I believe works best here, with the system generating the core playspace and a level designer doing a quick pass on the terrain with basic ‘anchors’ that validate gameplay locations to define loose important placement locations. This is basically ‘shaping’ the PCG output to create better, albeit not perfect, randomly generated gameplay spaces. I honestly don’t know how you can get both randomized gameplay spaces and ensure that they’re fun.

Something else to noodle on that I still would like to workshop, is the best approach to handling a game with terrain deformation and AI pathfinding. Off the cuff, my first thought was what’s most important here? I want to say, hands down, was performance. You can’t have a game with any sort of cross-platform staying power if it doesn’t perform on the slowest acceptable piece of hardware. That’s literally your floor and should influence your decisions for the game. This means your AI pathfinding has to support an efficient system such as a NavMesh that can update segments in realtime. Keeping it performant at scale ties directly into this need, but it feeds into another, bigger issue: invalid terrain.

Terrain deformation coupled with AI pathfinding to locations where the terrain is allowed to change creates situations where AI cannot pathfind into or out of sections that have changed state. I have mentioned elsewhere that I believe a possible solution is allowing for terrain that’s been modified to be flagged as ‘dirty’ or just momentarily ‘invalid’ while it gets rebuilt in realtime. Some constraints are necessary, however, ones where you would likely have to figure out the largest number of grid squares you are willing to dirty and still allow for play. If you give an NPC or player some sort of super bomb and it obliterates a huge radius, you now have reduced playspace while you wait for the NavMesh to update and validate those mesh points. Additionally, AI needs to be able to handle situations whereby terrain around them (like a donut, with them in the middle) becomes unavailable and yet gameplay must continue. The same can be said about the ground directly beneath an NPC, as the AI must be able to recognize the change and react appropriately in a manner that’s acceptable.