Monday was my birthday. I went to the studio early, feeling quite unhappy, and started making a Unity project for the vertical slice of the wind area’s interaction. This meant spending some time copying over the necessary parts of old scripts, which was pretty tedious. George and Josh also gave me some presents and a card when they came in, which I very much appreciated. After a while, we all spoke as a team, with George saying about our goals to get most of the work for three of the environments out of the way before the Easter break. We discussed our need for more social media presence, setting certain days of the week for us each to be uploading images or videos on (in the order of Ella, Bernie, George and then me). We then spoke about our plans for the coming weeks’ work, and I was told to focus on getting everything sorted for the wind mechanic and implementation over this week, then the basic string mechanic implementation, and then the mechanic and implementation for the brass area.
After the discussion, Bernie sent me a test model to see whether a particular modelling technique (which he called “instancing”) would work for developing buildings. When he saw that I could only manipulate the objects in a certain way, he felt that the technique wouldn’t work. After this, I was feeling very unhappy, and was incapable of getting anything done for a good while. In fact, I broke down and tried to go home, though a couple of friends tried to help. Eventually, I did go home, crushingly depressed, though I won’t go into details. While I did eventually feel a bit better in the evening, I didn’t get any more work done for the rest of the day.
On Tuesday morning, after doing a bit of sketching for a side project, I looked through the various scripts associated with the wind synchronisation mechanic, and thought about which parts of the code I’d need and how I’d sort everything in new scripts. I also spent a while thinking about how to get a perpendicular vector for the “vertical” positions of the waveform, but then decided that this was unnecessary (in hindsight, I’d have to base the perpendicularity on the wave’s relative position to the camera). While looking through the code and making tweaks while considering what would need changing, I started feeling unhappy again. I decided to work through the unhappiness, which was unpleasant, and continued copying and adjusting code. I then considered how I’d structure the three sections of the wave in code, and decided to group the first section with the second until it’s looped once, then have the second section alone while it loops, and then have the second section paired with the third once the looping has finished (which is when the player has successfully synchronised). I drew a quick diagram of this structure on the whiteboard to remind myself, which you can see below. After continuing working on the code and going out to get something to drink, I had another breakdown and went home, feeling cripplingly depressed again, incapable of working. I got no more work done that day, though I did numbly watch an archive of Google’s Stadia talk from GDC before I went to bed, still feeling terrible.
On Wednesday morning, I went to the studio feeling incredibly unhappy and numb. After I’d been distantly sat in my chair for a while, Adam came into the studio and we discussed what we’d been working on, as well as having things in-line for my depression. After this, I spent some time tweaking the main wave drawing script to allow for the planned three-part musical structure during synchronisations, where the main wave is only drawn for the first two parts (with the second part looping until the player has properly synchronised). Once I’d had my lunch, I spoke to Adam about the possibility of working in another room to stop causing problems for the others with my breakdowns, and he suggested some potential options for places to go to. Afterwards, due to an intense unhappiness, I was incapable of working for a while.
When I was able to work again, I made the wave scripts only calculate the offset counter value at any one point of the wave once per frame. After working through rewriting the code for a while, Adam returned and showed me some possible places to work around campus, and when we got back to the studio, he told me that I don’t need to worry about getting a blog post done each week if I can have a day off or get more coding done at the weekend, since I constantly take notes each week on my phone. After Adam showed me what he’d been working on and with in his office, I headed home, still feeling numb, and it wasn’t long before I broke down again. For a long while, I struggled to get anything done, but I did eventually get to working on adapting the wave synchronisation script to allow for the two different forms of synchronisation (the player matching the character and vice versa). Then, before bed, I began working on adapting the waves’ trail drawing script to do the same, while also incorporating parts of the old cursor movement script to avoid segmenting the code too much.
On Thursday morning, I went to the rotunda instead of the studio, so that I’d be causing fewer issues for people. Here, I continued working on adapting the wave trail generation script for it to support the planned three-part synchronisations. With the intention of having the waves placed with global positions and the resulting need to allow for the “horizontal” coordinates of their points to differ on the x and z axes, I felt that it’d be easier to have the trails have defined start points and lengths, as opposed to both start and end points. This would save me having to calculate exact positions based on desired lengths and the vectorial distances between points. I changed the code to allow for this. I then started to adjust the code for visually representing the current synchronisation level to account for the changing length and position of the player’s trail (due to how it overtakes the character’s), such that the two trails would line up properly. I didn’t get to think through the main calculation as much as I’d wanted, however, as I had to go to an appointment with the university’s First Support team.
After going to the appointment and having lunch, I thought a bit more about the aforementioned calculation, and then thought through ways in which to program having the character’s trail move to match the player’s during the final part of the synchronisation. I then adjusted some conditions to allow for setting a Boolean that determines whether the character’s trail should set its positions based on the main character wave or on the player’s trail position. After this, I went to Adam’s office and our team recorded the “podcast” for the game that Adam expected from everyone, though I just sat there awkwardly, unable to say anything (due to my state of mind).
After the “podcast”, Adam suggested that George join me in the rotunda (rather than having me immediately return to the studio), so we did so and showed each other what we’d been working on. George told me about his concern for not being able to see the tower from every area, due to potential obstruction, and I suggested that we could either make the tower very tall or have the isometric camera child itself to the tower and zoom in a bit as it pans upwards, though we agreed that it’d all be a case of trial and error. George also suggested that we could just show piano-related symbols in the sky once the tower’s already been shown, just as a reminder for the goal without needing to repeatedly show the tower itself. George then spoke to me about our plans for the project, saying that we need to make as complete a version of the game as possible as soon as we can, so that we can actually visualise everything and see what we’ll need to add.
After talking, I moved the code for setting the Booleans for the character’s trail behaviour to its own subroutine, moved the setting of the character’s trail’s vertical displacement into its own subroutine, programmed an initial version of the behaviour of the character following the player (lerping towards the player’s displacement value plus a sine wave value of decreasing magnitude, and at an increasing rate, all based on the current synchronisation level), and cleaned up the code for calculating the distance between the two trails. I then started thinking through the implementation of the player’s trail overtaking the character’s, looking to my code for the isometric camera script (and how its values gradually change) to see what I’d need. Adam then joined us in the rotunda and walked us through the process of using GitKraken collaboratively, first testing it with an empty folder as an initial repository, and then having the current Unity project folder (after I’d backed it up) pushed to a new repository. Adam also suggested that I’d be the one to update the master commit, and George could work on his own branch. After this, I headed home.
That evening, I eventually returned to programming the code for the player to take the lead during the wave interaction. Once this was programmed, I changed the code that refers to the length of the player’s trail to factor-in the new offset value for the player taking the lead. I then thought about how changing the length of the player’s trail would affect the key points of its colour gradient, and adjusted the code accordingly. Afterwards, I set the starting values for the trail drawing script and wrote some code in the main wave drawing script to signal when the player has successfully synchronised (during the looping middle section of the interaction). After I pushed the changes to GitKraken, I headed to bed.
I went to the studio on Friday morning and put the Desmos Graphing Calculator to use again, so that I could come up with some placeholder values for the three-part wave. After I put these values into the script for storing them and passing them back to the main wave generation script (and halved the number of times each wave value is calculated each frame), I set the subroutines to be called each frame in the trail script. Adam then showed us all a preview of the new course film, asking for our feedback (I think they did a pretty good job of reflecting the multidisciplinary nature of the course). After this, I programmed the trail code such that the player’s would appear on top of the character’s, by calculating the normal vector to the vectorial distance between each point on the line. Next, I added empty objects with line renderers to the scene (parented by the camera) and gave the renderers an unlit particle material, so that I could see whether the new version of the wave mechanic was working. It was pretty broken, and when looking back through the code, I realised that I wasn’t accounting for the overall wave size modifier for the conditions that separate the wave parts, so I added that to the calculations. At this point, the middle section wasn’t looping, so I looked over the code to make sure the starting point for the section to loop was being set correctly. It took a few attempts to fix this calculation, which I did by adding the length of the intro section (multiplied by the wave size) multiplied by the floored integer of the current wave position divided by the intro and middle lengths (multiplied by the wave size).
Although the main wave generation was now working, the trail script wasn’t. While looking for why this was, I saw in the inspector that the character’s displacement value wasn’t being calculated properly, and when I looked for the cause, I noticed that I wasn’t storing the sine wave values for the leftmost position of the main wave each frame. I looked at how I was setting these values in the mechanical prototype’s scripts, and thus stored them at the end of the subroutine for setting the sine wave values for any point on the wave, which also meant tweaking which variables are passed into the subroutine as parameters. While there were now no more errors, the trails still weren’t being drawn. To get them to actually be drawn, I had to move the setting of some initial values to where the values they relied upon were being set. At this point, Sid showed us the snow particle system he’d been working on, and it looked really nice. Adam then came in and tried to schedule our team’s work for the remainder of the afternoon and evening (also drawing a cute Ewok, called Dave, on the board), but the time requirements he’d given me were pretty optimistic.
The player’s trail had been drawing, but only in an incorrect way, which I fixed by just putting some missing brackets into a line of code. However, it still wasn’t taking the lead when it was meant to, and the character’s trail wasn’t properly following it. I realised in the inspector that the Booleans for determining whether the wave is in range or the roles have been reversed weren’t being properly changed based on on the wave counter value. When looking, I saw that I wasn’t accounting for the wave size modifier in the conditions for their ranges, and while changing this initially broke the wave drawing, correcting the positions of the brackets I’d placed made it work as intended. I then spent a while making a number of tweaks to values and calculations to factor-in the changes I’d made. After this, Adam checked in on our progress, and I told him that I was still working on the first goal, so I still had a fair amount left to do. Then, I headed home, and after dinner, tweaked some more numbers and tried to fix the issue of the player’s trail not disappearing after the interaction’s finished. Looking at the inspector, the array of the player’s vertical displacement values wasn’t shrinking or clearing at all after the interaction had finished, and the wave also seemed to be moving into the distance. I noticed, however, that I was referring to the wrong variable in code, so changing this allowed the array to clear properly. I also stopped the wave from going into the distance by remembering to normalise the sample distance vector that the lead offset value was being multiplied by, and made a number of small changes to make the trails work more consistently when synchronising. I then briefly thought through a possible way of implementing the brass area’s synchronisation mechanic, and sent a video of the three-part wave mechanic working to the team before heading to bed.
When I opened the Unity project on Saturday morning, I looked at the direction/order in which the trails’ vertical displacement values were being set, and realised that I could have the character’s trail target the point nearest to its head on the player’s trail by referencing the point in the player’s displacement array at the index of the difference between the two array lengths. Making this change was transformative to the experience of having the character synchronise with the player. I also noticed that the lerp speed for changing the character’s displacement towards its target value was decreasing from the maximum value instead of increasing towards it, so I amended this calculation. I sent the team some footage of the mechanic working as it was, and pushed the changes I’d made to the GitKraken repository.
After lunch, I imported the environment that George had made and sent me, but the importing didn’t work (as I don’t have support for .max files). Therefore, I imported the original string area white box as a placeholder environment, using the regular version for its rendered meshes and the ramped version for its colliders (as I had done before). I also imported George’s two posed models for Gloria (one with the violin and bow raised, and the other with them lowered), and copied over and attached the coloured, unlit materials I’d created for the movement prototype. I also looked at how I’d set up the objects and components in that prototype, and proceeded to do the same with the current one. Then, in Photoshop, I got the RGB values for Gloria’s violin from Ella’s promotional drawing, so that I could make new unlit materials for the colours in Unity. However, when I set about attaching the material’s I’d made, I saw that I was only able to attach a couple of materials to the models that George had made, as the parts weren’t separated yet.
After this, I saw that the normal vector for making the player’s trail appear in front of the character’s wasn’t being set at all. I looked for why, and saw that it was because it was being calculated based on a variable that wouldn’t be set before the calculation, so I moved where the calculation was happening and fixed the issue. I then made it so that the scripts for drawing the main wave and the trails enable and disable their associated line renderers appropriately, and the trail subroutines only function when a Boolean is true (to avoid unnecessary errors). Next, I added a cuboid as a placeholder for the flautist, and gave it a coloured, unlit material to resemble the main colour of the character’s cloak (as I used Photoshop to get the colour from Ella’s turnaround sheet for the character). I then created a script to manage the player’s status and progress, and made it so that the ability to move relies on a Boolean. Then, I created a script for plucking the violin and cuing interactions, tested that everything was working, and after I amended some conditions for changing necessary Booleans, everything seemed to be cuing properly. I then tweaked some code for setting certain Booleans, and created a script to make Gloria switch between character models based on whether she’s using her violin or not. After this, I recorded and edited a video of the three-part wave mechanic integrated with world traversal, and uploaded this video to Twitter and Instagram. I then set about starting this week’s blog post (so that I could have some time on Sunday to spend with my parents, since they wanted to visit), and started feeling incredibly unhappy, though was able to work on it until I went to bed in the early hours.
This brings me to Sunday, where I worked on the blog post until meeting my parents for lunch (which was nice), and then continued to work on it through the afternoon. I intend on spending a chunk of tomorrow polishing the wind area’s vertical slice in preparation for the afternoon’s testing session, hopefully making the camera work as intended, having the waves’ positions set globally (rather than locally, relative to the camera), and making the characters change their rotations to either face each other or stand at an angle to each other. Also, I’ll hopefully be able to import a functional version of the new environment, and I should change the character’s wave colour and the synchronisation colour to match the main green of the flautist. For the rest of the week, I believe I’m expected to be working on the basic interaction for the wind area (where NPCs will naturally pluck their instruments when Gloria does so around them), and then on the synchronisation mechanic for the brass area, which could potentially take some time (but should at least be very interesting to do). I hope I don’t end up having multiple breakdowns again, but I guess I’ll see. In fact, as usual, I’ll see how everything goes in next week’s post.
Crowence Game Development 