GDevelop new experimental IDE


I’ve been working these last months on a new experimental editor built on new technologies! :slight_smile:
I’m still really busy on it and on the Lil BUB’s game so that’s why I’m not answering on the forum. I feel really sorry for that! :neutral_face: But that’s the way I can continue working on it on my spare time, which is only a few hours a day.

[size=150]Why a new editor?[/size]

The current editor is slowly becoming old and harder to maintain as the underlying technology is quite hard to get for new developers and not often updated.
The idea is to have a new editor that is:

-Built on web technologies, so usable on a desktop, tablet, maybe even mobile phones.
-Easier to understand and modify for external developers that want to contribute to GDevelop.
-Have a more simplified UI, easier to understand for new comers (based on “Material UI” components and guidelines by Google).
-Unifying GDevelop and GDevApp.
-Working on Windows, OS X, and every major version of Linux without having to do special work on my side or maintain tricky compatibility!

[size=150]When it will be ready?[/size]

My idea is to work on this new editor and allow it to replace parts of the current editor progressively. I’ve already added an option to GDevelop to have the new scene editor launched.

For the first version, it may not be bundled with GDevelop as it is quite large. But the idea is that you download the new editor, put it in the same installation directory as GDevelop, check an option in the preferences, and the new editor will be launched when you edit a scene.

Also, as it will be a major changes in the user interface (even if most of what you are used to will be there!), it will be experimental and hidden by default and probably released officially later as GDevelop 5 :mrgreen:

The wiki/tutorial will have to be updated => the easiest will be to flag tutorials as being for GDevelop 4 or GDevelop 5. Let me know if you think it’s a good idea and if you will be able to help me :slight_smile:

[size=150]What is already done?[/size]

So far I’ve been working on the scene editor. It’s almost usable to create levels, it still miss a few features.

[size=150]How can I test it?[/size]

When I’ll release the next version of GDevelop, there will be an option to launch this new editor instead of the current scene editor.

[size=150]Show me some screenshots![/size]

Here you go! Warning big screenshots ahead. It’s still pretty raw and unpolished!

Let me know what you think! Keep in mind that this is still an experiment but could change the way people create games, as it will be available for desktop but also surely in browsers later! :slight_smile:
People that want to have a discussion about the development can go on the GitHub thread:

It seems like you have already set your mind on pretty much everything, not much left to us but to accept the facts :laughing:
I believe the most exciting thing about this new IDE is compatibility. It should be relatively easy to make it run on all major platforms and even inside web browsers which means, finally GDevApp may get the IDE it deserves :slight_smile: On the top of that, it would be nice if the IDE of GDevApp and GDevelop would be the same experience (finally). This way GDevApp users could benefit from the GDevelop tutorials on the wiki and GDevelop users would be more interested to move their project to the cloud.
Also web browsers could be used as a backup solution just in case the IDE doesn’t run locally for any reason, it may run in the browser.

I’m not too sure if it worth targeting mobile phones, I mean the screen is just too small for development, it nice if it finally happen to be compatible and usable but I don’t think it worth the effort to make sure it is usable on a 5" screen.
In my opinion this new IDE should target PC and Tablet devices.

I can’t wait to try it.
Good luck.

Yeah, by the release of GD5 tutorials must be flagged but most importantly, must be updated. I’m definitely willing to help with that as soon as I get my hands on the first beta :wink:

Sounds like a good idea! I can’t wait for it. Btw, will there be an extension to pause a layer for the upcoming version?

Overall i like Gdevelop and it is such a god damn good engine.

Thanks Florian and his friends for keeping gdevelop awesome and the forum alive.


Actually I personally don’t prefer an HTML 5 GUI, but I understand the compatibility advantages, and as others, willing to help you out with testing and get the testing build once it’s released.

One very important thing is the ease of writing extensions, as of course the Gdevelop core engine has some limitations for HTML 5 and it would help if it can be extended easily. If this can be made in a simple way for extension developers, and would be easy to share with other Gdevelop users, that could potentially make a big advantage. :slight_smile: You may notice on the forums that everyone asks for at least one or two features that they could use in their products, but are not integrated in Gdevelop. Giving the ability for someone to integrate them without too much effort could really expand the capabilities and user satisfaction.

