Archive:
I try and self-host as many services as I can, including my Source Control. I have a Perforce server which is mostly hands free, apart from the one day a year when an update comes along and hoses the entire f’ing thing.
Guess what day it is?
Borkage: a complete failure to listen on the correct port over SSL. I spent far too long trying to work this out, went through every config file, gave up, bounced the server to the latest Ubuntu LTS, purged Perforce entirely, re-installed it, and then pointed it at the old database files. Which worked! Phew!
My actual plan for the day was to migrate the moving platforms from Maenhir into a plug-in and amend them to use Data Assets. I had about enough time in the day left to migrate the code over, but I've not hooked up the Data Assets.
Went through the Moving Platform code, found three bugs (!), and added a physics sweep along the movement trajectory so they can pause before intersecting anything that unexpectedly moves in their way.
The platforms configure their audio and mesh from a Data Asset, during construction, so there's nothing hard-coded in the base Blueprint. All that's needed to change things in the world is to swap out the Data Asset. It's a super tidy way to work, and one I'm going to lean into heavily on this project.
Also moved the Floor Spikes over from Maenhir. Considering they're a copy of the ones in the first game, it seems only fitting.
Created another type of moving platform: one that moves when the player presses a joypad button. I liked how sections of the level moved in Captain Toad, so I'm going to play around with something similar.
Went through the process of deriving new Blueprints from the plug-in’s bases, adding 2umo specific interfaces to them, and tying them up to a Room Controller, and fading materials. The latter's something that everything in the game needs, as rooms, and their contents, are only visible whilst you’re in them. To keep the plug-ins reusable, 2umo specific stuff, like this, needs to be behind those interfaces. It’s boilerplate, but nothing onerous.
Also added a way to cancel the Player Character’s float (from a jump or fall): press the B button and the character falls straight down. No air control. Gets rid of an annoying wait, when you’re hovering over something you want to land on.
Moved the conveyor belt over from Maenhir and gave it a spring-clean.
Added tracking to the Player State, so anything can query if the wand is lit, and added some delegates to the Game Mode. When the Wand's state changes, anything tied to the delegate will automatically be informed.
Put together a skinny interface for WandInteractives, and a simple base class that toggles the actor’s Tick and defines common configuration properties. Like the moving platforms, this uses a Data Asset to define the mesh and material override, and the components that are added to it.
I think the only thing I need to add is a check to make sure Static Mesh bounds can't intersect with the player when the wand is enabled. I'm guessing preventing the Actor from appearing will be enough, but I'll need to play with it.
Got the Steam Deck setup as a build target in UE, along with the Linux cross-compilation tools. Maenhir is faster under Proton than native Linux on the Steam Deck, so I have to keep an eye-out. I suspect I'll only ship "official" Proton versions but Valve seem to be moving quickly. Would be nice to officially support Linux again. It’d be even nicer if I could use the Unreal editor under Linux, but it’s too slow and a little unstable… One can dream.
Took the build to a mate's house so they could have a swizz. Their 31:9 ultrawide monitor broke my camera (for obvious reasons), so I need to handle monster screens correctly; I don't want the field of view to change, and I definitely don't want UI elements glued to the far corners. That always looks completely amateur-hour.
Friends:
If you like any of my work, please consider checking out some of the fantastic games made by the following super talented people:
