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.
Get The Running of the Wolves Demo
The Running of the Wolves Demo
An Adult Stealth Adventure
Status | In development |
Author | methodia |
Genre | Adventure |
Tags | 3D, Adult, Erotic, Furry, Indie, Procedural Generation, Singleplayer, Stealth, Unreal Engine |
Languages | English |
Accessibility | Subtitles |
More posts
- Public Release v3.1.04 days ago
- Halloween Edition... Coming tomorrow...5 days ago
- Release V3.0.1 now available for Subscribers & Purchasers!44 days ago
- New Release Incoming...58 days ago
- Next Release Update...81 days ago
- A Quick Content Survey91 days ago
- Late Update - 26/7/24Jul 26, 2024
- Release v2.2.1 now availableJul 08, 2024
- New Demo Version Incoming...Jul 07, 2024
- New Release Incoming (also news and changes)Jul 01, 2024
Comments
Log in with itch.io to leave a comment.
not sure if this ones been reported yet but the pause feature on the adult scenes has exploitable behavior it alows one to press e to escape while paused... nice if you got slow reflexes or for some reason one useable hand.
edit after re-reading this post again i got to thinking of terraria and how hoik's work by exploiting a phyiscs flaw in the game that pushes the player in a set direction if it detects the player is stuck in the terrain... could something simalar be useful in this case?
I honestly didn't even consider escaping while paused. I'm torn between fixing it and leaving it as an exploit. I'll probably leave it be, cos I've been considering changing the escape sequence into more of a "move the mouse from side to side to escape" so you get to do a bit more than hammer a button.
It's a good idea about pushing players out of walls, but I *think* the collision meshes might not allow that. The easiest way is to detect if the player spawns in a wall then adjust the respawn until it finds somewhere valid to spawn. The issue I keep hitting is reliably detecting what is and isn't a wall. I've got a few ideas, and I'll try to get a fix out in the next bugfix update.
Echoing what Squiggles said-this game runs... Badly To the point that my potato refuses to play it anything resembling reasonable gameplay.
That being said, this looks like a fun game, so I will be following this project! Can't wait for some optimization. :)
I can only apologise. Do the graphics settings not help at all?
I didn't futz with them too hard, but the menu itself was a bit laggy. The gameplay more so.
And don't worry too hard about it! I saw, in the other comment chain, that you're still getting everything in place and in order. Take your time, make a good game. Don't stress about it.
My best suggestion is in the options, the game can auto-detect settings that should work for your computer, though in my experience it seems to select slightly higher than is comfortable. Might be worth a punt.
In this game gonna be impregnation and pregnancy?
No. The game takes place over the course of a couple of days, so there wouldn't be time.
My homie in christ this game is not optimized well at all. If it cant run shadows on low on a 1080 its not going to run.
I know. This is a very early build. 90% of the content in the game will be changing, and will be getting optimisation as the finalised parts go in. The main objective is to get core mechanics and gameplay in, then build up the main content. Diverting time into optimisation of assets that will be removed takes time away from fixing the bugs!