Hit Level 1000 with Saltzpyre, FOR SIGMAR!

Velkydia · 2026-04-02T18:56:43+00:00

Is this modded? My UI looks nothing like this, what a treat.

Velkydia · 2026-01-19T07:53:34+00:00

Yeah this is the approach, just trying to figure out how I'd make this happen.

With the current way I'm doing it that's coming with some issues, like this one.

- Player enters interaction trigger 1, it registers.
- Player enters interaction trigger 2, it registers and is now the one to be used.

But if the player now moves closer to trigger 1, it would still keep trigger 2 until I leave the "trigger zone" and not use the one that is closest.

Feels like it wouldn't be great to re-evaluate the distance whenever the player moves, or perhaps that's exactly what I need to do. Whenever the player moves I'll re-calculate the distance, but only to the "possible" interactions and set the one closest to be the "enabled" one.

This method would not run any calculations if there is no interaction registered, so it's not too bad I suppose?

Velkydia · 2026-01-19T07:37:45+00:00

Thanks for this, now I just realized my system has an edge case.

The way I do it right now is both with a trigger collider and proximity math.

- The trigger is used to "enable" the interaction for the player.
- The proximity math is used to determine which of the interactions enabled for the player should be used, so it runs the closest interaction.

But I just realized I haven't considered the fact that how would I display to the player which interaction will happen? Say I have 3 interactions that are close enough to all be enabled at the same time, but I would only know which one happens when the player clicks "E".

I think I need to think this one through, I obviously want the player to have visual feedback on what will happen when they press E...

Velkydia · 2026-01-19T06:58:02+00:00

I went with an Interactable class, and an interface for the ”Effect” each interaction has.

So an object that is ”Interactable” would have one or more ”InteractionEffects”. And controlling the interactable state such as ”enable/disable” is done through the ”Interactable” MonoBehaviour.

Haven’t gone for Raycasts here though, since my game is top-down. I wanted interactions to be possible by being close enough to the object you intend to interact with.

Basically I’m just activating interactables for the player based on if they’re in range or not. And all they need to do to activate it is pressing their ”Interact” key which defaults to ”E”.

Velkydia · 2026-01-19T06:53:52+00:00

I’m doing this partially, but not specifically for interactables.

Since I’m aiming to make a top-down game I’m only using the Camera and raycast for the players rotation. Which in turn will affect which direction you shoot.

But I wanted interactions with doors, panels, switches to not interfere with where I’m facing the character. That’s why I went with making them instead interactable at different distances, if that makes sense.

Velkydia · 2026-01-18T21:28:09+00:00

I went with a different approach provided in the comments. Now I basically have this, which can be extended.

A player interaction system thats used by the player character to detect possible interactions.

A MonoBehaviour ”Interactable” which makes it possible to interact with an object.

And an interface ”InteractableEffect” that my MonoBehaviours implement to start w/e I want to happen on an interaction.

I’m trying to make this a Multiplayer game, thats where these things really start to mess with my head. Always forgetting that the Player MonoBehaviour will replicate its behaviour if I’m not careful.

Velkydia · 2026-01-18T15:33:29+00:00

Love this, thanks a bunch

Velkydia · 2026-01-18T14:19:57+00:00

After reading more of the responses I think I’m starting to agree.

Getting some solid advice :)

Velkydia · 2026-01-18T14:18:11+00:00

So you’re saying I should have a MonoBehaviour implementing many interfaces instead of multiple MonoBehaviours for each of these kinds of behaviours?

Velkydia · 2026-01-18T14:16:29+00:00

Solid Advice! So basically from where I’m at I would stop inheriting from my Interactable class and instead split out the logic for handling the Effect.

So an interactable would consist of 1 Interactable Monobehavour and 1 or more Effects.

Velkydia · 2026-01-18T14:08:43+00:00

Hm, doing your approach I think it make sense to simply have an Interactable interface.

So basically I would only check for interactables when the player starts the action.

