Approaching The Finish Line
- Skye Winters

- Apr 5
- 5 min read
This week I started gearing up for the open house around the corner and revaluated some of the work I’ve done so far.
Introduction
So since coming back from GDC, I’ve been working a lot on both my research and the game accompanying said research. Through meeting so many amazing industry experts this year and talking about my work, I’ve come to several realizations that caused me to take a step back and evaluate the direction each of my projects were heading. In the end, after discussing my thoughts with my advisor, I’ve decided to shift away from the two large project framework. Instead, I am now looking at completing a series of mini-projects to explore aspects of my proposed system while developing a large-scale project that can incorporate and evaluate the benefits of those findings. So without further ado, lets get to the updates.
The Dialogue Permutation System
One of the largest updates I would say is the shift away from a Twine based approach to now using an Ink based approach. Why? Well for a couple of reasons.
While Twine was technically working, in reality saying that I was incorporating Twine would be like saying I am using Google Docs to publish my book when I’m actually just copy pasting text in it to proofread. This was because Twine did not have native support for Unity incorporation so I had to create a custom based Twine importer which resulted in many functionalities being lost. However, by using Ink, I can also build off Ink’s Unity Importer to allow my solution to directly integrate with the Ink writing pipeline.
In addition, after talking with several practitioners and attending a roundtable discussing narrative tools, I walked away with the impression that Twine appears to be more so utilized as a prototyping tool whereas Ink usually holds up better for full scale projects. Additionally, the more programmer style of writing I am proposing for my solution fits better into the culture and capabilities of Ink.
So because of these two big reasons, I decided to shift my system over to Ink. It luckily was a relatively seamless pipeline since my code was already pretty system agnostic after shifting away from Arcweave so it was not too large of a headache. The largest task left now is simply cleaning up the project to remove the old Twine code.
Since shifting over, Ink has already shown itself to be a far more productive writing tool since I do mainly script based writing rather than visual / node based writing. Additionally, after several different attempts at finding a method of embedding my system, I landed on an Ink native based approach which leverages features that Ink writers would already be familiar with. In essence, I use Ink’s branching narrative features based on conditionals to branch based on Praxis language data. All that was needed was to hook it up to my Praxis evaluator through an external function. Thus my tool will largely be hands off for developers and will just need to include a method of handling Praxis data. Below is an example of code using my solution.

The next steps now will be to go through and practice writing with this approach to see what patterns emerge and what strategies developers can lean on. Already for example, I’ve found that treating it as an expansion step where you rewrite and expand upon text written in a first pass works relatively well. For example, start with writing the line “Hey watch out, the wall is about to fall over” and splitting it into two versions based on agreeableness of “Oh shit the walls coming down” and “Hey look out, the walls coming down!” where you only mention others if they are agreeable.
Additionally, I now should be able to start testing and evaluating if these scenes are working better then if I fix the path on only one permutation. To do so, I’ll start by simply making each conditional always evaluate true so the first permutation is always chosen and conduct an A/B style design where half of the players will do the first and the half will do the second version.
Project: R&J
After going through and working on Project: R&J, I’ve made some discoveries that have shaped the future direction of this project. Below I’ve included a visual walking through my discovery process.

After discussing with my advisor this finding, we have agreed to shift Project: R&J to being more of a collection of micro projects so that I can continue to evaluate these interesting questions. For example, below I include a few hypotheses I have about this system and three use cases I can see it applying to. By using a micro project structure, I should better be able to explore each of these questions while also hopefully finding some edge cases I may have otherwise missed.


The next steps now are to begin exploring applicability to procedurally generated NPC stories through creation of a micro story about needing to go and slay a dragon with a collection of NPC followers. Through this, I hope to explore the following:
How well the system works when the NPCs are procedurally generated rather than author written?
Does including a backstory strengthen the effectiveness of this solution?
To evaluate the first, by using a research through design approach, I hope to see how well the theory holds up in practice while trying to write the scene and documenting my findings. For the second I will use an A/B style approach where one version of the game will provide the procedurally generated backstories while the second version will not include said backstories.
Project: Theatre
For this week, in preparation of the upcoming open house where the game will be shown, I’ve focused primarily on polish. To accomplish this, I’ve been utilizing the feedback received from the playtests I’ve conducted over the past month, using both observations and notes from testers, to optimize the experience to allow players to focus on the enjoyment of the game rather than the systems they need to interact with. In UX terms, I focused on reducing the noise as much as possible so that the experience would be more seamless. This is important seeing as my thesis relies on properly evaluating participants' views of the game characters and if players are more focused on their frustrations with the game, then that may negatively impact my results' validity.


Additionally, I’ve recruited the original artists for the game to redo the UI’s aesthetic now that we have a new UX design from these additions. As such, one of the tasks of the coming week will be to implement this new design into the gameplay. Additionally, I want to now go back and polish some of the auxiliary menus in order to make the player experience more cohesive throughout since the menus outside the rehearsal phase have received relatively little attention.
Conclusion
Overall, this has been quite the productive week. Next week, I am looking forward to the public demo but will need to put in still quite a bit of work to pull it off. So with that I’m going to call it a night before the chaos begins.
Until next week, logging off.


Comments