Project Roadmap

[AnidemDex]

Project Goal:

Be a visual scripting solution using blocks as their visual representation of functions, using those blocks to determine the application flow.

In case of more context

I wake up one day and wanted to mix scratch, blockly, gdvelop, construct3 and gamemaker visual scripting in a single tool, to integrate whatever what I wanted without much effort to create a game, and ended doing this.

Somehow is also know as Event Sheet Visual Scripting, so we know now.

In order to complete these tasks, I try to follow godotengine/godot-visual-script#27 discussion, using it as base to generate solutions to the points mentioned there.

What's the plan

• Create a system that defines a function in a visual form. These are Commands, single resources that serves as the representation of a function. Those are our blocks.
• Create a system that tracks the blocks relation. These are Collections, a resource that contains commands, and for specifically tracking the relation between those we have CommandCollections.
• Create a system that uses the block representation to execute their behavior and determines the system flow. These are our Processors, specifically CommandProcessor. This node takes a collection of these blocks and executes their functionality, one by one, asking the block itself the next step or determining the next block to use.
• Define a tool to manipulate the previous created systems. This is our editor, specifically BlockflowEditor (under editor/), which is made thinking on editor and runtime scenarios where needed. It works... but just works. Is ugly at my perspective, and some friends have told me that is kinda complex to use, so it is not serving its purpose to be something "easy" to use and understand.
• The system that uses the block representation should have a way to determine when it has to execute something. For now we handle this manually, requesting the user to do CommandProcessor.start(), but the ideal scenario has to remove completely the need to use the script to start the processor. The most simple way would be using signals and boolean values to determine this behavior. See Implement event behavior #149 as a possible solution.
• The block definition has to define a way to do something forward and backwards. This can help in scenarios where users, for some reason, want to go back in the visual code, but don't want to jump to that block, but interpolate between all blocks from point A and B. This is currently implemented partially, where forward is just the normal behavior.
• It must be easy to use. Read it again. And read it again. It must be absurdly easy to use. Easy enough to write full documentation docs but users don't reads them because they just simply figure out by their own how it works without needing to make too much effort. This is probably the most difficult task here, but we should aim to do that (specially me, for some reason I make complex stuff?)

Are we going to generate gdscript?

No, for now we use GDScript to define the functionality, but the flow is determined by the user using the visual tool. In this order, we can't ensure a 1:1 conversion from the visual representation of flow into a single GDScript function, but we ensure a GDScript function representation, which probably saves us and the user from the compilator yelling at us.

We can try to generate a relative for each command block so is easy to teach the relationship, but is not in the plans yet.

Why this issue?

For some reason I've been busy dealing with human things, so I didn't had the opportunity to work in the project as I wanted to do.

This situation forced me to write somewhere what I wanted this plugin to be, so here we are, reading this paragraph. Thank you, human.

I'll keep updating this issue to keep track ideas and some stuff that escapes my brain rn.