Category: gaming

LudoForge #4

On By Jon UreñaIn Inteligencia artificial, Programación, gamingLeave a comment

Now that the evolutionary process to grow game definitions is progressing at a steady pace in my app, named LudoForge, I fed the architectural docs to ChatGPT so that it would write a good explanation on how it works. It may be interesting to those curious about how complex systems can grow organically through an evolutionary algorithm that mimics biological evolution.

Teaching a computer to invent tabletop games (and occasionally rediscover the classics)

If you squint, evolving game designs is a lot like evolving creatures: you start with a messy ecosystem of “mostly viable” little organisms, you test which ones can survive in their environment, you keep the best survivors—but you also keep a diverse set of survivors so the whole population doesn’t collapse into one boring species.

In our system, the “organisms” are game definitions written in a small, strict game DSL (a structured way to describe rules: players, state variables, actions, effects, win/lose conditions, turn order, and so on). Each candidate game definition is wrapped in a genome: basically an ID plus the full definition.

From there, the evolutionary loop repeats: seed → simulate → score → place into niches → mutate elites → repeat.

1) Seeding: where the first games come from

Evolution needs a starting population. We can generate seeds automatically, or import them from disk, or mix both approaches. The important bit isn’t “are the seeds good?”—it’s “are they valid and diverse enough to start exploring?”

So seeds must pass two kinds of checks before they’re even allowed into the ecosystem:

  • Schema validation: does the JSON structure match the DSL’s required shape?
  • Semantic validation: does it make sense as a playable ruleset (no broken references, impossible requirements, etc.)?

And there’s a third, subtle filter: when we place games into “niches” (more on that below), seeds that land only in junk bins like unknown/under/over are rejected during seed generation, because they don’t help us cover the design space.

Think of this as: we don’t just want “a bunch of seeds,” we want seeds scattered across different climates so evolution has many directions to run in.

2) Playtesting at machine speed: simulation as the “environment”

A human can’t playtest 10,000 games a day. A simulation engine can.

For every candidate game, we run automated playthroughs using AI agents (simple ones like random and greedy are enough to expose lots of structural problems). The engine repeatedly:

  1. Lists the legal moves available right now
  2. Checks termination (win/lose/draw conditions, cutoffs, loop detection)
  3. Lets an agent pick an action (with concrete targets if needed)
  4. Applies costs and effects, recording what happened
  5. Advances the turn/phase according to the game’s turn scheduler

Crucially: when a complex game definition tries to do something illegal (like decrementing below a minimum, or targeting something that doesn’t exist), the engine records skipped effects/triggers instead of crashing, so the system can observe “this design is broken in these ways” rather than just failing outright.

This is the equivalent of an organism interacting with the world and leaving tracks: “it tried to fly, but its wings didn’t work.”

3) Turning playthroughs into numbers: metrics, degeneracy, and fitness

After simulation, we compute a set of analytics that act like proxies for design quality—things like:

  • Agency: did players have meaningful choices, or were they railroaded?
  • Strategic depth (proxy): how large is the typical decision space?
  • Variety: do many different actions get used, or does one dominate?
  • Interaction rate: are players affecting each other or only themselves?
  • Structural complexity: is this a tiny toy, or something richer?

These are not “fun detectors.” They’re sensors.

Then we run degeneracy detection: filters that catch the classic failure modes of randomly-generated rulesets:

  • infinite loops / repeated states
  • non-terminating games (hits max turns/steps)
  • games with no real choices
  • trivial wins, dominant actions, excessive skipped effects, etc.

Some degeneracy flags cause an outright reject (hard gate), others apply a penalty (soft pressure), and too many penalties at once can also trigger rejection.

Finally, all of this becomes a feature vector, and we compute an overall fitness score—the number evolution tries to increase.

4) “Growing in niches”: why we don’t keep only the top 1%

If you only keep the single highest-scoring game each generation, you get premature convergence: the population collapses into one design family and stops surprising you.

