Capstone - Ernest & Alexander

Title Sequence

I added in Lily's draft title sequence into the starting menu using Unity timeline (fig. 1). It is a very rough draft at the moment, but I wanted to see how it would work since I haven't done much more than character animations before. While sitting in the Title Screen, there will be an idle animation of the bus, then when play is clicked, it will smoothly transition into the title sequence. We decided that a short scene to lead into the game would help to smoothly set the scene and go into the narrative without forcing it on the player.

Timeline

This is the timeline I have created for myself (Fig. 2). I will aim to make two minigames every week, but I have given myself a bit of leeway by leaving time in the mid-sem break in case I get sick or have other things on. I am focusing on the minigames before the rest of the mechanics since they are the most important part of the game for me, especially since my research question is concerning minigames.

Draft title sequence (Fig. 1)

Font

For the font we wanted a handwritten style since the menus are Ernest's diary. I looked at some free fonts but couldn't find any that fit, so I made one using Calligraphr. I made a regular and bold version. (Fig. 3, 4, 5)

Timeline (Fig. 2)

Regular Font (Fig. 3)

Bold Font (Fig. 4)

Font in Game (Fig. 5)

Quest System

It is important to our game that there are quests. These are what will progress the story. I followed this tutorial. However, my game so far was set up in a different way to the tutorial, so I had to make my own changes. For testing, I wanted to make a simple quest for collecting a certain amount of flowers, so I added a function that finds the amount of the required item currently in the inventory when the quest is activated.

The tutorial used an event system for all of their components, which is not something I have done. However, because I didn't, I ran into a lot of issues trying to set up the quest system the same way. I attempted

to change my game to use an event system, but I messed up and it was a lot more complicated than I thought it would be. Github decided to be dumb and wouldn't let me revert the changes, but I managed to get it back to what I had before with some help from my dad. I will pause on implementing the quest system for now, it has taken a lot longer than I thought it would and I need to move on to making the minigames. I will come back to this later since I'm also still considering if it would be worth it to try add an event system again since my game isn't that large and won't need to handle a lot of quests at once.

I also added in the audio manager, I followed this tutorial by Brackeys.

Sneaking Minigame (Fig. 6)

Sneaking Minigame

While I had already made a sneaking out minigame, it was very basic and boring. We wanted our minigames to be puzzles, to not just be an interactive part of the story but something the players will want to do again. I thought a kind of cat and mouse game could be good, where the player and teacher each take turns moving, and the player is trying to get past without being caught (fig. 6).

‍

For the movement, I looked at using the grid system. For now, I found a free tilemap to use as a placeholder. I made this simple Player Movement script (Fig. 7) that uses the horizontal and vertical inputs to move two spaces at a time so it goes to the corners. To prevent the player simply walking through obstacles, before the player moves, it performs a check to see if there is an obstacle one block in front (like a hedge or log) and if there is, the player doesn't move.

Sneaking Player Movement (Fig. 7)

I was sick this week so I didn't make as much progress as I wanted to.

Sneaking Minigame (cont.)

For the teacher movement, I followed this tutorial using a star pathfinding algorithm. It uses nodes to tell the teacher where it can move to from each spot (Fig. 8). For some reason, it was not working when I copied the tutorial, I went back over it several times, so I copied their script into mine and it worked, but unfortunately it had saved and wouldn't let me go back to see what I had done wrong.

I wanted to make the teacher glide rather then jump to each spot. I made a silly mistake and used a while loop in the Update function (Fig. 9) which caused Unity to crash as soon as I tried to run it. I added a new bool called isMoving (Fig. 9a), and used an if statement to tell it when to move.

The tutorial was written in a way that the teacher would continuously move towards the player, however, I want them to take turns. I added a public bool that was turned true and false when the player and teacher moved.

Pathfinding Visuals (Fig. 8)

Teacher Movement Script (Fig. 9) Red outline (Fig. 9a)

Rhythm Minigame

We wanted to have a rhythm minigame around the campfire, like singing songs around the campfire. I followed this tutorial by gamesplusjames for the basic gameplay. The part that took the longest was trying to make the arrows line up with the song. It was set up in a way that each beat should be exactly 1 space apart, but the rhythm isn't exactly on the beat, often on the half, or sometimes even quarter. I tried a few methods to line up the arrows. First I tried manually placing them a few at a time then playing the song to test it, but this was taking a very long time. The song is 1 minute 30 seconds and I could only do a few seconds at a time. I then tried adding arrows on every beat and making them turn red when I pressed on the beat, but most of the time 2 arrows would light up or none would (Fig. 10). I then set it so an arrow would be instantiated every key press, then I used those to line up the arrows on the correct beats (Fig. 11).

‍

I'm taking a lot of inspiration from the 'Night in the Woods' rhythm minigame. The current assets are placeholders and will be changed to be pixel art and to fit better with the camp theme, so maybe look like a guitar. I did add in the scoring system, but I think I will change it to just show your highest streak and misses and things like that. The multiplier and current score system feel too arcade-y.

Creating Notes (Fig. 10)

Creating Notes (Fig. 11)

Unpacking Minigame

This is going to be the first minigame the player will play, so it is a fairly simple one. We have not decided yet if the player will be able to come back and play this one like they will with the others beacuse if they do not unlock new items, what is the point in rearranging the room? It is very simple, you get the items from the bag then place them in their highlighted spot (Fig. 12). The assets are not finished yet, Lily is working on them. If we want this minigame to be replayable, I would need to alter it so items could be placed anywhere, and there would need to be more customisation available which I don't think would suit the game, so we probably will not be doing that.

I had some trouble when trying to make the held item know when it was over the outline and therefore able to be placed. I tried OnCollisionEnter, OnTriggerEnter, Physics Overlap Circle, and even manually checking the transform position. The thing that worked was using a raycast on the Z-axis to detect if the outline was behind it.

Unpacking Minigame (Fig. 12)

New Font

Since we changed the artstyle to be pixel art, we needed a new font. I created this one, I think it will be good for headers and titles, but I don't know how well it will work for smaller text like dialogue and item descriptions. We will test it out, but we might need a new font.

Fishing Minigame

I have been taking inspiration from a few games for this, mainly 'Webfishing'. Their mechanic works by filling up a catch meter and then mouse clicks to get past the yank spots (Fig. 13). The more rare the fish, the more clicks are needed. I have decided to use a similar mechanic. Every second or so, a button will appear on screen with a random letter on it and the player has a limited amount of time to press the button. Each press will draw the fish in, but missing one will either release the fish or just put it back a few spaces. I am still developing this minigame, I plan to finish it in week 6.

Webfishing fishing mechanic (Fig. 13)

Rhythm edits

Before playtesting in week 6, I made a few changes (Fig. 14 and 15). I thought the arrows looked too clunky so I reduced the size slightly and got rid of the arrows at the bottom of the screen. This might be something I change back since now there is no feedback when you press a key, but I'll see how it goes during playtesting. I also added lines in to look like a guitar and to hopefully make it more clear what order the arrows need to be pressed. These still aren't the final assets, the background will be pixel art, and we are going to use WASD instead of arrows to match the rest of the game's inputs, so I will make keys to replace the arrows. This should also help to reduce the clutter on screen.

Original Rhythm layout (Fig. 14)

New Rhythm layout (Fig. 15)

Annotation - MDA Framework

Hunicke, Robin & Leblanc, Marc & Zubek, Robert. (2004). MDA: A Formal Approach to Game Design and Game Research. AAAI Workshop - Technical Report. 1.

Originally proposed by LeBlanc, Hunicke, and Zubek (2004), the MDA framework (Mechanics, Dynamics, Aesthetics) is a model for analysing and designing games. It separates games into three building blocks: Mechanics, the basic rules and systems such as player controls, enemy detection, algorithms; Dynamics, the behaviour that results when the mechanics are enacted during play; and Aesthetics, the emotional responses elicited from players from the dynamics. Players primarily engage with the game starting from its aesthetics, like looking for games that fit a specific genre, designers typically start with the mechanics to produce the intended experience.

