Tutorial Rework Talk - ARS Devlog #3

Hi!!!1!11

Woah! Been a while huh? I've sat down to write multiple times these past two months, but i just had nothing to write about!!!

My original plan for situations like this were to show off some of my coding and behind-the-scenes work, but a lot of it is pretty bad since I was crunching like mad to be ready for CHROMA. I was hoping I wouldn't run out of topics so soon and that I would have better BTS stuff to show by then...

But I finally have stuff to talk about today!

_______________________________________________

A new topic?

I've slowly been chipping away at the new tutorial, and I've had to come to grips with the fact that a lot of my rushed systems are... total bunk. Dialogue systems, timeline systems, replacement systems, and the small things I just needed to get done for CHROMA are not fit for expansion. So while I work on this tutorial I've had to take a step back and rework some of those systems. It sucks, but that's just how gamedev is sometimes. It does feels nice to finally redo systems with the proper love they need this time, though. 

For this devlog, I want to focus on how I'm approaching the new tutorial and how it interacts with my dialogue system. So let's talk about it!

To get started, let me explain how my dialogue system works. It's as simple as it can be, honestly. It reads text from the main dialogue list, and then writes it out one character at a time. Each string in the list is a different text box and once you run out of strings, the dialogue box closes. Same general process for the talking heads / character sprites, big list of sprites given and displayed with it's corresponding text line. Clicking mid-writing skips to the full text, and with tags I'll talk about later, I can give Yes/No prompts.  I'd love to add more functions (animated sprites and sfx are a big ones) but what I have now does it's job, and that's what matters. I haven't had the chance (or direct need) to overhaul the entire thing just yet, but I have done a few things to get it to play nice with the new tutorial system.

The way that I programmed it originally was whenever I wanted to add new dialogue, I just overwrote the list of strings and sprites and then restart at line zero. Here's a snippet of how that works:

