Logic Driver - Easily Design Gameplay Systems with State Machines

[Recursoft]

@CRYOMEN

Thank you for your reply. I made a deep analysis. Seems like SMachines is a developer oriented solution. Using this for dialogues would be overkill, as it does not allow to extend States/Transition functionality. As long as showing dialog sentences is a repeatable procedure one should copy/paste same code in the States, instead of creating a specific State for the dialogues, reuse it, and allow to change it’s settings (character name, sentence, etc) without a code manipulation.

Just in case. You said local variables are in development. Please could you consider to implement that in such way:

• Expose State instance. That would be great to have it. It should give access to local variable anyway - right?
• If you expose State instance, would you allow to create custom States, with a custom functionality? Basically instead of placing all code usual way through the States Machine editor, one could implement this using a blueprint. And then select custom State in the State Machine Editor (similar to “Add State Machine Reference…”). This will catch several rabbits: it will allow private variables and functions. Will make it artist friendly, t.e. developer creates a custom State nodes with extra options for artist to select in the Details window.
• Same idea for Transitions. Expose Transition instance. Allow local variables and functions. But this guy seems more tricky, t.e. how we gonna select a custom Transition from the list?

Seems lots work to me. But should you grab it on board that would be awesome.

So ideally… developer creates New State Class (or New Transition Class) blueprints.

In a state machine blueprint be able to set the state or transition to the created classes. Possibly similar to state machine references. Then be able to set instance values in the details window of each state or transition. And to be clear, you only need instance variables to change, and not the BP logic itself, correct? I ask because that would be extremely difficult.

If I have that right, I’ll consider ways of implementing this (or parts of it). I don’t want to commit to anything yet because you’re right in that the work to do this isn’t trivial and multiple problems would have to be solved like passing the context (and using it from within each state or transition), replication settings, etc. It might be better to see if I can enhance state machine references to set instance values in the details window and then use those as states.

Also in case it helps, inheritance works for state machines now. You can have a base state machine class with variables and functions, and use those in a child state machine class. Additionally with state machine references you can enable an intermediate graph and set properties of the reference there. All though that is done in a BP graph and not the details window. I’m also not sure how well that will work if you have the same reference multiple times on the same graph.

But to your first point, this is likely overkill for dialogue systems. I know there are plenty of dialogue editors on the market. Awhile ago I started working on a dialogue system based on logic driver. A blueprint editor where each node is actually a BP graph to construct a dialogue sentence, auto constructed from text or user created. Definitely have me consider working on it again, as a separate plugin or maybe including it in logic driver. I could see mixing state logic with dialogues being handy.