Since the Easter break will be over tomorrow and I’ll be entering the final four weeks of Year 3 before submission (which are probably going to be pretty intense), I’ll be making my last handful of weekly blog posts a bit less wordy. Rather than manually retyping everything I’ve done, this post and those that follow will be direct edits of the notes that I take to inform the posts each week. While this means that I’ll hopefully be able to get through the posts more quickly (and thus have more time to spend on other work), it also means that you can expect the writing to be a bit less Deanish (which is either a good thing or a bad thing, depending on your preferences). So yeah, let the final sprint begin…
Monday
Morning:
- I was feeling quite unhappy when I got up (carried over from the prior evening), so I didn’t get anything done for some time
Afternoon:
- After lunch, I went on a walk, then spent a while doing very little, as I was still feeling unhappy
- I started feeling extremely unhappy, and did nothing for a long time
- Eventually, I started thinking about more details for the implementation of the brass mechanic, and adding variables to the script to manage its values
- I noted down some more specifics as to the implementation of the brass mechanic
Evening:
- After having dinner and washing up, I spent some time doing nothing productive (watching videos and talking to a friend)
- Eventually, I started thinking about and adding variables to the brass mechanic’s values script, but then started feeling very unhappy and was once again incapable of working
- After some time, I headed to bed
Tuesday
Morning:
- I went to the studio in the morning (as the university had reopened after the Easter weekend), but decided that I needed to back my work up, so I didn’t do anything productive for a while
- Once the backup had finished and I returned to coding, I was prompted to install Visual Studio 2019, so I did
- By the time I’d picked up some lunch, the installation had finished, and I uninstalled Visual Studio 2017, but then found that IntelliSense/autocomplete wasn’t working with Visual Studio 2019’s Unity integration, so I downloaded Unity 2019.2.0a11
Afternoon:
- Once I installed the new version of Unity and saw that Visual Studio still wasn’t working properly, I checked Unity’s preferences menu and saw that I could change the preferred code editor, and doing this fixed the issue (having wasted a fair amount of time trying to do so)
- I met with a friend and went on a relatively short walk
- Back at the studio, Adam came and tried-out the piano mechanic, and gave me some feedback:
- Make the Piano Man’s pattern simpler, so that it’s easier to match
- Make the lines closer together, so that they’re both kept in the player’s focal area
- He also found a bug where the player’s and character’s lines were going in different directions around the tower, which I thought could be down to both values having the distance to the end point added individually, so that crossing a threshold meant that they were forced into different directions
- I opened the project file and commented-out the adding of the endpoint distance value to the character’s radial position, as it was lerping towards the player’s position anyway, and that seemed to fix the problem
- I also reduced the number of keys (to make them a bit wider) and decreased the distance between the rings, and Adam said that that made it better
- Adam said that changing the Piano Man’s bouncing pattern could be left for another time, but it would require some tweaking through play-testing, and he left the studio soon after
- Sam Green came into the studio and I helped him out with some programming and Unity implementation for one of his other projects
Evening:
- I was still helping Sam out for a while (since I had to figure out and reverse-engineer the project’s code, the whole process ended up taking a few hours), and eventually headed home
- While helping Sam out, I learnt that you can use coroutines to carry out the core loop of a game instead of calling subroutines in update, and that you can hide public variables in the inspector with a simple bit of code
- After dinner, I struggled to get anything done, as I generally wasn’t in the right mood or frame of mind to be thinking through the brass mechanic
- I eventually headed to bed, having got nothing done
Wednesday
Morning:
- I went to the studio fairly early, but spent a while doing nothing productive (mostly because I wanted to try out Joker, the new playable character in Super Smash Bros. Ultimate)
- I joined Sid and Josh in the computer room, and used Photoshop to create a high-resolution circle sprite for the brass mechanic
Afternoon:
- I added some objects to the brass mechanic prototype’s scene, and added components to the objects accordingly
- We went to town to get lunch
- I spent some time thinking about and coming up with variables for the brass mechanic prototype, and then spent a bit of time helping Sid out with some code
- I copied some old code for taking the stick inputs from the piano mechanic prototype, so that I could use the same system for switching between which analogue stick is used
- I briefly programmed the code for setting the player’s position based on the stick angle, and started programming the code for dropping balls, but couldn’t think straight, generally not being in the right mindset for work
- I played some matches of Super Smash Bros. Ultimate with Sid in the studio, then headed into town and home
Evening:
- After having dinner and washing up, I returned to coding the brass mechanic, thinking through and beginning to program the code for dropping balls
- I spent a pretty considerable amount of time thinking of how to handle programming the character’s movement in the interaction, after having thought of multiple ways to program the character dropping balls (based on whether to make the drop times fully customisable or at a constant rate)
- A big issue was how to handle moving between target positions, due to the desynchronisation between the player dropping balls and the character moving to them, so I decided to make the balls (which would be dropped upon each beat) take two beats to reach the middle (and one to get from the character to the player or vice versa), so that each time the character reached its target position, it’d have a new target position to go to
- I spent some time not doing much, and then headed to bed out of tiredness
Thursday
Morning:
- I thought about how to handle the triangle mechanic while in the shower, particularly how to handle its grid system, programming traversal around it and having a repeatable pattern that doesn’t leave the Triangle Man out of place
- I also thought about having a randomised rate of increasing a value from 0 to 1 for each pinging character, so that they instantiate visual ping effects at random intervals (when their counters reach 1, before being reset to 0)
- When I got to the studio (quite early), I spent some time doing very little and then helped Fred out (over Discord) with some algebra for his camera zoom switching (as I felt that a linear zoom would look too stiff)
- I spent a while working out patterns for the triangle mechanic’s triangle grid, so that I could program a consistent way of traversing it or determining which movements are possible from a particular space, allowing for the size of the grid to be customisable
- Fred came in and I started talking to him about the solution that I suggested to make the camera transition work on a curve instead of linearly, and then spent some time explaining the solution to him so that he could program it
Afternoon:
- I went to my First Support appointment, during which I filled-out some paperwork for signing-up to counselling through the university
- After lunch, I looked at Fred’s code and came up with a different curve for his zoom function, then added that for him
- I helped Sid think through how to program magnetic lightning beams (potentially using something similar to aim assist)
- I spent some time thinking of how to find the sum of all integers up to an integer, and eventually found (and thus remembered) an extremely simple way of calculating it, meaning I could have calculations for the leftmost and rightmost spaces on a row of the triangle grid (knowing the current row)
- I thought through how to calculate the row of a point on the triangle grid using the point’s value, but couldn’t think of a simple way of doing it, and then spent a while doing very little
- We headed home
Evening:
- After having dinner, I programmed the subroutine for setting the character’s position (reusing code from the piano mechanic to determine which way to calculate the distance to the target position), by setting a different target position to move towards upon each beat
- I slightly changed the code I’d already written for dropping balls to have fewer conditions, and thus fewer lines of code
- Looking at code for the piano mechanic, I briefly programmed the increasing and looping of the brass mechanic’s counter value
- Feeling tired, I headed to bed
Friday
Morning:
- I went to the studio early, but spent a fair while doing nothing
- I briefly worked on programming the player’s synchronisation values to change and be constricted (within a range of 0 to 1), and then I spoke to Adam for a while when he came in, had my lunch and briefly spoke to Sid
Afternoon:
- I went to town for a drink and snack, and then replied to an email concerning counselling through the university
- I programmed the subroutine for setting the current state of the brass mechanic based on the current counter value, whether the player has synchronised and whether the reversal has fully happened
- I spoke to Sid for a while, and then headed home
Evening:
- After having dinner and watching a couple of videos, I briefly adjusted the code for making the character match the player’s position to make sure the matching value doesn’t exceed 1
- After drying-up, I programmed a subroutine in the ball’s script to set the values associated with the ball dropping
- I added a couple of lines to the code for dropping balls, so that it properly sets the radial position and nature of the ball based on which character dropped it
- I briefly changed the conditions for adding to the target synchronisation values when the ball reaches the centre, such that it can’t happen when the respective synchronisation value has reached 1
- I pulled the three initial colours I’d need (being that of the player, that of the character and the midpoint between them) from the old version of the wave mechanic (when I was working on it for the brass town)
- I programmed a subroutine to draw the ball as a single point on a line renderer, setting its position based on the radial position from which it was dropped, the total radius and the current value that represents its drop distance (which is itself a transformation of a linearly increasing value from 0 to 1)
- I made a prefab for balls to be dropped, which also meant creating a new material for it and the other line renderers to use
- I programmed the subroutine for setting the sizes and colours of the two circles in the background of the brass mechanic, based on their respective synchronisation values (and whether the interaction is playing)
- Looking at the script for drawing the lines in the piano mechanic as a reference, I came up with the necessary variables for the brass mechanic’s lines
- I was feeling incredibly tired, so I headed to bed, hoping to finish the work the next day
Saturday
Morning:
- I programmed subroutines to set the synchronising, blending colours and gradients of the lines, and to set whether the lines should be drawn
- After spending a while coming up with a consistent formula to calculate the positions of every point on each line, I coded the subroutine for drawing the lines
- I went to Tesco for my weekly shopping
Afternoon:
- After having lunch, I changed the conditions for drawing the lines, such that the counter value has to have exceeded the offset value, and added a few test values to the line drawing script
- I put some test values in, added the analogue stick inputs to the project’s input settings and tested the game
- The balls weren’t detecting whether they should be bouncing properly, the angle of the player’s line wasn’t properly synchronised with the analogue stick and the character was targeting angles that seemed completely unrelated to the player’s
- I was suddenly feeling very tired, so I sat back in my chair for a while and rested
- I spent a while looking through the code to see why things weren’t working properly
- I saw that the balls were adding to the synchronisation values whether they bounced or not, so I made it so that they’d only do so had they not bounced (meaning they’d passed through into the centre)
- In order to make the lines turn the right way, I removed the minus at the beginning of the y position calculation, realising that it was there because the code that I was referencing had it to accommodate for drawing on the z axis
- I made the balls spawn with their line renderers set to have no points, so that there wouldn’t be a flicker of a blank line renderer on each ball’s first frame, then I did the same for the player’s and character’s lines
- I changed the code for setting the reversal value to make it less of a sharp change in the middle, relying on an offset cosine curve instead of two joined circle arcs
- I switched the ball prefab to use a sprite renderer instead of a line renderer, removed the subroutine for drawing the line and replaced it with a subroutine for moving, colouring and scaling a sprite
Evening:
- After having dinner, I was making a number of small tweaks to the code, trying to find out why the balls were sometimes working and other times always bouncing, and I noticed that doing circular motions with the analogue stick was causing the player’s position to exceed the range of 0 to 2π
- I restricted the player’s and character’s position values to the desired range, which somewhat helped, but there did still seem to be errors with balls bouncing back when they should have been passing through
- I didn’t like the linear nature of the circles shrinking at the end, or how the player’s green circle remained on-screen after the reversal, so I reprogrammed the circle subroutine to factor the reversal value into the sizes of the circle, and reduce that value once the interaction is over
- I noticed that the radial position that the balls were storing was sometimes negative, so I changed the code that finds the remainder of the positions when divided by 2π (or 360°) to add their respective limits first, which seemed to fix the issue
- I also removed the remainder calculations that I’d added to the ball’s distance calculation code to save on performance, as none of the associated values should exceed the desired range anymore
- After watching a couple of videos, I made it so that the player can only move their line if the counter has exceeded the initial offset
- I then came up with test values for the character’s target positions, and upon testing, it seemed to be working fine
- I also made it so that the character’s synchronisation value doesn’t degrade once it’s reached 1, by amending the conditions for it decreasing, and tweaked various values as I saw fit
- I made it so that the widths of the ends of the lines are dependent on the reversal value, the respective start widths and the number of points as a fraction of the maximum, so that I could give the whole circle some thickness when trying to catch balls, but have the line thinning to nothing when dropping balls
- I made a build of the game, recorded footage of it and sent the footage to the team
- I was feeling tired, so I headed to bed
Sunday
Morning:
- I uploaded the video from the prior evening to social media, and then started working on the week’s blog post
Afternoon:
- I met up with my parents and went out for lunch with them, which was a nice way to spend my last day of the Easter break
- I finished off this blog post, which brings me to this moment in time
This coming week will be the first week back after the Easter break, during which I haven’t got as much done as I’d wanted to. I was hoping that I’d have also finished the triangle mechanic by this point, and while I do have ideas for how to handle what could be the most difficult part of its code, I’m still behind. So, my plan for this evening is to get started with programming the triangle mechanic, which will first mean coming up with a consistent way to calculate the positions of each point on the triangle grid (so that I can set the positions of the player’s and character’s lines). Over the week, I hope to finish programming that and to incorporate all of the mechanics into one project, but I’ll see what I’m asked to work on. Also, on Wednesday, I’ll be visiting the studio at Moving Brands, which should be cool and interesting (though I’ll assuredly be quite nervous). Anyway, I’ll see how everything goes and let you know in next week’s post (which will begin with this evening, since this is where I’m cutting-off this post).
Crowence Game Development 