That way, even if we cannot influence the direction of Gdevelop development too much (you already have plans and very limited resources understandably), we could expand it ourselves to make more people happy with the available features.

All the best.

Fantastic to see there are new versions in the near future! Can’t wait! :smiley:

Now that the IDE of GDevelop is going to be rewritten from scratch, I would like to bring up one of my old feature request/suggestion for replacing the event system with a visual programming language called Blockly which is developed by Google and completely free to use:

Even though I like the current event system I still believe that visual programming would be more powerful, more elegant, more attractive, better organised while it CAN BE just as easy as the current event system.
As the IDE including the event editor going to be rewritten from scratch in the coming months, I do believe it something worth considering.

Also an other thing that I have mentioned and thought about before is to make every condition and action an actual JS code that we can open, modify inside the IDE and make it possible to add our very own conditions and actions this way… In case you decide to “experiment” with my suggestion and replace the event system with Blockly, I think it would be something also worth considering.

I don’t know if you are open to suggestions in the early stage of development I don’t want to seem grasping just thought it might worth take the opportunity and mention some of the things that I believe worth considering now that you rewrite the IDE anyway…

Looks quite a bit like Scratch from MIT. I think that’s a very simple to use system. Scratch also comes with some additional features (functionallity) worth considering too. :slight_smile:

It seems like even the Scratch team at MIT decided to go with Blockly for the future educational tools, so maybe even Scratch going to be using Blockly by the end :stuck_out_tongue:

I think the same.
Instead of doing this
we could do something like this:
Of course it different (especially now that I was using only stock blocks in the screenshot), it might require some time to get used to it but I don’t think it would be more difficult for beginners but it would be definitely more powerful. Blockly can be extended with custom blocks, so there would be no limitation really what kind of blocks we can implement to utilize it full power and at the same time make it as simple to use as possible for beginners with custom blocks to work with variables, objects, texts, sounds…etc.

Thanks for your ideas :slight_smile:

For now I’m putting my efforts on the new scene (and external layout) editor, so the event editor won’t change for now. But it will be the next task once the new scene editor is working well and released as beta :slight_smile:

For Blocky, I’m wondering if it’s really efficient to work with this for a long time?
Event are a kind of visual programming, but they should be quite quick to work with. I’m not sure if drag’n’dropping every single part of what you want to use as in Blocky is efficient. If I remember correctly, you have to drag’n’drop almost everything including mathematical operator. This can be cumbersome for large games, don’t you think?

That’s true, for now I’m targeting desktop computers and then webbrowsers/tablets :slight_smile:

Cool! :smiley:

Suggestions are welcome :slight_smile: I’m still not sure about how Blocky is working for a real world usage in a large game, but it’s always interesting to see if GDevelop can benefit from other existing game development library/engine/editor! :smiley:
For example, I made some research for the scene editor but I could not find any open source level editor that is simple and flexible enough to be integrated into the new GD IDE.

This might be a bit of an issue with both Blocky and Gdevelop system. Sometimes it’s not very convenient to edit or add events without double clicking on them (if editing. to make sure it does the syntax check), then you open a dialog, then you change settings… both of the systems are slower than writing the code… but only if ‘coding’ would be exactly as simple, using preexisting functions,e.g. set object position Ball 1,10, move ball towards portal 2 (speed number) and not if you need to code 100 lines of course. If you have to worry about language syntax a lot, then it would be slower to write the code. :slight_smile:

I really can’t comment on whether or not blocky is more difficult (didn’t use it) for larger projects, but let’s say in blocky you are trying to change an operator:

  • You would click on the existing operator (the arrow next to it), select a new one.

Now in Gdevelop:

  • You would double click on the operator (or single, not sure), then you would write a new one.

This should take a similar amount of time.

If you’re interested enough in this system as a potential candidate, I guess you could ask some of us forum members to make simple tests by trying to make exactly the same project using Gdevelop and a blocky based engine (e.g. Scratch may not be using it, but it’s visually and probably functionally similar from what I can see).

This part is just a note when talking about speed, regardless of the visual system, maybe the fastest possible way to work on complex projects would be writing the code, while keeping it as simple as possible (e.g. basically the same as currently, but just writing instead of having to click into fields before we can edit them). Maybe this could be a special “edit source” mode where you can copy,paste and edit sections of code textually, then continue working in the visual mode. The XML file that Gdevelop IDE makes is of course not suitable for manual writing. In reality, I have no idea if this would be complex to implement, and if there would be other issues with it. Just something I desired for faster work. I made the mistake quite a few times, e.g. trying to change the operator quickly, but instead of clicking on the operator, I end up adding the operator to the number/expression value, and deleting the actual operator. This looks kind of fine in GUI, but of course doesn’t work in game. :slight_smile: Syntax check only works when you are in the visual editor dialog (not if you click and edit a value directly while viewing the events).

I’m not sure if comparing the current event system and a Scratch/Blockly based system would give us a good picture. Just because an engine use Blockly a certain way that’s not necessarily the only way it can be used.

Actually, what I was thinking is that for the conditions and actions we might be able to create custom blocks that is already including the fields required to input information.
For example, to compare the value of a variable it could be a custom IF block that is already including the math operator field, a variable field and a number field to input information. Actually, instead of a text/number field it could be an other custom block or field, that allow us to enter just about any kind of value, even expressions. When we click the field, it would open the expression editor and we can use it to enter any kind of value…

I believe, every single condition and action could be made as custom blocks including all the fields required and it would be just as easy and fast as the current event system. But thanks to the modularity that you have concerns about, Blockly could be a lot more powerful because we could do just about anything by drag 'n drop individual blocks to connect them and make them interact with each other.

This is exactly the reason why I decided to bring this up now, so you have time to think this through.
Of course I’m not saying the event system must be replaced, I like the event system but you won’t rewrite the whole IDE very often so this is a rare opportunity to think about such a huge change. This opportunity may not going to return for many years.

So even if you haven’t though about it I believe it worth to consider the possibility to replace the event system with Blockly because it would have number of benefits in the long run. Apart from flexibility and power, it would be also more elegant, modern and more attractive in my opinion.

You might also need to consider that in the past few years number of educators did show up here mentioning they are looking in to GDevelop or GDevApp to teach game development in their class or school but finally, none of them returned with the news GD has been selected. And that is probably because the event system is easy and fun but doesn’t really teach any practical skills that would be useful in other places (other than logical thinking of course and maybe some introduction to variables, sprites, layers…etc). With Blockly, it could be different because it would help people to get familiar with the fundamentals of coding while using the ‘condition’ and ‘action’ blocks and later become more advanced by building their very own functions block by block. There is a good chance it would help GD and GDevApp to be used even in education may even picked by schools officially. … I’m not saying it must be a goal but it would also has it benefits but it would unlikely to happen with the current event system.

I decided to give it a try and see if I can come up with some custom blocks in Blockly to replace events in GD.
This is the result: (169 KB)

It was surprisingly easy actually.
Just unzip it and open index.html.
It is include only 4 simple blocks that you can drag around and connect, 2 conditions and 2 actions. No code generation so it is not “functioning” just wanted to show what I have in mind, not only talk… :stuck_out_tongue:

I hope it helps.

I’m excited to hear that GDevlop is getting a general overhaul.

I’m mostly focused on animation and graphic design which is reflected in the type of game I’m making.

Although there are a lot of great ways to cut corners and reduce the total number of frames of an animation (strong key frames, in-animation motion blur, stretch and squash etc.), for a fluent animation there’s always a minimal acceptable frame rate. Since there is no in-engine bone system, the only way it can be achieved is by using sprites [which does have a lot of benefits, since a professional animating program will usually give superior results compared to animations rendered in real time [it allows for things like mesh deformation, smart bones and various after effects which are crucial for making high quality animations)]. And this is where the issues I have stem from: all the games I make become very resource-heavy, even at small resolutions. I’m aware that a lot of GDevelop users have a limited number of game-assets and might not encounter this problem. But if you’re planning on making an engine that isn’t only intended for small-scale projects, but something that can be visually stunning and also want to give a quick and easy way for artists to express themselves in the game medium, you might want to consider the performance of the engine, especially when it comes to rendering and memory usage. For me personally this seems more important than GUI redesigns, as I think the ease of usage and intuitive design of GDevelop are already its strongest points (though the planned cross-platform compatibility sounds great).

