jschomay / elm-narrative-engine

A tool for building interactive fiction style stories in Elm.

Hi, I'm Jeff. I like to explore that special place where games, narrative, and AI intersect. I made the Elm Narrative Engine for making non-linear story games and lately I've been experimenting with generative AI in games.

Play Deadline Escape the subway before it is too late	Adding Inworld AI Characters to an Existing Game, Part 3: Reflections, Trust, and Pigeons What I learned from my players and my characters	Adding Inworld AI Characters to an Existing Game, Part 4: Going Deeper Getting the most out of AI chat bots	Getting Lost in the Forest Postmortem on Using AI Generative Tools to Create a Forest Maze Game

Follow on LinkedIn

Follow on Twitter

elm-narrative-engine's Issues

Change DSL for building story rules?

I've given a lot of thought on the dsl for the story rules, and if you've seen my ElmConf presentation you know it went through a number of iterations.

However, I'm thinking of changing it one more time!

Reasons:

• Get rid of infix notation
• Add flexibility
• Add clarity
• Follow standard patterns

I really like Luke Westby's forward apply approach, and think it would work well, though it does have some implications on the design.

This is what it would look like:

myStoryRules =
    [ Story.rule
        |> onInteractionWith (location Hallway)
        |> when (inLocation Kitchen)
        |> moveTo Hallway
        |> narrate "You find a back door leading out..."
    ...
    ]

That would build up a record for a story rule of trigger, condition, commands and narration.

As nice as that is, it loses some constraints from how I have it currently:

1. You can "chain" pieces together in any order, though that's really not a problem.
2. You can omit pieces, which is fine too, it just means I need some reasonable defaults (no trigger matches every rule, no condition matches every rule, no changes does nothing, no narration gives default narration for the item interacted with.)
3. You can duplicate pieces, which gets trickier. Multiple triggers would probably match if any of them matches, multiple conditions would probably match if all of them match, multiple changes would make all of those changes, and multiple narrations would be appended together (which is weird, but works).

Although these implications change some of the fundamental ways of thinking about story rules, I think they make sense and are even more expressive. One downside is losing the possibility to specify all or any when giving multiple whens. I don't see a clean way to add that to the dsl.

Thoughts?

For what it is worth, here are some other alternative approaches that I have considered, but don't like as much:

howItIsNow =
    [ interactingWith (location Hallway)
        `when` (inLocation Kitchen)
        `changesWorld` []
        `narrates` afraidOfHallway
    ]


rawRecord =
    [ { trigger = interactingWith (location Hallway)
      , condition = (inLocation Kitchen)
      , changes = []
      , narration = afraidOfHallway
      }
    ]


constrainedTuple =
    [ ( interactingWith (location Hallway)
      , when (inLocation Kitchen)
      , changesWorld []
      , narrates afraidOfHallway
      )
    ]

Let me in!

I have a commit to push