AnidemDex / Blockflow

📜 A visual language to make games in Godot 4 🎮
MIT License
79 stars 6 forks source link

Create our own CommandTree UI #92

Open Crystalwarrior opened 8 months ago

Crystalwarrior commented 8 months ago

Godot's Tree control node is kind of bad. Really bad. Text overflow is bugged thanks to the existence of icons, buttons or both. The outline is rendered incorrectly. There's no way to adjust the width of each column without some hacky shenanigans. And there's just a lot of unnecessary limitations like being unable to acquire the buttons the Tree is clearly using, and only being limited to mouse clicks and not mouse drag etc.

Godot_v4 1 3-stable_win64_NMuP3W14A4

The Tree control node in the current build did allow us to focus hard on functionality, make the inspector view robust, improve drag&drop and understand the flaws with our program UX-wise. However, it seems like we'll have to create our own view just for the commands, taking the best of the Tree view and looking at its source code whenever we're stuck, while also improving it in such a way that we can cram a lot more in each command while also visually distinguishing it all better.

For reference we can learn from there's Dialogic UI: image

^ This isn't perfect, for example the rows aren't as clearly defined and there's some weirdness going on in the 2nd choice. It's also odd how the Text has choices as its children and the relationship lines are not entirely clear. But the ability to modify properties directly in the editor without using the inspector is a plus.

aaonline.fr: image

^ The ability to embed scenes into the command view, and let the user edit their dialogue while seeing it exactly how it'd look like when within their text box of choice would be a huge improvement. Ability to use markdown/bbcode and auto-process it as you edit would also go a long way into improving program usability as the user will not have to learn markdown and other syntax just to make text be bold. However, this interface isn't perfect as it makes the dialog command responsible for far too much. Here's a mockup of an edited-down essentials: image

Scratch and Google Blockly: image BlocklyDemoImage

^ These are taught to and used by children, so simplicity and ease of understanding of the relationship between blocks etc. is essential. There's still some caveats for our use cases (where do you even fit previews?) but it's an important consideration to see what they do well and what we can replicate.

Game Maker 8 Events: form_control_actions

f0010-01

^ This one is ancient, though still shows off ways events can be handled. Compiled for reference

AnidemDex commented 8 months ago

We have to set exactly which things from each examples we want/need in the displayer. The current displayer was made to simplify the usage and keep consistent between editor and game, but the more we used it, the more things we started to notice that it lacks

AnidemDex commented 7 months ago

Keep track of #49

AnidemDex commented 7 months ago

106 is related aswell

Richard-Oz commented 5 months ago

I personally think you are doing a great job, scratch for me was helpful initially. If I may make a suggestion, the event system in Construct 3 is the one that managed to make me understand how programming works, it is really simple and intuitive.

AnidemDex commented 5 months ago

hero2.png

Construct3 Scripting is event driven, and looking at the executed commands individually, design side, is a list. Is clear and minimalist

AnidemDex commented 5 months ago

Forgot to mention https://github.com/godotengine/godot-visual-script/issues/27 which is a very good source of designs for event driven editors and code logic (how many times have I mentioned it in other places now?)

AnidemDex commented 5 months ago

Since Tree is too complex, I tried to keep the main features that we use of it: the tree view and the column (cell) separation, and after a few draws I ended with this: a "block" node composed of "cells", formally a CommandBlock.

The command block will be a custom container that sort their child BlockCells.

BlockCell will be something similar to a PanelContainer and users can add many as they want, the command will define a function to define the command block generic so users must override that function if they want custom blocks.

Blockflow workflow-Page-2 drawio

How indentation will work?

We cheat, we use the spacer block cell (which is mandatory and added automatically in all blocks) that indent the block.

How are they gonna be displayed?

We use a PanelContainer+VBox+Scroll for now, we just need to display

What about drag&drop

Must be reimplemented, manually (oh the pain)

Crystalwarrior commented 5 months ago

@AnidemDex good stuff, good start! We replicate what we already have but with more control and that will give us the necessary tools to improve and expand on it.

AnidemDex commented 2 months ago

I want to point the previous design that it had: image

Crystalwarrior commented 2 months ago

I want to point the previous design that it had

I actually want to bring back the color coding strip for the command buttons, that was a good idea

AnidemDex commented 2 months ago

For now, this is what I've done: image

image

Red is the block node, yellow is a block cell with the icon added to it, blue is another block cell with command name and green is the arbitrary content that user may add with more block cells.

This is the node structure: image