Archive:
One thing UE’s missing is a way to add a bunch of actors – selected in the scene, or from the outliner – to an array in the details pane. It gets tiresome quickly, so I knocked up a couple more scripts (Editor Actor Actions, new hammer, yay!): one to add static actors to a Room Controller, and another for dynamic actors. Bosh. (Future Gareth: These were probably the biggest time-saving thing that I added to the project. Editor Actor Actions are incredibly powerful, and they removed a lot of opportunities for me to mess something up, by doing things manually. If you’re not playing around with them, you should. I highly recommend them.)
Room Controllers need a way to ensure any actors shared with another room, like moving platforms, are in the correct position when the player wanders in (they might have reloaded the game, or something), which means taking “ownership” during Pre Room Entry, setting them up correctly, and then fading them in as normal. I figure any room that needs to do this will have some specific need, so rather than attempt a generic solution I’ve added a couple of native events into the Room Controller Interface, which appears to be clean enough for now.
My real intention, today, was to crack on with an Impossible Mission style room. This involves slightly different character actions (including a somersault!) and a new mode for the camera. I thought I could do this by swapping out the PlayerController… except, it’s tied to the active GameMode. The GameMode is connected to the map… and I don’t want to load a new map.
And thinking about it, I can see why Epic tied them together in that way. I’ve just never gave it any thought until now. What I should have done (like, forever) is have the PlayerController call functions on the possessed pawn, rather than do the leg-work within the controller itself. That way, I could possess anything, with the same controller, and the pawn could do whatever it wants to do with the input. Like, I dunno, control Gilby from Iridis Alpha, or 001 from Uridium…
Anyway, bit the bullet; refactored the PlayerController and the PlayerCharacter so the controller’s agnostic, and the Player Controller does what it wants. Although, I’ll probably need to make an Interface for possessed pawns to implement. At the minute, everything casts to a specific PlayerCharacter class.
Oh, and Doors can be locked!
Impossible Mission room here we goooo….
So this one needs something specific from the camera; a fixed rotation and a larger distance from the origin. I’d partially implemented support for both; the settings existed, but the code ignored the distance and offset. A bit of fettling later and every room can put the camera wherever it wants, on entry, or during other events.
The PlayerController refactor is working, so I hacked together some basic left/right movement code, and changed the jump velocity to get something closer to the C64 game. Also made a couple of tiles for basic layout, and textured them. Which leaves the somersault…
Jim McCauley reckons Impossible Mission is the somersault Daddy. Before it, somersaults didn’t exist in video games. After it, every-bloody-thing somersaulted. Moles. Ninjas. You name it.
He has a point. It’s the king of the 8bit character actions, and I bloody hate animating characters that roll. It’s a royal pain in the arse because my character’s root isn’t at the centre of mass, it’s on the floor. There’s bound to be a way to sort this out in Blender, but I’ve never been arsed enough to work out how… Including today, so I tried a couple of workarounds, including rotating the mesh in code. Predictably, that looked shite.
Ended up deploying the ol’ faithful Triple Eh? guide to video game animation: get a decent pose, lerp to it quickly, then lerp out smoothly. Most people don’t notice, well, unless they’re an artist, animator or a video game developer… It took a bit of tweaking to get the smoothment (yes, that’s a word, copyright Dave Hynd) right, but the result’s good enough for me.
The cape, on the other hand, caused a lot of problems, but I found a decent workaround: set the blend weight to < 50%, suspend the physics update on the cape, do the animation, then on landing, blend the physics sim back in. It’s obviously wrong, but it stops the cape from wrapping itself around the player’s head or getting stuck in the character’s bum crack.
F#ck knows what they had to do on Batman…
Didn’t get much done, today. Plumber was over, and what was supposed to be a simple job ended up becoming a minor disaster. Home ownership…
I did spend some more time on the Impossible Mission room: layout is done, lifts are in, and I modelled a tape drive for the player to search. Need a couple more objects, but I don’t think a desk and chair would actually work in 3D. (T’was a bit weird in the original game, imo…) On the code side: Room Controllers can apply tags on entry and individual UI elements have a collection of blocking tags that can prevent them from appearing (or disappearing). God, I love me a good Gameplay Tag.
Friends:
If you like any of my work, please consider checking out some of the fantastic games made by the following super talented people:
