First release and bugs

If you're reading this, then you've probably downloaded the game or are planning to.

Thanks!

This is one of the first steps in expanding this game into a full product. Of course, despite a bunch of testing and bugfixing over the past few days, some more bugs have reared their heads. 

The Bugs

Most of them are minor, but one seems to occasionally put the player into the ground after an animation. This is the worst kind of bug, because it isn't consistent. The reporter implied it had happened a few times to them, which is worrying, but try as I might, I've been unable to replicate it, so right now I'm stabbing into the dark to try and work out what could cause it and try to implement fixes for the assumed problem.

There were also some comments about cameras in the dungeon.

There will be a patch for these as soon as I can find them and fix them. But to understand why the first bug happens, it's worth going over how the animations work.

Group Animation Process

Getting characters to interact with each other was a major issue. For the most part, animations are just a single character doing stuff. Not many problems there. Once they start interacting with each other you get issues with alignment. So for example, you need to have both characters in exactly the right place for contact to look right. At the start, one of the characters would have an animation reference model that is hidden ingame. This would be positioned exactly where you want the second character to be for the animation to work.

This lead to all kinds of issues with rotations and actually getting them in the right place without the player input moving things.

In the end, the reference characters were already attached to one character, so it became easier to just lock and hide the player, then unhide the animation reference model to go through the animation. At the end, the animation reference vanishes and the player is spawned back in. When the player is removed the game saves the location and height they were removed from, then on respawn places them back in that exact same spot.

This is where the clipping into the floor gets tricky. If the location the player was captured in was valid, then respawning there should also be valid.

Possible Solutions

I've already tried out a few ideas. The first is to do a linetrace directly down from the player just before respawning. If the ground distance is less than half the players height away, then in theory, they are in the ground and the spawn location should be raised by how much below 50% height it is. The flaw there is that if the player is stood on a box and is sunk into the box then the next collision object may be the floor under the box.

The next idea is to respawn the player at the exact height of the enemy they were interacting with. But if they are standing next to a hill, or he's lower on stairs than the player, things get so much worse.

A suggested solution was to give the player a button to noclip back out if it happens, which is a good idea, but it only addresses getting around the problem rather than fixing it. The game needs to be robust enough to recover when things go to shit.

A possible cause could be interaction between collision objects on the characters. Potentially what could be happening is that the switch from player to animation happens fast enough that the enemy collision box moves into where the players one should be, then when it re-enables the player, it tries to spawn outside that collision and pushes you into the ground. At the moment, the enemies go to a nocollision state when they go into recovery, so maybe the solution is to remove collision just before respawning the player. That would fix it, assuming this actually is the problem, which is nowhere near guaranteed.

I'll keep plugging away at it. The priority is bugfixing, and I'd like to clean up the player/wolf sex scenes a little. Those were some of the first game animations I did, and they're looking janky. It shouldn't be too much of a job to bring them up to the standard of the plant animations, which were redone last week.