Deep Dive: Creating seamless dialogue for narrative poker game Sunshine Shuffle

Game Developer Deep Dives are an ongoing series with the goal of shedding light on specific design, art, or technical features within a video game in order to show how seemingly simple, fundamental design decisions aren’t really that simple at all.

Earlier installments cover topics such as how solo developed Devon Wiersma optimized the spraypainted world of Bombing!! 2: A Graffiti Paradise, the updated visuals and production pipeline of Ravenlok, and how the team behind the genre-bending God of Rock blended fighting and rhythm games into one cohesive style. 

In this edition, Strange Scaffold developer Stav Hinenzon breaks down the narrative design structure of Sunshine Shuffle. 

Hello! I’m Stav Hinenzon, a game designer and developer based in the northwestern US. I worked as a freelance programmer on indie studio Strange Scaffold’s new game Sunshine Shuffle, which launched on May 24. In Sunshine Shuffle, players sit down to play a friendly game of poker with a group of animals ready to finally tell the story of how they robbed a bank twenty years ago. Like the game’s primary inspiration, Telltale’s Poker Night at the Inventory, the game and the conversation occur simultaneously. This created some interesting constraints for the game’s narrative tools and systems. In this article, I’ll get into how the game’s dialogue system was designed to meet those constraints and create the experience of seamless conversation.

Narrative Goals and Constraints

Like Poker Night at the Inventory, Sunshine Shuffle aims to create the feeling of sharing a space with a group of fictional characters by centering gameplay on an activity shared by the player and the characters and then never interrupting the space of that activity. Once the player gets past the main menu, the game stays in the boat cabin where the poker game takes place. Even the game’s menus are accessed by rotating the camera to look at a different point in the room to keep the player in the cabin. Inscryption is also a good example of this. That game moves between its distinct roguelike and escape room modes through a simple camera movement indicating the player getting out of their chair. Sunshine Shuffle’s dialogue needed to abide by the same constraints while also being the main vehicle for story.

Unlike Poker Night, Sunshine Shuffle’s conversations are longer, and they contain plot information that will be relevant in future conversations. The game’s characters have simpler designs and do not rely on voice acting, putting most of the weight of conveying the narrative on text. These differences increase the cognitive load taken up by the dialogue and threaten to undermine the whole experience by overwhelming the player. Important gameplay and narrative beats need to be given the time to land. A big part of the dialogue system’s role becomes managing content and timing. It needs to know what to play and when. This includes knowing which of the game’s two tracks currently takes focus, resolving timing conflicts between those tracks, and controlling narrative pacing. Controlling the spotlight is central to the weaving between poker and conversation that forms Sunshine Shuffle’s core loop.

Gameplay Units Narrative Units

This job is made manageable by dividing both gameplay and narrative into units. Those units can then be organized, prioritized, and reacted to. Poker is already a turn-based game, so it’s easy to divide into units. Player turns form one kind of unit, and the end of a betting round forms the other. For narrative, a unit is a line. Since text drives Sunshine Shuffle’s narrative, a line is always centered on a piece of text and includes everything that happens in reaction to that piece of text, such as camera cuts and character animations (on all characters). Lines belong to either barks or storylets. Barks are made up of single lines that react to specific gameplay triggers, and storylets are formed from a group of lines meant to represent a conversation. These units give clear definition to what the dialogue system is managing. They can be assigned priority, preconditions, and time intervals, all of which are exposed to the narrative designer, allowing them to control the pace of the game’s systemic narrative.

This method of organization didn’t arrive fully formed. I knew early on that I would need to define discrete events to prioritize, but I didn’t have the full structure of the game in my head yet. Early in development, I wanted flexibility, so my units were much more atomic. These units consisted of a single system doing a single thing—displaying one line of text, playing one animation, or performing one camera cut. These small events, called “chores,” were meant to provide flexibility in how the game handles all its different systems acting at once. As development progressed, clear patterns in how we grouped and prioritized chores began to emerge. In response, I changed the schemas I use to organize the game, both in my head and in code. However, the game is still built on its earlier, more atomized iterations. Lines are, in fact, collections of chores that all get resolved at once. The continue game chore, meant to trigger the next gameplay unit, is the only one that didn’t get combined into a larger grouping.

The Parts of the Machine

The game’s units get handled by the dialogue system’s two major components: the chore queue and the storylet parser. The chore queue is a priority queue that takes events from multiple sources and resolves any timing conflicts between them. The role of the chore queue was inspired by the Telltale tool, and Telltale programmer Tulley Rafferty helped with its design. Whenever a game system wants to trigger an event that is dependent on the game’s flow, it puts a chore on the chore queue. A game turn, a bark, and the start of a new storylet are all represented by chores. These chores each have a priority, represented by an arbitrary integer, that determines the order of their execution. During normal gameplay, chores don’t spend more than a few frames on the queue, so priority mainly becomes relevant when multiple systems are firing chores all at once. The chore queue itself can also be closed, preventing new chores from being executed. When this happens, priority also determines which chore gets executed first once the queue opens back up. The closing functionality also informed how I prioritized chores. Any chores that close the queue need a high priority so that any rogue chores don’t get through before closing.

Barks in Sunshine Shuffle are triggered by and resolved as part of gameplay, but the storylets need their own system to manage them. That’s the job of the storylet parser. Every few betting rounds, the parser uses weighted randomness to select a new storylet to trigger. Its preconditions must be met by the current story state. Once a storylet is selected, a start chore is placed on the queue. Once it goes through, barks are disabled, and the storylet begins playing. Sunshine Shuffle’s storylets are visual scripting graphs, a series of connected nodes, representing the chores that make up the conversation.

Once the storylet starts, the parser uses a virtual playhead to go down the graph and turn each node into a chore on the queue. The playhead moves one line at a time, then waits on an event to continue. Initially, that event was triggered automatically once the text of the line had finished displaying, and once an adjustable interval of time had passed. During development, in order to give players the time they needed to read each line, and as part of an ongoing effort to reduce the game’s cognitive load, the game moved to having the event triggered by the player. The first iteration of this was an optional feature created by Alex Sussman, and the final iteration, implemented by Timothy Gatton, became the only way the game allows for storylet advancement.

While a storylet is ongoing, the narrative has focus. Most other chores don’t take away enough of that focus to warrant an interruption. There are three exceptions to this: the player’s turn, which requires player input, the showdown, which reveals the outcome of the hand, and an all-in, which necessitates the drama of the game to come to the forefront. Each of these stops the storylet and allows itself to resolve in the spotlight. Once it is done, the game plays a return to storylet bark and continues from where it left off. Although showdowns and player turns perform this interruption by stopping the chore queue, all-ins instead block the storylet parser from advancing, since poker chores still need to go through. This is one of many examples of how, even with the planning and organization I did to manage the game’s narrative, the system ended up being quite messy in practice.

Conclusion

That messiness results from evolving schemas, developing processes, and ongoing iteration on a game with a lot of text whose presentation is dependent on systemic gameplay. That was a daunting prospect when [studio head] Xalavier [Nelson Jr.] first described the project to me in 2020, but it was made manageable through planning and categorization. The blocks that form this game’s narrative and gameplay aren’t universal or mythic, although they are built from pre-existing concepts. They are not narrative Legos. They are the result of figuring out early on what the game was and what it wanted to do, and then designing a system to accomplish that. This allowed me and the rest of the team to make more relevant iterations on the narrative loop. Through these iterations, Sunshine Shuffle delivered a seamless style of dialogue not often seen in games of its budget, while working as a spiritual successor to a game I’ve wanted to see followed up for ten years.