Dialogue Tale

The Project

---

Dialogue Tale is a runtime Dialogue Editor in Unity. It allows a Unity user to easily CREATE and EDIT Dialogue Trees belonging to various differect characters. It supports the creation of new characters and subsequent addition of dialogue and player responses if the game allows for the player to respond to an NPC. Dialogue Tale also allows for full customisation of previously created dialogue, from initial greetings all the way to deep down in the dialogue tree. The user can create new characters with any name, new dialogue nodes and new reply nodes allowing for full dialogue customisation and a branching story. Once a Dialogue is created, it can be applied to any character in the project. All that is required is the character name. The system matches up the character name with the character in the scene and automatically assigns the dialogue to that character.

Template Scene

To showcase how the dialogue system works, I have created a Template Scene which can load in any of the files that were previously created in the Dialogue Editor. The user can preview, test and try out dialogues they have created in this scene. I have built this scene for Virtual Reality as I believe that VR has been slowly gaining more and more traction in recent years, hence I wanted to give it some recognition and try create this template scene for VR. However the scene can still be easily played through Unity without a VR headset, for quick testing.

Project Abstract

The problem which I have chosen to research is the complexity of dialogue creation in games and other forms of media stemming from this. In my project I aimed to research this issue and take steps to eliminate the problems at hand while making the project a more accessible and intuitive alternative to the traditional way of writing dialogue. The most obvious issue which looms over dialogue creation is simply put the inexperience of writers in coding or programming. Very often writers or individuals who are tasked with writing a story or dialogue to a game are unequipped to write it in a way which is easily accessible by a game. These writers have their own area of expertise which is writing not coding or in this specific case the syntax of dialogue. With this project I aimed to eliminate this issue and minimise the errors and further work that writers would have to deal with due to their lack of knowledge in programming and how dialogues are implemented into games.

The solution in my mind was simple, to create a Dialogue Editor which would not only easily allow writers to write dialogue for a game but on top of this represent the dialogue in a visual way which clearly indicates to the writer the different paths of dialogue and how the flow of said dialogue will run. These things are not obvious at all when simply writing a text file, especially when having to add syntax on top of it. As an additional piece of this puzzle, I have made the decision to create a Dialogue System which would process all of the text created by writers in the Dialogue Editor and then have the capability to apply it to a game scene or simply save or load the dialogue to a place on the hard drive. With the Dialogue System and the Dialogue Editor intertwined and working together the problem at hand would not only be solved but also the new way of creating dialogue would be a new easy to understand and attractive way of creating dialogue for Unity games for veterans and beginners alike.

Project Introduction

This project, Dialogue Tale has been inspired by a few key factors. To begin, I have a truly great passion for video games. I wished to base my project on something which would allow me to have a direct connection to video games. It could be a game or something that could be used in games or in the process of creating games. After some in-depth research I have settled on the latter. Alongside my passion for games, I have a lot of love for writing and storytelling. I immensely enjoy well crafted universes and characters in games that are captivating and relatable in different ways. I love the feeling of being transported to a different place through playing video games. The true power of dialogues in media such as Games can should never be underestimated and more so undermined. "The most fundamental communication mechanism for interaction is dialogues involving speech, gesture, semantic and pragmatic knowledge." (Merdivan, E. et al., 2019). So that is what I focused on. Through my research I found how dialogue for games can be tricky and more complex than it should be. So, with the problem identified I had a proposal for a project which involved streamlining the creation of dialogue to the point where anyone without some knowledge for computers could easily hop into a Dialogue Editor which I would create and easily edit and create new dialogues for a game.

This project has truly a lot of potential as it alters the idea of something complex and confusing to the average writer into something that could be used by anyone who wishes to simply write dialogue. The way it is formatted the project can easily be adapted into a Unity package which would allow users all over the world to utilise these new systems rather than having to work through writing files manually. It not only simplifies the writing process for games, but it also speeds it up and makes it reliable as no human error can be made when writing syntax as simply there is no syntax to write thanks to this project.

Research Question

How can Dialogues be written quickly and efficiently, allowing for quick insertion of the Dialogue into a Unity game?

Project Milestones

15th of December 2022: Code and Progress Demonstration, Feedback and Discussion of Future of Project.

The Project Supervisors have gathered for a demonstration, the main goal being an inspection of current project direction and assistance on making any adjustments and improvements which would allow for a better project to be delivered.

I delivered a satisfactory amount of progress at this time however the Final direction of the project has not been fully recognised and set in stone. This meeting allowed for a fleshing out of the project goal and setting a clearer direction with the help of supervisor feedback. Incredibly Important information and feedback was shared in this meeting which acted as a foundation for the rest of my project. After this meeting I had obtained a clear and vivid image of what I want to achieve and where I want this project to be on submission day.

I was on schedule with my work however my direction was not clear enough prior to this point and I needed to readjust myself to adhere to a more suitable schedule for myself. I needed to focus more on the importance of the Dialogue editor rather than having so much focus on the other aspects of this project, the Template Scene, and my Maze Generator. Having those two in a very elaborate state was great, however I have not given enough attention to the Dialogue Editor at this point in time.

18th and 19th of January: Created a basic early version of the Dialogue System and begun work on its editing capabilities.

This is the day that I completed the creation of the very first basic version of my Dialogue System. It was not much more than a simple blueprint which would later guide me to create a more functional system. This was the first time where I began working through and noting what I would like to have my future Dialogue Editor do. I have created my first version of the Dialogue Editor also, although both of these were extremely limited in functionality and did not add much it was a crucial step in the development of my project. An interesting detail of note is that this initial Dialogue Editor was a version which was part of the in-game world. Meaning dialogue would be able to be edited in real-time while a game runs. However, this was not the goal of my project, and as I have gone through more and more research it became even more obvious that I should focus on a separate scene for the editor as it would direct focus to what this project is about. It also became clear that Virtual Reality is not a good option when it comes to performing anything which involves editing text.

10th of February 2023: The Upload of my Dialogue Parser.

How storing of to store a file to then be accessed in Unity efficiently? How can dialogues be stored? What is the best file format to use for storing dialogue data for Unity? How parsers work? How can dialogue be stored and accessed using syntax?

Those and many more were the questions which I have asked and undertaken extensive research about. For the weeks prior to this Milestone date, I have gone through many different ideas and “prototypes” in search for an easy and efficient way to save, store, load, edit and access all my dialogue files. After all my research and tests, I have finally decided to settle on the use of XML for my dialogue storing. It was easy to syntax and very malleable to whatever I needed. After I settled my way of storing the dialogue, I needed a way to load it into Unity and apply it to NPC’s so that the characters were able to use all the stored dialogue. This is where a parser needed to be made. So, I have undergone research, and through much trial and error I finally came out on top with a well refined and useable version of my own custom written Parser. I was incredibly happy when I got it to work. This day marks a huge Milestone of my project as the parser is now one of the major components of my project. With the parser created I was able to move to the implementation and improvement of my Dialogue System and further evaluating its editing capabilities.

17th of February 2023: Completed the first functional iteration of my Dialogue System.

This day marks the upload of my first fully working Dialogue System, it had many flaws and was very “hard-coded” in a sense that there was not much room for change or customisation. It was only working with my set of characters. However, it was a great foundation for my future modular rework of the system. A lot of the code was good and would prove to be useable in a modular system I would just have to evaluate and rework the way in which I stored and processed dialogue and characters in the future.

15th of March 2023: Major Progress Demonstration to Supervisors.

The Project Supervisors have gathered again for in depth demonstrations on project progress and discussions about the final deliverable as well as positive and negative feedback alongside, constructive criticism. Most importantly it was a check on progress allowing for feedback and important advice.

After the last major meeting in December, I re-evaluated my progress so far and thought through the future of my project. Thanks to all the feedback I was given back then, I slowly but surely got back on track towards my final goal. For this demonstration I had created an initial setup for my Dialogue Editor, at this stage I was only able to edit my Dialogue in its raw form as an XML file, that is no good for the final submission as it is exactly what I am trying to get rid of with this project. However, this was a good basis and example to show that I am capable of creating a Dialogue Editor and with enough work put into the project I would be able to achieve my final goal. In retrospect the Dialogue Editor was nothing of note on this day, but my main progress thus far was my Dialogue System which allowed me to save, load, preview and use dialogue files in my “Template Scene” which I had created. I was able to showcase the ideal where I have a conversation with an NPC, but I am capable of editing this dialogue with my very early basic version of the Dialogue Editor, then saving this to my chosen save file. Once saved I was able to load in this custom dialogue and show the change in what the same NPC says depending on how I edited his dialogue.

12th of April 2023: Dialogue System Rework to move to a more modular approach.

In this Milestone I have successfully achieved the removal of all my “hard-coded” components from the Dialogue System. I have created a new class called DialogueSystemNew. This new class was an expansion and improvement of my previous Dialogue System. It was a more refined and a much cleaner version which also was capable of handling dialogue in a modular way. This meaning that I no longer needed to name characters in any special way and give them their own names in code. This modular approach has allowed me to create any character of any name and correctly parse all components of their dialogue and store them correctly to allow for use in my Template scene to showcase how the dialogue works exactly.

This Milestone was originally completed around one to two weeks prior of April 12th. However, I have had internet issues at the time of achieving this milestone. Shortly after our Easter break began and I chose to focus my time on researching other Dialogue systems as well as ways of displaying these dialogue “Trees” effectively. As a result, I was unable to upload this to GitHub until April 12th but expanded some more and made some improvements during this time without uploading.

18th and 19th of April 2023: Important progress milestone prior to the final Submission Day.

These days were an important milestone for my progress on this project as this day marks the completion of all basic functionalities of the project. On the 18th of April I have created a system for displaying a Dialogue tree, in a set of nodes in a correct and easy to understand shape and manner. On the 19th I finished up the basics of the editor. The Editor was capable of editing each node of a character’s dialogue as well as each answer. It was also capable of creating new characters from scratch on top of that. From this point on I was able to fully direct my focus on more extensive editing as well as all extra functionalities. Another priority from this day was creating a more user-friendly (and customisable) experience alongside adding some more substance to the visuals of the project to create a more pleasing image to the eye while using the Dialogue Editor. On this day I was on track to completing this project on schedule.

24th of April 2023: Final Submission Day

The day where I had to submit all the work I have gathered throughout the year. All the project code, documentation, and other deliverables.

After being able to direct all my focus to this project for the recent few days prior to this date, I was incredibly happy with where my project ended up. I am very proud of my achievements and how the final product turned out. I was able to keep on schedule for this final submission and I had everything ready. My final delivery was on-time.

Major Technical Achievements

Modular Dialogue System

First major technical achievement of this Final Year Project is my Dialogue System. I am extremely proud and happy to have created a fully functional Dialogue System that is fully dynamic in the context of multiple characters in a game scene and further editing of the dialogue stored by the Dialogue System.

My original Dialogue System needed to separate my dialogue file into multiple dialogues each for a different character and these characters had to be hardcoded. Hence this was no good as the whole idea of my Final Year Project was to simplify dialogue creation and editing which would in turn allow for easy implementation into a game. So, the Dialogue System needed to be reworked. The current Dialogue System is the result of that rework. I tend to call in the Modular Dialogue System or the Dynamic Dialogue System as it refers to what it is at its core. It stores dialogues in a dynamic way so that characters do not need to be hardcoded. All that the characters require is simply a tag which contains their name, the same one that is used by the Dialogue Editor. For example, the user creates a character named Bob and he is given dialogue by the user. To add dialogue to this character I simply give him the tag named “Bob” and the New Dialogue System does all the work for the user and assigns all the dialogue that was created to this character. To do this easily I created a struct called Dialogue. In this struct I separated the dialogue into the key components I used when writing some sample dialogues in the XML file. The variables I used in this struct are as follows. Character for a character’s name. Dialogue for each piece of dialogue a character says. Replies for storing all the possible replies that the player can give to a character’s specific piece of dialogue. Stage which would store the current index of the dialogue indicating how far into the conversation the player is.

I have kept this final relevant detail about the Dialogue System till last as it coincides with my next point and that is the Parser. The Parser takes an XML file stored on the computer and parses it in a way to remove all syntax and allow the Dialogue System to format it in a way that is both easy to access and understand. The Dialogue System has its very own Dialogue Struct which populates the new Parsed Dialogue file in a relevant and formatted manner allowing the Dialogue System to access any given piece of Dialogue with ease.

XML Parser and Formatter to format Dialogue back into XML

As mentioned above the Parser is the second major achievement I write about. After settling on the XML extension for my dialogue files I needed a way to load the XML file into Unity and then convert it into useable Dialogue without any of the syntax that XML contained to differentiate between different data types or in this case different components of a Dialogue. As a result, I needed a Parser and after doing research I have decided that I wish to create my own Parser rather than using a premade one or basing it off something that came before. I wanted to research necessary topics, but I still wanted this project to keep as much identity as possible. So, after much trial and error, many failed attempts I got progressively closer and closer to a result which could be used for the Dialogue System and Dialogue Editor.

