This week wasn’t exactly an exciting one, so please don’t get your hopes up too much. Most of the work I did was putting things together, implementing assets and tweaking values for mechanics to work properly. However, it’s now quite visually evident that the project is coming together, and while there’s still a lot more work to be done, the deadline is very much drawing near… Anyway, I hope you like bullet points.
Monday
Morning:
- A while after getting to the studio, I wrote my portion if the week’s team blog post
- When Ella came in, I had her try the triangle mechanic, and she said that it’s more intuitive now
- Bernie tried the triangle mechanic, and gave me some feedback:
- He said that no previous mechanic has needed you to remember things, so the triangle mechanic is confusing at first
- To prepare the player for that, he said that I could make it so that the Triangle Man starts by doing his shape, and only after the shape has been drawn can the player move and is the triangle grid drawn
- He said that because it’s not a continuous motion anymore, it doesn’t feel so intuitive to queue motions before getting to the junctions
- Both he and Ella said that the interaction feels slower with the new motion method (even though it’s the same speed)
Afternoon:
- After having lunch, I used Ella’s scale indicator for the characters to resize their colliders and placeholder capsule objects
- Ella sketched out an idea for handling the string villagers, faking them being taller by elongating their dresses to below their actual feet
- I spent a while placing the characters’ capsule placeholders around the environment
- I spoke to Ella for a bit about the publication, and we looked at potential paper sizes, semi-settling on B5
- I spent a while placing the objects for the camera targets looking at the tower
- Adam tried out the new version of the triangle mechanic, saying that it’s better now because it’s easier and makes you feel like you’re working together, and that after the role reversal, you now feel more inclined to experiment
- He said that the pattern’s too simple at the moment, so I should make a bigger, more complex pattern and see how complex it needs to be in order to be fun
- When I told him about the issues I’d had with opening the project, he said to run a disk checker on the HDD to make sure it’s not corrupt or failing
- I headed home, and was feeling quite unhappy
Evening:
- After having dinner, I replied to Tim’s questions on Discord, letting him know about my understanding of the intentions of the Piano Man’s theme
- I continued to place the characters and the camera targets around the environment
- After faffing around and trying to fix dpi issues with my essay’s images for the publication, I continued placing those objects, and began placing the origin and camera for the wind mechanic
- I spoke to Emma, my housemate, about printing in preparation for making our art book
- I placed the wind interaction’s origin and camera, and then did the same for the brass mechanic, though I noticed that I’d have to modify some size-related values to get them looking as intended
- After pushing the changes to GitKraken, I headed to bed
Tuesday
Morning:
- A while after getting to the computer room, I spent some time placing the triangle mechanic in the environment, attaching it to the Triangle Man
- Fred and I play-tested Enchanted Kin for Sarah and Rubi, pretending to be kids (for maximum authenticity)
- After moving to the studio, I placed the piano mechanic at the base of the tower, setting it as a child of the tower to centre it properly
- I spent a while programming the switching of the current camera target
- I tested that the camera switching was working, and it wasn’t cuing properly at first, so I fixed the condition for checking that the violinist is in range and then changed the order in which the initial position and rotation offsets for the camera transitions are set
- It still looked like the transition was being cued multiple times in a row, even if the variables indicated that it wasn’t, and the big problem was that it didn’t seem to be moving back to the isometric camera after looking at the tower from the violinist
Afternoon:
- For a fair while, I looked through the camera transition code and was stumped as to why it wasn’t working properly
- When she came in, I told Ella the info about printing that Emma had given me the evening before
- I started feeling unhappy, and was incapable of working for a long while
- Still feeling unhappy, I headed home
Evening:
- My unhappiness greatly escalated, and the start to my evening was very difficult (and unproductive)
- Eventually, I returned to trying to fix the bug that affected the camera switching, and after looking through my code, I realised that I hadn’t increased the maximum value for the camera target index from 0 to 11 (meaning that the current camera was being constantly switched between its intended value of 1 and 0)
- Switching the max value to 11 fixed the transition problem
- I tested the interaction cuing, and everything seemed to be being cued properly (though I couldn’t get past the brass interaction due to its size exceeding the screen area)
- I imported George’s models for the environment areas (minus the triangle area, as Bernie was set to be handling that)
- I placed and resized the string area, and spent some time disabling the mesh renderers and adding mesh colliders to George’s designated collider objects
- I then did the same for the wind area, which lined-up more closely than the string area (as the area wasn’t completely remade)
- I did the same for the brass area, which took a fair amount of time due to how its size in the initial white box wasn’t really to scale
- After pushing the changes to GitKraken (which took longer than before, due to the environment assets), I went to bed
Wednesday
Morning:
- Some time after getting to the studio, I placed the flautist and wind interaction in the new version of the environment, and thought about how I could write the code for making the wind villagers hide or show in the same script as the ping system behaviour for NPCs
- George sent me Bernie’s white box for the triangle environment, so I imported that and then added it to the scene
- I scaled the environment by trying to line the scale of Bernie’s houses up with George’s from the wind environment, and after positioning the area properly, I moved, rotated and shrunk a section of cliffs to serve as a proper boundary for the area and avoid detracting from the view of the tower
Afternoon:
- After lunch, I spoke to Ella about what’s left to do for the project in the lead-up to the deadline
- I added the tower to the scene, scaled, positioned and rotated it and placed the Piano Man’s placeholder at the top
- I spoke to Ella about what we’d need for the art book, and potential ways in which to handle its layout
- I went with Ella to Sarsen Press, so that we could ask about printing specifications for the art book
- I headed home (and it was pretty hot…)
- After a while, I tweaked the size values of the triangle mechanic to make it fit on the screen when zoomed into the Triangle Man’s triangle
- I spent some time adjusting the wind mechanic’s values for it to appear nicely in the environment
Evening:
- After dinner, having started feeling quite unhappy, I did some baking for occlusion culling, as there were performance issues with the wind mechanic and I wanted to see whether occlusion culling would alleviate that (which it did)
- After drying-up, I continued tweaking the wind mechanic’s values until I got it to a point at which I was happy, with the interaction shown to the left and Gloria and the flautist to the right
- I spent a while placing and resizing the brass mechanic, so that it would sit nicely on the face of the clock on the brass area’s clocktower
- For a while, I was doing the same for the piano mechanic, which included making parts of it set their positions locally instead of globally, and I made it so that the interaction ends facing away from the other areas (since looking at them kills performance and reveals their boundaries), but this meant that the player wouldn’t be able to see the characters at the top of the tower
- After pushing the changes to GitKraken, I watched the evening’s Nintendo Direct and then headed to bed
Thursday
Morning:
- A while after getting to the studio, I moved the tower target object (for characters to turn towards) to the top of the tower by setting it as a child of the tower’s roof section and resetting its position
- I placed the camera for looking at the tower from the string area, trying to keep the void to the right out of view and maintain an interesting composition
- I moved the wind area’s tower camera, trying to keep the tower visible past the trees and cliffs
- I did the same for the brass area’s tower camera, attempting to keep as much of the tower visible past the cliffs and houses as possible while keeping the characters in view
- I then did the same for the triangle area’s tower camera, which required a closer camera to keep everything and everyone in view (due to the positions of the houses)
- I tested the game in its entirety at the time, and everything seemed to be triggering properly, though I did halve the sample count of the wind mechanic to save on performance (which helped) and noticed that the occlusion culling made it even more problematic when the camera clips through objects
- After having lunch, I went to my First Support appointment
Afternoon:
- Back at the studio, Adam wanted to try out the prototype so far, so I set it up for him and he played through everything
- He said that we need to be able to press a button to skip minigames, so that we can skip to testing the environment traversal more quickly
- When I said that I need to increase Gloria’s movement speed, Adam said that I could speed up Gloria only at the end, “to make the trudge more trudgable”
- He said that he was impressed and that the game feels fine, and while he thinks it looks/works great, he said that it will be ten times more playable with the cameras sorted
- Considering how he’d been getting through the environments as quickly as he could, Adam said that if we can keep it up, the gameplay could last for thirty minutes, which is great
- He told me that we’d need to come up with a testing plan the following day, so that we can test different elements independently, having people dedicated to standing somewhere and pulling-in testers
- He said that while the last 10% is probably the hardest part of development, little things (like the changes I’ll be working on) make a big difference
- He told me that the animations and art book are nice things to have, but we need to focus on priorities
- Since the rest of the team weren’t in for the day, I headed home, and started feeling incredibly unhappy
- After getting home, I spent a considerable amount of time thinking through some very unpleasant thoughts that I can’t go into details about
Evening:
- After dinner, I added some code to make Gloria turn towards the tower when she’s meant to be looking at it, and at an angle to whomever she’s interacting with
- I used a large cylinder to determine the centre of the circle that the trail leading to the tower is an arc of, and put an empty object there to mark it (for the camera used when the player is traversing the trail)
- I started thinking through and programming the script for manipulating the cameras associated with the tower
- I added and positioned an object to act as the camera’s parent when Gloria is crossing over through the middle of the tower when climbing it
- I added an empty game object to mark the (rough) midpoint of the tower for the camera for its trail to target
- After thinking through the implementation for a while, I added all of the variables I’d need for the tower cameras and programmed a subroutine to determine which camera to use at any one time
- I programmed the subroutines for setting the positions and rotations of the different cameras for the tower, with the trail camera orbiting its centre behind Gloria and always looking at the tower, the climbing camera always orbiting the centre of the tower and pointing in the direction of the normal to the vector between Gloria and the centre of the tower, and the camera for crossing over simply looking at a position slightly above Gloria’s stored position
- I updated the camera management script to properly set the current camera based on which is determined as in use by the tower cameras’ script
- After pushing the day’s changes to GitKraken, I went to bed
Friday
Morning:
- When I got to the studio, I attached the tower cameras’ script to the manager object and tested whether the camera for the trail leading to the camera was working, but it wasn’t, instead slowly moving away from Gloria
- I felt that it could be due to a conflict in which camera was being set as the current camera, so I added conditions to setting the current camera target as the isometric one such that it’d do so only if either the area isn’t set to being the tower, or if the area is the tower and the tower cameras’ script is determining the current camera as the isometric camera
- After that change, the camera was being properly set, but it wasn’t moving correctly, which I fixed by adding the cosine of the radial position value to the trail’s orbital centre point instead of subtracting it
- I showed George the additions I’d made to the game, and he gave me some feedback:
- He said that the camera’s really important (as something that’ll have a drastic effect once it’s fully implemented)
- He said that it was functional, which is good, but there needs to be more visual feedback during the interactions to tell the player that they’re doing the right thing (using sounds and the ping system)
- I showed Ella and Bernie the changes, and they also gave me some feedback:
- Bernie said that the rows of keys in the piano mechanic were too far apart, so he didn’t know where he needed to move
- He said that the pier in the string area was massive/too large
- He told me that the amount of negative space on the floor in the brass area is ridiculous (which is because the area was originally designed to accommodate a faster, more expressive movement system)
- In response, George said that he’d add lamps and cobblestones to the brass area to cut down on the negative space, and that he’d also scale-up the area’s trees
- Ella said that adding people to the brass area should also alleviate the emptiness issue (which should be happening soon)
- She said that she was unsure about the triangle mechanic appearing on the Triangle Man’s triangle, mentioning that it appearing in a fire (as was suggested at some point) would be nice, but that might be too much work at this point
- She said that the camera pans to the tower are great, but the lack of freedom in controlling the camera is weird to her (though she acknowledged that this could just be down to personal preference)
- She told me that it’s great that the transitions into interactions have been worked-in, as “it feels like an actual game”
- I spoke to Ella about which menu options we’d need, so that she could design the UI elements for them
- Karen from the university’s careers section came to talk to us about CVs and employability, and I took some notes
- I spoke to Ella and George about the video we’d be making, and we determined that we’d each do thirty-second answers to three prepared questions, and we’ll record some B-roll at the start of the following week
Afternoon:
- I spoke to the team about the art book, and how to handle annotations – Bernie and I feel that art books with annotations and explanations of design decisions are inferior, but we wanted to strike a balance for how much detail to include so as not to draw away from the images
- After having lunch, I went to my counselling appointment
- After catching-up with Ella and George about what’s left for the project (and my coding), I checked Ella’s potential settings UI icon with three second year students, asking what they thought it was, and then what they thought it’d be in a menu
- The first said that it looks like a turtle, or settings in a menu
- The second said that it looks like a snail, or settings in a menu
- The third said that it looks like a seashell, or saving in a menu
- I spoke to Ella about UI elements, as she was drawing them, and we spoke about how recognisable the stylised icons were
- Adam gathered the team together to discuss our need to be testing the game from now on, mostly to test how long it takes to traverse the environment
- He said that we need to have a testing plan to regularly look at certain aspects of the game, and we need to get it in front of people with the basics implemented (with someone sitting in the canteen and having people test the game)
- He told us that we need to be able to press a key to stop players from cuing the interactions, so that we can test the environments
- When considering the issue of the camera not directing people to their objective, Bernie suggested that we could have the camera look in the correct direction at the start of an area to guide the player
- When I said to Adam about all of the potential camera directions I’d need to account for to keep the player on-track, he said not to “over-design for every edge case” (and he also told me not to worry about the camera clipping through objects for now)
- For a while, Adam looked at a top-down view of our string village and drew all of the camera directions he saw as necessary onto the image, so that I could potentially use his suggestions as a reference when adding all of the angles in
- When discussing the camera, Ella said that she’d prefer for the game to have a player-controlled third-person camera, so the plan became to program a third-person script (with collision detection) to allow the player to look around, and once that’s tested we can determine which camera system is better
- When I explained my plan for the weekend, Adam said to prioritise programming the third-person camera over getting the images for the art book collected
- We discussed pricing for the art book, and settled on selling each copy for £15
Evening:
- After replying to an important email, I headed home
- Eventually, after having “dinner” and talking through some things with a friend, I used an empty game object to determine the radii of the tower’s interior and exterior walls, and the vertical range when moving across the tower’s interior, so that I could properly cue the correct tower camera
- After doing very little for a while, I realised that the player probably shouldn’t have a free camera at the top of the tower (since they’d see all of the environments and the void between them), so I created a new camera object for the player to have a fixed perspective from the top of the tower
- After pushing to GitKraken, I decided that I was tired enough that I should probably sleep
Saturday
Morning:
- I quickly fixed the camera used when climbing the tower to make it face in the right direction, by subtracting 180° from the angle that was being added to the angle for the vector between Gloria and the centre of the tower
- Through trial and error, I tweaked the values of the cameras for approaching and ascending the tower until I was relatively pleased with the visual outcomes
Afternoon:
- I went to Tesco for my weekly shopping
- I eventually created a new game object and script for the planned third-person camera, copied some old code to let it take the player’s right stick input and wrote some code to set its horizontal and vertical angle values based on the stick input (since I was intending on making it a trigonometric camera system, like the isometric one)
- I added some code to use a ray to calculate whether there are any objects blocking the camera within its maximum radius, and to set its radius accordingly (going no lower than its minimum radius value), and then programmed the camera’s position and rotation to be set based on its angle values and the calculated radius
- I made the camera management script set the camera target as a child of the third-person camera instead of the isometric one, and commented-out the code that detects the right stick for Gloria’s movement system (so that the player wouldn’t both move around and look around when moving the right stick)
Evening:
- After having dinner and testing that the system was working, I made some calculation tweaks to get everything working as intended
- While tweaking values, I decided to add a horizontal offset to the camera to keep the centre of the screen unobstructed, but then I realised that simply adding this to the camera’s obstruction detection wasn’t going to work (as it’s possible to push the point from which the ray is cast through geometry, and thus prevent it from colliding with anything)
- I tried a different system that involved casting a ray from Gloria towards the offset position, but it wasn’t working well at all, seemingly deciding to work at random
- After drying-up, having been confused as to why it wasn’t working (since it was theoretically functional), I fixed the issue by removing a stray minus from the direction in which the ray was being cast, meaning it was initially being cast in the wrong direction (and I also made it so that the camera sets its position just in front of the collision instead of directly on it, so that it clips through objects less frequently)
- I tested the game with the third-person camera and saw that it was completely functional, but it had the issues that I was expecting (concerning being able to see areas that weren’t made to be seen, and the resulting performance issues and immersion breakage)
- I let George know about the issues with it being visually unclear as to when/how the player can progress, and the potential need to add some moving objects around the key interactions to draw the player’s attention
- I tweaked some values from my tests, and also remembered to add a missing collider to the tower to prevent the player from running through a wall
- I briefly moved the object for the camera to look at when approaching the tower down, so that the camera wouldn’t so aggressively cut Gloria out of view
- I spent the rest of the evening speaking to and playing with a friend, eventually getting to bed in the early hours
Sunday
Morning:
- I briefly programmed some code to make the wind villagers show or hide based on the player’s proximity and whether the player has synchronised with the flautist (or whether the NPC in question is the flautist)
- I started looking for images reflecting the progression and development of the game’s mechanics for the art book
Afternoon:
- After lunch, I went into town for a couple of cards
- Once I returned, I got back to looking at images from the last two semesters about the mechanical development of the game for the art book
Evening:
- Even after dinner, I was still gathering images for the art book, being sure to keep them in an order that made sense
- Eventually, I got around to starting the week’s blog post, which brings me to this point in time
So, as you might be able to tell by the screenshots, things are coming together to some extent. I do still have a number of pretty crucial jobs yet to do, though, including adding all of the NPC-related behaviour, properly adding the “ping system,” implementing progression blockers (and their unlocking), programming the specific details of the piano mechanic (like the other characters joining in), adding animations and, quite crucially, adding all of the music (and tweaking lots of values so that interaction mechanics are lined-up with their respective tracks). There are also the extras, like a pause menu and main menu, a colourblind option, an easier difficulty setting and a timer to automatically restart the game if it’s left idle for too long. I’ll see how much can be done before handing-in (if I can’t get everything done by then, I’ll get it done by the degree shows), and I’ll specifically tell you how much I can do this week in next week’s blog post.
Crowence Game Development 