So the final devlog on interactivity, and it’s time to focus on the two that manage to single handedly break the project whenever I even look at the system, Static objects and Attached Items.

Static objects in a weird and infrequent part of the game, as for the most part you can pick up, throw, and drop objects wherever you feel like it. This works fine for the open world areas, but presented problems in the car journey segments, where important items often dropped through the floors and disappeared, or were left behind by the car.

To solve this, I had to create a different form of interactable that could still be picked up, rotated etc, but would also return to a specific position when dropped, as opposed to being manually placed. Logically this was simple, just have the object become kinematic and slerp back to its location when dropped, but there was also the issue of changing parents, altering the interaction systems expectations, and a few other gremlin areas that made it slightly more difficult than it should have been.

The final result was effective though and allowed the player to still have objects they could play with or use in the car, without having the objects constantly glitch or break based on unity’s physics.

Attached items were something I had always intended to have in the game, as they tend to be a core elements of horror gameplay. To clarify by attached items I mean objects that are hidden on other objects, and can only be discovered by rotating the parent, e.g. rotating a statue to find a key. Sometimes this was necessary for puzzle elements, other times it was purely diegetic to the environment, but it felt like an important feature to have.

As my interaction system was primarily using raycasts to detect what it could interact with, a problem immediately arose where the system struggled to differentiate between the host object and the attached item, as each would block the other in turn from detection.

One of the flaws in the old interaction system was that the item you were holding wasn’t stored and could only be interacted with if the ray was still hitting it, creating scenarios where the object might shift slightly, and therefore never be droppable. To circumvent this issue I instead relied on the attached item to tell the player when it could be taken, using a long collider on the attached item to collide with the player when the player had rotated it to a correct angle, triggering a bool that allowed it to be picked up. The attached item would then float towards the player and destroy itself, marking the appropriate collection script that it had been received.

This system is still in place, despite the ray casting no longer being an issue, as it is relatively low cost and proved very effective, but there is definitely room for improvement down the line.

So there we go, that’s all the interaction systems covered in some form or another, phew that took longer than I thought.

Starting next week I think it’s time we began looking at the monster, and how the Ai was constructed with the goal of making an aggressive creature that could use some tactical elements.

Until next time, thanks for tuning in!

Nick

If you want to come discuss the game, have a general chat, or reminisce about Captive Audience, why not join our discord or Facebook pages, or follow us on twitter for more news!

Discord: https://discord.gg/bhgXgH

Facebook: https://www.facebook.com/ItWillFindYou/

Twitter: https://twitter.com/HeraldofLoco