Experiment Development, n°1 ‘Dialogue Systems & Ink’.
For Experimental Development, I’ll be looking into the Dialogue Systems mini brief, and exploring Inky for unity. I had already done some basic fiddling around, to see how it played out and followed through basic tutorials. However, its integration into Unity, how to display the text and dialogue choices, and how to properly structure story, etc.
I’ve learned rather quickly that there are two types of dialogue in games, which depend on how dialogue/narration heavy the experience is. These are non-branching dialogue, and branching dialogue.
Non-branching dialogue is pretty straight forwards. The player approaches an NPC, the NPC gives out their lines, and then the conversation ends. Sometimes if the NPC is essential, there will be the rare YES/NO answer, (or an answer revolving around a plot essential item), but other than that conversations tend to end. When interacted once again, either they will have exhausted their dialogue and repeat their last line. Examples of games of this kind are equivalent to early Final Fantasy Games, or The Legend of Zelda: Ocarina of Time.
Branching dialogue has the illusion of choice on its side. More story-focused games, such as the Baldur’s Gate or Mass Effect series live and die by its story, meaning the dialogue display and choices have to allow the player to explore every path granted to them, or to roleplay as a specific character/archetype we have in mind. Games like these will often branch off either according to a morality system (i.e: Paragon or Renegade choices in Mass Effect), or according to one’s characteristics, as seen in CRPGs (computer roleplaying games) such as Pillars of Eternity, Baldur’s Gate, Divinity, or Planescape.
The reality of the branching dialogue system is that it will rarely actively branch out, aside from major plot points or influencing other characters. The player’s choice, when talking to non-player characters for information, is not necessarily taken into consideration or merely outfitted by a different response, only to head back to the dialogue’s ‘hub’, or main display of answers.
An example of the branching dialogue system, with a central dialogue hub that branches after the player’s input.
Branching dialogue helps gathering more information on a subject, as well as grant the player freedom of choice. Dialogue is essential to roleplaying games: in tabletop roleplaying interaction between players as their characters creates the most crucial method of play and storytelling, while in video roleplaying games dialogue serves multiple purposes, gathering clues, furthering the core player fantasy, offering various answers that will fit the player’s own role or projected persona onto their character.
Later on, I’ll work on the structure of dialogue systems, and attempt to implement my own in the form of a basic interactive story. For now I’ve begun to teach myself Ink, using the tutorials for the tool. It is alot like learning a new language, but it comes with its own intuition.
Experimental Dev, part 2: Implementing Ink into Unity.
I’ve been getting used to Ink’s new scripting language, the way its vocabulary flows and how to link various “knots” or story points together. Put simply, Ink uses various functions that allow the writer to switch between lines of text and choices. An ink file is called a “story”. Stories are seperated into story knots, which are seperated into substories, with story choices allowing the player to move through knots, or express dialogue.
Here are some examples, I will use () to display inputs:
(== intro ==) is used to define the start of a story, essentially similarly to a chapter.
(*) or (*[action]) is used to define a choice, as shown in the script above, however this choice is only active once. The second example will hide the choice’s text when
(+) is used to define a choice that can be explored multiple times.
Whilst working around implementing the story itself into Unity, I encountered troubles with unity-ink implementation, namely displaying dialogue choices, so that the choices’ text represents the choices in the Ink story file properly. Thanks to Tom, another course member, I was able to find tutorials and explore various possibilities in an attempt to make the implementation happen… However, it was a failure.
The dialogue choices don’t appear as requested. The choices are inverted, and regardless of my efforts I couldn’t effectively have them be displayed according to the test story’s script. That isn’t to say it wasn’t a sufficient effort, attempting to build the implementation from scratch allowed me to gain a better understanding of the system. Nevertheless, I still need to get an active text based game. After deliberation and some counsel from my course leader (and the aforementionned Tom), I chose to default to the “BasicInkExample”, an example scene imported alongside the Unity Intergration Plugin for Ink that showcases a basic scene of how Ink can be used in Unity.
The example scene provides a functionning example, so I figured why not simply work using that and alter the UI later on, making it more interactive. So far, I have no intention on alternating the example’s script that comes with the Intergration plugin, however I do plan on finding out a way to display the text and options in an ergonomic manner. Which means I had to do a little deep diving into text based adventure games. All examples can be found here: http://textadventures.co.uk/
Here the text is displayed like a page out of a book, the side bars display your inventory, and an interactive compass that allows you to shortcut your way through the game. Essentially, you click on a direction, such as east or west, and the game will register it as an input. Alternatively, you can write your direction/actions in the type box at the bottom of the browser’s screen. A particularly handy tool is the map at the top of the game which displays your current location and evolves with your actions.
The way Whitefield Academy displays information and dialogue makes for a very interactive experience, the compass to the right allows for a quick exploration of the story’s locales and level. Compared to other text adventures I have experimented with, the added UI and display methods aid in generating investment and interest. As a personal testimony, I always end up getting bored of seeing nothing but text on screen. One might think I have the same attitude to books, but this applies mostly to games alone. Which will primarily lead my intentions to make something more ludical than simple text.
Comparatively, we have Portcullis, by Robin Johnson. Portcullis is reminiscent of Amiga text adventure games, though even then those had illustrations and semi-3D pictures to aid the player understand what was going on. Though it isn’t played like the game I wish to create, it is still an advocate for better UI design and presenting dialogue/information. Whilst engaging, Portcullis lacks making the visual experience anything other than simply text on a screen.
So, to-do list: – Get the story more defined, use the basic example scene as the building block for the rest of the game. – Complete at least one story, alongside the prologue. – Download the basic example scene again and use that as testing grounds for new UI and displaying dialogue. – Look into UI and Dialogue Systems some more, annotate that in new Dev Log.
Experimental Development Part 3: “Updating the UI”.
Now then, the prologue of the game itself is finished. In essence, it was my own way of experimenting with Ink’s interface and trying to figure out how to properly design dialogue and a text-based adventure for this unit.
After some deliberation, I chose to split the UI into two different canvases, one for the text and the other for the buttons. A moveable game object would appear at the end of the prologue, the alchemist’s guide, which details the various diseases the players will encounter and describes them accordingly. I had in mind to inspire myself off of Minecraft’s book, which rendered an additional UI hud that prevented interaction anywhere else in the game.
Whilst that would have been easier to produce, I felt like trying something else, as it would end up stopping the game’s flow and would be less interactive. Remembering “Papers, Please” I examined how the game treated the various kinds of documentation it handed out to the player during the game. Basically, those documents are simply drag and droppable objects that have present features. I chose to emulate that, and have it be an in-game item that allows the player to open and close the book, as well as peruse the various diseases.
Finally, having finished the prologue, I drafted a basic plan of what the first chapter of the game would be. The idea was to have a blacksmith be afflicted by small pox. Using your knowledge of the disease thanks the book, and by speaking with various characters – as well as the disease itself – to determine which kind of illness is afflicting the patient. The drawing below illustrates how players would cycle through dialogue and slowly gather knowledge of the situation before diagnosing their patient.
With regards to progress, things are not advancing as quickly as I’d like. I will likely have to omit a few game features from the final product, but the purpose of the unit, I feel, will be met appropriately. I feel like I’ve only brushed the surface of what Ink can provide, though perhaps I should have started off sooner.
Experimental Development, part 4: “Implementation issues 2 electric boogaloo.”
Implenting Ink into Unity proved more difficult than expected. I had plans to use tags within the Inky file to start events on the scene, however struggled to properly read said tags through code. These events included changing audio effects/ambiance, spawning game objects on scene, changing the background colour of the camera or some other event. The issue is that the documentation didn’t provide – in my mind – a sufficiently clear example. That being said, one of my course members had previous experience with Ink’s implementation.
Following Tom’s advice, I attempted to use his example to identify, store and access tags written within Ink’s script, however it proved to be too difficult and I had a sense of doing something wrong (namely the script didn’t work). The progress I was making was too slow and insufficient to execute without sacrificing a playable example by the release date. I considered mimicking “Keep Talking and Nobody Explodes”, by providing with the game a downloadable PDF that would cover the diseases encountered during the game.
I decided to undo everything and instead made use of a List<string> currentTags, to fetch any of the current story tags in the ink file. Ink has a function called story.currentTags that returns a List of all current story tags, debugged that underneath the function story.Continue() which as it says continues the story.
With that out of the way, I could finally get to implementing spawning different game objects when the script reads through the various tags. With this placed properly, I can finish the story and begin to embellish the whole project.
Things left to do:
* Finish the smith’s story.
* Make it prettier.
* Make the background change depending on the tag.
* Add sounds and feedback to buttons and interactions.
* Add a proper text box behind the main text box.
Experimental Development, part 5: “Conclusions.”
Progress!
I wouldn’t want to say this project was a failure, as things have been learned and properly executed. I have set out what I wished to do, which was to use Ink to create a text adventure. However, I’ve not successfully created what I had originally envisioned. My original plans were to create something far more interactive, but in the end I fear I’ve overstepped my intentions.
I have successfully completed the text adventure itself, it is fully playable albeit there is little else to it. The book I have created can be interacted, and using it one will be able to determine what disease afflicts the doctor’s patient. So far, this what the main UI would look like.
I’ve also added audio files that are read depending on which tags are recorded throughout the ink story script. This is mostly used for ambiance’s sake, however provides little else. Due to the ink implementation script, one of the audio files I attempted to execute conflicts with the button’s basic script. Something that I cannot afford to fix and that changes little to the game as a whole. Sound design often makes or breaks a game, but I would rather think in the light of this unit, it will have little effect.
I’ve basically remedied the whole tag problem by simply creating a list and foreach loop that checks for specific tags within the story each time the UI refreshes, activating said events from the Game Manager with each noticed tag.
In addition to this, I’ve decided to cut much of the original content of the adventure down to a singular story. I had originally planned for the ‘prologue’ of the game to be a tutorial period, then followed by the tale of a plague doctor living in a small town from fictional France. Originally I had the doctor meet with various figures from the town, curing their diseases one by one to prevent the onslaught of a plague, referring to each plague through the use of the doctor’s own book of a diseases.
However due to time, I had to cut much of it out, and instead focus on making sure the game would run with only one, which I dubbed the Smith’s Tale. Much of my time has been writing said tale and trouble checking it to ensure it would run smoothly. I’m glad to say it does, though does present some issues I have yet weeded out. As it currently stands, the game is playable, but unimpressive and rather boring to look at. Not all audio has been implemented properly, and there are no graphics to be seen, sadly. While I’ll submit a functionnal copy, if I can add some graphical effects before the hand in time, I’ll see that it can be done.
WHAT WAS LEARNED, AND WHAT IS POSSIBLE:
For the time being the first adventure is complete, the game has a beginning, middle and end. It is sufficient though not satisfactory to my own expections, which I shall explore in my report. However, I have learned considerably in making this project, namely in implementing Ink, but also its scripting language and its versatility. The scripting API is remarkably easier to understand than C#, much of it suits a writer’s perspective, but one can add variables that can be manipulated/incremented through scripting, just like so:
This would then lead to other opportunities that can be set at the beginning of the story. Different names could be inputted as string variables, maths can be done in the scripting as well to calculate player levels or dialogue options, various different endings can be provided through conditional statements, so on and so forth.
If I were to continue the project, however, I would likely implement these variables in methods that would increase player interactivity. Allowing them to choose or input their own name, for example.