This is more for LGM/RadialGM.
One of the sore points of GM is that visual scripting capability is seriously limited, compared to tools like those by Clickteam or Game Develop. I know about GML/EDL but what I'm saying is that users should have a choice whether they want to use visual or textual scripting. Without any proper VS solution, the choice is virtually non-existent.
What I'm proposing is to base visual scripting on node-like structure (if anyone of you had ever used Jeskola Buzz, Psycle or SunVox should roughly know what I mean). Separate "modules" (aside of few built-in ones) could be coded in EDL and would come in two varietes:
- Events - basically work like "if" instruction and execute any action nodes (see below) that are connected to it when conditions are met. Event modules can be negated to make the condition they are supposed to evaluate be opposite (like adding ! in front of boolean expression)
- Actions - what to do when it is executed by event block.
There will also be some special "event" blocks that will be in always present in every visual script. Such as:
FrameStart - fires at start of every frame
FrameEnd - fires at end of each frame
Continuous - fires as fast as it can (no synch to framerate).
RoomStart - fires when room starts
RoomEnd - fires when room ends.
Ok. So how it would be processed?
Let suppose we have this simple workflow ([EV] means event block, [AC] means action block)
[EV]FrameStart->[EV]Player presses space && Mario can jump-> [AC]Mario.jump ->[EV]Mario is in water (negated)->[AC]Mario.allowjump==false
Yes I know handling input in synch with framerate is bad idea. Shut up, this is an example.
What happens here is that at start of frame activation signal is send to event block that checks if Mario can jump and if player presses space. If it is met, Mario jumps. Then, AFTER jump action is executed, signal goes to event block that checks if Mario is in water(where he can jump infinitely) and if Mario isn't in water (as condition is negated), allowJump property for Mario is set to false (this is property that is evaluated "under the hood" for Mario can Jump module) so he can't do multiple jumps.
Of course you can link event module to multiple action/event modules:
[AC]Play musicIn such case all connected blocks/modules will be executed at once (or so fast that it would seem like at once).
[EV]RoomStart -> [AC]Put player at start
[EV]Player collide with enemy -> [AC]Remove any colliding enemy at start so player won't get insta-death
If we have such setup:
[EV]Some event \
[EV]Some event 2 /
"Some Action" will be executed if either of events will be true.
Of course modules will be able to be shared between users.
During compilation, visual code will be compiled into EDL.