This framework has changed the way I look at designing minigames. For our capstone, I am creating the minigames to work with Lily's narrative. If the resulting player experience, the Aesthetic, doesn't match the narrative, the minigames feel disconnected and break the immersion. Using the MDA framework, I can trace back to the mechanics and edit them to create the response I intended. For example, in my rhythm minigame, there is a scoring system that creates a competitive feel since that is how rhythm games are usually scored. However this does not fit with the vibe of the overall game, it is meant to be a nice minigame to play at the campfire before bed, not stress the player to get the highest score. I can see the Aesthetics are not what I intended, so I will go back to the Mechanics to change the scoring system, which will change the Aesthetics from competetive to calm.

I will find the MDA framework a practical tool that will help me design the minigames more efficiently in a way that blends seamlessly with the Aesthetic of the narrative. By first considering the emotional response I want to evoke, the Aesthetic, I can then identify the required dynamics and mechanics. This approach supports iteration and helps ensure my design choices stay consistent with the intended player experience.

Playtesting

We did playtesting in class this week, it was very helpful and fun to see everyones games and get feedback on our own. I put the Rhythm, Unpacking, and Sneaking Out minigames out for playtesting.

‍

Unpacking

The main feedback I got for this was to add something to indicate when you are done. It is quite plain right now, so maybe add some more output for the player to know when they place it right. Someone suggested to add another minigame inside this one to fold the clothes yourself which could be interesting to add. It would also be cool to lay down the bedding yourself, unroll the sleeping bag etc.

Rhythm

The main feedback was there needed to be some sort of feedback for the player to see when they press a key. This is something I had but had taken away because I thought it looked clunky. I will definitely add it back in, or something to the same effect. It was also mentioned to add an indicator if the button is pressed too late or early, and penalties for missing since right now you can spam the keys and not get any penalty. This is already something I was thinking of adding, so I will definitely do it soon. Someone suggested increasing the scroll speed to increase the space between the arrows which I think is a good idea because it can be hard to see the difference in placement. Someone recommended adding more songs which is something I would like to do to increase replayability, but it will be something I do later.

Sneaking Out

The main feedback was that it was too easy, once you get in front of the teacher they cannot catch up. I think this is more an issue with the map rather than the pathfinding, but I will definitely adjust the map to be more difficult. Someone suggesting adding intense music which I think could work well, it would stress the player out and they would be more likely to make a mistake. Another important bit of advice was that the teacher should catch you if you are in eyeline, not just when she is next to you. I like this, it makes a lot more sense in this context, so I will add this in or I'll adjust the map so that you are only within eyeline when you are next to her.

All of this feedback was really helpful, and I got a lot of inspiration from all the other games I played.

Annotation - Self Reflection

From weeks 1 to 6, I have developed almost four minigames: sneaking out, unpacking, rhythm, and fishing. Although I am slightly behind my timeline due to a few reasons, I think I will be able to catch up over the mid-semester break. One challenge that set me back was the quest system which proved more complex than I thought. I followed a tutorial, but since I was using a different system than the video I struggled to implement the same features. I plan to scrap my original attempt and readjust my timeline accordingly. Despite this, I feel confident I will complete everything I have set out to do.

‍

My design process has been influenced both by my research into experience-based play and, more recently, the MDA framework. These perspectives and my continued self improvement have helped me to better understand the code, mechanics, and player experience. Earlier in this semester and last, I often relied on tutorials but struggled when I needed to adapt them. Now I am much more confident in creating minigames independently, in seeing how the different elements combine to produce the intented outcome. Moving forward, I aim to reduce my reliance on full tutorials and will instead research specific problems as they arise while constructing the systems myself.

Looking ahead, it is crucial that I keep my research question in focus: How can I create a game that integrates minigames to enforce and support narrative to design an experience that subverts visual novel expectations? To answer this, I need to ensure that each minigame feels cohesive with the overall narrative. The methods and frameworks I have been engaging with will guide me in making design choices that maintain player immersion while also allowing for iteration and refinement as needed.

Fishing

I got started with the fishing game. I made buttons for every letter created a function that instantiates a new one every second. When a button appears, it starts filling up with red, and once the red is full, you have missed that button and the fish will move back a space. I created a coroutine to move the fish (actually will look like a bobber in the scene) for testing (fig. 16). I tried using a Vector3.Lerp to make it move for 6 seconds to fishing rod, but I could not figure out how to pause it. Instead, I will try using Lerp to get the distance, then every correct button press will move it forward like 1/5 of the distance between the start and end point.