As mentioned prior, I created my own Dialogue struct in the Dialogue System class. This allowed me to write the XML parser in a way that took advantage of the struct. All that was needed was for me to correctly loop through the XML file in search for syntax that corresponded to a variable in the struct. Once found, the appropriate line is processed by the Parser to remove the syntax. Once the line is processed the line is then assigned to the appropriate variable in the dialogue struct. The most efficient and intuitive way of storing all these variables was to make them into lists which could be accessed by the correct line index. Or by searching for a character name and then specifying the stage number depending on previous progress through a dialogue tree.

A Fully working Dialogue Editor

The Dialogue Editor was a crucial part of the Project and an integral component to allow for full dialogue tree customisation, which is what this project is about. Initially the first version of the Dialogue Editor which I worked on was part of the “Game” now “Template” scene. This way the user would have to enter the gameplay scene every time they wished to edit dialogue. On top of this I have my “Template” scene created to work for VR mainly which is not that useful in terms of writing dialogue as it is quite tedious and takes significantly longer than simply typing the dialogue on a keyboard. Hence soon enough after gathering some supervisor feedback and thinking through this issue I have decided to go in the direction of a completely separate scene for the Dialogue Editor. This would not only make the project more intuitive and easier to use but it also gave the project a genuine purpose as it could even be made into a Unity package fully manifesting the idea of creating a user-friendly Dialogue Creator/Editor for anyone to download and use.

After this imperative change it became clear that the project really came into final gear and my idea was becoming more and more realised. Now the Dialogue Editor is its own entity in a separate fully dedicated to loading, analysing, editing, and creating dialogues for characters. Its functionalities include creating a new character from scratch, adding new dialogue nodes, adding reply nodes, deleting dialogue or reply nodes, editing existing characters and their dialogue and player reply nodes, adding new nodes to these existing characters, saving edited dialogues, loading edited or example dialogues, customising the user-experience of the dialogue editor and more. All without having to worry about any syntax as the editor takes care of all the confusing and complex things instead of the user. These edited dialogues can then be loaded into a game scene with the use of the Dialogue System. All that is needed is an object in the scene with a tag corresponding to a character name and that is all, the user is then able to load any dialogue he wishes into the game. The Dialogue Editor is without a doubt one of my great technical achievements of this project and together with the Dialogue System they play an integral part in this project.

To make the experience more user-friendly and personal. Each user has the ability to drag the dialogue nodes around the Dialogue Editor. This is a feature of the Dialogue Editor which creates additional freedom for each user but also it is a great means of counteracting the issues that come with a large dialogue tree. The larger the dialogue tree the more confusing the visual representation gets. The nodes get messy, begin to overlap and can overall get unnecessarily convoluted. With the dragging of nodes in the project, this issue is no longer as prominent as any user can now move every single node to any place in the Dialogue Editor. The lines connecting nodes will always stay attached to easily signify node connections, so it does not matter how far the user chooses to space out the nodes. Overall, this feature greatly improves visibility and the feeling of personalisation in the Dialogue Editor.

Maze Generator

Lastly, I would like to give a mention to my Maze Generator as it deserves to be part of my major technical achievements. Through the use of a backtracking algorithm, I create a procedurally generated maze every time I load into the “Template” scene. To do this I have a Maze Plane which acts as the dimensions for this Maze. I then populate the plane with wall prefabs, this created a grid which the algorithm will traverse. I choose an end and start node in this grid. After that the algorithm begins traversing the grid to the end point destroying each wall it passes through. Once it reaches the end node it begins its backtracking visiting each unvisited node and destroying each wall it passes through once again. The algorithm stops once all nodes in the grid have been visited. A random maze is created as a result.

Its functionality is great and works just as intended, the only issue which I would have wanted to address given more time is its overall impact on the project. It does not have as big an impact as some of the other technical achievements as I did not have enough time to expand on my “Template” scene to showcase how Dialogue can be changed in real time depending on environment. The main goal was to have characters guide the player through the Maze, the neat twist is that the Maze is always randomly generated, this combined with my Dialogue System would’ve altered the maze characters dialogue each time as the maze would be different each time.

Project Review

What went right?

Firstly, and most importantly, the project as a whole went right. It went very well and despite some hiccups and issues along the way the project ended up in a satisfying state. I was able to deal with those issues in a smooth and professional manner allowing me to have a final submission which reflects well all the work which I have put into the project. The Dialogue Editor had its own fair share of gimmicks and specifics which had to be adjusted and addressed to ensure the correct functionality of the Editor. Now the Dialogue Editor not only works perfectly fine but is also incredibly satisfying to use and perfectly equipped to do its job. On top of this the Dialogue Editor also has customisation options allowing users to fit the Dialogue Editors visuals and some of its functionality to their own needs and desires.

The Parser was a great weight off my shoulders once I have finalised it. It went perfectly right and does exactly what I want it to do. It is capable of taking my XML files and parsing them in a way to be understandable by both the user and my Dialogue System in Unity. Then once a user wants to save the Parser is capable of reformatting the Dialogue back into XML with syntax to ensure all data is stored correctly in an orderly fashion. The improved new Dialogue System that I had to work on after inspecting the limitations of my previous Dialogue System ended up taking some portion of my time, yet in the end it was worth it as now the project had a fully dynamic Dialogue System which did not have any pre-set character data hardcoded. It is incredibly useful, and I can see it fit in very easily into many games where a user uses the tools provided to add dialogue to their game.

What went wrong?

The original working Dialogue System which I created was not what I needed to make. I wasn’t fully focused and in understanding of exactly what I needed at the time of making the first Dialogue System hence when it came to the point where I finalised some of my Dialogue Editor capabilities it became apparent that the initial version of the Dialogue System will not work. It was simply too specific. I needed a system that could be dynamic and modular. One that didn’t need any specific characters or didn’t expect any specific names. I needed a Dialogue System that could take in Dialogue data and assign it correctly to any character in a scene only based on the properties of the specific character object. Due to this I had to return to the Dialogue System and re-evaluate some of the ways in which I stored information and how my Dialogue System would process data.

If starting again, how would you approach this project differently?

Instead of instantly focusing on the Maze Generation I would first focus on the creation of a Basic Dialogue System and proceeding from there I would delve deep into the creation of a complex Dialogue Editor which gives a user all that they would desire all put together into a neat, pretty package that is easy to use and not complicated for the end-user but incredibly detailed on the inside. That is what I aimed for, and I have gotten to a satisfactory point yet, I would shift much more of my focus onto the editor itself if I could have started again as I believe that simply the Editor deserves much more focus than I ended up giving to it., simply to even make it more personal for each user and more customisable. However I am still incredibly satisfied with the Editor I have in place, I just wish I could continue my work on it to perfect it even more.

What is still outstanding/missing ?

The one outstanding piece of content in my project would have to be a more complex implementation of the Maze Generator. I have written an algorithm which allows me to create a procedurally generated maze. I have created a plane and I populate it by instantiating walls to create a grid on the plane. The algorithm I wrote for this project then runs through the grid and destroys the wall that is passes through when visiting a neighbouring node.

What advice would you have for someone attempting a similar project in the future?

My advice would be to definitely give a significant percentage of attention to user testing. Simply give a friend or a family member 5 minutes or so to go “have a spin” of your Dialogue Editor. It might not sound like much, but the feedback gotten from someone using your project is invaluable. It allows you to put yourself in a user’s shoes and see the project from an outside perspective. How do they go about performing simple tasks? Is the UI intuitive and the user feel comfortable or is it not obvious enough? Those and many more important questions can be answered within minutes with the help of user testing.

Ensure that you understand how you are storing and parsing information about the different dialogues. It is of highest importance that this is understood by the developer of a project like this one as these things are constantly coming up and the project simply needs to be handled in an adept way in regard to this. This is a prime example of where issues could appear if the creator does not understand the way their own parser works or how the XML or file of choice stores information. Issues and necessary code additions will show up all over the project as the dialogue have to be stored, loaded and parsed so that it can display correctly in Unity, overwritten, and saved and reformatted back into XML so that when loaded in again the same loader and parser can be used.

Another thing I could recommend to someone is a greater focus on the overall user experience. Make the system more approachable and visually pleasing. In projects of this sort, code and functionality is of course above all else, most important. However not a single person will choose to use the system if it is unintuitive, convoluted, confusing and much too complex to understand or simply if it doesn’t look nice. First impressions matter!

