I've been thinking a lot about how I want to approach the design for interactive objects in my 2D Platformer. I wanted to do something lightweight and centralised so I started work on an Event Class that embodied anything that would be interacted with. The type of interaction would be defined in the Unity Editor though a Custom GUI that I am working on.

As you can see, this "event" would be for a moving platform. If "Is Triggered" is ticked, the Platform moves only when the player jumps onto it and activates it. Otherwise it will interpolate between the definable "Start Position" and "End Position". Depending on which "Event" (enum) is selected, the Editor properties will change and so will the behaviour of the Game Object with the event attached to it. For example, selecting "Item Collect" would mean that the Game Object is no longer a platform - no longer an object that moves when activated - it would be a stationary sprite that, when activated, would disappear and add itself into the player Inventory.

Here's some code to show where I'm at with it:

/* 
* #############################
* ##@@## INITIALIZATION ##@@##
* #############################
* 
*/

    private void Awake()
    {
        SetupEvent(eventType);
    }

    public void Activate(bool calledFromTrigger = false)
    {
        if (autoTrigger && !calledFromTrigger)
            return;

        Debug.Log("Activated " + name + "!");
        StartEvent(eventType);

        
            
    }

    private void StartEvent(EventType type)
    {
        switch (type)
        {
            case EventType.Movement:
                MovePlatform();
                break;
            case EventType.Dialogue:
                break;
            case EventType.NPC:
                break;
            case EventType.ItemCollect:
                break;
            case EventType.Cutscene:
                break;
            case EventType.Switch:
                break;
            case EventType.Custom:
                break;
        }
    

Don't be deceived by the snippet - this is all quite functional as of right now, but I can't help but feel I am making a mistake.

I keep having this gut wrenching feeling pulling me to scrap it and rewrite the "Event" class to be a base class of "Interactible" and for each type, or what is currently an enum, to be a child of Interactible.

Essentially, I am not sure whether to base my events off of one Event class, with functionality dependent on the selected "Event Type" enum... Or have the "Event Types" span multiple classes inheriting from a base "Interactible" class. I like to be able to just drag and drop, select what I want all in one place - but I feel that this is entirely impractical due to its low level of abstraction and code being all in one spot.

Can I get some opinions? I am a relatively beginner programmer but I know code decent enough to be able to use more advanced techniques I think. Here is a screenshot of my game for context.

The first thing to note is that the word 'event' in Unity/C# already has 2 existing meanings:

1. Unity's own 'Event' system - https://unity3d.com/learn/tutorials/topics/scripting/events

2. C#'s 'event' keyword - https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/events/

These are both for a slightly lower-level concept - the idea that you can register a bunch of functions with an event, and when you trigger (or 'invoke') the event, it calls all the functions. But you might consider whether you can write your system in terms of one of these. For example, instead of having a StartEvent call which has to examine the type and then have a switch statement call a specific function based on that type, you can register these functions (such as MovePlatform) with the event, then when you call invoke on the event, the platform will move (or whatever).

You might want the movement capability (stand/end position, speed, etc) to be in a separate component or object, so that the event part only deals with the "if X happens, do Y" section. You have a bunch of different event side-effects, from moving platforms to cutscenes and item collection, so I don't think it makes sense to either wedge them all into an event class or to pretend they're all some sort of 'Interactible'. All they have in common is that they happen when something else happens first, and a fairly decoupled event system like the 2 described above are probably adequate choices here.