Twine Game: Thirsty At The Blue Lagoon
This exercise challenged me to design and refine a branching narrative from the ground up, ending with a playable Twine prototype. The premise I developed was a thirsty customer trapped in a fantasy bar, facing eccentric servers who could help or harm. Through multiple versions, peer and mentor feedback, and scope adjustments, the idea grew into a polished interactive story.
Sections Below:
Concept & First Iteration: Building a whimsical fantasy scenario with branching endings featuring a devilish waitress, an orcish waiter, and a floating eye bartender.
Feedback #1: Early peer critique on pacing, depth, and character actions.
Second Iteration: Expanded nodes and refined dialogue, with light peer feedback.
Feedback #2: Senior mentor review pushing for gameplay variety and more distinct branching.
Third Iteration: Solving branching logic challenges and creating a direct bartender path.
Flowchart to Twine: Adapting the flowchart into Twine, reinforcing the “dying of thirst” core loop, and restructuring choice-to-button conversion.
Feedback #3: Peers and senior mentor highlighting scope, descriptive texture, and optimization for development.
Fourth Iteration: Trimming, restructuring, fixing grammar, and finalizing the Twine game.
Final Reflection: Lessons on endurance, scope management, and feedback-driven rewriting.
👉 Use the sidebar navigation to quickly jump to any section of the page.
First Iteration
The end goal of this exercise was to create a readable flowchart for a development team and then convert that flowchart into a Twine game. The premise was simple. Our player character had to be a thirsty customer, while our villain was a snooty server who did not care for our struggles. Our character had to get to the glass before they fainted or died. My initial thought of this test was one of creativity and scenario writing while maintaining the player’s attention.
This exercise did not require extensive research as there were no proprietary characters or lore, but I needed to research how to use Twine because it would be the first time I used it. This worried me at the moment, but I put my fears on the back burner and focused on creating a flowchart.
I focused on the character of the villain. A notable villain and a misunderstood villain would be the most interesting. A devilish waiter is what stuck in my mind. Eventually, eventually the waiter became a waitress with a sharp and deadly tail. This concept helped me lay the groundwork for a fantasy setting. The idea of the player being able to die from dehydration and or the people serving him sounded like whimsical fun. These ideas formed themselves into version 0 of the flowchart.
Flowchart Version 0
Flowchart Version 1
After fiddling with the concepts of version 0, version 1 was born. In this version, I gave the player three endings. Two resulted in you being alive, while one let you die a miserable death. Using these endings, I also formed the rest of the cast the player would interact with. Devilish waitress, Orcish waiter and One-Eyed Willy the floating eye tentacle bartender. All three servers have different vibes, allowing me to keep up with the whimsical theme I mentioned earlier.
Feedback #1
In the first round of feedback, I sought a peer who enjoys fantasy narratives. He was delighted to provide feedback to me. After reading version 1 of my flowchart, he told me the base concept for the exercise was a great first swing. His main critique was the lack of more depth in each node and maybe an increase of character actions. He felt as if the scenarios happened too quickly. He referenced the decision points of 2A and 2C, which develop into 2AA and branch 2BC. I noted this information and processed some ideas of how to fix this.
Second Iteration
I developed version 2 and added eight new nodes. Four new option nodes and four new response nodes. This let me add depth and give character actions to the player. The expansion focused on the devilish waitress and the orcish waiter mainly because the floating eye bartender seemed to come across perfect the more I worked on other parts. I had another round of feedback, but it was light and not as in-depth as my other rounds. The peers who looked at version 2 enjoyed it and commented about fixing lines about grammar and formatting issues, technical work. With those considerations, I constructed version 3 and tackled as many of the previous issues stated before handing it off to my senior mentor for feedback.
Flowchart Version 2
Flowchart Version 3
Feedback #2
I asked a senior mentor for their wisdom on this round of feedback. He liked how I kept every previous version within my Miro so that he could see the growth and development of branches come to life. He had many positive things to say, but I asked him to do his best to push me. So with that request, he pointed out silly mistakes. One example of this is in the grammar of calling a waitress a waiter. He also highlighted branch 3A and asked if I could expand it. The two options were acceptable to him, but there was no dodge option. He felt as if he could add more to it and dig deeper. His final critique was giving each waiter their own distinct branch and melding them into each other if that was possible, as it was very easy to miss the floating eye bartender scenario, which he thoroughly enjoyed.
Third Iteration
Version 4 had to solve two problems. The first problem on branch 3A which required a dodge scenario. This was easy for me to do. The second problem and the real problem was creating a mainline branch that led straight to the bartender without overwhelming myself. This truly stumped me for a bit. Adding a new branch early could lead to more logic issues that might waste my time and not yield any positive feedback. Eventually, my solution involved using option 1AB to begin the new 2B and transforming the initial 2B into 2C. With the new 2B developed, I use its options of 2BA and 2BC to filter into major branches of 3A and 3C but still let the original options filter right back into the new branch. This version gave me the same results but also a direct path my mentor asked of me.
Flowchart Version 4
Twine Conversion
After finishing version 4, I started working on my Twine ability and learned the basics I needed to bring this flowchart into that engine. I watched several tutorials and practiced with small passage concepts to practice the syntax. Once I finished practice, I reread my flowchart, and two additional problems arose. The first issue was the absence of the core aim the task asked, the dying of thirst. While my original flowchart offered engaging choices for many players. The branching narrative made the core goal of obtaining water unclear. To address this, I had to reinforce the main objective by weaving more concepts into the choices with descriptive tidbits about being thirsty. I thought this would ensure that the players would always remember the concept of thirst even as they pushed forward with their unique choices. Then, I doubled back to make sure the logical consistency remained after my choices.
The second issue I noticed was that the brief lines after choices or during the descriptive actions did not naturally convert into button presses for the player. So, during each scenario, I had to add new lines or dialogue not present in my flow graph chart so it would make sense when a player actually played, and then I attempted to fix any grammar issues I had without a word processor. Once I finished this last task, this would complete version 5 of the flowchart and version 1 of my Twine game.
Flowchart Version 5
Twine 1.0
Feedback #3
This was the final round of feedback I gathered for this exercise. This feedback included peers and one senior mentor, none of whom provided feedback in rounds one and two.
Peer #1
He enjoyed, similar to our senior mentor from feedback #2, being able to glance back at my earlier work. He found the growth staggering, and that was his biggest critique as well. There was so much content I would juggle; he wanted me to trim down and focus on the key aspects and add more descriptions instead of options. He referenced how some paths didn’t even mention the waitress tail. When he did a second run of the Twine game, it caught him by surprise. He wanted more understanding upfront so that he could have more buy in power.
Peer #2
This peer followed the same thinking as peer #1. He asked for more descriptions and texture of the world during the gameplay experience. While he was not concerned about the length, he was worried about what a theoretical development team might do if they saw such a flowchart of scenarios. They would gawk at the resources needed to complete such a task. He noticed some branches reused similar scenarios, and because I demonstrated that, he asked if I could restructure in a way that considers asset use for trimming down development time.
Senior Mentor
My senior mentor examined my twine and then switched to my flowchart to get the bigger picture of the scope I was trying to accomplish. Sen enjoyed the world I built and loved the whimsical nature. She highlighted how the threat of death was high, but I could incorporate a lighthearted tone, it appears whimsical. The main issue she wanted me to solve was the size of the flowchart and combining responses into single nodes. I created scenes where two options lead to different outcomes, but those outcomes then converge into a single node. She wanted me to find a way to rewrite these and fix this.
Fourth Iteration
This was going to be my final iteration of this flowchart and Twine game. I analyzed the parts I could reduce, as my peers and senior mentor suggested in feedback #3, and I tried my best to reduce and maintain the fun. I started from the top and subtracted sections and rewrote them in a way that would still lead to each other. It took some time before I was happy. Once I got the cohesive piece stitched back together from the butchering, I focused on adding texture to the nodes and using a word processor instead of writing in Miro. This resolved the lingering grammar problem that Miro did not detect. With all that solved, I transferred and transformed the nodes into a playable game within Twine and rechecked functionality and formatting to make sure the content worked and called it a day on this extensive exercise.
Flowchart Version 6
Twine 2.0
Final Thoughts
This exercise felt like an endurance and memory test. Juggling the multiple choices and endings while maintaining the fun was exhausting. It taught me how many logic checks are required at this level of scope. This exercise taught me how to find new angles constantly in approaching feedback requests, so I am grateful for that experience. It really enhanced my ability to discover threads in the writing.