top of page
Sunshine Shuffle (2023)
Designer and Programmer
Strange Scaffold
Summary
Sunshine Shuffle is a narrative poker game developed by Strange Scaffold. The player play Texas Hold'em poker with a group of animals and hears their story of how they robbed a bank twelve years ago. I was hired early-on in the project's development as a programmer and implemented many of the narrative tools and systems that drive the game's dialogue. Characters are able to talk in real time while playing poker, giving the game's narrative a free-flowing pace that matches the feeling of talking over a game.
Challenge — Doing Chores
The hardest challenge of Sunshine Shuffle was creating a system to handle the timing and focus of events from both dialogue and gameplay. This system was built in two parts. The first was a node-based dialogue system that allowed the narrative designer to build conversations through visual scripting. At run time, the conversation is read by a parse that converts each node in the conversation into an event, or “chore”, that gets put into a priority queue. This queue, the “chore queue”, gets events from both the dialogue system and the gameplay, sorting and triggering them in order of priority. This way, the parser controls the flow of the story with the pace at which it goes through the graph, and the chore queue resolves priority conflicts when events from multiple sources are trying to play. Tweaking the way each part of the system fires its events allowed the team to create a game that seamlessly blends gameplay and narrative.
Challenge — A Rotating Cast
Sunshine Shuffle was a small project worked on by a small core team and a rotating cast of contractors, of which I was a part. This provided the challenge of maintaining a consistent knowledge base even as people moved on and off the project. This is a problem I feel I could have done more to resolve. Clear commenting of code to outline what it does step by step, as well as onboarding meetings and a central place to store documentation helped reduce confusion, but the documentation we had was very limited. As a result, newer programmers on the project could sometimes misunderstand a class' functionality, or assume that an intentional design choice was a bug. Creating more robust documentation could have mitigated these issues.
bottom of page