Chaining existing methods together and storing them in a dictionary

Hi I've been struggling for weeks now implementing a simple way to chain together methods that already exist in the project.
Doing so is no problem in code but since I'm gonna create potentially hundreds of these, having a huge script with all the method combinations the game will ever use is far from ideal.

So I looked into a way to select methods from a drop down menu in the inspector and made it work quite successfully after 3 weeks of banging my head against the wall learning about serialialization, how unity does it, how to do it to methods using reflection and learning how custom inspectors work. It's still not quite working though since I also need an extra drop down menu for all the types in the project to filter out the methods to pick from.
Assuming this will work I have to save these "methodChains" somehow.
I jumped to scriptable objects as the obvious choice but I hit the 10th wall which is that generic scriptable objects aren't allowed and I need those type informations to inform the method's possible parameter and/or return types.
I took a break and then looked into Unity's new visual scripting system (Bolt) which is a fantastic way of connecting already existing methods together and adding some logic to it as well. It's amazing for high level programming. But obviously I hit a wall which is Bolt only runs its graph logic in a special Bolt component linked to a gameobject in the scene which again isn't ideal.

So while I go crazy looking for ways to do this somewhat basic thing I'd like to know what your solutions have been. I assume you at one point had to create a dictionary of basic events using the game's already existing functions. How did you serialize them and store it? I'm so exhausted

 

Here's a way to use ScriptableObjects to create a list of behaviors... I made a base

Act

that has a

DoYourThing()

virtual function, then derived an

ActHappy

and an

ActCrazy

ScriptableObject from each.

I made 2 happies and 2 crazies, with different

quantity

values (so four total different behaviors), dragged them into a list in a TestScript in a scene and "ran them" at runtime.

It's one approach, fairly generic and extensible, and you could have all kinds of base acts, such as "Attack" or "Debuff" or "Resurrect" and then implement them below that.

Or you can make a single completely generic act and implement a bunch of things for it to possibly do, and throw not implemented exceptions at the base class. Or even have a function that gives back a list of all the things it can do in some kind of dictionary?

See fully-functional example in enclosed package.

 

@Kurt-Dekker That's a really cool way of using SO's. My problem is that my implementation can't really have any base, rules or restrictions since I'd like to use it during random events or cutscenes where I just want very distinct things to happen that won't really repeat, so it makes little sense to create a system around something that doesn't happen regularly. A quick example is that I give a character an item, I want the character to say a specific thing then I want him to drop the item and walk away. It's not really a repeating behaviour and I want the freedom to easily create "unique" scripted occurrences like that, easily by just referencing my already existing bulk of functions.