First iteration of MoveFish function (Fig. 16)

I rewrote the MoveFish function to just use the space bar for testing (fig. 17). I set movesLeft as 6 at the start (so 6 correct presses will make you win), and each key press brings the fish closer by 1/movesLeft - so 6 moves left, you press the key, then you move foward 1/6 of the distance, then next key press, you move forward 1/5 of the distance. This should hopefully keep all the key presses moving at the same rate.

Next iteration of MoveFish function (Fig. 17)

I didn't like how the buttons looked that I first made, they were just a plain square with the letter in the middle, and the filled up with red to show how long you had left. I wanted to create something that fit in with the minigame, so I decided to make it look like the keys were rising up of the water, and you have to press them before they sink again (fig. 19).

I cleaned up the script a bit (fig. 18). MoveForward is called when you press the correct key, which then calls MoveFish, a coroutine to make this fish move smoothly. I have it set that the button spawn frequency will match the time it takes the fish to move a place, so it keeps everything in sync.

Fishing button animation (Fig. 19)

Final iteration of MoveFish function (Fig. 18)

Timeline changes

I've decided to make some changes to my timeline, I'm futher behind than I wanted to be, and feeling quite burnt out so I need to manage my time better. I will use the break to catch up a bit, but I've decided to scrap two of the minigames - cornhole and rock skimming - since neither are really puzzle games, and were just added so we would have more. I will aim to finish up the bulk of the minigames by the end of the break, so I can spend the next half of the semester making the whole game functional all together.

Cooking Minigame

I took on all the assets for this minigame, it was good to have a break from coding and Lily has a lot of art to do. We decided to make the cooking game like a block game where you fit all the pieces into a specific outline. All the pieces are going to be burger ingredients (fig. 20), to make different levels, all the students will have different orders. I made each ingredient fit a different block shape, and tried to get as much variety as possible. Each student having a different order is a good way for us to actually tie the game in to the narrative and not have it feel like a random minigame, and also allows for some subtle environmental storytelling, like what ingredients each student asks for.

Food items drawn in Procreate (Fig. 20)

For this minigame to work as intended, the food items need to snap to the grid in the correct way. I tried a few different methods that didn't work, so decided to go back to the start and try again. I first made a function that detects if the food is over the board, and if it is you can place it down, otherwise it gets sent back to its start position (fig. 21).

First iteration of placing food items on grid (Fig. 21)

I added a few raycasts to each food item, one in each spot it would occupy in the grid (fig. 22). When you let go of the item, this function checks if every raycast is above the board. If they are, it gets placed, and if even one isn't, the food is sent back to its starting position (fig. 23).

Food items with visual raycasts (Fig. 22)

Next iteration of placing food items on grid (Fig. 23)

I next tried to add a function that also checks if there is food in the way of the board, so you can't overlap the food items. At first it was not working, and just kept detecting itself as all the food was on the same layer. I tried to set it to ignore its own collider, but that did nothing. It turns out I was using the wrong component - since this minigame is 2D, I should have been using Physics2D.OverlapPoint, not Physics2D.Raycast. With this change, it works as intended, and food cannot be placed on itself (fig. 24).

Final iteration of placing food items on grid (Fig. 24)

I unfortunately got the flu right as the break ended, and couldn't even look at a screen without feeling nauseous. Along with this, I was also still feeling burnt out, so I allowed myself to take a break and recover.

I did a few small tasks, such as adding in the idle animations Lily made for each character. I will make a change in these to randomise when they start because it looks vaguely unsettling with them all moving in sync.

I created a better to-do list with everything I could think of (fig. 25). I tried to go in depth as I could, and will continue to add thigns to this as I think of them. One of my main faults during this project has been not making detailed enough timelines and to do lists - I find it very hard to visualise and remember everything that needs to be done, so when I can't see it like this, I just forget about it.

Updated to-do list (Fig. 25)

Leaf patterns (Fig. 26)

Leaf Minigame

