Hello all,
I would like to propose a revamp for the events editor.
Why a revamp?
Because of two simple reasons, complexity and management. In the current editor, with increasing scopes of games, the editor gets complex and becomes tough to manage. With the proposed changes, the original way of coding in the “list” will change to coding in “groups”. This will result in better management.
For each group, there will be expanded views, which will further simplify code flow and will allow more features to be added like breakpoints, watchpoints, and parallel computation.
This change will also make the editor open in a new window, which will allow event editing along with changing scenes on the side.
For people who are already working on projects, there will be a legacy option to switch back to the current editor so that the project progress isn’t hindered.
I would like to have everyone’s suggestion and review on the revamp.
Thank you.
This gives a familiar “flow editor” interface to people who may be used to more workflow based design outside of game development (Microsoft Flow, other automation tools)
Drives users to use groups more (today many users view it as optional, or in some cases, don’t use them at all)
May help users to better understand how to process flows in general
Some points I would bring up:
You will need to either have:
A “Master numbering” per event sheet (e.g., Group 1 has events numbered 1, 2, 3, 4. Group 2 would start with events numbered 5, 6, 7, 8, etc)
or
You’ll need to have numbering per group (Group 1 actually has a number that says “1” and then events that say 1, 2, 3 ,4, Group 2 has a number that says “2” and then events say 1, 2, 3, 4, etc)
You might need to think carefully about how you do External Events. Would you just have a group for the Link event, and the event number for those external events? Or would you have to do some sort of dynamic numbering when viewing external events?
If this is implemented, it would definitely need to be a toggle in options. Some users work better with flow editors, some don’t.
I don’t think the editor gets complex and tough to manage. The projects themselves get complex, but the editor itself, being plain and compact, helps a lot with navigation IMO.
Your main change is offering “groups”, which is already a feature of the current editor and the way to organize event sheets. When I collapse all my groups, I don’t need to scroll to see the whole events sheet and access any section/group, which is great.
Now, regarding the screenshots…
First part:
Each empty space adds a burden for navigation. The small space you added between each group, once applied to a twenty-page events sheet, would amount to some 2-3 pages of empty space in total, I guess, so about twenty or thirty mousewheel turns? And the smaller the screen, the more navigation required, although GD should be compatible with laptops/tablets.
The logic of GD is that the events are executed in order. Separating groups like this might lead to believe that there is no real order when there really is one, and it sometimes matters a lot.
Second part:
I find the arrows confusing, as if there was a link (logic) between the two items linked by an arrow, when it’s just to indicate the order of events, if I understood correctly.
Your down arrow points to a child, but I would expect two down arrows, one for each child. Again, I find this confusing as this is not standard tree structure (it would be less confusing with an arrow that goes down and right )
With all that said, I would like to see a mockup with a bigger and more complex structure (several levels of events, children and groups).
Agree ,
What we can now see in one glace, would then want us to scroll and navigate more! I think when the editor becomes complex, its because the user doesn’t used groups and comments, if they are used properly then everything is managable, using groups and comments in the right way is making our project manageable, and we will need to add them no matter how the editor looks!
Can the new features like breakpoints, watchpoints and parallel computing be added to the current editor itself, in the current editor, can it happen that the event block change the color or the lines joining the blocks to show which events are to be parallel computed, and also the other in similar way, it will make it more compact and increase the speed of development.
As mentioned in my original post, I believe that adding this as a toggleable view in the main GD5 options would make it so people who prefer this method have access to it, and those who don’t retain the normal event sheet view.
However, I wonder if there’s an alternate path for this to get the best of both worlds. What if this is an enhancement to group functionality rather than the entire event sheet?
i.e. After adding a group, there is a button on the right of the group that displays a “Grouped Events View”. Clicking it would display all of the events in this group in the style being presented above? That would maintain the main event list functionality, but gain this style of flow-based event display when desired. Obviously, it’d still need the parent numbering for groups and events as well.
Hello all, I will try clearing up most of your questions and problems with the following post. @Silver-Streak
The numbering system will be as follows:-
Each master group, i.e. every group in the main branch will have numbers starting from 0.
Each sub-group will have continued numbering from the previous event.
External events will have their own numbering, however, the external event call will be numbered as well in continuation of previous events.
@Gruk I understand your suggestions and the issues you brought up with the idea. So here are the changes from the previous idea.
The unnecessary spaces will be removed to avoid scrolling 2-3 pages of space XD. However, the point remains that, each event shall be grouped under a name or base graph. This also eliminates your concerns with the order of groups.
The arrows are gone now. poof. Instead, there’s only a tread showing attachment between the events.
Prajwal(Sorry I can’t mention you) Yes, using the management tools is handy enough but, GD uses verticality to its advantage whereas a lot of devices have horizontality as an advantage. Using flow graphs would decrease verticality use and increase horizontal use as well.
The new features like the points can be added into the current structure except for parallel computation which would need tree structure to fit in.
@Silver-Streak I thought of the same idea. To get the best of both worlds, I will hence, propose only two changes.
Making everything group-based.
With everything collapsed, the view will be almost as same as the non-collapsed groups of the current editor. When groups are expanded, they will show up a flow chart and allow better understanding of how the code flow occurs. In this way, the breakpoints and parallel structure can be added and allow for a better debugging experience.
Doing so will also eliminate the need for a legacy option as the flow charts will only show upon second expansion.
Keeping in mind that not everyone uses groups, I still think it would be best if its a “deep dive” button on a group to show up your new view. However, that’s just a suggestion.
On your first screenshot, let’s say I want to move event #3 to nest it under #1 instead of #2. I would expect its siblings (#4-8) to follow it, because they are attached to it. But only #3 would be moved. #4 would become attached to #2 and I guess the whole numbering would change? This doesn’t seem intuitive to me.
On “both groups collapsed”, you nested the subgroup when I think it shouldn’t be.
The last screenshots are very confusing because in compact mode, you’re using the normal tree structure, and when expanded, you’re switching to your inverted mode (as explained below). And as before, I think #8 should be attached to its parent instead of being attached to its sibling.
Back to the theory now…
I agree that too much space is often wasted horizontally on widescreens, even though sometimes, that empty space is welcome:
Currently, children (nestings) are shown horizontally and event sequence is shown vertically.
What you’re suggesting is inverting that logic: the event sequence becomes horizontal and the nesting becomes vertical. But the event sequence can be very long (much longer than a screen width) while the nesting is usually limited to, say, around five levels, from my personal experience so far.
What would happen then is that we would need horizontal scrolling to display the event sequence, which goes against the default wheel behavior.
To me, the solution to this widescreen issue is to do what some of the other engines do: display the scene on one side, and the events next to it (and I would leave the current double tab system for small screens).
The first point really made a whole lot sense to me, which was a major flaw in the flow, however, if the flow was used for only debugging purposes, editing order could’ve been locked and only debug activated.
The nesting of sub-groups was meant to be like that.
Your point of flow confusion could be related to your first point, which was fixed in the same way. Shown above in the doc.
)
,
