November 10, 2022
I went a little lighter on the work this week after last week’s crunch for the Alpha code deadline. Most of my focus this week was on non-game Scenes like the menu and lobby screens and handling the input devices in and between these scenes. These are the kinds of things that are important for a polished product at the end of the project that I don’t want to leave for the last week when I’m inevitably crunching for the Gold code. I’d much rather cut a couple enemy or magical spell types than have a poor, unpolished menu and lobby screen.
I’ve done a number of adjustments to the dynamic split-screen cameras this week:
No more camera popping/flickering on the edges when split-screens recombine.
Cameras now have a small amount of smoothing when only using a single camera (it’s more important to have a tighter camera without smoothing when the screens split and the horizontal real-estate is reduced).
Split-screen solution now works with any aspect ratio.
I’m in the process of rewriting a lot of the world generation code. For one, I want to abstract away the details of a particular level’s generation into a separate class for each level. Also, I’m going to be shortening levels and having 3 distinct zones visually in each stage to reduce repetitiveness. Finally, I want to more evenly space out environmental objects and write a proper framework for placing objects of different sizes evenly throughout the game world.
As mentioned earlier, I’m working on properly developing the non-gameplay scenes so I don’t rush them last minute. The menu currently has options for settings, which aren’t currently hooked up to anything, and credits, which will just play a scrolling textbox for references to any external assets I used in the project. Hitting the Odyssey option will bring players to the game lobby.
For the game lobby, I was inspired by Unrailed to have a blueprint-esque lobby where players can run around in an open space, adjusting their settings before the game starts. I wanted to make sure that this lobby could flexibly support different input devices jumping in and out, which even with Unity’s new Input System, was a bit challenging. I’m currently working on a solution that will maintain the state of devices across all scenes by associating players with a particular ID that should preserve relevant information across scenes. This is currently a work-in-progress; at this time, inputs are maintained between the menu and lobby scenes, but not the game scene as it’s still under development and I don’t want the game scene to require data passed from the lobby scene at this time. The lobby itself is also still a work-in-progress: players cannot currently edit their name or switch costumes. However, the jumping in and out with different devices in different slots is working well at this time and I’m happy with the progress.