One of the minigames we decided on was a leaf/stick organising game (fig. 27). At first we weren't sure how it would fit in with the story, but Lily made sure the narrative incorporated it, where Alex shows Ernest the cool patterns he has made in the forest and invites Ernest to make some. At first I wasn't sure if I wanted the game to kind of be open, like you could make your own leaf pattern, but since all the games so far have a win condition, I wanted to keep in line with that. Lily created some leaves and sticks, as well as white outlines for each. I arranged these into patterns in unity (fig. 26), and one of the few patterns will be chosen for the player to complete when they play this minigame.

This is a very simple minigame. I was worried that a few of our games would be too simple, but when I tried it in context with the game so far, it works very well. These minigames are not meant to be complicated. They are just meant to give the player some more interaction and freedom, to make them really consider this a game and not a visual novel.

Leaf minigame (Fig. 27)

Spotlight Minigame

Most of our minigames take place in the camp. However, the leaf minigame and this one are both forest minigames. While the player will spend a lot more time in the camp than the forest, we did still want a few minigames for the forest so it is not only dialogue. Our game is more of a cozy game, however this minigame should hopefully bring a little bit of tension to the player. The dialogue before will be Ernest wondering if he heard something in the forest, and then you will have to find Alex in the dark using only a small spotlight.

This again is a very simple game, but I believe it really adds a lot to the game. The player will have to move the spotlight around to reveal the scene and find where Alex is hiding, and click on him to win (fig. 28). Alex will also move around every few seconds to make it harder. We decided to add some other animals to add more life to the scene, so Lily drew a deer, a possum, and a ruru (morepork, native to NZ). These animals will also be moving around the scene, but nothing happens if you click on them.

Spotlight minigame (Fig. 28)

Cooking Minigame - fix

I was still having issues with the cooking minigame. Occasionally, the food items would get stuck on the board and you could not pick them up, and when this happened, you could then place other food items on top of them. I ended up changing how I approached this minigame, and instead of detecting different layers, I gave each of the grid spots a collider and a script that tracks whether it is empty or not (fig. 29). When you try to place food down, it will use each of its raycast to find the grid space underneath and will only be successfully placed if there is a grid spot (it is over the board) or if it is available (not got food already on it). This works a lot better and I find this way much cleaner and easy to understand. This did mean that for each order/level I had to manually make all the colliders around the grid spots, but it was definitely worth it.

‍

As a back-up, I've also added in a button that removes all the food off the board, just in case they do get stuck again. This is something I think I would have added anyway, because if you place down all the food except one and then realise it won't fit, it would be annoying to then have to manually take off all the food. I also added a rotate mechanic, triggered by the space bar when holding the food. This makes the game slightly harder, but also allows for more solutions. (fig. 30)

Grid spots with colliders (Fig. 29)

Cooking minigame (Fig. 30)

Camera

One of the mechanics we wanted to include was taking photos of plants around the camp. This ability will be unlocked during one of the quests/tasks from the teachers. We thought this would be a good way to get the player to explore the map, as well as being a perfect way to incorporate some New Zealand culture with native plants. I drew all of the flower assets in procreate, both the large and small versions (fig. 31). The small versions will be the ones displayed around the camp and in the item slots in the book, and large ones will be what pop up on screen when you take the photo and in the book when you select the item slot. The native plants I chose were:

• Marlborough rock daisy
• Dwarf pohutukawa
• Snowcap
• Wiri Charm
• Forget me not

Since I was changing the inventory system I already made in semester 1 to a camera system instead, there were only a few tweaks I needed to make. I didn't want the quantity to display since you would only be able to get one photo of each. I didn't want the item in the scene to get destroyed since the player isn't taking it. Instead, the prompt to take a photo just gets disabled. And when a photo is taken, a polaroid of the flower and its name pops up on screen for a second.

Native flower assets (Fig. 31)

I also redrew lots of the UI elements as pixel art (fig. 32).

New UI assets (Fig. 32)

Game Flow

Me and Lily created this timeline (fig. 33) for our game. This is something we meant to do a while ago, but we kept being busy with other elements of the game. We decided on a five-day long game, with around 2 minigames per day. I started adding in the dialogue Lily had written. Some of the dialogue was simply triggered by talking to a student who had a yarn interactable script, while others needed to be triggered by certain events. Looking back, I probably should have created some kind of quest system that held all the variables, but instead I used a lots of bools and the day count to trigger certain events. This is definitely not an efficient system for a longer game, but since ours is only 5 days, it should be fine.

For the playtesting next week, I got most of Day One complete. It was still quite rough since I could not figure out how I wanted to structure it and how to carry the data across scenes that didn't have the same active scripts. This took me a lot longer than I thought it would, to get the game flowing. However, I'm hoping I will speed up since while doing day one I am figuring out how to make it work at the same time, and trying different methods.

In-game timeline (Fig. 33)

Solitaire Sprites

I redrew the solitaire sprites to be pixel art (fig. 35). While I loved the cards I had previously designed, there was no way I'd get that much detail on pixel art and still look good. The new ones are simpler and easier to read. I also changed the background since Lily modelled some picnic tables and we decided it would make more sense to have the solitaire at a table.

Old solitaire sprites (Fig. 34)

New solitaire sprites (Fig. 35)

Final Playtesting

For the final playtest, only Day 1 was available and it was not fully finished. Most of the feedback was positive, especially about the art style and dialogue, and the rest was stuff we expected, like the tasks not being crossed out when you have completed it and needing more visual feedback when tasks or minigames have been completed.

‍

A lot of people were struggling with the rhythm minigame. One person suggesting we change the keys from WASD or the arrow keys to DFJK, which seems odd but in practice, it is actually much easier. This change definitely helped with this minigame, so while I didn't get time to adjust the speed of the flow, this did help.

‍

One thing I had been struggling with was data not passing across scenes properly. Only some scripts persist across all the scenes, and this is why the quests weren't being crossed off properly if you play a minigame part way through one. I ended up moving all the main functions to a Game Manager that would persist across every scene. I also created a script to pass variables between the Yarn Spinner scripts and C# scripts whenever a new scene was loaded or variable was changed to keep all the variables in sync.

Updated To Do List

Even though I had only redone my to do list a few weeks ago, it wasn't working for me. I created this one (fig. 36) which is very detailed (it was 2.5 pages...). I separated every minigame and feature and added in everything I could think of that needed to be done. Some were smaller things, like changing a sprite to a new one or adding instruction screens, but others, like all the Days at the top, would take a lot longer. I definitely did speed up while doing the days, I got days 1, 2 and 3 fully finished this week. I also did manage to cross off a lot of the smaller things.

Updated to-do list (Fig. 36)

Setting up interactables

I connected a few of the interactable game objects in the camp scene, like the tent where you go to sleep, to functions like this one (fig. 37) in the Game Manager. The Game Manager keeps track of most of the conditions, so when the player interacts with the tent, it will see if CanSleep is true, else you'll get a dialogue saying it's too early to sleep. The campfire and entrance to the forest have a similar function. So far, I only have day 1 in, but I will add in the rest of the days as I get to them

CanSleep function (Fig. 37)

Instruction/win screens

One of the main feedback we got during playtesting was that we need instruction and win screens for all the minigames (something we were planning to do anyway). I wanted them all to look similar but obviously be catered to each minigame, so I made a template for myself and copied it to each scene and edited it to fit that minigame.

Dialogue fixes

Earlier I made my own custom Line View script for Yarn Spinner to show the character portraits. Ernest's would always be active on the right side, and the left portrait would switch depending on who is talking. However, some dialogue is Ernest thinking to himself, so I wanted the left portrait to be empty. With my original script, even if Ernest was the only one in the dialogue, the previous right portrait would still be there. I created a tag that I could add to the Yarn scripts that sets the right portrait to inactive (fig. 39, 40).

Checking for isSolo tag (Fig. 39)

Setting solo tag (Fig. 40)

Another issue I was having was that the dialogue would flash slightly in between each line. It turns out that even though I had set the fade in and fade out times to 0, the use fade effect bool was still ticked, causing it to flash. Turning this off fixed the flashing, however it presented me with a new issue. The fade must have caused the scripts to wait for a frame before turning interactions back on, beacuse with it off the player would get stuck in a loop with an NPC. Pressing E to continue the dialogue would end the dialogue but immediately restart it in the same frame. To fix this, I added an isInteractable bool to all the interactable objects, which makes all the objects unable to be interacted with during dialogue and only re-enables it one second after dialogue ends. This also helps fix another small bug of the player clicking through the dialogue too fast and accidentally restarting it.

Quests List script

I made a QuestsList script to cross off the quests when they have been completed (fig. 41). Looking back, I should have used something like this as the main thing to keep track of all the quests instead of the Game Manager, but it worked for me for this small game. In Update, I had these for each day, checking if the quests had been completed, and adding new quests when necessary. It would constantly check the yarn variables to see if they had been triggered, and if they had it would cross them out. I had to add bools for adding new quests, because for example when Campfire_Day1 had been crossed off, new quest Sleep_Day1 would be added every single frame. I probably should not have done this checking in the Update function, I should have had it directly attached to the LoadYarnVariables, and it would trigger a new quest being added once it had been changed to true. This is definitely something I will keep in mind for future games.

QuestsList Update function (Fig. 41)

I finished adding in all the quests and triggers to make the game run through all the way to the end at the start of this week. This was my main focus before getting to all the smaller things. I did get a lot faster as I did this.

Quest bug fixing

One thing I had been meaning to add was an indicator for the player to know when they had new quests or when they had completed a quest. We already had a small book icon up in the top left corner of the screen for the quests, but I wanted to add some sort of animation or sound to this. At first I tried a pencil line sound effect, like a strike through, but because of the quests being reloaded when the scenes were changed, the sound would replay when it wasn't neccesary, and sometimes play twice. I decided to scrap this and make the book icon continuously shake when there was something new to be looked at. I added a bool in the StrikeThroughQuest function (fig. 42) that would set newQuestsToSee to true. This bool would then remain true until the player opened the quest list. While the bool is true, a SpriteShaker script would be called to shake the book icon (fig. 43). This worked much better, it was less intrusive but still obvious enough that the player would notice.

StrikeThroughQuest function (Fig. 42)

Shaking book icon (Fig. 43)

Sound effects

All of the sound effects and background music were found on FreeSound.org. I used a basic AudioManager script to hold all the sounds, and just called them when needed.

Map Borders

I had previously added box colliders around the map to ensure the player stays in the correct area. However, sometimes the player can force their way between the colliders, no matter what I tried to change. To combat this, I added a trigger collider under the whole map that teleports the player back to the start position by the campfire if they fall through/off the map. I also added a layer of trigger colliders around the border so if the player gets out, they will be again teleported back in, with some dialogue of Ernest saying he is not allowed out of bounds. I figured this was a good enough work around since the solid colliders were not working effectively. (fig. 44)

Map borders (Fig. 44)

Final Edits

I spent the last couple of days tidying everything up, making sure all the dialogue worked properly, playing throught the whole game multiple times and getting my family to test it. One of the things my family said was that they didn't know the controls. It's very intuitive to me as someone who plays PC games, but they didn't even know to use WASD or E to interact. I added in the controls to the dialogue at the start to feel more part of the game.

Reflection

I'm proud of how our game, Ernest & Alexander, has turned out. I have learnt so much while making this game. So many new coding skills and game theories. When my code didn't work, I would turn to a range of resources, like video tutorials, Unity forums, and my dad who is a programmer (though not for video games). I've developed a much better understanding of how to problem solve within my own code. I also learned the importance of taking breaks when frustrated. Often, stepping away and letting my brain process and rest allowed me to return with a fresh perspective and find solutions quickly. That shift in mindset, from panic to patience, has made me a better and more confident developer.

‍

There are several things I would do differently if I tackled this project again. I would like to research better script management and variable organisation to keep my scripts clean and readable. For this project, I think what I did was fine, but for anything larger, the amount of variables I had across scripts was too disorganised. I'd like to try again with Yarn Spinner, especially the animated test features, or even try a different dialogue system. I think I could have utilised it a lot better if I had more time.

I’m extremely proud of how Ernest & Alexander turned out. Working with Lily was one of the highlights of this project. We worked together with honesty, creativity, and respect, constantly discussing our ideas, brainstorming solutions, and handling conflicting opinions constructively. It was a very healthy and collaborative dynamic, and I’m grateful for it. It has reminded me how valuable clear communication and shared creative vision are in a collaborative design process.