Instead, we use MAP-Elites, which you can picture as a big grid of “design neighborhoods.” Each neighborhood is defined by a few chosen descriptors (think: agency bucket, variety bucket, etc.). Each candidate game gets “binned” into a niche based on its descriptor values, and then it competes only with others in that same niche.

  • Each niche keeps its best resident (the “elite”).
  • Over time, the map fills with many different elites: fast games, slow games, chaotic games, skillful games, high-interaction games, and so on.

This is how you get a museum of interesting survivors, not one monoculture.

5) Reproduction: mutation (and why mutation is structured, not random noise)

Once we have elites across niches, we generate the next generation by mutating them.

Mutation operators aren’t “flip random bits.” They are rule-aware edits that make plausible changes to game structure, such as:

  • tweak a number (thresholds, magnitudes)
  • add/remove/duplicate actions (with safety guards so you can’t delete the last action)
  • add/remove variables (while rewriting dangling references)
  • change turn schedulers (round-robin ↔ simultaneous ↔ priority-based, etc.)
  • add triggers and conditional effects
  • modify termination rules (win/lose/draw conditions)

The key is: the operator library is rich enough to explore mechanics, not just parameters.

Mutation retries (because many mutations are duds)

Some mutations do nothing (“no-op”), or produce something that can’t be repaired. The runner will retry with a different operator a few times; if it still can’t produce a productive mutation, it falls back to keeping the parent for that offspring slot.

This keeps evolution moving without pretending every random change is meaningful.

6) Repair, rejection reasons, and staying honest about failure

After mutation, we may run repair (optional), then validation and safety gates. If a candidate fails, it’s not just dropped silently—the system classifies why it failed:

  • repair failure
  • validation failure
  • safety failure
  • evaluation error
  • evaluation returned null fitness/descriptors

And it persists these outcomes for observability and debugging.

This matters because “evolution” is only useful if you can tell whether the ecosystem is healthy—or if you’ve started breeding nonsense.

7) Adaptive evolution: learning which mutations are actually useful

Not all mutation operators are created equal. Some will be reliably productive; others will mostly create broken genomes.

So the runner tracks per-operator telemetry every generation: attempts, no-ops, repair failures, rejection counts, and how often an operator actually helped fill a new niche or improve an elite. evolution-runner

Those stats feed into adaptive operator weighting, so the system gradually shifts its mutation choices toward what’s working in the current region of the design space—without hardcoding that “operator X is always good.”

8) Optional superpower: motif mining (stealing good patterns from winners)

Sometimes an evolved game contains a little “mechanical phrase” that’s doing real work—like a neat resource exchange loop, or a repeating pattern of effects that creates tension.

When motif mining is enabled, we:

  1. select elites (top per niche + global best)
  2. re-simulate them to extract trajectories
  3. mine repeated effect sequences (“motifs”)
  4. convert those motifs back into DSL effects
  5. feed them into a special mutation operator that can inject those motifs into new games

That’s evolution discovering a useful mechanic, then turning it into reusable genetic material.

9) Human taste enters the loop (without turning it into manual curation)

Metrics are helpful, but “fun” is subjective. So we can add human feedback:

  • ratings (“how good is this?”)
  • pairwise comparisons (“A or B?”)

Rather than asking the human to judge random games, the system uses active learning to choose the most informative comparisons—especially cases where its preference model is uncertain, and it tries to include underrepresented niches so taste is learned across the map.

Under the hood, the preference model is an ensemble trained online (so it can update continuously) and its uncertainty controls how much feedback to request per generation (adaptive budget).

Fitness can then blend:

  • “objective-ish” signals (metrics/degeneracy)
  • “human preference” signals

So the system doesn’t just breed games that are non-broken—it breeds games that align with what you actually enjoy.

10) Why this can rediscover known games and invent new ones

If your DSL is expressive enough to describe the rules of an existing game, then in principle there exists a genome that encodes it. Evolution doesn’t need to “know” the game—it only needs:

  1. Search operators that can reach that region of the rulespace (structural mutations, not just numeric tweaks)
  2. Selection pressure that rewards the behaviors that make that game work (choice, balance, interaction, clean termination, etc.)
  3. Diversity preservation so the system keeps exploring many styles instead of collapsing early

Once those are in place, rediscovery becomes a side-effect of searching a huge space under the right constraints. And invention is what happens when evolution stumbles into combinations nobody tried on purpose—then keeps them because the ecosystem rewards them.

