Catch me on twitter
Another solution to some of the Actor Behavior issues is working out the scripting system. For some reason, I’m okay with a data solution being to pretty much “hardcode” game object behavior - but that’s cause it’s script… script is data! I’ve already integrated MoonSharp into the project, and it looks quite easy to setup - so another “relatively soon” move should probably be to get some simple scripting working.
What will you script though? Props / Actors could be fully scriptable. A Lua table defines what frames to use in the sprite animation (this begs the question, how do we access sprites already in the project, can we load external sprites?), defines what behaviors to include (built-in + require more script ones by name), and then each behavior’s properties can also be setup for whatever params they require.
The Actor Behavior System is the crux of every object in the game currently. I wrote it to be super flexible and open-ended, while also trying to keep it within a minimal scope - I know, aren’t we all? The way it currently works is that each behavior is a descendant of the base ActorBehavior class, and they all override
Execute(ActorCommand command) - checking if its a command they own on themself (ActorCommands are Scriptables).
The amount of Behaviors is growing larger than I thought it would though and this structure is becoming a bit unwieldy. I think rather than handling it this way, each Behavior should pair up a command with a UnityEvent for what function to call when that command fires. A CommandDispatcher Class would have to then live as part of each Actor (maybe it’s part of the actor itself, rather than an additional class). The BehaviorType flags are also becoming somewhat questionable so I think maybe nixing those in favor of filtering by Commands.