Herman Pettersson
Aspiring Gameplay- And Systems Designer
Cosmic Repair Duo
A cozy 2 player co-op puzzle game made in 7 weeks in a team of 13 people.
Systems & Technical Designer
Interactable Widget Systen
Sublevel Load System
Coin Pickup System
Implement Character Animations
"Interactable" Widget
Interactables Widget System
Shows text based on distance
Scalable for any number of local players
This is the first time I've been able to make a system completely on my own during a group project and I am very happy with the outcome, but it certainly came with a set of challenges.We made a game with local co-op split-screen. The first iteration of the system had the widgets created by the interactable actors, but this caused unforseen issues.The icon indicating if something is interactable was meant to only be shown on the POV of the player in proximity. This did not work as intended because the widget showed up on both players' screens, ignoring proximity.This caused confusion for the players. They could see the icon through walls and even if it was 100m away. It cluttered the screen and there was also no limit on how many widgets could be visible at once.Another issue was how the widgets were activated. Using a simple trigger that checks for the player class meant that the widget could be turned off even if a player was close by, simply by the other player walking in and out of the trigger.I realized that I had to start over from scratch, starting with finding a way to only show the widget on one players' screen.I did this by moving the widgets from things in the world, to being spawned by each player. This made it much easier to only show the widget on one players' screen by only being visible to the player that spawned the widget. This immediately solved the proximity issue.It also solved the clutter issue, because this limited the amount of widgets on a players' screen down to 1. It only shows the closest interactable, no matter how many there are, because the player only spawns 1 widget.Since the group project finished, I've gone back to optimize the code and also make it into a plugin for future projects. If you wish to see that progress you can click on the buttons below.
Cosmic Repair Duo
In-depth about the system
I went through numerous iterations before I found this current system.This iteration of the system is one that can be modified to fit the needs of different situations.Each interactable actor has a specific child actor blueprint. This actor is what the widget uses as a reference for its location relative to the interactable actor parent. The spawned actor also uses an enumerator that is set up to show different text, depending on which interactable actor spawned it.Below is the code I've written, all code shown is in the Player Character Blueprint running off of tick. Further down I will show an updated version that is further optimized.
Each player spawns two widgets on beginplay. They are never shown at the same time and are used to differentiate between the distance to the interactable actor.On player Event Tick, Sphere Overlap Actors is used to check for the spawned empty child as a reference for the widgets. If it returns false, both widgets are set to be invisible.If it is true, a distance check is done to see whether the current closest actor referenced is still the closest to the player, or if another actor is closer.The system is set up to only show the widget on the closest actor.. This is not only to limit the number of widgets that each player spawns, but also to reduce clutter on the screen as there is already a lot going on at once.When the closest spawned actor is determined, a line trace is done to check whether the spawned actor is within view or if it is obstructed by something like a wall for example. If it is obstructed, the widgets are set to be invisible.In the previous iteration there was a lot of code that was running on tick for no reason, such as the set visible nodes. In the code posted below that has been fixed with boolean checks.
Cosmic Repair Duo
Making it a plugin
I was pretty happy with the result of the optimization I did, but I still encountered issues when trying to export the system to other projects. This was partly due to the fact that blueprints can't be exported to older versions of unreal engine because there is no backwards compatability.Because of this I had to copy-paste all the code manually into an older project and manually set up all the variables again. It worked, but I didn't want to do this again.This lead me to the idea of making it into a plugin, something I've never done before.By going through the process of setting up this system as a plugin, I noticed things that I thought were modular, that still required me to change variables in more than 1 location.One example is the text that is displayed on the "interactable" widget. I previously used an enumerator to set up different text alternatives, but this required me to change the text in multiple locations when adding new text to display.First, add the new text to the enumerator. Second, add a new output from the switch in the "setText" function. To optimize this, I removed the enumerator completely and send text directly instead, allowing anybody to set the display text immediately when setting the actor.During this process I also set up the plugin to be usable for online play, not using the player index to get player controller.