The simplest mental model

If you want the non-technical version in one breath:

We generate lots of small rulesets, machine-play them thousands of times, score them for “does this behave like a real game?”, sort the survivors into many different “design neighborhoods,” keep the best in each neighborhood, then make mutated children from those survivors—occasionally learning from human taste and reusing discovered mechanics—until the map fills with strong and varied games.

That’s the evolutionary process: not magic, not random, but a relentless loop of variation + playtesting + selection + diversity.

LudoForge #3

On By Jon UreñaIn Inteligencia artificial, Programación, gaming1 Comment

If you don’t know about LudoForge, you should probably read the previous posts. In summary: I’m developing an app to evolve tabletop game prototypes according to a “fun” factor made up of plenty of fun proxies like player agency, strategic depth, etc. The code is now mature enough to run X evolutionary generations on demand, produce shortlists of the best games, and finish. That’s great because it means the code works well, although there’s always room for improvement. But the shortlist of four winners is absolutely terrible in a way that has had me giggling for a while. I’ll let ChatGPT explain these “games.”

Game 1: “The Shared Counter Chicken”

Two players take turns. There’s a shared number on the table that starts at 0 and can be increased up to 15. The “win condition” is simple: whoever makes it hit 15 wins instantly.

The game also includes a couple of other buttons that change other numbers… but those numbers can never actually produce a win. They’re basically decorative dials. One of them always gets set to 12, but the victory threshold for it is 20, so it’s like having a “Launch Rocket” button that always fuels you to 60% and then stops forever.

So what do players really do? They increment the shared counter… and then start playing a tiny psychological game of chicken: “I could push the counter closer to 15… but then you might get the final move.” So the game hands them some useless actions that function as “stalling.” If both players are stubborn, they can just keep stalling until the match times out.

It’s not strategy so much as who blinks first.

Game 2: “The Game Where You Can’t Move”

This one is my favorite kind of failure because it’s so clean.

The game defines two counters. The only action in the entire game says: “Decrease both counters.”

But the action is only allowed if both counters are greater than zero.

And the game starts with both counters at zero.

So on turn one, a player looks at the rules and… there is literally nothing they’re allowed to do. No move exists. The game doesn’t even fail dramatically. It just sits there like a vending machine with the power unplugged.

In other words: it’s a tabletop game prototype that begins in a stalemate.

Game 3: “First Player Loses: The Speedrun”

This one actually runs, which makes it even funnier.

There are two counters. One counter is the only one that can possibly lead to a win — the other one only goes downward forever, so its “win condition” is a permanent lie.

The “real” counter starts at 0, and there’s an action that increases it by 2. The victory threshold is 4.

Here’s what happens:

  • Player 1 goes first. Their only sensible move is: 0 → 2.
  • Player 2 goes next and does the same move: 2 → 4.
  • Player 2 instantly wins.

So the entire “game” is basically:

“Player 1 sets up the win for Player 2.”

It’s like a sport where the first player is forced to place the ball on the penalty spot and then politely step aside.

Game 4: “The Unwinnable Ritual”

Three players this time. There’s one shared counter. Winning requires the counter to reach 4.

But the rules only let you do two things:

  • Set it to 2.
  • Decrease it by 2 (if it’s above zero).

Notice what’s missing: any way to make it bigger than 2.

So the win condition is a castle in the sky. The game is a ritual where players take turns setting the number to 2, or knocking it back down toward 0. It can never, ever reach 4. No amount of cleverness changes that.

It’s essentially a machine that cycles between “2” and “less than 2” until you get bored or the turn limit ends it.

ChatGPT finished its report with this note: “The first evolutionary run didn’t produce brilliant board games. It produced life, in the same way early evolution produced algae and sea foam. These were rule-sets that technically existed… but didn’t yet deserve to.”

These idiotic games already provided fun by existing, so as far as I care, this app has already been a success. The good thing is that I have code to handle degeneracy, fitness, etc., so I simply have to tighten that code so some of these nonsensical points would either kill a genome or penalize its fitness.

