Archive:
Back from holi-bobs with a bump. Paid work, today, as the stuff I was blocked on has been fixed. And joy! iOS and Xcode both need updating…
Spent most of the day animating the run cycle for the Rat NPC. Took a few attempts, but the final thing looks fine. If you don’t look at it too closely.
The rest of day was spent recreating the floor in the Dungeon. Like a dumb-ass, I deleted the Substance Designer project before committing it to source control. That’s a slight problem, as I can’t generate texture variations without it. At a minimum, I want to have a version without the stones, and maybe a darker one for some vertex painted blending…
I should really do a bit of research into Substance Designer, as I’m fairly sure I can embed a graph as a node in another graph, which would make all the variants easier to maintain, but I’ve run out of time today and my eyes are killing me. Obviously still recovering from seeing actual blue skies and green grass…
The eagle-eyed among you will have noticed that I’m still prevaricating over the NPC AI and movement…
Slight detour. A few engine versions back I tried to put Force Feedback [Joypad Rumble] into the game. I’ve never been a massive fan of rumble – Lumo has none at all – but old-age is mellowing me.
Back then, for some reason, the force feedback previews worked in the editor but when used in-game the same assets would do nothing, or work a few times and then disappear, never to rumble again. I never got to the bottom of it (not that I tried all that hard) so it’s been an open GNTODO for months. Today was the day. And, of course, they all worked fine, first time. RUMBLE ALL THE THINGS!
If it’s good enough for a rumble, then it’s probably good enough for a little shake of the camera, and hey, if people insist on calling me Indie then I might as well hit some of the tropes:
I copied the shake from Cecconoid, as it’s simple and looks quite nice. Code-wise, I needed to go through the various Follow Cam update types and make sure that they stored the position they calculated for the camera to move to, rather than simply moving and forgetting about it.
Camera shake is defined as a jump to a random point, in a circle, that’s centred around the newly calculated camera position. Things in the world can add to the shake’s amplitude, thus increasing the radius of the circle, and the camera rolls down the amplitude over time. There’s an argument for lerping between points, rather than jumping immediately to random ones, but I didn’t find the difference to be a major aesthetic improvement. What’s more important, to my eye, is the amplitude and how long you take to roll it down, so that’s where I’ve got my levers.
So, new toys! That I need to be careful not to overuse…
Spent the morning giving a design lecture, which was fun. In the afternoon I feel down a rabbit hole, which was not fun…
I was looking for something quick and easy to do, so opted for a quality-of-life thing. Because I’m working on elements in specific dungeon rooms, I want the player to be in the correct room when I hit play.
The RoomControllers already know if they’re an entrance room, so I can change a bool on those and most of the code will “just work”, but, because I only have one PlayerStart in the map I have to physically move it to a new location when I’m bouncing onto something in another room. This takes seconds! Ideally, I should be have an arbitrary number of PlayerStart points in the map, and the code should do its magic when I hit Play. Every second counts!
My first pass was to grab all the PlayerStart actors, see if their tag matched the name of the entrance room, and teleport the player to it. This would happen in BeginPlay and worked fine, 9 times out of 10. But… Occasionally the player would be facing the wrong direction.
This causes a problem in my game because the player character object doesn’t rotate, the mesh, parented to the object, does. This is because all actors in the game are tilted, away from the camera, to give a forced perspective. So, If the player character is rotated, the controls will break, and other bad shit can happen.
I teleport the player all the time. I’m using well-worn code. And I can’t work out what’s happening. So, I re-write the Dungeon’s start sequence to match the overworld, and instead of using UE’s PlayerStart actors, I use my own, home-rolled RespawnPoints, but again, the same thing starts happening.
One benefit to UE4 is that you have all the source code. With a bit of Googling, and a lot of trawling through GameModeBase, I learn enough about the spawn sequence to fix my problem. If I do the search and compare of the PlayerStart tags in ChoosePlayerStart (overridden in my GameMode) the engine’s spawning code kicks off with the correct location. Because BeginPlay is called after ChoosePlayerStart, I don’t need to teleport the player manually, or do anything funky. It ends up in the right place, facing the right way. Phew!
I spent 3.5 hours on that so I’m going to need to bounce around a lot of dungeon rooms to claw back those 10800 seconds… :/
Started bouncing around some dungeon rooms, adding sequencing, missing assets and VFX for elements as they move in. Atm I’m going with the rule that forced camera movement in code triggers the black bars, otherwise they’re left off.
Here's a short video showing a couple. (Lots of audio is still missing, very WIP, may contain nuts, etc...)
I'm aiming for the next Dev Vlog in a couple of weeks, so I'd like to get this Dungeon "finished" in time for that. Todo-lists are primed and prioritised...