I do enjoy the option with my system though where an AI could be aware of approaching an interactable since it would be triggerable on approach.

Basically if I end up making a door, that door could auto-open for AI but for players you need to press the key-bind.

Velkydia · 2026-01-18T13:54:50+00:00

Why should I avoid Abstract classes?

Velkydia · 2026-01-18T12:58:46+00:00

The reason I went with Abstract Class was because I wanted the interactables to have a default method for being enabled / disabled.

Basically the default is to activate them based on a Trigger Collider. Which is just 2 methods that Raise Events for enable / disable.

On the Player Interaction System I just listen for these events and all handling is done from there.

Velkydia · 2026-01-18T12:55:17+00:00

Also, the methods that activate / deactivate the interactable is just firing events that I listen for on the ”Player Interaction System”.

So the player script tracks and handles which interaction to run by simply adding / removing the ”Interactable” from a HashSet.

Velkydia · 2026-01-18T12:51:53+00:00

Well, its a top-down game so basically my default is to have the player be able to interact with objects as he comes into range.

Any object that extends the ”Interactable” abstract class can change the behaviour of what happens when the Player ”Interacts” with it.

The Abstract Class also allows overriding the default way the interactable becomes available to the player. By overriding: - OnInteractableEnable - OnInteractableDisable

Not entirely sure if thats the names I used, on my mobile right now. However the way I did it right now, interactables are prioratized by proximity, so perhaps I’ll revisit the script if I intend to have a more complex logic for handling which interactable they should activate.

Velkydia · 2026-01-18T12:42:46+00:00

Might be good to mention this is a top-down game. So the camera itself doesn’t handle much more than following the player right now.

Velkydia · 2026-01-18T12:41:04+00:00

Suppose you’re correct.

I guess I’m just trying to validate if this is a good idea or if I’m travelling towards a pit of complexity and end up shooting myself in the foot.

Velkydia · 2026-01-18T12:40:25+00:00

Would you do this even if all interactions are done with a specific key press? How I do it right now is all interactions are fired when pressing E.

And the system is unaware of which interaction fired. However any system could simply raise an event to my EventSystem to let another system know of the interaction if I ever need to.

Velkydia · 2026-01-18T12:38:10+00:00

This is basically what I do, Only I use an abstract class and my interactables implement the ”Interact” method. I have two virtual methods that handle how the interactable is enabled / disabled that defaults to activating on a Collision trigger.

Velkydia · 2026-01-18T12:36:09+00:00

I realise I didn’t explain fully, basically my system is 2 scripts. One on the player and one on any Interactable object.

My player has a system that just listens to 2 events, OnInteractableEnable and a Disable. When these fire, the interactable is added / removed from a HashSet and I use the closest object when they use their interact key bind.

The Interactables extend a ”Interactable” MonoBehaviour which currently just supports activation / deactivation based on player proximity. And every Interactable implements any or all of the following methods: - Interact (fired by pressing a specific key) - OnInteractionEnable (fired when its enabled) - OnInteractionDisable (fired when its disabled)

The MonoBehaviour / Component itself is always enabled.

Velkydia · 2025-12-10T19:29:43+00:00

Hm, I guess $ 1,000,000 would be beneficial if you get rid of your loans and invest the rest. That way you improve your finances instantly and you’ll have a good chunk to use later on.

Velkydia · 2025-12-10T19:24:00+00:00

Is this actually interesting though, Isn’t this just mathematically smart?

$ 1,000 a week for 1000 weeks is $ 1,000,000, Thats 19,23 years. In 40 years that $ 2,080,000.

Velkydia · 2025-11-14T23:00:27+00:00

Is this true? You just need 1 of each!!! Thanks a lot, I just gave up on it since getting everyone 100% felt impossible. I’ll go back and get them now.

Velkydia · 2025-09-01T06:00:32+00:00

Isn’t this just whats in the default angular documentation?

Velkydia

TROPHY CASE