By the way, earlier tonight I was playing tennis in VR with people across Europe while I waited for Claude Code to work through the tickets of one of the app’s new features. And yet the world is terrible. We live in the lamest cyberpunk dystopia imaginable.

Living Narrative Engine #19

On By Jon UreñaIn Escritura, Arte, Inteligencia artificial, Programación, gamingLeave a comment

I have quite the treat for you fuckers. I’ve recorded myself playing through my test scenario involving Alicia Western. More than an hour of me speaking in my accented English even though I rarely speak in real life, and showing off a fun, frustrating playthrough that made me hungry.

This is, of course, related to my beloved Living Narrative Engine. Repo here.

Living Narrative Engine #17

On By Jon UreñaIn Arte, Escritura, gaming, Inteligencia artificial1 Comment

I’ve recently implemented an emotions and expressions system in my app, which is a browser-based platform to play immersive sims, RPGs, adventure games, and the likes. If you didn’t know about the emotions and expressions system, you should check out the linked previous post for reference.

I was setting up a private scenario to further test the processing of emotions for characters during changing situations. This was the initial state of one Marla Kern:

Those current emotions look perfectly fine for the average person. There’s just one problem: Marla Kern is a sociopath. So that “compassion: moderate” would have wrecked everything, and triggered expressions (which are narrative beats) that would have her acting with compassion.

This is clearly a structural issue, and I needed to solve it in the most robust, psychologically realistic way possible, that at the same time strengthened the current system. I engaged in some deep research with my pal ChatGPT, and we came up with (well, mostly he did):

We lacked a trait dimension that captured stable empathic capacity. The current 7 mood axes are all fast-moving state/appraisal variables that swing with events. Callousness vs empathic concern is a stable personality trait that should modulate specific emotions. That meant creating a new component, named affect_traits, that the actors would need to have (defaults would be applied otherwise), and would include the following properties:

  • Affective empathy: capacity to feel what others feel. Allows emotional resonance with others’ joy, pain, distress. (0=absent, 50=average, 100=hyper-empathic)
  • Cognitive empathy: ability to understand others’ perspectives intellectually. Can be high even when affective empathy is low. (0=none, 50=average, 100=exceptional)
  • Harm aversion: aversion to causing harm to others. Modulates guilt and inhibits cruelty. (0=enjoys harm, 50=normal aversion, 100=extreme aversion)

In addition, this issue revealed a basic problem with our represented mood axes, which are fast-moving moods: we lacked one for affiliation, whose definition is now “Social warmth and connectedness. Captures momentary interpersonal orientation. (-100=cold/detached/hostile, 0=neutral, +100=warm/connected/affiliative)”. We already had “engagement” as a mood axis, but that doesn’t necessarily encompass affiliation, so we had a genuine gap in our representation of realistic mood axes.

Emotions are cooked from prototypes. Given these changes, we now needed to update affected prototypes:

"compassion": {
  "weights": {
    "valence": 0.15,
    "engagement": 0.70,
    "threat": -0.35,
    "agency_control": 0.10,
    "affiliation": 0.40,
    "affective_empathy": 0.80
  },
  "gates": [
    "engagement >= 0.30",
    "valence >= -0.20",
    "valence <= 0.35",
    "threat <= 0.50",
    "affective_empathy >= 0.25"
  ]
}

"empathic_distress": {
  "weights": {
    "valence": -0.75,
    "arousal": 0.60,
    "engagement": 0.75,
    "agency_control": -0.60,
    "self_evaluation": -0.20,
    "future_expectancy": -0.20,
    "threat": 0.15,
    "affective_empathy": 0.90
  },
  "gates": [
    "engagement >= 0.35",
    "valence <= -0.20",
    "arousal >= 0.10",
    "agency_control <= 0.10",
    "affective_empathy >= 0.30"
  ]
}

"guilt": {
  "weights": {
    "self_evaluation": -0.6,
    "valence": -0.4,
    "agency_control": 0.2,
    "engagement": 0.2,
    "affective_empathy": 0.45,
    "harm_aversion": 0.55
  },
  "gates": [
    "self_evaluation <= -0.10",
    "valence <= -0.10",
    "affective_empathy >= 0.15"
  ]
}

That fixes everything emotions-wise. A character with low affective empathy won’t feel much in terms of compassion despite the engagement, will feel even less empathic distress, and won’t suffer as much guilt.

This will cause me to review the prerequisites of the currently 76 implemented expressions, which are as complex as the following summary for a “flat reminiscence” narrative beat:

“Flat reminiscence triggers when the character is low-energy and mildly disengaged, with a notably bleak sense of the future, and a “flat negative” tone like apathy/numbness/disappointment—but without the emotional bite of lonely yearning. It also refuses to trigger if stronger neighboring states would better explain the moment (nostalgia pulling warmly, grief hitting hard, despair bottoming out, panic/terror/alarm spiking, or anger/rage activating). Finally, it only fires when there’s a noticeable recent drop in engagement or future expectancy (or a clean crossing into disengagement), which prevents the beat from repeating every turn once the mood is already flat.”

That is all modeled mathematically, not by a large language model. In addition, I’ve created an extremely-robust analysis system using static analysis, Monte Carlo simulation, and witness state generation to determine how feasible any given set of prerequisites is. I’ll make a video about that in the future.

Living Narrative Engine #16

On By Jon UreñaIn gaming, Inteligencia artificial, Programación1 Comment

A couple of nights ago, at two in the morning, I was rolling around in bed thinking about my current obsessions: the browser-based app Living Narrative Engine as well as Alicia Western, the tragic character from Cormac McCarthy’s last two novels. Recently I mixed them both by playing through a scenario in LNE that featured Alicia. I “novelized” that little bit of theater in the short story You Will Spend the Rest of Your Life.

Well, I wasn’t entirely happy with Alicia’s acting. Yes, she’s an analytical gal, but she’s in a deep hole there. I wanted to feel the despair from her. The relief. I wanted to see her cry. I wanted to cause a beautiful, blonde woman at the end of her rope to cry. And she didn’t.

As I thought about whether this was a solvable issue, my dear subconscious had a spark of genius: LLM-based characters in LNE already create thoughts, speech, notes, and choose actions. Why not task them with tracking mood changes?

Some deep research and several iterations later, ChatGPT and I came up with the following notions, which are displayed below in a lovely manner, as they appear on the game page of LNE.

The simulation relies on seven base mood axes: valence, arousal, agency control, threat, engagement, future expectancy, and self-evaluation. Apparently that basic breakdown is psychologically sound, but I’m trusting ChatGPT on that. The sexual variables apparently are also well-known: an excitation component is the accelerator, and the inhibition is the brake. Added to a baseline libido dependent on the individual, that calculates the arousal. As seen in the picture, Alicia right now is dry as sandpaper.

The most interesting part for me is that the mood axes and basic sexual variables are ingredients to form emotions and sexual “moods”. I have dozens of them defined, as I’ve been working with ChatGPT in order to depict the whole breadth of emotions that are distinct and meaningful. Here are the current listings of emotions and sexual “moods” that my app calculates:

  • Emotions: calm, contentment, relief, confidence, joy, euphoria, enthusiasm, amusement, awe, inspiration, aesthetic appreciation, interest, curiosity, fascination, flow, entrancement, hope, optimism, determination, anticipation, sadness, grief, disappointment, despair, numbness, fatigue, loneliness, nostalgia, boredom, apathy, unease, stress, anxiety, craving, thrill, fear, terror, dread, hypervigilance, courage, alarm, suspicion, irritation, frustration, anger, rage, resentment, contempt, disgust, cynicism, pride, triumph, shame, embarrassment, awkwardness, guilt, regret, humiliation, submission, envy, trusting surrender, jealousy, trust, admiration, adoration, gratitude, affection, love attachment, compassion, empathic distress, hatred, surprise startle, confusion
  • Sexual moods: sexual lust, passionate love, sexual sensual pleasure, sexual submissive pleasure, sexual playfulness, romantic yearning, sexual confidence, aroused but ashamed, aroused but threatened, sexual craving, erotic thrill, sexual performance anxiety, sexual frustration, afterglow, sexual disgust conflict, sexual indifference, sexual repulsion

Emotions are calculated based on detailed prototypes. Here’s one:

"anxiety": {
      "weights": {
        "threat": 0.8,
        "future_expectancy": -0.6,
        "agency_control": -0.6,
        "arousal": 0.4,
        "valence": -0.4
      },
      "gates": [
        "threat >= 0.20",
        "agency_control <= 0.20"
      ]
    }

Those emotions and sexual moods are fed to LLM-based actors. They figure out “hmm, I’m intensely disappointed, strongly cynical, strongly sad, etc., so that needs to color my thoughts, speech, notes, and the actions I take.” I haven’t tested the system much in practice, but the little I tested, the results were like night and day regarding the LLM’s roleplaying.

In real life, we not only do things, but our bodies do things to us. We are aware of how our emotional states change us, and those turn into “tells” to the other people present. In addition, when one thinks in terms of stories, you add “reaction beats” when the emotional state of an actor changes, so I did exactly that: if the LLM has returned changes to the previous mood axes and sexual variables, the library of expressions have a change to trigger (one at a time), based on whether some prerequisite triggers. The following example makes it self-explanatory:

{
    "$schema": "schema://living-narrative-engine/expression.schema.json",
    "id": "emotions:lingering_guilt",
    "description": "Moderate, non-spiking guilt—an apologetic, sheepish self-consciousness after a minor mistake",
    "priority": 57,
    "prerequisites": [
        {
            "logic": {
                "and": [
                    {
                        ">=": [
                            {
                                "var": "emotions.guilt"
                            },
                            0.35
                        ]
                    },
                    {
                        "<=": [
                            {
                                "var": "emotions.guilt"
                            },
                            0.70
                        ]
                    },
                    {
                        "<=": [
                            {
                                "-": [
                                    {
                                        "var": "emotions.guilt"
                                    },
                                    {
                                        "var": "previousEmotions.guilt"
                                    }
                                ]
                            },
                            0.12
                        ]
                    },
                    {
                        "<=": [
                            {
                                "var": "emotions.humiliation"
                            },
                            0.25
                        ]
                    },
                    {
                        "<=": [
                            {
                                "var": "emotions.terror"
                            },
                            0.20
                        ]
                    },
                    {
                        "<=": [
                            {
                                "var": "emotions.fear"
                            },
                            0.35
                        ]
                    }
                ]
            }
        }
    ],
    "actor_description": "It wasn't a catastrophe, but it still sits wrong. I replay the moment and feel that small, sour twist—like I owe someone a cleaner version of myself. I want to smooth it over without making a scene.",
    "description_text": "{actor} looks faintly apologetic—eyes dipping, a tight little wince crossing their face as if they're privately conceding a mistake.",
    "alternate_descriptions": {
        "auditory": "I catch a small, hesitant exhale—like a half-swallowed \"sorry.\""
    },
    "tags": [
        "guilt",
        "sheepish",
        "apology",
        "minor_mistake",
        "lingering"
    ]
}

I’ve created about 53 expressions already, but they’re surprisingly hard to trigger, as they require very specific (and psychologically logical) conditions.

Because testing this new system through playing scenarios would be a nightmare, I’ve created a dev page that makes testing the combinations trivial. In fact, I’ve recorded a video and uploaded to YouTube. So if you want to hear me struggle through my accent that never goes away, and the fact that I very, very rarely speak in real life, here’s ten minutes of it.

I think that’s all. Now I’m going to play through the same Alicia Western scenario as in the short story I posted. If the result is different enough, I will upload it as a short story.

Post-mortem for Custody of the Rot

On By Jon UreñaIn Escritura, Arte, Inteligencia artificial, Programación, gamingLeave a comment

If you’re reading these words without having read the story mentioned in the title, don’t be a fucking moronski; read it first.

I assume you’ve read some of my previous posts on my ongoing fantasy cycle, so you may remember that I’m producing these stories in tandem with improvements to my app, named Living Narrative Engine. It’s a browser-based system for playing scenarios like immersive sims, RPGs, etc. I’m compelled by the mutual pulls of adding more features to my engine and experiencing new scenarios; sometimes I come up with the scenario first, sometimes with the mechanics. That has my brain on a constant “solve this puzzle” mode, which is the ideal way to live for me.

