Archive:
Two interesting problems, today. One: how do you legit make the default CharacterMovementComponent float, without a custom movement mode, or setting it to “Flying”. Most answers lean toward manually overwriting the component’s Velocity vector. That feels like a hack, so I had a dig around for another way. The movement component has a method – Launch – that’s used to make the character jump. There’s also a method on the character class itself, LaunchCharacter that lets you override the XY and/or Z components of the velocity. Why are there two? No idea, but the latter looked ideal, and it turned out to do exactly what I needed.
I now have vertical fans:
Any actor who overlaps the green capsule will have a force passed to it. If it implements the ITDI_ForceActorResponder_Interface, it can decide whether it floats or not. I use the Actor’s distance from the base of the fan to linearly roll-off the amount of force that’s sent to it, so with some in-editor number tweakage it was easy to find a sweat-spot, and get the player character to float at the top of the capsule. (I’m also switching on some Wind Source components to make the cape fly about, which I doubt anyone will notice, but it looks cool).
Sorting out the player character, the animation blueprint, and making sure everything entered and exited cleanly took a little while, but I got there. And, in theory, fans should be able to make anything float. I’ll test that out with some Push Blocks at some point.
This is the tallest room in the game, so far, which threw up problem number two: How to light it on the Switch? I don’t want a bunch of overlapping lights and the Switch doesn’t have Lumen. So I ended up with a single spot, with a large soft-source area, that follows the position of the Camera Origin. Obviously wrong (if you stare at it), but I doubt many people will notice.
Sat down to play the build on the lounge TV, and found three crash bugs. Last week’s modifications to the Wand Charges meant the other pickups (derived from the same base), need to be added to their Room Controller’s object list. Forget to do that and null pointers go Boom!
I’ve also made a design change to Moonbase. Up to now, the first pass through the map has been linear, and I locked several doors behind the player to help direct them. The major one being Impossible Mission, making those four rooms a “one time” thing. If you missed the duck or the paint pick-ups, tough. That’s a bit harsh, so I’ve made sure you can access them the second (or third) time through. Oh, and I fixed up the animation side to let you somersault while holding the Wand.
The Chimera section is still one-time, so you could potentially miss some paint in there. That’s a bit more fiddly, so I’ll cogitate.
I finished off yesterday’s room, and added a new type of paint pickup; ones that move along a spline. I swear, I’m seconds away from doing a Crackdown 2, and adding Paint Pickups that you have to chase. Still one of my finest hours… [https://www.youtube.com/watch?v=egxjuLkhXUw]
And I decided that I didn’t like the loop back to The Hall, in Willy’s Mansion, so I’ve added a new room that will take you from Priests Hole to First Landing: The Swimming Pool. Some wand platforms, with a Duck. Nothing too strenuous.
Sat down last night to play on the big telly again, and yeah. I’m not happy with the Jump. Again. There’re some teeny tiny inconsistencies that are affecting the feel, and some have been there forever. (For ex. you don’t enter float if you walk off certain ledges. Fxxx knows why). Others look like glitches. More things falling down the cracks between the Character Controller’s Finite State Machine, and the Animation Blueprint? [[Week 56]] definitely improved it, but nah.
I woke up at 6am, two hours before my alarm, wide-awake. Clearly a sign, so I went to the forge and did the one thing you probably shouldn’t be doing a year into making a game: refactored the entire character controller.
Rather than perform a heart transplant, I’ve got the scalpel out and done key-hole surgery, piece by piece. First, dropping off ledges. Then single jumps. Then jumping into gaps that necessitate a float. Then, double jumping… You get the idea. At each step, I’ve removed state checks from the Animation Blueprint, along with anything that was querying the world. Rather than try and dig into the Character’s FSM, the Anim Blueprint checks against the Player’s GameplayTags. This let me remove a few aliases (and many state transitions), along with a load of animation notifies, drastically simplifying the whole thing.
On the code side, I’ve kept the FSM, but it’s driven – of course – by Gameplay Tags, something I’ve been threatening to do for months. I’ve cleaned out duplicated / redundant code, and moved ALL checks against the world back into C++.
The tags really came into their own when adjusting the feel. Simple example: you press jump. I record the height at take off, the character jumps, and won’t float until: A) it’s gone just below the take-off height & B) the ground is more than 2m away. So, quick hops, and little jumps down, do what you expect. Jumps into bigger gaps pop you into float. Again, as you’d expect. But double jumps shouldn’t act the same way. Chances are, when you’re doing a double jump you’re going for height, and/or distance, so floating earlier is beneficial. You get more control and time to spot your landing. This worked in the old implementation, but I didn’t have the levers to (easily) say how much earlier double jump should float. Now, it’s clean as a whistle, and I’ve got a tweakable.
I found similar benefits with Force Actors; things like springs, and the fans I’ve just been working on. And when I want things like the jump cancel to be blocked, that’s easier as well. Got a Force tag? Cool, you can’t cancel out of a jump. Less FSM transitions to keep track off, a more fine-grained definition of what the player’s doing (that anything in the game can quickly and easily see), meaning code that’s easier to read, debug, and scattered across fewer places.
So yeah, a big, scary, stupid task that I shouldn’t have needed to do, but I’m pleased with it. So far. I’ve done a lot of testing, but I’ve not done a full run through, so, you know. There’s bound to be something. But that’s tomorrow’s job. Today’s been a 12-hour squirt, which is enough for one day.
Obviously, it helps to know, up-front, what your character is meant to do. But if you don’t, at least know that you’ll get a much, much nicer version of it, the second time you make it. Gameplay Tags FTW!
Was mostly testing, today.
Found two little edge cases with the character controller, via the classic QA technique of “mashing the buttons” to see what breaks. One was a legit bug in yesterday’s work, the other, an edge case you had to be frame accurate to hit. I’m feeling pretty good about the whole thing, tbh.
While I was testing, I made a few design changes in the Moonbase: extended out the computer room, so I could put a Fat Worm sign by the door, and removed one of the robots in the Impossible Mission room. I also tweaked Willy’s Mansion. There’s no longer a door in The Hall leading to The Backstairs. Now, you teleport to the stairs via the Prince of Purple section. Removes the only bit of back-tracking that would have been required in the first run through. I think that’s going to be better, cos the second time, it’ll feel more like you’re actually exploring the place.
Oh, and I started a new room in Moonbase. Knocked up a Sum of Sine plasma, which I’m masking through the material. Looks great when it’s moving.
I’m off to Zzap Live, tomorrow, so I’m going to take my Steam Deck with the latest build on, and let a couple of mates have their first look… I don’t think anyone other than me has played the game yet, so that’ll be interesting.
Friends:
If you like any of my work, please consider checking out some of the fantastic games made by the following super talented people:
