Announcements, feedbacks and other discussions about GDevelop.
User avatar
By ddabrahim
#63677
I've adapted and rewritten the existing Platform game tutorial...Feel free to improve it or create new pages


In my opinion it was and it is a mistake to create a completely new layout. I think you should try to remake the GD4 layout instead. I'm a noob with Javascript and HTML5 but imo it could be done and should have been. You can create draggable, droppable, resizable elements easily with different JQuery based frameworks and plugins and inside those elements you can create any kind of element to be displayed just the way it is in GD4. The challenge is, to make it responsive so I totally understand if you prefer something already have all the functionality out of the box, but with this completely new look and feel you are about to remake many years of wiki content from scratch for GD5 and I'm wondering if it ever going to be done :?

Most people interested in making tutorials prefer to share tutorials on their own blogs don't even bother to put a link on the wiki and the ones did add content to the GD4 wiki are no longer here. And the ones interested to add content to the GD5 wiki, should have a more final layout to work with. For example even the add item button is not final or is it? Only because of that small little thing in the future someone need to go through all the tutorials to change the wording and the screenshots at some point if it going to change and I think it should... So it is completely pointless to make tutorials just yet...

Even though the current UI is cool, and working, and touch friendly, imo you should consider to start from scratch literally...Whaaat :o Yeah, I know it is insane idea :mrgreen: and probably you won't :evil: but you are about to drop many years of content in favour of what exactly? To be touch friendly? Or to be done quickly?

Scirra decided to create their very own UI framework for the reason to keep the Construct 2 experience in Construct 3 so old users get the same experience and new users can benefit from all the help, content, tutorials, documentation shared for C2.

I think you should consider the same or something close to it for the exact same reason unless GD5 is meant to be nothing but a touch friendly alternative or something.
User avatar
By 4ian
#63681 Sometime you have to start from scratch to create a new improved experience for users. :)
But I'm quite surprised that you're only saying that now, considering that I've announced and published first versions of GD 5 months ago. Is there anything that make you afraid about GD5?

JQuery based frameworks


Technical note here: GD5 is not based on jQuery, which is a library that is getting really old and not adapted at all to modern apps. New JS library like React (used by GD) (or Angular 4, Vue.js...) are much more powerful and much more adapted to the creation of advanced, huge apps like GDevelop.
React is used on Facebook.com, used by tons of website, apps and can even be used to create mobile apps (using React Native) like the one done by Airbnb, Instagram, Facebook, Tesla, Bloomberg... React is a huge deal.
I'm 100% confident that jQuery based frameworks are the worst way to achieve a responsive interface. And trust me, I'm saying this based on years of experience using React to create apps and mobile apps. :)
(End of the technical end).

new users can benefit from all the help, content, tutorials, documentation shared for C2


It's true that it's similar but it's also different enough to have them rewrite the whole documentation/tutorials I think :)
EDIT: Note how C3 dropped the ribbon from C2. Same thing basically for GD5 :)

you are about to drop many years of content in favour of what exactly


I'm not dropping it. I'm making a new, improved interface that will help new users create games while existing users can still use GD4 for a bit of time, until they are ready to switch to the new version. :)

Of course, it's a pity to loose a bunch of tutorials adapted to GD4. I know. But most can be adapted **very quickly**, as GD5 interface is following the same editors/guidelines compared to the interface of GD4. But I want to be sure that you fully understand the deal with GD5:

* It's more modern, based on evolving technology (GD4 interface building blocks have not evolved since many years), easier to understand.
* In a few months, it has received more open-source contributions compared to what GD4 did in the last month. Because it's radically easier to get started with.
* Even better, it's based on ground breaking technology, so that the whole editor can be used in a browser - which is something that was not doable at all with the old interface.
* It allows me and allows you to onboard new users by just sending them a simple link to GD.
* New users can start to discover GD in less than 2 minutes. Before, you had to download, install, run the software before even trying it.
* Even better again, in a few months, you'll be able to use GD5 from your tablet. GD might be the first viable free & open-source way to start the creation of a game on your desktop computer and continue on your tablet.
* GD5 can be the way kids learn how to program at school as they'll only need a tablet and an access to the internet.
* Google is pushing for a new way of doing apps called Progressive Web Apps and GD5 is one of the very first real advanced Progressive Web Apps.
* GD5 is vastly superior compared to my previous attempt (GDevApp), as it's unifying a webapp and a desktop app in a single cross-platform app.

All of this is great but it implies a few sacrifices, and as the interface is a bit different, old tutorials are indeed not adapted anymore. It's really a pity but I'm sure we can mitigate this by having interfaces that are not so different and by having the community "translate" the old articles from GD4 to GD5 wiki.

I also recognise that GD5 might still be less powerful and less adapted to an intensive usage. It's true and I know that for some part, GD4 is more adapted to the creation of large scale games. But it's something that can and will be improved.
I've already started switching to GD5 for create large games like Lil BUB. And if we loose some speed because of the new interface that is touch friendly but less adapted to desktop, we will win by having a product based on recent technology and that will adapt better in the future to the user needs.

Porting the old Platform tutorial from GD4 to GD5 was a matter of a few hours. This can be done for other tutorials and **I need you to do this**.

So it is completely pointless to make tutorials just yet


It is not pointless! Of course things can always evolve but it's more important to have content created than worrying on whethever the "Add button" will change in a few months.
If that's the case, well just take a new screenshot of the new button, and replace all old screenshots. You probably won't have to even change the text of the tutorial :mrgreen: How sweet is that?

The weak spot of GD has always been the lack of proper tutorials. With GD5, we have a huge chance to create a lot of high quality tutorial for a new and cleaner interface. We can create tutorials that people can enjoy directly in their browser/tablet/phone. I need the community to create a lot of tutorials - it's time consuming but really rewarding.

I'm convinced that by having GD5 accessible as it is and with a few high quality tutorials, we can already do a better job at onboarding new users and showing them how to create games compared to GD4. :)
User avatar
By ddabrahim
#63682
I'm quite surprised that you're only saying that now, considering that I've announced and published first versions of GD 5 months ago. Is there anything that make you afraid about GD5?


It is not that I don't like the interface or something just the fact there are many tutorials also outside the wiki on youtube and blogs that probably won't be updated to the new IDE as the people made the tutorials no longer active on the forum
It is just a huge loss and lot of work to replace, that's all I meant...

things can always evolve but it's more important to have content created than worrying on whethever the "Add button" will change


Well, I used the add button as an example for something that must change and I hope it will :P
Of course things always evolve but never on a monthly bases that's exactly what I'm having concerns about.
People just won't update tutorials monthly take the GD4 wiki as an example. From what I see, not many people contributed to the GD4 wiki so not many going to care much for the GD5 wiki either.

If that's the case, well just take a new screenshot of the new button, and replace all old screenshots.


Yes but imagine this on a bunch of tutorials across a tons of pages... I would prefer to make a tutorial one time only at least prefer not to update it every few months even if it just changing a screenshot.

But I want to be sure that you fully understand the deal with GD5:

I have no doubts regarding the advantages of the HTML5 based IDE and I don't questioning the libraries you are using. the only thing I'm questioning is the actual layout of the IDE. It is not bad just that it completely different and might split the community between GD4 and GD5.

Actually I was suggesting to create a survey to see what the community think about the different layout then I decided to create one myself.
Let see what the active user base think about the layout.
Survey:
viewtopic.php?p=63683#p63683
By Nnarol
#63690 Hi! I've just been using GDevelop for a few hours, since yesterday evening, on Linux.

I've got some feedback:

GD 5 should have text and tooltips on the UI elements as well IMO, since most icons do not speak for themselves.

Also, Ctrl + Z / Ctrl + Y still do not work in the scene editor.

The "Project" pane is pretty clunky, since it is not resizable and even hides part of the UI in an irregular manner. It was better in GD 4.

Dialogs like the "Scene properties" still do not close when pressing Esc and Alt + F4 closes the whole application.

I think that to work efficiently, strong visual separation is needed between different parts of a GUI. The event editor's background can barely be distinguished from the top pane, sometimes making me try to scroll upwards to make sure that I have really reached the top. It reminds me of the syndrome the new Microsoft Office GUIs have, where the designers were convinced they designed a "clean" and "modern" interface but made elements barely distinguishable.
Food for thought: "new" =/= "modern", "soft on the eye" =/= "usable".

I think a good point is that the "scene inside a scene" problem has been solved with the redesigning of the top pane, which is now not multi-layered and doesn't follow a tree-like structure with respect to scenes.
The "sceneX | sceneX (EVENTS) | sceneY | sceneY(EVENTS)" scheme still does not look good though.

The typo in the action selection dialog window where a category name was "Musics" has also been corrected, so props for that.

The condition / action editor dialog can now be closed by clicking on the background, which is also convenient in my opinion.