What were the implications of your technology choices?

My technology choices were the correct choices. I wanted to create a Dialogue Editor that could be used for a game engine. Choosing Unity was a great choice as it is an engine that is very often used by smaller and indie studios as well as students and enthusiasts like myself. Unity also does not have its own built in Dialogue Editor which has given me the perfect opportunity to truly create something with meaning and it gave my project a place where it could be used.

Conclusions

In conclusion my project has fulfilled and answered my research question accordingly.

How can Dialogues be written quickly and efficiently, allowing for quick insertion of the Dialogue into a Unity game?

I believe that my project is a prime example of how this can be achieved. The Project “Dialogue Tale” tackles each layer of this question and presents a simple yet effective way in which the question is answered. The project has the tools which are presented to a user, allowing said user to write dialogue quickly and efficiently in an easy to use and understand manner. The project is transparent and hides as little as possible from the user, allowing a user to understand and learn how the Dialogue Editor and System both work. Once the dialogue is written by the user, the dialogue can be loaded into the “Template” Scene to showcase the functionality of the Dialogue System. The research question presented by me asks for a quick insertion of the dialogue. The project does exactly that, all that the user has to do is to add a component to the target character object and then add a tag which coincides with the name given to the character in the Editor. That is all, the Dialogue System then proceeds to do all the complex work of loading, parsing, reformatting, and assigning the dialogues to correct characters for the user.

Future Work

Since games and writing are both an incredibly large part of my life and a significant portion of my passion goes directly to them, I intend to align my future as closely as possible with those two.

The finalisation of my FYP and its subsequent submission do not mean the end of my work on this project. I have put a significant amount of work, effort, research and, genuine interest into this project and its research. As a result, I do not intend to finish the project yet. My FYP and what I have planned for it will be finished and submitted, yet the project has much more potential than that. Hence, I plan to extend work on this project for a further few months, perhaps over the Summer. I will dedicate my own free time to perfecting this project and to transforming it into something more than just my FYP.

My intentions are very simple, I wish to further refine and develop this System and once ready I would intend to release the project as a package onto the Unity Asset Store. I very much understand that the chances of having thousands of downloads is very low, however it is something I would want to achieve. I believe this would be a great achievement and asset to have and showcase not only on my CV but as part of my career. I genuinely enjoy working on my Dialogue Editor and System regardless of some of the issues and great difficulties I have faced. I really believe that this project can be something great and an amazing opportunity to not only create something big but also to put it out there into the world and gain potential feedback and further improve the package as time goes on.

The next important steps on the journey to creating a fully functional releasable package from my FYP would be focusing more on the User-Experience. The idea of this project was to simplify the creation of dialogue for game creators. It is to remove any potential syntax errors and simply focus on the writing of dialogue, in an easy to navigate and intuitive environment. And I do believe that I have achieved that, however I would focus on this even more as my first step. I would get friends and family to test this for me and make notes how they use the system. How easy it is for them to use and what are the main errors and/or complaints they have. I would then ask them if they feel like there is enough customisation and editability in the system and if they have any suggestions or wishes in regards to what they would like to see added or what action they would like to perform. I would focus on this user-testing in particular because I have done a slight amount of user testing for this FYP and Research. All those user-testing sessions proved to be incredibly valuable towards my progress, further understanding and overall direction. Once the feedback is received, I would simply use the notes from that feedback and try to find sensible ways to implements these features or improvements.

The last very clear idea in my mind in regard to further work on this project would be to fully incorporate the Maze Generator into my “Template” scene. My “Template” scene is where I showcase and test all of my dialogue. It places the Dialogue System into a game setting with different characters and it assigns each dialogue to each corresponding character. I have a Maze Generator in this scene which randomly creates a maze using a Backtracking Algorithm. I would like to fully incorporate this Maze into my Dialogue System showcase. I would do this to show how dialogue can be changed during the game also as it runs. Simply put I would have a set of characters inside of the maze and each one of them would tell the player the next few directions they must take. Since the Maze is randomly generated this would mean that the dialogue for those particular characters needs to change during runtime of the scene. My current Dialogue System allows for this already, but I simply would not have enough time to fully implement this example now and I feel like it is imperative to include this feature as part of future work.

Project Code Video Showcase