Basic state machine where a node contains an event sheet #2357
Replies: 4 comments
-
|
It is a mix of nodes (aka blueprints) and the FSM that @Silver-Streak talks about. (Forum 1, Wiki) |
Beta Was this translation helpful? Give feedback.
-
I recall also this interesting thread on the forum:
I think this hits the right thing: events sheet are good for allowing to express logic which is similar to usual code, while node based system are useful for finite state machines/transition/animations - basically anything that has transitions between states. But it's not working well at almost everything else :) Which is a good thing for GDevelop, because this means that right now we have a system that is very good as expressing most things (i.e: most of what code can be used for), but not great for things transitioning to one state to another. One thing that is important to understand: I don't believe this kind of new feature would simplify things for beginners - it's actually making GDevelop more complex. So we have to be careful how we surface this. I imagine we could make a "state-transition node editor", which would allow you to make a graph of nodes, with transitions (i.e: a FSM editor). Then you could use it in events, hooking it to event group (for "global" transitions like the state of a level) or hooking it to an object (for object related transitions, like transitions between hit/run/walk/etc... animations). |
Beta Was this translation helpful? Give feedback.
-
|
As both of the forum posts are basically mine or come from discussions with me: Yes, I strongly feel there would be great benefit to the community if there was an easier way to visualize FSMs in GDevelop. I think having a way to do state machines more cleanly in GDevelop could be a great feature even if it seems more advanced at first. I wonder if it would be best to have it as an option that has to be linked to objects, like a behavior. So just like you have the behaviors tab on objects, you could also have a State Machine tab? Otherwise using links just like external events makes sense to me, too. What's interesting is that if we have state machine 'support" (more easily visualized/implemented), it would actually help some people migrate to GDevelop from something like Unity. Playmaker is REALLY big in Unity (Hollow Knight was made with it), and it's entirely state machine based. I know people that hate using Unity due to it's content pipeline and general footprint, but can't find anything else that lets them make games like Playmaker does (no code, state machine focused). GDevelop having a way to replicate some of that would make the transition easier for them. |
Beta Was this translation helpful? Give feedback.
-
|
well in terms of an event sheet way of doing it, I tend to keep the state in a string variable. Then do if check block for each state and nest the logic for that state beneath it. Its not a big deal, but still hard to overlook how much simpler it is when you put that stuff in a node structure, even one as poorly done as the one in pixel game maker mv. I notice that godot users have been implementing different state machine addons. Godot itself also has a built in node approach to state for animation trees, which greatly simplifies implementing complex character controllers. Could be worth investigating those. In any case we should think carefully what this would do and how it would be used, before trying to make anything. Godot has a visual programming material editor that uses nodes too - it works for 2d filters too. A node interface can be useful in many different ways. This node programming is really bad when it goes granular though. Its what makes it terrible in godot and unreal too - we should be careful about not trying to reimplement the event sheet in the form of blueprints too much. So maybe something that sits as an abstraction above the event sheet and is optional? It would be fantastic for transitions - between object states and even game scenes |
Beta Was this translation helpful? Give feedback.
-
BEFORE opening a new feature request, please make sure that you:
AFTER opening the feature request, the issue will be closed by a maintainer (@4ian or someone else) and a card will be added in the roadmap if it's relevant and does not exist yet :)
Description
So I have been thinking about this and wonder if a state machine like visual programming interface can work well with event sheets.
Basically there are two camps where developers opt for one visual programming or the other. Godot and Unity3d and Unreal use blueprints - which is kind of like what yarn does - you create a bunch of nodes and connect them logically with arrows.
This is absolutely great for enemy and player behaviours, especially for complex ones as it better represents the different states of an entity and the way it jumps from one state to another. Great! But if you go and try using it for more granular logic that is for example in creating and altering variables, doing math operations- the even sheet completely wins there. The reason - going granular with blueprints may easily lead to a spaghetti nightmare!
So we have this great event sheet and a bunch of people that would always swear to blueprints. What if we take the best of both worlds? We have some sort of a blueprint programming that lets you set up a state machine easily. But for the granular stuff we use the event sheets?
Solution suggested
So imagine you have a blueprint editor-much like unreal and godot. But in it - a node is something different. A node is just a container for three things:
That way for example you can set up a more complex player or enemy behaviour where the entity changes state based on player input and what happens to it (collisions with other things, etc). Each state/node is a different event sheet where things are happening to the entity. That event sheet can be visited from a different one or may be deactivated to visit a different one (that part being handled by "links" - taking in only conditions)
Alternatives considered
This idea came to me after looking at pixel game maker mv.
https://youtu.be/mzL91RAHIbg?t=1818
They seem to have gotten to something really basic there, but with a poorly implemented interface (I think we have foundations for much better).
The Nodes there are kind of like event sheet containers. The inputs and outpults are called links (the lines between nodes) and they take in conditions to leave a node and go to another one. The nodes themselves contain what we think of as actions to execute - but in our case we can be using an event sheet with both actions and conditions in it (much more granular)
Anyways, just food for thought. What do you guys think? Am I a raving lunatic thinking this could work? :)
Beta Was this translation helpful? Give feedback.
All reactions