Despite the last devlog being about how I needed to back away from all my projects due to a family member being in hospital, it turns out you can't actually visit until the afternoon, so rather than brood on it, I finished off what I think should fix the biggest bug people have found so far outside of optimisation.

The best bet is to explain why it happens, then how it's been hopefully fixed.

Why is this a thing?

Full disclosure. Despite being a software developer and building/animating 3d models for a few years, I've never actually built a game before, so a lot of this is new, and like with software development, you learn enough to get by then google the rest until you know that too. The roots of this bug are from a workaround from nearly the beginning of development, and it goes like this:

First, the need for two or more characters to play interacting animations. To get this to work, you have to make sure one character has the reference location that the second character uses to align itself. In this case, I decided that the enemy would be the constant, and the player aligns to him.

The problem was taking away player control to get them to the right location. I could get it working, but the player was able to rotate in position, or sometimes wouldn't move to the right spot. Then there was the issue with synchronising both. The tutorial I was using had an invisible player character attached and aligned on the enemy characters. This was used as the reference for where to place the player. But I could not get it to work.

In the end, I scrapped the idea of actually having the player do the animation, because the reference one also had access to the animations, so the whole thing changed to the enemy catching the player, then the player gets disabled and hidden and the reference character appears to play through the animation. At the end, the reference disappears and the player is respawned to continue play.

How does this break?

To get the right location, the game saves a Vector from the player, just before the player is removed. A vector is just an x/y/z world co-ordinate. This meant that on reappearing, the player moves to that spot. Theoretically, this means that if the player started there, they should be able to end there as well, so something was moving them.

Enemies have a collision box, as does the player. If you try to spawn two collision boxes inside each other, the last one to try to spawn gets shoved aside. I think this is what causes the player to move forward or down into terrain. It doesn't go far, because when the player respawns, they are almost out of the enemy collision box but not quite.

Once an enemy finishes a sex scene, they have a recovery animation where they lay down. In order to stop them being an obstacle, they lose their collision. The first fix was to make it so they lose their collision just before the player spawns.

But you could still end up inside a wall.

The next thing was rotation. When a player is captured it gets the location saved but not which way they were facing. When spawning in, the game doesn't get a rotation, so it rotates to 0,0,0. This could sometimes put you in a wall. The solution to this was to save and return the correct rotation for the player on spawning back in.

Finally, to make doubly sure, just in case it isn't actually any of these things doing it, I added a trigger to the player. This trigger is a sphere located halfway up the characters height and 50 units wide, so too small to reach the ground. When respawning, the game now makes this trigger sense anything overlapping it. It then filters out enemies and the player themself. If it detects anything else, it's a wall or stairs and teleports the player backwards by about 50 units. Usually this is just behind the enemy.

Whats next?

The biggest problem is that these may not actually be what is causing it. After doing these fixes, I've repeated play about 50 times and not had it reoccur, but testing 50 times is different to thousands of plays.

The next biggest, is that this is not really a good solution. In games, you need to suspend disbelief a little, but I don't want the player teleporting backwards out of walls. What I would like to do is try and rebuild the animation system again. I now know a shitload more than I did 4 months ago when I first did this, and think I can now do it way better. For starters, the player is the most important character, so the enemies should be aligning to the player, not the other way round. I can also disable inputs way better now, so I think I have the solutions for the problems at the root of the current issues.

The ideal endpoint is to make this more robust.

And one more thing

There have been comments about optimisation, and I agree. The only optimisation so far has been to bring the game down to a filesize that itch will accept, and removing the 4k+ textures on the trees in the distance. Serious optimisation needs to happen, but at this early stage, it could also consume a lot of time. Practically all of the game content right now is either placeholder or early iterations, so optimising them could eat a lot of valuable time just for them to get scrapped in a month or two.

One of the big reasons for filesize could be asset libraries. For example, the trees come from Unreal Megascans. But by installing them, you're also installing a lot of other tree models and textures which aren't even in the game. My understanding was that compiling the game only packed in the used assets. It turns out it actually packs in everything in the project, so a quick and easyish optimisation might just be removing unused assets.

As I said in the last devlog, real life comes first, and while this hospital thing is going on, I can't dedicate time to development because I don't know how things are going to work out. If I have time, I'll do what I can. Luckily, this should resolve the major bug, so things should be a bit nicer to play.