{"id":736,"date":"2024-07-22T22:49:14","date_gmt":"2024-07-22T22:49:14","guid":{"rendered":"https:\/\/abdoubouam.com\/?p=736"},"modified":"2024-07-23T10:43:03","modified_gmt":"2024-07-23T10:43:03","slug":"devlog-week-31","status":"publish","type":"post","link":"https:\/\/abdoubouam.com\/index.php\/2024\/07\/22\/devlog-week-31\/","title":{"rendered":"Devlog Week 31"},"content":{"rendered":"\n

Interaction System V2<\/h2>\n\n\n\n

Most of this week was spent on revamping the interaction system. All 27 unit tests I have for the individual features passed.
I already mentioned this last week, but the reason I changed it is flexibility. Previously, it was an actor Blueprint class, so I either had to make one that has all the functionality I need and use it for everything, or create several types and add code that handles each of them individually. That of course is very cumbersome. I already had 4 classes for different objects : static objects, skeletal meshes, camera that follows you, and spinning ceiling fan, and each of them implement a different interface function.
The new method uses an actor component class instead, which means I can attach it to any actor of any type and it will work. One challenge I had (aside from readapting the code) is how to find actors with interaction. Checking if an actor has an interaction component (using “get component by class” and checking if the return is valid) has some performance concerns, especially if an actor has many components, so instead I made the component add a specific tag (eg. “Interaction_Amenzu”) on BeginPlay, and then I just checked if an actor has that tag instead when needed.
I also modified the old interaction blueprints to add the component and copy settings from the old interaction system variables to the new one, which means all the existing interactive actors work fine with the new system. This only applies to existing actors I didn’t want to modify. New actors will only contain the interaction component.<\/p>\n\n\n\n

I also cleaned up one particularly nasty part of the code. It doesn’t have any positive impact on performance. It’s just easier to maintain and modify. Here’s the before and after.<\/p>\n\n\n\n

\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Before<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
After<\/figcaption><\/figure>\n<\/figure>\n\n\n\n

And a zoomed out overview of the entire interaction system<\/p>\n\n\n

\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Interaction system overview<\/figcaption><\/figure><\/div>\n\n\n

One last change I made was the way branching was handled for “Multi-Choice\/Question” “Go To” and “Go To Milestone”. It was previously using line numbers (eg. “Go To 29<\/em>“), so if I needed to add or remove any line then I had to edit all the line numbers for those. Now it uses label instead (eg. “Go To key_found<\/em>“). I can add and remove and move lines around more freely. It should have been made this way from the beginning, but it’s better late than never.<\/p>\n\n\n\n

“Look at” functionality<\/h2>\n\n\n\n

I wanted to make the flashlight follow the camera, which game me the idea to attach it to the head bone and also make the player character move their head to look in the direction the camera is looking at. The result looks a lot more natural than the player character just standing there and not reacting. I added some lag to it too and adjusted some values until it felt natural. Here you can see it in action (the red sphere is just to help with visualization)<\/p>\n\n\n\n