Renaming a subentry in the "Project" pane can not be cancelled by clicking on a different item, only by retyping the original name and pressing Return, e.g.: External events->EnemiesManagement.
Since single-clicking such an item is equivalent to choosing "Edit" in its options tooltip, maybe binding the rename action to double-clicking it would be useful.

The condition / action editor now has a more logical design. There is one serious flaw however: the absence of a sort of expression editor. Without it, more complex arguments to operations can only be specified if the user remembers code that represents the desired expression. Also, I see no reason why the condition / action editor should not be resizable and movable, since it hides everything from the screen. In these 2 points, GD 4 most definitely wins.

I could not scroll to the left of the viewport in the scene editor, which made some of the scene unavailable.

Changes to an object in the "Objects" pane cannot be cancelled, only applied. This applies to object groups as well.

Double clicking an object does not edit the object, in fact it does nothing, only triggers an animation.

The "Click to add an object" button is hidden when a sufficient number of objects is present in a project. The header of the "Objects" pane should provide an option to do this, either through a drop-down menu, a button or a context menu that triggers on right-clickng it.

Textual search of objects and groups is now unfortunately missing. In GD 4, it was located at the spot which is now occupied by the (in most cases, regardlessly hidden) "Click to add an object" button.

I could not find the "point" editor which is present in GD 4, although I might have just missed it.

The magical Ctrl + Shift + U bug I found yesterday in GD 4 by searching for autocomplete in the expression editor is still present, albeit in a slightly different form (try it, it's fun!).
On Linux, in the scene editor, try pressing the above mentioned combo (which stands for Unicode character entry by code point under Linux). Try moving around several objects one after another!
You can get out of this state by pressing Esc, then Ctrl + U (no Shift, just a lowercase u), although after this, glitches sometimes remain until I restart the editor.

I hope the switch will be a great success, because I've read up on your posts where you support your decision with claims that it will bring much better maintainability across all platforms. I just hope that you will emphasize stability over chasing after the latest technology, since GD 4 as of now also feels like it's in beta, even though it is very feature-rich, yet 5 is being released.
User avatar
By 4ian
#63696 Thanks for all these feedbacks!
I had some time today and I tried to tackle most of the issues that you've mentioned! See my comments below and try the changes by downloading the new version on http://compilgames.net/ :D

GD 5 should have text and tooltips on the UI elements as well IMO, since most icons do not speak for themselves.


Indeed, I've added tooltips to all icons of the toolbars

Also, Ctrl + Z / Ctrl + Y still do not work in the scene editor.


I've added the shortcuts. Not yet implemented in events sheet but that's gonna be implemented.
I've also added Ctrl+ / Ctrl - (Cmd+ and Cmd- on Mac) to un/zoom. :)

The "Project" pane is pretty clunky, since it is not resizable and even hides part of the UI in an irregular manner. It was better in GD 4.


My idea was that when you work, you don't need to always have it open, so I made it as a Drawer. Maybe I could add options to have Drawers available as resizable/draggable panels instead (like the properties panel and objects editor).

Dialogs like the "Scene properties" still do not close when pressing Esc and Alt + F4 closes the whole application.


Fixed, all dialogs should be closable by pressing Esc.

I think that to work efficiently, strong visual separation is needed between different parts of a GUI. The event editor's background can barely be distinguished from the top pane, sometimes making me try to scroll upwards to make sure that I have really reached the top.


Ok, for now I've tried to improve this by changing the events editor background to a slightly darker grey from the theme.

The "sceneX | sceneX (EVENTS) | sceneY | sceneY(EVENTS)" scheme still does not look good though.


Do you have anything in mind to improve this?

Since single-clicking such an item is equivalent to choosing "Edit" in its options tooltip, maybe binding the rename action to double-clicking it would be useful.


Not sure about this one, having different behaviors according to a single/double click sounds strange to me.

The condition / action editor now has a more logical design. There is one serious flaw however: the absence of a sort of expression editor.


Yes, it's on my roadmap :) It's a quite complex piece of work to get this working so that's why it's not included yet. And I want something easy to use, like completions that are displayed while you type.

I could not scroll to the left of the viewport in the scene editor, which made some of the scene unavailable.


You can scroll horizontally by keeping pressing Alt (Option on Mac). I'm not sure how to make this more discoverable :/

Changes to an object in the "Objects" pane cannot be cancelled, only applied. This applies to object groups as well.


True, this is not implemented yet but on my todo list too!

Double clicking an object does not edit the object, in fact it does nothing, only triggers an animation.


Yes, I wanted to have a single behavior for the click (selecting the object to put it on the scene) and as I said before I'm unsure if adding double click would help/would be confusing.

The "Click to add an object" button is hidden when a sufficient number of objects is present in a project. The header of the "Objects" pane should provide an option to do this, either through a drop-down menu, a button or a context menu that triggers on right-clickng it.


I've added an item to the menu displayed when you right click on an object "Add a new object...". This should help mitigate this problem.

Textual search of objects and groups is now unfortunately missing. In GD 4, it was located at the spot which is now occupied by the (in most cases, regardlessly hidden) "Click to add an object" button.


I've added search bars at the bottom of the Objects editor, Groups editor and even Project Manager (useful for large games!). Their design should not disturb the user as they are grey like the background, but still always visible so very useful when games are getting bigger!

I could not find the "point" editor which is present in GD 4, although I might have just missed it.


Not implemented yet, it's on my roadmap too :)

The magical Ctrl + Shift + U bug I found yesterday in GD 4 by searching for autocomplete in the expression editor is still present, albeit in a slightly different form (try it, it's fun!).


Not sure about this one, can you describe/send me a link to the description of the problem? :) Not sure if it's related to GD at all?

I've also updated the web-app (in fact most new changes are first deployed to the web-app as it takes me exactly 2 minutes to deploy any change!): http://4ian.github.io/GD/
By Nnarol
#63698 Nice work!

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.
I would also like to get to know the source code and contribute, but unfortunately, I am not very good with technologies like JavaScript and HTML5, I'm more of a C++ / Unix scripting guy, even though I find them very interesting.
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.
By Nnarol
#63702 What I forgot to mention / haven't tried at first:

I tried the horizontal scroll functionality on both Windows and Linux, but on Windows, holding <Alt> does not change the scrolling direction, while on my Ubuntu machine with a Unity desktop, holding <Alt> while scrolling with the middle mouse button does work correctly.
Still on Ubuntu, holding <Alt> and accidentally making a sideways movement while trying to scroll vertically on the touchpad works like an <Alt> + <Tab>, i.e. it rapidly changes focus between the windows of all my opened applications. Pressing <Alt> and not holding it just opens the Unity Dash search window, hiding the whole screen.
During these experiments, I tried both <Alt> keys, though on my keyboard, only the left one is relevant.
To summarize: I do not think this method is a sufficient substitution for having a horizontal scrollbar.
Also: maybe dragging while holding the middle mouse button would also be something that people would expect to work.

Maybe binding <F5> or <Ctrl> + R to "Run preview" would also be useful, it certainly would be for me, as at first I could not stop myself from trying to run the program by pressing <F5> after each of my modifications. Then I realized I had to click back to the scene editor and click on the button located somewhere on the ribbon, then back to the event editor to continue my work. This was still in GD 4.

Another thing I noticed is that when right-clicking an object in the "Objects" panel, the focus, along with the highlight stayed on the previously selected object, making me confused as to which item the context menu belonged to. Even more confusingly, after clicking "Edit" and expecting the name of the object to appear in the dialog, it wasn't there. Then I decided to choose an image and set an animation for the object. After applying this change, I was able to see which object had its sprite changed, and it dawned on me that the object I was editing was not the one which was highlighted, but the one my mouse cursor was on when I right-clicked.
User avatar
By John Wienke
#63716 Iv been playing around with GDevelop 5, and it works great on my Windows machine but for some reason I cant seem to get it to run on my Linux machine. I'm running Ubuntu Studio on a 32 bit machine, and when I try to execute the "gdevelop-electron-app" file nothing happens. I'm assuming I am doing something wrong. Could someone please be so kind, and explain to me the proper steps to run GDevelop 5 on a Linux OS?
By Nnarol
#63719 John Wienke: I am not 100% sure, but since the original was for Ubuntu 64 bit only, and it says on the GitHub page that the new one contains classes used in JavaScript, compiled from C++ code, the new editor might be 64 bits only too for Ubuntu.
Since it ran without any problems after download for me, that's the only thing I can imagine.
After all, the proper steps should be: "download the package", "double-click the executable".
User avatar
By 4ian
#63720
After all, the proper steps should be: "download the package", "double-click the executable".


Yes, that should be all if you have a recent distro.

Nnarol thanks for your extensive feedbacks in your last messages, checking this out tonight to see what I can do or if things are already planned for the future :)