EGREGORE - PROCESS

Overview

With Egregore, I set out to explore grammars of interaction in adventure games, tapping into what made our graphing mechanic unique.

During prototyping, I arrived at our experience goals: player intrigue and a vast possibility space with clear guidance. I strived to subvert the friction in many classic adventure games while rewarding the player’s curiosity the way the best adventure games do.

Gameplay & Interface

  • We tested several rulesets for Egregore, landing on a grammar that used the natural affordances of node types to dictate what links were allowed. I tracked these with a systems sheet, calculating the scope overhead of different node types and adjusting rules accordingly.

    For example:

    • Nodes can be Persons, Places, Things, or Concepts.

    • Persons can be put in Places, given Things, or asked about Concepts or other Persons.

    • Persons and Things cannot be in two places at once.

    • Places can’t be in other Places.

    • Things can’t combine or be asked about Concepts.

These rules use commonsense logic, and we included prompts to clarify why certain links are invalid. Despite the fantastical premise, there’s a consistent ruleset for which links are valid.


I made Place nodes into “embedded“ nodes, requiring that the player be in a Place they’re placing things in to see changes as they happen (and preventing linking Places together).


By limiting the number of link points on each node, I limited the possible combinatorial complexity of the graph - a Person or Thing needs to be in a Place before it can be interacted with, so only one modifier can apply to an object at a time. This also affords handing multiple Persons books from the Bookshelf while preventing multiple Persons from wearing the same Glowing Mask.

Since each node added considerable complexity, we landed on a total of 11 throughout the main sequence, Cafe Ramses: just enough to unlock multiple nodes of each type and meaningfully combine them, with Concepts as an afforded means of getting more information.


Players gain nodes after seeing a Person, Thing, or Place in the environment or after it’s mentioned in conversation, with clear calls to action to show the new node. Nodes are thus given when they’re holding the player’s attention, and can be acquired in multiple ways - but there’s always a dependency for getting a node, with the player in given places or conversations.

I laid out all rules for graphing in a living master document, prototyping example cases and their interface feedback for players in Twine, Figma, and Unreal Engine 5.

I also provided a spreadsheet guide for valid combinations for the narrative team to reference.

Levels

  • Designing levels for Egregore was a challenge, since the style of navigation we were going for hadn’t been explored by many recent games, and wasn’t always intuitive in games that did use it. Through early prototypes and work in Unreal Engine, as well as an interview with Riven director Richard Vanderwende, I distilled some rules of thumb we followed when iterating throughout development:

  • Compositions and lighting must lead the player’s eye to important objects and all exits. This has to hold true for all possible graph states.

  • Value the player’s time. Keep transitions fast without disorienting the player, and allow alternate paths/cut down on dead space. We built Ramses around a courtyard both for a natural way to get to any room from any other room and an authentic portrayal of Cairo architecture.

  • Reward intent. Don’t “cheat“ navigation; it must be clear where transition points are and where they’ll take the player. We added interface elements for back-steps and turns for this reason.

  • Compositions must hold visual interest. Full control over compositions is a major advantage of node-based navigation and Unreal, and we made the most of it.

I set up our navigation nodes, turn points, camera angles, lights, set-dressing, and geometry, as well as animating transitions, character poses, and environmental changes in Sequencer.

I implemented almost every location, effect, and animation in the final game.

Using real locations such as Cafe Riche and tools like the Unreal mannequin for reference, I iterated and optimized levels constantly throughout development.

Puzzles

  • Since Egregore is based around a novel mechanic and a broad possibility space, puzzles illustrate the rules of the graph one by one and have multiple simple solutions. The first sequence naturally guides the player through using the graph in multiple ways, and is immediately followed by diegetic tutorials affording navigation and conversation.

For our puzzles, I laid out a puzzle dependency flow chart for the team, showing possible progressions through the game and the player’s node inventory at each point. This chart gave multiple disciplines a simple way to break down our possibility space:

  • Narrative (for player guidance in dialogues)

  • Usability & QA (for playtesting)

  • Design & Engineering (as a source of truth for implementation)

Crucially, the dependency chart let us track the current possibility space open to the player, and gradually open that space as they cleared dependencies and earned nodes.

Giving players a clear way forward (as well as immediate goals through the letter and Al-Bawab) prevented analysis paralysis and let them take approach the cafe at their own pace.