Anyway, the following scenarios involving a brave bunch of dredgers in a fantasy world, tasked with extracting a dangerous arcane artifact from some gods-forsaken hole, will require me to develop the following new mechanics:

  1. Lighting mechanics. Currently, every location is considered constantly lit. Given that we’re going underground and that the narrative itself requires using lanterns, I have to implement mechanics for recognizing when a location is naturally dark, and whether there are light sources active. There are other mechanics providing information about the location and actors in it, so from now on, when a location is naturally dark and nobody has switched on a flashlight, we have to block offering descriptions of the location and other actors in it, and instead display text like “You can’t see shit.”
  2. Once lighting mechanics exist, we need actions for lighting up and snuffing out lanterns and lantern-like entities. By far the easiest part.
  3. Currently, when an actor speaks in a location, the speech is only received by actors in that location. At the same time, I consider an entity a location when it has defined exits. Now we find ourselves in a situation in which we have a thirty-feet-long underground corridor separated by grates. That would make each segment between grates a location (which would be correct, given the boundary), but an actor could step from a boundary into the next and suddenly not hear a character on the other side of a grate’s bars. Obviously idiotic. So I need to implement a mechanical system for declaring “if an actor speaks here, the voice will be heard in these other places too.” That will need to extent to actions too: if you have eyes, you can see someone scratching his ass on the other side of bars.
  4. No other scenario has featured water sources that could play a part. And by play a part I mean that actors could get in or fall in, exit them, struggle in the water, and drown. I really don’t want to see my characters drowning, but that’s part of the stakes, so the mechanics need to exist. Given that water sources tend to be connected to other locations and not through the regular exits, I will need some way of allowing “I’m in the water, so I want to swim upstream or downstream to a connected stretch of this water source.” This whole water system will be arduous.
  5. Line-tending mechanics. Until I started researching matters for this story, I doubt that the notion of line-tending had ever entered my mind. Now we need mechanics for: 1) making an owned rope available to others. 2) Clipping and unclipping oneself from the available rope. 3) pulling on the rope to draw back someone clipped that’s wandering away. 4) possibly other cool line-tending-related mechanics. I can see line-tending reappearing in future scenarios such as traditional dungeon delves (for example, to avoid falling in Moria-like environments). Admittedly, though, this whole thing is quite niche.
  6. Blocker-breaking mechanics. Basically: this door is bar-based, so this allows a hacksaw to hack through the bars. I don’t want to make it a single action, but a progressive one (e.g. if you succeed once, it only progresses a step toward completion).
  7. Mechanics related to mind control. To even use those actions, I will need to create a new type of actor for the scenarios: a dungeon master of sorts. Basically a human player that’s not accessible to others, as if it were invisible, but that can act on present actors. I would give that dungeon master for this run the can_mind_control component, then allow actions such as putting people into trances, making them walk off, dive into water, etc. This means that there would need to be opposite actions, with the victims fighting to snap out of the trance. It will be fun to find out what happens when the scenario plays out. In the future, this dungeon master could be controlled by a large language model without excessive difficulty: for example, feeding it what’s happened in the story so far, what are the general notions about what should happen, and giving it actions such as “spawn a hundred murder dragons.”

That’s all that comes to mind now regarding the mechanics to add.

About the story: so far, it seems I want magic to be treated in this fantasy world as if it were toxic material. That’s not a decision I’ve made about worldbuilding, but a natural consequence of the stories I’ve felt like telling. I actually don’t believe in the kind of worldbuilding in which you come up with imaginary words for the warts on an invented race’s ass. I’m all about use and tools. My mind always goes for “what can I build with this.” I’m very rarely interested in a subject if I can’t see myself creating a system out of it. It also doesn’t help that due to autism, abstractions tend to slip through my fingers, so I need to feel like I’m sensing something to understand it.

In a way, I wanted to create a story about specialists working through a problem that needs to be solved. Jorren Weir, Kestrel Brune, Saffi Two-Tides, Pitch… these people don’t have superpowers. Most of them are glad they can keep a job. There is no grand evil here, just people’s self-interest. I want them to do well so that they can return home at the end of the ordeal. But given that we’re dealing with chance-based tests, that’s not a guarantee. And that tension alone makes it exciting for me to experience these scenarios.