I’m curious how much space there is to further boost the performance. I have no programming background, so forgive me if the following questions are stupid. For example:
-Are off screen images also rendered?
-Are fully transparent pixels automatically cropped, or are they also rendered?
-Is there a way for compressed, indexed png-s (which are currently not supported, or at least don’t work for me) and limited palettes to affect the GPU usage and not only the physical size of the game file?
-And what other ways are there to optimize the performance (mostly in graphics)?

Sorry, I have no clue about these things.

Anyways, I wish you best of luck with the development and thank you for everything, you’ve given me a very fulfilling hobby.

Speaking of image loading performance, I also encountered many issues with a large animation (e.g. 360 frames for an isometric Turret for a defense type game). I have to solve this or redesign the game entirely or even give up, if I’m not able to. The same would go for any similar type of projects.

Having 360 images per object means I have up to a few thousands of images (to give an illusion of the third dimension, isometric type) in total, and loads extremely slow at the beginning (really really slow, does not even work properly with or if I turn off preloading, creates significant lag the first time an enemy appears, or a turret is placed, etc.

The solution for this would be to support some kind of spritesheet (1 file per object instead of 360 files per object). With only a few image files loading (even larger ones) the loading speed will be significantly increased. I assume that’s easier to implement than some kind of streaming that might require specific server support (where multiple images are sent into a single HTTP requests), but I would be happy with any solution.

Without this, it’s very unpractical to have a large amount of assets or animation frames, as you will either have a laggy game or very slow initial loading (some people will actually skip on the game if it loads for too long, thinking that something is wrong with the game).

So, for large projects (not limited to defense type games of course but really any larger game with a lot of content), this might be a huge benefit in performance (even if you only have 10 images per object, at 10 objects that’s 100 images to load, and if a spritesheet system is supported, you would only have 1 image per object, so 10 instead of 100 requests to make, which would give an incredibly faster load time).

This helps not just with standard character animations and isometric type games, but also for loading “particle animations” (animations that simulate particle effects, based on pre-rendered particle effects and such). We could have fluent animations that load quickly (up to 100 frames per effect animation could still load quickly as one image spritesheet).

Apart from that, what a big project needs is a really good save system. It is a pain trying to save every single variable especially when you have to save alot of the npcs position and levels.

This may already exist in the GUI (excuse me if so) but it would be nice to be able to select multiple object images at once in the new GUI.

E.g. if you have an animation with a ton of images, then want to change them for other image files, you have to press delete many times, and wait a bit. It seems you cannot select multiple frames and delete them at once.

I could be wrong, there might be a faster way! If so, please let me know as it will speed a part of the work for me. :slight_smile:

Hi there…

I have used blocky system before in stencly and some other editors and i must say it makes thing wayyyy harder and more difficult if you design a lager game which you have mentioned above. Blocky system is good if your gonna make a simple game like mario or so but for serious games hell no… The event editor now is perfect simple to add portions of code, see whats going on in full text, easy to copy paste ectc, and very easy to organise by just dragging line up or down or stuff l,kle that. So i believe it just perfect as it is.

Something that would be really nice is to be able to set the collision mask with the sprite(make it pixel perfect) that way the hit boxes can be more accurate. However the knowledge to do anything like that is way above me so this is just a request, I am very knew to this program and have tried unity and gamemaker, and this so far is the easiest and best one for me to use, i love it a lot I thank anybody and everybody who has helped to get it to where it is and where it will be in the future!

I am new here and I have not yet used GDevelop. However I have been reading that GDevelop has been getting long in the tooth. So from me this is welcome. :slight_smile:

Would it be possible to implement something similar to this? See the link below. … -world-map

Plugin support would also be welcome.

You are right, some kind of polygonal approximated collision or a pixel perfect collision (or both) would be needed to have proper steep hills and such utilizing the physics engine fully. E.g. a hill climb racing type of game for android. I don’t know how complicated that is to add, but would also love to see it!