When I went to the studio on Monday, I was feeling quite numb, tired and unhappy, and thus didn’t get anything done for a while. Speaking to Ella when she came in helped me to feel a fair bit better, but after lunch, I started feeling so unhappy that I headed home. Things were pretty rough, and although I won’t go into details, I will say that I was incapable of thinking straight or getting anything done for the rest of the day, and I ended up going to bed relatively early. In hindsight, this thankfully wasn’t indicative of how the entire remainder of the week would be.
On Tuesday, I went to the studio in the morning, but I was still feeling quite unhappy and didn’t do anything for a while. Eventually, I did some research to recap myself in preparation for a discussion with Moving Brands that had been scheduled for the afternoon, looking into details surrounding some of their projects (as I’d done months prior). They’ve certainly had some cool projects, so it was interesting to look into them and see the outcomes. After lunch, I started thinking about how to go about drawing the bouncing lines for the piano mechanic, looking at old code (for the wind mechanic) as a reference point. However, the unhappiness meant that I couldn’t really think straight, so I didn’t make much progress. After a fair amount of time spent feeling distant and numb, I joined Adam in his office for the video call with Toby and Maddie from Moving Brands. While I’d expected a more casual talk from what Adam had told me about it, it was a lot more interview-like than I’d anticipated, and I was pretty nervous. It was nice to talk to them, though (barring the technical issues), and my nerves gradually eased throughout the conversation. I should be visiting their studio fairly soon, and I’m looking forward to doing that, though it’ll be my first time of having to be an actual adult and get around London alone. After the video call, I spoke to Adam for a short while, and then headed home. Although the talk with Toby and Maddie was a cool experience, I ended up feeling unhappy and numb at home, and the feeling expanded into some pretty intense depression by the time I went to bed. For this reason, I didn’t get any more work done that day.
Due to the university closing for Easter until the following Tuesday, I didn’t go to the studio on Wednesday morning. Although I was feeling fairly unhappy, not really in the mood for anything, I continued to add necessary variables to the script for drawing the piano mechanic’s bouncing lines, still using the old code as a reference. I also pulled the RGB values for the Piano Man’s purple from Ella’s key art rainbow in Photoshop, and put that colour, Gloria’s colour (from old line drawing code) and the midpoint between the two in the line drawing script. A while after that, I wrote a subroutine to calculate the colours and gradients of the player’s and Piano Man’s lines at any one time during the interaction, depending on whether the interaction has reversed and the current appropriate synchronisation value. Afterwards, I went on a walk and ordered my graduation clothes, which also meant carrying out some measurements.
After I had dinner, I programmed the logic to determine whether the lines should be drawn, and using the wind mechanic’s code as a guide, I programmed the lines to actually be drawn by the line renderers (which took a while). I then attached the script to the scene’s manager object, came up with a set of test values and tested that the code was functional. At first, the lines were only having their first points drawn, so I went back to the code and remembered to set the currently stored vectors (to be set as the line points’ positions) as values taken from the the position arrays. Changing this made the trails be drawn properly, but the lines were moving inside the cylinder rather than around its circumference. I made a number of calculation tweaks, but eventually realised that I was setting the x positions of the lines’ points twice (as opposed to setting the x and z values of each, as intended). Fixing this made the lines properly move around the cylinder, which was a relief. Once that was sorted, I changed the test values to make the test feel more accurate to the intention, but the Piano Man’s line was jumping across an inconsistent number of keys (instead of consistently moving one key across with each bounce). This meant that there was a fault with either the code that was dedicated to finding the distance between where the line lands and the nearest middle of a key, or the code for applying this distance to the actual movement. Also, the player’s synchronisation value was taking too long to lerp towards its target, which meant that it wasn’t cuing to degrade (as it only degrades once it’s reached its target value), so I’d need to set it to the target value if it reaches within a certain range. However, I was feeling tired at the time, so I headed to bed and decided to continue in the morning.
On Thursday morning, after spending a while doing basically nothing, I added a placeholder version of the subroutine for setting the current number of keys the Piano Man’s line is covering based on the counter value. As a placeholder, I made it so that the line moves one key per bounce, but starts off not moving at all until the first bounce. I was trying to figure out what was making the Piano Man’s line vastly change its radial speed, looking at the calculation for finding the distance to the nearest middle of a key and the utilisation of that value, but everything seemed theoretically fine to me. While removing the calculation made the movement even (the Piano Man’s line seemed to be bouncing on the midpoints of keys), I didn’t want to risk it desynchronising when changing directions or speeds, or if there are performance issues.
After having lunch and spending some time feeling generally numb and unhappy, I moved where the midpoint distance was in the calculation for the Piano Man’s movement speed, and that seemed to fix the midpoint targeting (though it didn’t make a lot of sense to me at the time), such that the Piano Man’s line was no longer wildly changing its speed and direction. Once that was sorted, I programmed a small script to have the camera follow the radial position of the player’s line around the tower/cylinder. I attached this script to a new, empty game object, and set the camera as a child of this object (as that’s how I’d handle switching between camera modes in the full game). When I realised that the camera was turning the wrong way while testing, I subtracted the rotation angle from 360° and that fixed it. I then realised that I had to change the point along each line that the colour merger would start, so that it’d be more obvious, so I spent a bit of time thinking about how I’d do this. However, while I was washing up, I grew increasingly unhappy, and after dinner that unhappiness became quite unbearable, though I won’t go into details. It’s safe to say, however, that I got no more work done that evening.
I was feeling numb and unhappy on Friday morning, so I spent some time trying to retain some semblance of sanity. After that, I briefly changed the code for generating the lines’ colour gradients so that the colour merger would be more clear (with the fade to the midpoint colour starting closer to the head of each line). I noticed that the lines were still being drawn when the interaction was over (with two circles being left beside each other), so I looked at the Booleans that determine whether they’re drawn and saw that the Boolean that shows whether the the interaction is currently in the reversed state was being reset to true after it was set to false at the end of the interaction. To fix this, I made it so that the interaction has to be set to be playing in order for the reversed Boolean to be set to true, which made it so that the lines were being properly erased and disabled once the interaction had finished. After lunch, I used Desmos Graphing Calculator to figure out a good curve for gradually changing the rotations of the lines as they begin to ascend the tower, and generally thought about the intricacies for how I’d program the shift in rotation and movement direction. Using the ideas I’d come up with, I then programmed a subroutine to set the values that the ascension and rotation would rely upon (with the final climbing modifier value being a transformation of a linearly increasing root value between 0 and 1, and the rotation value being a transformation of a determined portion of that root value). Then, I set the line positions to rely on both their respective radial positions and that of the desired ending position for the two lines (so that they can converge on a point that allows for a good ending shot of all of the characters), using the final climb value as a modifier to determine how much of each radial position to take. I also made the camera follow the same logic to set its position, and made it have its own lerped climb value to make it move upwards smoothly, as well as a vertical offset and pitch angle to gradually shift towards as it climbs (so that it’ll be in a good position for the game’s final shot).
At this point, I started to feel quite overwhelmed by unhappiness, and thus couldn’t do anything for a while. After some time, I returned to my code to see what was causing the root value for climbing to exceed 1 (reaching 1.75) and make the lines reach the top of the tower far too soon. I noticed that I hadn’t included the duration of the interaction’s looping section in the calculation, and adding it in fixed the problem. However, the lines were still freaking-out during and after their rotation, assumedly because the rotation value was somehow reaching infinity, so I looked through the code to figure out why this was happening. After some looking and thinking, I realised that I was meant to be dividing by a particular value instead of multiplying by it (as the result was otherwise too low, meaning that the value being square-rooted was negative, resulting not in infinity, but in an imaginary number), and changing this fixed the problem. This was when I noticed that the while the climbing seemed to be working as intended on one side of the tower, on the other side, the two lines would diverge greatly until rejoining at the end.
After going on a walk to catch the sunset and doing very little for a while, I determined that the issue was that adding the radial positions of the player/Piano Man to that of the endpoint with both modified by the climb value was playing havoc with the trigonometric calculations that determined the world-space positions. I came up with a way to make the lines’ radial positions gradually move towards that of the desired endpoint, by adding the difference between the current radial position and the endpoint multiplied by the climb value (so that it’d be adding the full difference by the time the lines reach the top) right after the radial positions have been otherwise set. To account for the threshold between 0 and 2π that may have to be traversed (depending on whether it’s quicker to cross that threshold or increase/decrease normally between those two values), I referred to the code I wrote for gradually changing the isometric camera’s horizontal angle to make sure I was calculating the differences in radial positions properly. After I wrote the solution for the player’s radial position calculation and copied it to the character’s, I reverted the changes I’d made to the line drawing and camera calculations to rely, once again, on just their respective radial position values (without accounting for that of the endpoint). When I tested the solution, I felt that the lines were being locked too quickly in the radial position of the endpoint, so I slowed-down the locking by factoring-in delta time, and after a couple of tweaks, it was far better.
With everything seemingly working, I put in some test values for the Piano Man to change the number of keys he’s covering and his direction with each bounce. When testing these values, the system was working as intended, but the bouncing was far too erratic to follow and I determined that covering three keys at once was too much to keep up with. Accordingly, I changed the test values to be more reasonable, and also tweaked the player’s maximum speed and acceleration. Furthermore, I set the player’s line to be drawn above Piano Man’s (by drawing it at a slightly wider radius), and set his to be drawn above the piano keys, just to avoid visual regularities. I then briefly made it so that the distance to the nearest key midpoint is divided by the width of a key when it’s added to the number of keys covered to determine the Piano Man’s movement speed, as it didn’t make sense to me for this not to be factored into the calculation. I then made a build of the game, recorded myself playing it, uploaded the clip to YouTube and sent it to the team. After this, I met-up with a friend for a while, and went to bed when I got home.
On Saturday, I created a new Unity project for the brass mechanic prototype (which would be the next I’d tackle), and spent a fair amount of time coming up with and noting down ideas for how to handle the mechanic’s lines and balls. As long as my ideas work, these notes will be extremely useful when I get around to writing the code for the mechanic. After coming up with the notes, I edited my prototype footage from the prior night and uploaded it to social media, as you can see below. The remainder of my day was then spent relaxing, starting to play Devil May Cry 2 (that game has some big problems) and going over to a friend’s to play Super Smash Bros. Ultimate.
This brings me to Sunday, which I’ve mostly spent working on this blog post. Over the coming week, I intend on (hopefully) fully programming the brass mechanic and at least starting the triangle mechanic (which might take some thinking). The studio will also reopen on Tuesday, and on that day, I may also be meeting Sam Green to help him with some programming and version control setup. I hope that I don’t reach such intense lows, mood-wise, this week, and that I’m able to maintain a decent level of productivity. I’ll let you know how everything goes in next week’s post.
Crowence Game Development 