Archive:
Banged out two rooms, today. One where you have to fall down through some moving laser beams – very similar to what I did at the end of the first game – and another where ground tiles appear / disappear as you jump. Sprinkled a circle laser in, for that extra Mario spice…
Back in [[Week 58]] I remodelled The Attic, so the player would need to use a push block, on Wand Platforms, to get access to a sky-light that leads to The Roof. But… It wasn’t actually possible for Wand Platforms to lift anything.
Most interactive objects in the game work under my control, meaning they don’t simulate physics. This stops things falling out of rooms, or pinging off into space when they depenetrate. To get around this, I created a new type of wand platform, with a trigger that looks for overlapping actors that implement ILU_WandCollisionResponderInterface. If any are overlapping, they’ll be lifted nice and slowly. I also added a bit of code to the Pushblocks, to check if they’re floating when the wand is disabled. If they are, they run a timeline to fall back to the ground.
Hacky bodge, but it does what I need for in room. (Can’t see me using it again, tbh…)
Jet Set Willy has two ballrooms, East and West, which immediately made me think, “Mario Galaxy”. I’ve been cogitating over this for a while, so this afternoon I set up a room with a big sphere, and started digging into the code to see how hard it would be. Turns out, not very! Epic added gravity override functionality to 5.4 – timing! – so all I have to do is feed it a vector.
The controls, on the other hand, are a bit more fiddly, but for once in my life Epic actually documented it with an example, which I’ve hacked about to suit my needs. Thanks Epic! Thepic.
I’ve got two things to fix: Jumping assumes “Up” is Z positive, so I need to rotate that, and the camera is going to have to be special-cased. I’ve written a new PlayerFollowCam_Origin, that finds the correct position on the sphere for the camera’s position, but there’s nothing in the camera itself that takes the player’s orientation into account. It should be fine, everything’s already driven off Gameplay Tags… Easy check.
The big question is, do I let the player manually rotate the camera in these rooms? If so, all of that will need to be based off gravity relative rotations as well. I’m leaning against it. I want to force them to run around the whole thing.
Hmmm. Nearly.
Getting the jump (and double jump) to work, regardless of the direction of gravity, wasn’t too bad. The recent character controller refactor paid off; the recent clean-up meant there were only a few places that needed tweaking. But it’s still not perfect. Sometimes the character’s not entering float, and I’m not sure why. There’s a check for something, somewhere, that’s doing the wrong thing. (I skipped making the changes to forced jump, so you won’t be able to bounce off springs, which is fine, I won’t put any in these rooms).
The camera is almost there, but I’m deep in quaternions and, honestly, its melted my brain.
That’s the character at the bottom of the sphere. The camera should be looking down, not up. The roll is correct, but the pitch isn’t, and I don’t quite understand why. I’m using the control rotation’s forward vector, which is gravity relative, to do the camera offset, but since that’s not adjusting the pitch correctly, I think I’ll try another approach tomorrow: forward vector to push the camera out, gravity normal to calculate the pitch. Or something. And I’ve not attempted to let you rotate the camera using the right stick yet. :(
I wish I’d paid more attention to maths when I was in school. This stuff always takes me too long.
My brain obviously processed it in my sleep. I vaguely remembered something about Quaternion composition being sequential. I was applying the pitch and yaw to the control rotation in one quaternion, splitting them out into separate quaternions fixed the problem. Woo!
With that working, I tidied up yesterday’s pass at the movement code, and changed the camera’s ‘Aim Assist’ to work no matter the orientation or gravity direction. I’ve basically got Mario Galaxy now, apart from that little floating bug. I’ll try and track that down another day.
Added some pick-ups – thank god for UE’s surface snapping options – a teleporter, and fixed the camera transition when leaving East Ballroom. I’ve not added anything fancy, like moving platforms, or enemies to the room. I figure I’ll make Ball Room West the more difficult of the two and keep this one as a simple “hunt the pickup”.
Laid out The Bathroom, modelled & textured a bath, and researched a new thing: Water in games is normally some sort of plane. The vertices on it might be animated, but essentially, it’s a big ol’ polygon that will happily intersect anything that’s ‘floating’ on it, like a boat or a bath. So how do you hide that intersection? Honestly, I had no idea, but it turns out to be a simple trick. UE can build signed distance field meshes of the models it imports, and the material can use these to work out "how close" each fragment is to a mesh.
Four nodes that make a lerp from 1-0, that plugs straight into the opacity.
You can see that I’ve gone for a soft fade and there are holes around the corners of the bath, but you can’t really see these when you’re playing. Nice trick, wish I’d known about it before.
Friends:
If you like any of my work, please consider checking out some of the fantastic games made by the following super talented people:
