Open Crystalwarrior opened 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
Keep track of #49
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.
Construct3 Scripting is event driven, and looking at the executed commands individually, design side, is a list. Is clear and minimalist
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?)
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 BlockCell
s.
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.
We cheat, we use the spacer
block cell (which is mandatory and added automatically in all blocks) that indent the block.
We use a PanelContainer+VBox+Scroll for now, we just need to display
Must be reimplemented, manually (oh the pain)
@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.
I want to point the previous design that it had:
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
For now, this is what I've done:
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:
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.
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](https://github.com/AnidemDex/Blockflow/assets/3470436/a4c04a27-5d8e-4bc3-8879-a6fccc43e84c)
^ 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](https://github.com/AnidemDex/Blockflow/assets/3470436/58062182-37b1-4707-82b9-5a1541de0ba6)
^ 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](https://github.com/AnidemDex/Blockflow/assets/3470436/cf9f26fa-5957-4023-b223-b50c75367d8d)
Scratch and Google Blockly:
![BlocklyDemoImage](https://github.com/AnidemDex/Blockflow/assets/3470436/43c959ab-4ae4-4536-953d-c625b41c49c2)
^ 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](https://github.com/AnidemDex/Blockflow/assets/3470436/bbfe6e31-6753-4557-b68b-ba5b083c0459)
^ This one is ancient, though still shows off ways events can be handled. Compiled for reference