As usual, if you’re enjoying these stories, then great. Otherwise, fuck off.

Review: Dispatch

On By Jon UreñaIn Arte, gaming, ReseñasLeave a comment

Back in late 2000s and early 2010s, we had this thing we affectionately called Telltale-style games: heavily narrative-driven games that relied on letting the player make more or less compelling decisions that would affect the narrative. They didn’t have the complexity of early adventure games, but they couldn’t be called simple visual novels either. They were tremendously successful, until corporate greed swallowed them, spread them thin, and eventually dissolved them into nothing. The company shut down.

A new studio made of former Telltale devs decided to try their hand a new Telltale-style game that removed the dragging parts of former Telltale games (mainly walking around and interacting with objects) to focus on a good story, a stellar presentation, and compelling minigames. Their first product was the game Dispatch, released about a month ago in an episodic format (two episodes a week, but all of them are out already). The game has become a runaway success.

The story focuses on Robert Robertson, a powerless Iron Man in a society where many, many people have superpowers. He carries the family legacy of battling villains with a mecha. As an adult, he pursued the supervillain who murdered Robert’s father, and who now led one of the most dangerous criminal groups. However, during an assault on the villain’s base, Robert’s mecha gets destroyed, which puts him out of a job.

However, he’s approached by one of the most notorious superheroes, a gorgeous, strong woman who goes by the name Blonde Blazer. She offers him a job at the company she works for, SDN (Superhero Dispatch Network). Their engineers will work on repairing Robert’s mecha, while he offers his expertise on fighting crime as the one in charge of dispatching other heroes to the appropriate calls.

Robert finds out that the team of heroes he’s supposed to handle are a bunch of villains who either have approached the company to reform themselves, or were sent by the criminal system for rehabilitation. They’re a diverse bunch of rowdy, at times nasty superpowered people who aren’t all too keen on having a non-superpowered nobody in charge of them. The narrative explores how the team grows to work together better.

The execution of this story could have gone wrong in so many ways: wrong aesthetic, time-wasting, atrocious writing, and above all, marxist infiltration; like most entertainment products released on the West these days, the whole thing could have been a vehicle for rotten politics. But to my surprise, that’s not the case here. A male protagonist, white male no less, who is an intelligent, hard-working, self-respecting role model? Attractive characters, fit as they would be in their circumstances? A woman in charge (Blonde Blazer) who is nice, understanding, competent, caring, and good? Villains with believable redemption arcs? Romance routes that flow naturally? Where the hell did this game come from in 2025?

Entertainment consumers have been deliberately deprived of all of this by ideologues who despise everything beautiful and good, who, as Tolkien put it, “cannot create anything new, they can only corrupt and ruin what good forces have invented or made.” Franchise after franchise taken over by marxists who dismantle it, shit on the remains, and then insult you if you don’t like it. Dispatch is none of it. For that reason alone, I recommend the hell out of it. I’m sure that given its sudden popularity, the forces-that-be will infiltrate it and ruin it in its second season as they do with everything else, but the first season is already done.

It’s not perfect, of course. Its pros: an astonishing visual style that makes it look like a high-quality comic book in movement. No idea how they pulled it off. Clever writing. Endearing characters. Interesting set pieces. The voice acting is extraordinary, led by Aaron Paul of Breaking Bad fame. He deserves an award for his acting as Robert Robertson. It’s a good story told well, and you’re in the middle of it making important decisions (and also plenty of flavorful ones).

The cons: some whedonesque dialogue that didn’t land for me. Too much cursing even for my tastes, to the extent that often feels edgy for edge’s sake. Some narrative decisions taken during the third act, particularly regarding the fate of one of the main characters, didn’t sit well for me, as it deflated the pathos of the whole thing. But despite the pros, this was a ride well worth the price.

Oh, I forgot: they should have let us romance the demon mommy. My goodness.

Check out this nice music video some fan created about Dispatch, using one of the songs of its soundtrack.