public void BustedMotherboard()
 {
     textToDisplay = new List<string>
     {
         "", (this blank is used as a buffer)
         "Holy moly this motherboard is toast!",
         "What did this guy DO to this poor thing."
     };
      spritesToDisplay = new List<sprite>
     {
         spriteOptions[(int)AylaSprites.Confused],
         spriteOptions[(int)AylaSprites.Confused],
         spriteOptions[(int)AylaSprites.Sad]
     };
      ...
      (code for updating components and fixing issues caused by timelines, i'll get into this another time)
      ...
        
      animator.ResetTrigger("Exit");
      animator.SetTrigger("Enter");
      currentLine = 0;
      NextLine();
 }

Simple and easy to copy-paste, though annoying to fix issues in. I want to rework this to pull from a script instead of having to hard-code dialogue into functions. Doing so would make it easier for me to notice and fix typos, bad phrasing, etc on a larger scale and without having to find the functions in code. Dialogue System for Unity has a very good interface for this and I DO own it, but it has so many extra bells and whistles that I will never use and will take up unnecessary space (it also has issues in unity 2022.3.0, the version I'm using for ARS). In the end I went with my own solution instead. I think using individual text or json files could be good for my purposes, but I'm wary due to scalability and file bloat. In the end I've decided to take my time to sus out a good format for this use case.

_______________________________________________

Tutorial

The old tutorial was barely even a system. Just dialogue and sprites placed into the inspector. Though this has one major difference that other dialogue doesn't... tags! These act just like you'd expect. If the dialogue manager receives a tag in runtime, it runs the associated function (tags are removed from the written text). The "(PROMPT)" tag hides the continue button and shows the yes/no prompt . If the player chooses YES, it continues the dialogue as normal, if they choose NO there is a "(SKIP TO)" tag that the dialogue writer jumps to.

It's straightforward, but a huge text dump makes for a bad tutorial and a worse player experience.

I aim to make the new tutorial a little more traditionally hands-on, so I've turned to my best friend, Unity Timelines! I used this system when making a tutorial for a previous project I was programming for, and I know this will get me where I want to be.

The simplified explanation it uses Timeline Signals to overwrite text and then uses a new "(WAIT)" tag to pause dialogue until an action is completed. Here's a picture of the timeline so far. It's simple and I like how I've approached it so far. Each set of signals has one for dialogue and one for pausing the timeline. They're separated by a few milliseconds to stop them from running at the same time and breaking.

Each signal has different dialogue and sprites. They're broken up by "|" into lists and then inserted into the dialogue manager. The dialogue is hard to read like this, so I currently use window's sticky notes to read and write these. Not the best solution, but timeline signals don't allow for list inputs so I had to improvise!

The action requirements are individual hard-coded functions that watch the repair manager to keep track of what the player is interacting with. It starts at step zero and increments by one as you progress. Neither this nor the dialogue injection is ideal, but I've made it easy to replace when I come up with a better solution.

The timeline functions themselves are great, but tends to break when interacting with any other sort of timeline. This is pretty dreadful since mechanics I need to teach (wires and screws) use timelines to move objects around and get player input.  The repair timelines work pretty well, but at the time I couldn't figure out how I wanted to replace mid-timeline dialogue and spawn components. I gave up and just called them when needed in the timeline. This ended with me having to make duplicate timelines for missions with very minor changes and it's hard to change without breaking everything else. Very easy to do for a tight deadline, infuriating to deal with now. So before I can continue with tutorial actions, I now have to go back and rework these to be reusable for every instance of that component.

The screwdriver is also pretty hard to track because it barely uses the timeline! It uses signals to time function calls but that's it! Watching screwdriver position won't work because it moves to wherever the screw is. Timeline tracking COULD work, but it would break if I ever adjusted or changed it. Watching what's being held doesn't work since you don't hold the screw until it's finished. I guess I could track when the timeline is being started, but then it would mess up other timelines since the repair manager uses the same function. My only ideas are to add a call when these specific screws start the screwdriver timeline, or figure out a way to track the screwdriver itself. I'm leaning towards the latter since I wouldn't have to mess with all the screws and possibly introduce more bugs. Not to mention the idea of hard-coding even more stuff is making me annoyed.

While this specific tutorial will never be re-used, I will have to build off of the framework I'm making to introduce other mechanics later down the road. So I'd prefer to find a solution that is reusable and insulated as possible from outside changes.

And that's where I'm at right now! Mostly scratching my head trying to figure something out when I have the energy after work. But progress is being made and I want to make sure I do it right. I hope this was an interesting read! I'm still very new at writing these so I hope I continue to have your support and patience! <3 If you have any questions or ideas on what I should write about next, leave a comment!

_______________________________________________

In case you missed it!

I got the chance to show ARS at COGG's Prototype and Play event! It's a pretty small digital event on discord, but I still had fun and wanted to talk about it a bit.

COGG is the Central Ohio GameDev Group and is a wonderful little community! You can find both my and other's games on their website, https://thecogg.com/. If you're interested in checking out indie game developers from my area or you're a local and want to join yourself, check it out!

Also apparently COGG showed off ARS a little at GDEX this year?? I'm not sure if it was open to play or just the trailer, but I'm still pretty happy about it! I wanted to get a booth for both ARS and Mailroom, but I couldn't get the money in time and then got injured so I wasn't able to even attend. T-T

_______________________________________________

Recovery updates!

Last time I capped my devlog off with info about my injury, so I'm here today with good news! My recovery is going well!!

I've been able to walk again since late-September, and I returned to my day job in early October! Yay! Income! My two months of physical therapy have also started winding down. It's been incredibly helpful and I would not be where I am in my recovery without them. I do still have some pain, but my fractures have healed and all that remains is continuing to rebuild lost foot muscles. I can even skateboard again! I've been cleared for returning to rock-climbing, but I just haven't had the chance to go yet. But I will!!!!!!!!!!!!

Thanks for reading, seeya!

-Carri