Skip to content

Getting a Tutorial In

One of the last things we wanted to do was to get some type of tutorial in. Originally, we had wanted a full, in-game tutorial that had narrative and would teach the Player how to play more organically. That did not happen! It would have taken way too much time to come up with dialog, script other animations for the Crew, add a whole character for your mentor, etc. Most of that work would not have translated over into the main part of the game, so very little reward for how much time we had left.

Instead, we opted for a text based tutorial. To make it more digestible, we broke it into two screens: one with a basic intro and the most important details and another screen with gifs showing the character actually performing the actions. We wanted to not just have a wall of text, since that can drive people to not read it.

Andrew did a really good job of creating the tutorial screens and converting the gifs into sprite sheets that Unity could work with! Looking back, I would have liked to have stayed with the same button style that we are using on the other screen, instead of the arrows but it sounded good when we talked about it. This also would have allowed the button to have hover states and such, whereas the arrow is actually part of the background currently. Ah, the joys of deadlines!

Screenshot of the first tutorial page

Screenshot of the second tutorial page

Once Andrew had the screens created, I took on the task of actually wiring them up. He had created them in a separate scene, which had some pros and cons.

Pros:

  • Very easy to work into the overall flow of the game. Instead of Start taking the Player to the Main Game scene, it took them to the tutorial scene
  • I didn't have to worry about setting the time scale or anything to keep the caravan from starting without the Player while they read the tutorial

Cons: - Because it is so isolated, we couldn't add the tutorial screens into the other menus (like the Pause menu). This meant you had to go back to the Main Menu and click Start again to see the tutorial. Not ideal - I caused a "double" loading scene, where you click Start on the Main Menu and it loads the tutorial, then you click Start on the tutorial and it loads the game.

I think if we had integrated the tutorial more as a separate prefab that could be spawned into any scene, that probably would have been better, though it would have been more work to ensure the background stuff wasn't messing up. I think doing it as a separate scene was just fine for what it is and if I had more experience with additive scenes, I probably could have gotten it to work like that anyway.

I wanted a way to not show the tutorial on subsequent playthroughs, since I know how to play the game and I don't want to click through the tutorial every time! I hooked up a "Don't Show Again" toggle onto the last page of the tutorial that stores your choice to the PlayerPrefs. Then, when you click Start on the Main Menu, it checks that value and either sends you to the Tutorial scene or the Main Game scene.

Of course, if you could hide the tutorial, I felt that there should be a way to re-show it. As mentioned earlier, it wasn't as simple as just adding a menu option to show it. Instead, I added a button to the Main Menu that allows you to reset the tutorial, clearing out that PlayerPrefs value.

Gif showing how the tutorial works

Overall, I'm really happy with the flow and look of the tutorial!

Bad News Bears

Everything was looking great and we wanted to get a test build up with the tutorial while Andrew was finishing up some other changes. I got the new build made and deployed on Itch. Everything looked great with the tutorial but when I tried loading into the Main Game scene, disaster struck!

Gif of the error popping up when loading the main game scene

Screenshot of the initial error found in the web build

I had never seen that error before and the previous web build had worked perfectly. What was going on? The error is not very descriptive and online resources didn't really help much. I didn't understand. The game worked great running in Unity, so we didn't know there was a problem. I started tracking down where it broke. I knew the last good web build was the one I did after reworking the particle systems.

Thankfully, we have been using version control, so I was able to checkout the previous commits and make builds off of them to see if they were broken. I was able to go back a commit and the Main Game scene actually loaded but everything was borked in it. Most of the models weren't showing up,, which meant the lights didn't have anything to illuminate, which meant a very dark scene.

Screenshot of the main game with no meshes in it

On that build though, I saw a bunch of errors in the console. Progress! That meant that it was broken on that build and we had more errors to look in to. It was also around this time that I learned that you could Build and Run in Unity to test the actual WebGL build, instead of having to upload it to Itch or similar...simple now that I think about it but it never crossed my mind!

Screenshot of the fragment shader errors

Unfortunately, these errors weren't as helpful as I had hoped. It could be caused by any number of things. We went through and tried a lot of the common causes. None of them seemed to apply to our project. It was all set up "correctly" from what we could tell. Then why didn't it work?!? We did find some Render Layers that had accidentally been removed, which could be the cause but restoring them did not resolve the issue. There were also some changes to the PR_Renderer and Mobile_Renderer asset files in the project settings but Andrew didn't remember explicitly changing them and I couldn't tell what the changes meant. I could tell that a MonoBehaviour was added but it is all in Unity's serialization format and I couldn't see anything definitive on it. Our working theory is that something in the changes made to add the blood decals in doesn't play well with WebGL.

After a couple of hours testing and trying different builds, we were not making any real progress. The end of the night was fast approaching and so was the submission deadline. I made the call to start a new branch off of the last good build we found and apply as many changes as we could to catch up to the "current" build. This meant redoing the tuning we did the other day, the tutorial, as well as a bunch of sound and dialog stuff that Andrew had done. We were excluding the blood decal stuff, for now, even though it was one of the bonus challenges for the jam. Better to have a working game without blood, than a broken one with blood!

Sweet Release!

We scrambled to get all of the changes in on the new branch and we were able to get the important ones in! Now we just needed to make the Itch page public, do some last minute content changes, and submit the game!

Actually submitting the game was less exciting than I was anticipating. I'm not sure what I was expecting but I was kind of let down (about the submission process itself, not the game). I guess I was hoping there would be confetti or party poppers or something on the submission page but it was just this.

Gif of clicking the submit button for the game

I think the build up of the whole month+ working on this and the chaos of the build failing just made me want something with more fanfare! Regardless, I was super happy that we were able to get something submitted before the deadline and it was (mostly) what we had working!

It is an unreal feeling seeing your game publicly available. This is our first "real" game that we've published and definitely the one that will have the most people actually see it! The one game we published in college that had like 3 people see it and that wasn't actually a complete game doesn't really count in my book. I'm super proud of the team and glad it is finally over (or is it?)

Screenshot of our game along with the other submissions on Itch

Now though, it is time for sleep!