Programmer
This week didn't see much development progress from anyone, because we took the time to focus on introducing the new team to the project (myself included,) switching to GitHub, and solidifying our ideas for where this project is going to go. I'm looking forward to helping turn this rhythm game into a restaurant managemer rhythm game. We also did a LARP of our plans for this version to make sure it'd work out and that we knew what we were doing.
Development begins. This week, my task was to set up a reservoir system. The idea is that every time you wash a dish, cook a waffle, or any other task, the finished product goes into a reservoir, so that when it's time to put together an order, you can draw on those reservoirs. That's the key thing that makes this a restaurant manager - the player has agency to strategize between making each item as needed (which is probably not ideal in a rhythm game) or stocking up on a bunch of an item so they don't have to worry about it for a while.
In addition to counting the items produced (which would have been too easy,) I added in quality scores that can be used to help determine customer satisfaction. The better you do on the station preparing something, the higher the final product's quality. In scoring, the value of quality ranges from 0 to 1, with 1 being the best, but for display purposes, I let the actual value scale from 0 to 2. The idea is that, in waffles for example, values too far below 1 represent undercooked waffles, and values too far above 1 represent overcooked waffles, but a raw waffle and a lump of charcoal aren't going to look the same in the stack. Thus, there are two getters for display and scoring.
The reservoir system is complete... I think. I moved reservoirs to a static reservoir manager class, and added display objects. Reservoirs each have an update event that fires whenever an item is added to or removed from the reservoir, and reservoir displays listen to that event. Currently, the only display in place is for plates, and I think the stack looks rather nice. As you wash dishes, you can see them stack up to a maximum of 30, and the color of the plates depends on how well the dishes are washed. Catch all the stains, and it's pure white. Leave too many, and it'll become an icky yellow-brown. And of course, it can be anywhere in between. I also made placeholder waffle and pancake displays, so that when that station is finished, it'll be easy to link them up.
This week was a bit trickier. For context, in the last term, the original team had started developing a cleaner version of the dish washing script. My task was to finish it and get it implemented, but it just wouldn't work. Not that there was anything noticeably wrong with the code, just that the beat bar wouldn't fire collision events when it hit the smudges. Unable to get that sorted, I resorted to a bit more work on the reservoirs, improving their performance. We'll get the dishes figured out when we can put more heads together.
Unfortunately, I was pretty busy with other work this week, and wasn't able to get as much done. But what I did make was a coordinate system for dynamically drawing pancake shapes. It still needs some more testing and fine-tuning, but given a list of coordinates, it plots the points and draws the shape, which the marker will follow.Â
Adding to the previous week's work, I created a system that determines how far the player is from the marker in tracing the pancake's shape. But it's not just distance, it's a Vector2 relative to the marker's movement. The X coordinate determines how far ahead or behind you are, and the Z coordinate determines how far left or right. This was used (by other members of the team) to have the guitar track of the music alter based on the player's offset. In other news, I did a bit of cleanup like making the pancake trace over the course of two measures instead of one.
I forgot to fill in the blog this week, so I'm writing this after the fact, but what I worked on was an asset swapping system. Assets can be given a set of scripts that defines different variants they can be swapped to, allowing for easy cosmetic changes to the restaurant. In addition, they have their own ID system and a static manager so that multiple corresponding assets can swap in unison, even if the end results are different objects.
I improved on the asset swapping system from last week, letting it use prefabs to define variants instead of just meshes and materials. In addition, I added a new type of asset variant that swaps background scenes. It does need to run asynchronously, which might introduce bugs if the swaps are spammed, but we can guard against that in the UI.
In other news, I played around with the new particle pancakes and found a way to copy them into reservoirs. So I did that.
After fixing all the compilation and runtime warnings in the project - a move which fortunately didn't break anything, so it could get merged easily - I went on to tackle creating and integrating the prefabs for the various asset swaps. I was originally thinking this would be easy enough for the art team, but it's a good thing I took it, because the asset swapper script had two fields that required specific object references that couldn't be added in bulk. That would have made it way more tedious than it was, but I was able to rewrite the code to not need them. I also got to experience my first merge conflict in the main scene, which was tedious to resolve. My respect for Ryan, who usually handles those, has gone up.
These past couple weeks were wild, rushing to get so many final features in I can't even keep track of it all. But that won't stop me from trying. I added dancing eggs, varying shapes for pancakes, new beat markers for dish washing (and fixes for the reservoir,) an orthographic camera for the pancake station, a bit of cleanup from old loose ends, and final implementation of the scripts for asset swaps (and fixes for their prefabs.) I'm proud of what we've all been able to accomplish, finally achieving an actual gameplay loop.