- Mon 23 Oct 2017, 03:31
I tried GDevelop 5 after the modifications, but this time under Windows, to put a twist on it
The items in the event editor still blend in with the UI unfortunately.
I have come up with an idea for the placement of the event editing option that corresponds to each scene: since you have nicely freed up a lot of space in the "ribbon" area, a button like "Edit events", "Scene events", "Event editor", "Events view" or similar could get the user into event editing mode when a scene is selected, an "Edit scene", "Scene view", "Scene editor", "Sprites view" or whatever could in turn get us back to the scene editor.
With regards to the legitimacy of having different actions for a single-click and a double-click, I'd like to refer to the ages old standard WIMP paradigm of most of today's desktop environments, where clicking a file or folder once selects it, double-clicking it opens/runs it. In fact, the click actions are overloaded even more: clicking on an icon the second time after a short wait allows us to rename a file/folder.
As a better reference however, I just opened up a game development framework called Clickteam Fusion 2,5, which has matured pretty well over the years. In Clickteam's UI, clicking on an object instance in the "Workspace" area selects the instance, showing information about it in the "Properties" window. Double-clicking the instance allows us to edit it in a similar way your object editor does.
I am sure you could find this overloading of click actions in any random drag'n drop game engine you'd happen to download though, as a matter of fact in many other applications as well.
Options like these are some of the benefits desktop systems offer in comparison to portable/mobile ones, which is part of why they are still in use today. If a platform offers more possibilities, why not use them?
I'd also like to note that the object property editor dialog can still not be closed by pressing <Esc>, but based on your response I assume it is because a "close" or "abort" action is not yet defined for it in the first place.
Regarding the project manager, it is good that you made me think about how often one might like to use it, because I just noticed something: in GD 5, the project manager can not actually be used to manage projects, only some elements of the single project that is currently open.
This is important, because the main use case I'd like to present to you based on my little experience with GD 4 was learning. By having a tutorial project open side by side with my own, I could analyze how events were used to solve problems in the sample project, and also, what behaviors were used with certain objects.
Now in GDevelop 5, whenever I open a new project, the previous one is lost.
Aside from this, it is surely no coincidence that for instance Visual Studio has support for managing multiple projects at once, joining projects into "solutions", with a corresponding .sln file.
Another suggestion regarding usage of space: I noticed that when opening every one of the "Properties", "Objects" and "Object groups" panels, they hide most of the scene. I think it would make sense to get rid of the "Object groups" panel entirely and provide the option to create the groups inside the "Objects" panel, which could show object groups as some sort of distinguished item (dropdown tree menu?) and objects belonging to them as indented items, in between the rest of the objects. Sure, it might make sense sometimes to filter only objects belonging to groups, but that could be implemented as well.
As object groups are currently laid out, it requires several actions to see what objects comprise them, whereas if they'd be located within the "Objects" panel, it would be instantaneous.
This way, there would be 1 less icon on the ribbon on top of it all.
Also, by making panels completely undockable from the main window, you'd provide better support for a multi-monitor setup, like e.g. GIMP does.
Unfortunately, I don't have a proper bug description about what happens when you press <Ctrl> + <Shift> + U.
According to what I have perceived, both the <Ctrl> and the <Shift> keys got locked, resulting in permanent multi-selection and copying of object instances on selection at the same time on the scene editor.
It is related to GDevelop insofar it allows the keyboard shortcut for Unicode text entry under Linux to activate in its scene editor when no text is actually being edited, which is not the case with every application.
It is commendable by the way, that the headers of panels like the "Project manager" are thicker in GD 5, thus the font more readable and the "X" button more easily clickable!
Another thing that came to my mind when I was trying to make a small game was how nice it would be to be able to simply run the preview from the event editor as well, without having to click back to the scene view, as I was modifying my program incrementally and testing the results, mainly testing the effects of different parameter values in actions.
As to the redesigning of the event editor, in my opinion it is more intuitive to take an object based approach instead of an operation (function) based one, as is currently the case. It might be useful to have an option to switch between the two, but let me explain what I meant with that first.
When selecting a condition or an action, today we browse through categories of operations and properties, each belonging to some kind of object. After selecting it, we provide the arguments on the right-hand side of the editor, which most of the time includes some object as well.
The problem is, many of us program and think in an object oriented way: we do not have a universal set of operations which are always extended to know how to deal with new types of objects, instead we have objects which can have different types of operations, or interpret the same operation differently.
This means that when we decide on what information to query for an expression, or what action to take, a logical approach is to take the object and search for the appropriate operation it provides.
Example: if I want to align an object, e.g. a ball on the screen, that is, set its position to the position of the screen, sure, I know I'd like to do something with positions... but I also most definitely know it has to do something with the screen! I could equivalently go through "Position" -> "X coordinate" -> "Screen", or "Screen" -> "Position" -> "X coordinate".
However, what if the situation is not as simple and I have lots of objects with different behavior in my project already? Do I really want to throw categories like "Attack Types" between "Arithmetic operations" and "Text manipulation", just because I am using an extension that has an acid spitting dragon object in it? Or do I rather want to search in the good old list of objects, selecting the damn dragon and taking its "Attack Types" -> "Acid Stream" -> "Poison Damage" value?
Or what if someone develops an object where "Position" is named "Location" instead? Do we have 2 categories of properties for the same thing in this case, just because someone didn't follow our naming convention (do we have one in the first place? Should we really make an interface dependent on it?) ?
Now with operations which are either similar to friend functions, or act like functions taking more than 1 objects as arguments, like "Distance between two objects", they could be grouped so that out of a user interface perspective, they'd look like they belong to static (or "global") objects defined by the GDevelop framework itself. Examples of this would include "Time", "Screen", "Sound", "Mathematical operations", etc.
The difference is just that there are predefined and user-defined ones.
Sorry for the long post, although I think it will be worth it.
I am looking forward to seeing how the project evolves, especially after witnessing how much effort you put into it and how actively you react and integrate requests from the community.
However, I would most definitely like to get involved in the project's translation to Hungarian, as that is my native tongue and I'd be happy to use GDevelop as a teaching tool to get children into programming.