After feeling incredibly depressed on Sunday night, I stayed up all night to work on my Reflective Journal submission. When I went to the studio early (as usual) on Monday morning, I simply continued with Reflective Journal until I handed it in fairly late in the afternoon (soon before the deadline). Exhausted, I headed home, and after drifting off multiple times in my chair before and after dinner (and getting a headache), I decided it’d be best to get to bed very early. This meant that I got no more work done that day.
When I went to the computer room on Tuesday morning, I spent a bit of time getting Unity updated to the latest pre-release version (since I was mildly irritated by the update notification that kept appearing). When the scheduled session started, we spoke to James as a team, which we hadn’t done in a while. After we explained our progress and the extra mechanics that we’d come up with, James gave us some feedback on our ideas. Since we hadn’t come up with a separate mechanic for the ‘Piano Man’, he suggested that we could have two of the prior mechanics simultaneously (assumedly because the piano is an instrument that involves both hands independently doing different roles for the same job). When we described how the player would first synchronise with a character and then vice versa, James said that it’d make more sense for the two to be in unison than for the interactions to be purely dictatorial. He also said that, while it’s nice that we have different mechanics for different characters, we should consider the overall pacing of the game, thinking about how long players might take to explore environments between synchronisation interactions. Furthermore, he said that we might be aiming too high with the number of environments we want to create, and suggested that we put multiple characters into the same area. Then, James said about how he didn’t know whether we’d be more overt with UI and text for a younger audience, though we’re still aiming for a minimalist presentation. Finally, the idea came up of having the tower itself fill the role of the ‘Piano Man’ to cut down on modelling and animation work, but I’m sure that’d hurt the game’s consistency and narrative weight.
After the discussion, Bernie said to me about an idea he’d had for the brass synchronisation mechanic. He said that instead of having the player need to rebound balls back from a platform they rotate, we could have the player let balls in through an opening in a circular perimeter they rotate, in order to represent the player letting in or accepting the character’s ideas (and then vice versa). From here, I suggested that we could have the circle’s area gradually fill as balls fall in to reflect the level of synchronisation, as Bernie was unsure about the illumination of the balls as they come in being an adequate form of visual feedback. After I spoke to Bernie, we headed to the studio and I started programming the skating-like gliding movement system. I started by copying useful sections of code from old scripts, making adjustments where necessary. This included the analogue stick input code (with functionality for switching between sticks) from the wave mechanic’s cursor movement script and the rotation of the direction target objects from the old movement script. Then, after spending a good while looking back at old movement code and thinking about how to tackle the gliding movement and accounting for inclines, I continued copying old, useful code over. I also added the player character to a new layer, so that I could ignore them when casting the incline detection ray. I didn’t get as much done at the studio as I probably should have, and after I headed home, I wasn’t in the frame of mind to get any more work done before heading to bed.
On Wednesday morning, I went to the studio and eventually continued to work on the gliding movement, putting a lot of thought into the particularities of handling it, thinking about how I’d need acceleration-based movement to allow for skidding when turning. Adam came into the studio, and after we spoke about what we’d been working on, I offered to check text consistency for the winchester.games website’s game pages (editing things, if necessary). I also offered to edit his intro for the publication, and he told me that he could probably use more proofreaders for the publication in general, showing me a mistake from one of the game descriptions from a couple of years ago. After Adam left the room, I spent a while longer thinking about how to handle the movement code. This was until I remembered that I was meant to be going to an appointment for a mental health assessment, at which point I hurriedly packed-up and headed to it. After the appointment, I had some lunch and thought through various aspects of the movement system on the studio’s whiteboard, coming up with possible solutions to certain aspects.
Using what I’d come up with on the board, I continued programming the movement script. I also briefly checked the winchester.games site for dead links, and let Adam know what I found. Then, after spending a bit of time thinking about which variables I’d need for the movement, I updated Sam Green over Discord about the musical structure for each synchronisation interaction that George and I had determined when coming up with mechanics. When I decided that the emptiness of the studio was getting to me, I headed home and responded to Sam’s response. Eventually, I made the code for storing the analogue stick’s angle account for both sticks. I then added some code to set whether the player should be braking or turning, and in which direction they should be braking, based on the angle between the direction of the analogue stick and their current velocity (as well as the normal of the velocity vector).
After dinner, I put a lot more thought into the movement system, and decided to make both turn speed and acceleration rate dependent on the magnitude of the analogue stick. While thinking about how to handle the rotation of the player character’s model (which vectors to base it on), I called all of the subroutines each frame and set some variable values based on values from old scripts. I then made the player’s turning speed inversely proportional to their velocity, and when I noticed that movement was slow and not being changed by the max speed variable, I looked over the code and realised that it wasn’t actually factored into the calculation, so I fixed that. Since the player was quickly accelerating forwards to turn after braking, I tried making the turn speed dependent on the angle between the directions of the gliding movement and standard movement target objects, but this didn’t solve the issue. At this point, I started feeling incredibly unhappy (having felt fairly unhappy throughout the afternoon and evening, and then been triggered by hearing a particular song) and couldn’t work through the thoughts. I therefore gave up and got ready for bed.
While in the shower on Thursday morning, I thought through some potential coding solutions for the movement system. When I went to the studio, I added some code to make the glide direction target object set its rotation while braking based on the velocity direction and the current brake window (which alters its size based on velocity), in an attempt to stop the player character from accelerating forwards each time they turn from braking. I also moved where this subroutine was being called, so that it would be called both when the player is turning and when they’re braking. After testing it, I switched it to setting both the temp direction and the target direction (rather than only the temp direction directly), so that it wouldn’t reset as soon as the player stops braking. After this, I made it so that rather than attempting to map the stick axes as circles instead of squares (and ending up with the diagonal directions capping out at lower values than the cardinal directions), the adapted axes vectors would simply cap the axes vectors’ magnitudes to 1. For a while, I kept testing the movement and making small tweaks to the code, but it just felt really bad to play, and I thought that it might not be worth the time investment of fixing it (not yet, at least). At this point, Adam came in and tried out the movement, agreeing that it would probably be best to just rewrite it entirely at some point. After this, I packed away and headed to the lecture theatre.
At around midday, we attended a talk from Matteo Menapace, the V&A’s video game designer in residence. Using anecdotal examples. Matteo spoke to us about coming up with ideas for games and ‘hacking’ existing games to make new ones (changing aspects, whether aesthetic or fundamental). He also described the usefulness of ignoring the critical parts of our minds to tap into the creative parts, so that ideas can flow freely, and those that may seem silly at one time can be combined with others to create something interesting. I won’t describe the entire talk, but you can find my notes below. After returning to the studio, I spoke to George about what to do with the movement system, laying out some options for him, and he said to make a rudimentary movement system and add to it later if necessary (and if we have the time). I then spent a while programming the foundations of a boring movement system, suing old code as a reference for most of it, though I had to make some changes due to using a Character Controller instead of a Rigidbody (such as having to manually program gravity, and thus only have standard acceleration on the x and z axes). After seeing that the movement was no longer working, I realised that I was storing the Character Controller for use in a subroutine that wasn’t being called, so I moved that.
After some more tweaks to the movement system, George and I spoke to Matteo about the project (with Ella and Bernie working on their Reflective Journal submissions). He said that he liked the idea of the wave riding mechanic, but said that it’d be cool if you could control it with the pitch of your voice, and I promptly explained that that sort of feature was out of our scope (since I’d have to figure out how to take its input and program around it). It also wouldn’t necessarily fit with our game’s design (considering that you play as a violinist), and could be a bit gimmicky. Matteo said that he liked the idea of representing different forms of loneliness, and suggested that we could express characters’ personalities and stories through the ways in which they play their instruments (such as the timid flautist stopping playing initially when the player joins in). He finished the discussion by telling us that the essence of the game is interacting via non-verbal communication, and that we should prioritise bringing-out that essence, with all of the extra details being secondary. You can find my notes from the discussion below. After we’d spoke to Matteo, George told me that once the rudimentary movement is finished, I should focus on finishing everything surrounding the wind/wave mechanic before moving onto anything else. He then outlined his plans for what we should be covering and by when, suggesting that we should have the string, wind and brass areas mostly finished by the end of Easter, with the vertical slice for the wind area being the goal for the coming week. After this, I headed home, and I spent a chunk of the evening testing and attempting to fix the cassette player I’d ordered (which had arrived while I was at the studio). This meant that I got no more work done that evening before heading to bed.
When I got to the studio on Friday morning, I programmed a subroutine for the player model to rotate in response to the direction of the player character’s velocity, using old code as a reference point. I then tweaked this code to factor-in delta time for lerping towards the target rotation, and to account for the squaring of the analogue sticks’ input axes for the deadzone for setting the rotation. After this, I started feeling very unhappy, and left the studio first to think through things, and then again for the toilet. When I came back, Adam was explaining to everyone what would be needed to be submitted soon for the publication (including descriptions of ourselves and our games). After lunch, I jumped in on the conversation that George and Ella were having about which lighting model we should go with for the game. I said that unlit shaders can only properly be judged when everything’s unlit and properly coloured, and when George said that unlit shaders meant too much of a loss in detail, I explained how the loss of three-dimensional detail when looking at a static image without shading is potentially made up for in motion, when shifting outlines allow us to make sense of objects’ shapes without the need for shading. Ella and George agreed that unlit shading is generally a decent middle ground, and Ella specifically noted how having an unlit shader on the character when there are shadows on the ground (which isn’t affecting the character) is a bit jarring.
For a while, I looked back over my code for incline compensation, comparing it with my solution for Bugs Ahoy! last year, and realised that there was an issue with my calculation for the incline height. I was taking an absolute distance value rather than a vectorial difference, so I changed this. I also noticed that I wasn’t taking the absolute value of the vertical velocity ratio when factoring-in inclines for movement on the x and z axes, which meant that inclines weren’t affecting velocity properly. When I changed this, the incline compensation seemed to be working mostly as intended. I also decided to use the sloped variant of the test area for colliders instead of the version with proper stairs, so . I then spent some time speaking to the visiting external examiner, Justin (from Brunel University), about the course. Once George had sent over a model of Gloria, I imported it into the movement test Unity project and replaced it for the placeholder cuboid. With George’s and Richard’s feedback, I resized Gloria’s model (based on the height of a doorway and seeing Richard and Venny standing in the studio’s doorway) and changed the camera’s orbit radius, vertical angle and field of view. At this point, I started feeling very unhappy again, and was incapable of working for a good while. Adam briefly tried-out the movement system, and acknowledged that it gets the job done, as well as being pleased that George’s model of Gloria was in the prototype. After I headed home, I proceeded to feel far worse, spending much of the evening incapable of doing anything, cripplingly depressed.
Eventually, I got back to working on the project, working through the unhappiness. Since the right stick wasn’t working properly for the movement, I looked over the movement code and realised that the angle of the direction target object was only being changed if the left stick’s magnitude exceeded a deadzone. I fixed this by making the code have two separate deadzone requirements, depending on the currently used stick. I then imported the test walk cycle that George had sent me earlier that day, and separated the animation element from the FBX file it was attached to (so that I could attach it to the model that was already in the scene). I created the Animation Controller for Gloria, but when I created a new behaviour for it, I was immediately intimidated by the script that it brought up, as I really wasn’t in the right frame of mind to be getting through it. Therefore, I instead opted to open some of Ella’s concept art for Gloria and get the RGB values of her original colours (as it looked like George had been using approximations for his materials). Using these RGB values, I made new unlit materials and attached them to George’s model of Gloria, also realising that there was some hidden geometry inside the model that was casting a shadow (so I disabled its mesh renderer). Once I’d done this and put the values on the group’s Discord server, I headed to bed.
I spent most of Saturday feeling very unhappy, incapable of getting any work done. In the afternoon, however, I started working on this blog post, as I wanted to be able to put some time aside to see my parents the following day. I continued to work on this post until I went to bed. On Sunday, I saw my parents and my sister for an early birthday celebration (since I’d be busy working on my actual birthday), which was nice. I really appreciated them coming over, and it was cool to see them (and go out for lunch). After that, I continued working on this blog post, which brings me to this point in time. For the week ahead, the plan is to work on finalising some aspects of the wind mechanic, so that we can have a vertical slice of the wind area ready to be made. This will mean making it support proper three-dimensional placement, accounting for all three axes instead of having the z axis be useless, so that it can be properly placed in world space. It’ll also mean making the mechanic support all phases of the overall synchronisation interaction, with the initial stage, a looping middle section (until synchronised) and a final section in which the character matches the movements of the player. Also, if George wants it sorted sooner rather than later, I’ll see about getting Gloria’s walk cycle implemented. I’ll see how all of that goes, of course, in next week’s post. Here’s hoping there aren’t so many instances of intense unhappiness this week…
Crowence Game Development 