Devlog Week 30

This is a slow week in terms of actual game art and development.

I spent some time getting approved on steam and preparing promotional content, only to realize I cannot publish demos alone without a full game. It’s a bit disappointing, but I got the game published on itch.io. You can get a free copy from the following link : https://abdoubouam.itch.io/amenzu-demo

As for development, I decided to rework the interaction system, specifically the way interactive objects/NPCs are made. Previously, I used a custom actor with an interface, but it proved inflexible and limited, for example the cameras that follow the player only supported the very basic dialog feature.

The new system is an actor component which can be attached to any kind of actor. One limitation was the lack of support for interface functions, but I worked around this by making the component add a specific tag (eg “Amenzu_Interactive_Object”) to any actor it’s attached to. This way, when I get a list of overlapping actors, I can filter out all non-interactive objects without having to do any manual work.

I also edited the overlap detection. Previously it was a sphere collision on every interactive object, but now it’s a sphere collision in front of the player character instead. This has the downside of not having a customizable per-object interaction radius, but the advantage of that is that the collision shape is customizable, which is particularly useful for large objects.

Interacting with an object now follows the player character angle, and not the camera.

One issue I had with the previous system is dealing with multiple objects being within interaction range. It previously picked the first one that satisfied all conditions (close enough + camera is looking in its direction), which resulted in sometimes picking the wrong object.

The new implementation gets a list of all overlapping actors that generate overlaps and have the specific tag, then gives each of them a score based on distance and angle. The closer an object is, the higher its score. Similarly, the smaller the angle difference between the player character and the object (aka if it’s facing the player character) the higher the score. The two scores are then combined, and the object with the highest score will be highlighted.
I gave a multiplier of 75 to the distance and 50 to the angle. The values are picked based on test scenarios and what felt natural.

I started the distance score falloff from 100cm, because I felt like that’s a reasonable distance from the player character to interact with objects and NPCs, so I didn’t want to “reward” getting closer.

The results felt significantly better, more predictable and more consistent.

I also added an importance multiplier, to make objects that are more important take priority over other objects.

In the example below, the monitor has a lower distance score, and a slightly higher angle score than the radio in front of it. The overall score is still lower than the radio, so that one is picked instead. In the case I want to give the monitor more importance, I can give it an importance multiplier that’s higher than 1, which makes it proportionally more likely to be picked over other objects.

I am still working on porting all the interaction features from the previous system to the new one. What will take a significant amount of time is the way data is read and stored, because previously it went through an interface function, and now it should be obtained from a child component. It shouldn’t be hard though, just a bit time consuming. I’ll work on it this week.

That will be it, thanks for reading, and I hope to see you again next week!

Leave a Reply

Your email address will not be published. Required fields are marked *