-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
General Purpose Data Driven Finite State Machine Plugin #629
Comments
I think I might take a shot at it once I wrap up input map plugin development. |
Would the "general purpose" aspect of this allow the engine to control the scheduler, i.e. conditionally execute systems? Or is this purely for game logic? If the former, I would love to help on the scheduler aspect of things (and really anything that has to do with this) |
Yes in order for this to be user friendly or even possible, we need the ability to add and remove set of systems based on the current state. I am really interested in the idea of providing these add/remove systems api's in Command as mentioned in this discussion #654 (reply in thread). This will make things a lot easier. This tool is mainly for content authoring high-level game/app related stuff eg, ux flow, gameplay, ai, animation fsm...etc. I believe using visual tools for these kinds of high-level game-specific content makes sense. Since maintaining real world projects with large complex flows via code may not be the best way. It is much easier to follow a visual graph than code when it comes to flows. I will be penning down my thoughts and share them with the community first. To see if there are any technical red flags, regarding implementation that may not be feasible. But this is gonna take some time (need to get input map to a state it can be merged with bevy master first). If you are still interested when that happens I would love to have your support on this. |
I am working on an idea. Brahma Overview |
@PradeepKumarRajamanickam I was just thinking that it would be great if we could abstract the FSM and other logic into a crate that could produce some intermediate representation that would be translated to Rust code in a separate stage. Also it would be great to keep the logic separate from the UI. This would abstract both the input ( the UI ) and the output ( the code) so that they could be swapable. My primary motivation for this is that this kind of functionality is something that I would love to integrate into Arsenal. In Arsenal we would be using Blender's node system to power the UI and we would compile not to Rust but to a scripting language, probably either Lua or Python. Therefore we would have a different frontend GUI and a different backend code target, but everything else would probably function the same. |
I was wondering the same thing but I would just provide a serde helper in brahma_graph to serialise/deserialise graph to ron and generate *.rs src only when the user explicitly hits a "compile" button.
You are right there should be a separate glue layer on top. I have updated the diagram have a look. |
Update
|
I think before a fancy visual node-editor statemachine is implemented (I really would want that) I believe Bevy needs a working Finite State Machine implementation that can serve as the building block for many other features. Then later that can be extended to incorporate visual editors. What is the current status of this @PradeepKumarRajamanickam? |
Ludiq Bolt
It would be nice to have a robust, high performance data driven fsm with an easy to use visual editor similar to Ludiq Bolt on Unity. It will move various kinds of control flows out of code and into data.
Benefits
eg, Animation State Machine, AI FSM, UX State Graph
The text was updated successfully, but these errors were encountered: