TLDR: Middle-aged dude with a busy schedule who just wants to make games loves GDevelop, but unfortunately prefers Construct 3 for the pretty objective reasons bulleted at the end.
Introduction
To kick this off I want everyone to realize I write this with the sincere intent to help make GDevelop the best game making engine it can be. I’ve only been part of the community for a short period of time, but my experience has been wonderful. I hope any of my thoughts or criticisms come across as constructive. To build something up often you need to recognize the faults.
Additionally, software functionality and features are often subjective. I work in the software world on the sales side professionally and regularly speak with customers with the perspective that the intended functionality of a feature is inefficient or even buggy as it doesn’t align with their subjective use case even though it is ideal for most others. Let me give you some context as to who I am and what compelled me to use GDevelop. Context can be essential as everyone approaches software with different goals, preconceived notions, and constraints. If you don’t care, skip to the end.
My Experience
At the end of the day I just want an easy way to make indie games without having to become a software engineer. I’m a middle-aged guy with soon-to-be 4 kids, a full-time job, and I am enrolled part-time grad school. Obviously I don’t have much free time, but I love the creative process of building gameplay loops and interactive stories in my free time. I have a bit of technical knowledge in HTML, Javascript, and Python, but nothing serious. I’ve dabbled over the years in Unity projects although using the engine eventually becomes a drag as I find myself tripping over all of the features. I’ll get pulled away for a while for life obligations, my experience with the tool dulls, and I come back overwhelmed only to stop. Rinse and repeat.
Lately I’ve had the creative itch and actually started using Godot. The engine was a lot more approachable than Unity, but I wasn’t keen on the fact that it’s in the middle of a transition to Godot 4 with some major changes to GDScript. I stumbled across GDevelop when researching other open source engines.
The appeal of GDevelop was immediately obvious to me, but I was skeptical. I used to work in a computer lab teaching kids how to use Scratch. While ‘no-code’ can be a cool premise the imposed limits tend to be steep. Other no-code solutions are just as complicated as coding, but ultimately complex in a different way that’s less applicable to real-world applications.
I was pleasantly surprised by just how well GDevelop straddled the line of being intuitive and scalable, but not all was sunshine and roses. I regularly ran into frustrations with the engine that led me to see if there were other game engines that had a similar condition and action based approach. I stumbled upon Construct 3, gave it a try, and shortly after purchased a subscription.
Why I Prefer Construct Even Though I Don’t Want To
While I want to like GDevelop more I feel Construct 3 (at this time) has objective advantages for my current use case of building complex systems for a turn-based combat strategy RPG. Again, not just the ‘I prefer this interface over that’, but real tools that have given me the ability to overcome limitations I experienced in GDevelop.
I would prefer to use GDevelop not because it’s free, in fact, I would happily pay to support the development and have a subscription I picked up on Humble Bundle I plan on continuing. I’m still using both engines, but honestly following GDevelop more as a novelty because I enjoy the community and have seen a lot that gives me faith in the open source project.
Construct 3 is far from perfect, but this is why it’s going to be getting most of my time for game dev hobby projects:
Performance Transparency
From what I have read under the hood Construct 3 is not technically more performant than GDevelop - some seem to argue the contrary. However, the engine provides tools to more effectively identify performance challenges in games making it feel more performant in the real-world. I labeled this ‘Performance Transparency’ for a reason. I don’t have the technical expertise to tell you X tool is more performant than Y. However, in a real-world application as an end user of the GDevelop and Construct 3 engines I can confirm that it is infinitely easier to identify performance issues in Construct over GDevelop due to the real-time performance monitor.
GDevelop Screenshot (Game WIP)
Construct 3 Screenshot (Game WIP)
I initially ended up researching GDevelop alternatives because I redesigned my project 3 times to make it more performant. Each time I grew better in the tool and tried new strategies. It was honestly fun as for a lot of that experience I felt like I was simply learning how to optimize within the confines of the game engine. Eventually it hit a point where identifying performance issues wasn’t fun as I’d reached a strong foundational threshold and felt that the engine was not providing me with the tools I needed to easily see what was going on.
My current project has a lot going on to calculate AI movement, raycasting, tweens, interface elements, effects, etc. The frame rate pingpongs from 30-60 FPS seemingly at random. NGL - I probably missed something in the code, but the fact that the tools to figure out what’s going on lack sophistication is beyond frustrating. In Construct I never hit that performance bottleneck, and for the other little nuances I came across it took minutes instead of hours to diagnose.
The debugging and performance monitoring in Construct 3 is all realtime. You can turn off individual elements, change the location, hide them, update variables, and so much more without needing to refresh. All of those changes are visually represented in a detailed real-time breakdown of resource usage. You can kind of do some of that in GDevelop… but not really. It’s like saying you can do everything with an abacus that you can with an electronic calculator. That argument falls apart pretty quickly.
The GDevelop performance monitor in comparison to Construct 3 feels like a stone-aged tool. Seeing as my performance issues were so inconsistent and spiked at seemingly random times it was like trying to find a needle in a haystack that after hours and hours I still have not figured out the root cause. The performance monitor alone is enough reason for me to fork over the $20 a month to Construct.
Fewer Bugs in the Engine
Honestly, GDevelop is pretty solid in terms of reliability. Although there have been a few issues I’ve had that I’ve not experienced with… well… frankly any other engine. Occasionally you feel like the tool is working against you. There was one issue in particular with a timer. At first I thought it was just a user error. I tried over and over again to fix it. In my solution hunt I came across a video by Helper Wesley in his devlog on ‘subway hell’. The devlog seemed to indicate that he had the exact same issue I was experiencing.
I tried to reorganize the code in 100 different ways. The logic was sound, but it just wasn’t working how it was supposed to as the timer triggered before it was coded to, but not consistently. Finally I just decided to redesign that part of the game using a completely different strategy. The whole process really made me lose confidence in the engine’s ability to manage a big project as all the sudden I started asking if an issue was my incompetence or the unlikely (but seemingly possible) time where the engine just was not following its own internal logic as intended.
Error Handling is more Effective
This was a problem for me early on in my learning curve, but not much anymore that I have a good understanding of GDevelop’s nuances. I mention this as it was definitely the most significant reason I almost stopped my project as a newbie early on.
Error handling in GDevelop definitely needs some work. For example, if you have a string variable in Construct and you select an action to ‘Set Value’ you cannot then select an action that would update the value as if it was a number variable. Same thing applies to booleans. For some reason in GDevelop you can choose ‘Value of an X Variable’ and select a variable that is a boolean, array, number, etc. The code will then just not work with zero feedback to the user that they selected an option that’s an impossibility yet looks very similar to the correct selection.
As a newbie I would have problems with this all the time not realizing that, in order to change a String, I needed to select the ‘String of an X Variable’ even though the interface let me select that variable as ‘Value of an X Variable’. At times I’d just accidentally misclick on the wrong type. You have to be methodical about which actions you choose as the engine will not adequately inform you that you’ve chosen a nonsensical option that doesn’t work. That just doesn’t happen in Construct as they more intuitively anticipate what the user is trying to accomplish. I would argue this is essential for an engine focused on giving people with a non-technical background the ability to build a game.
The Implementation of Some Features do not Feel Complete
I realize that only recently a number of features had the ‘Experimental’ tag removed. With that said, the implementation of a few features pale in comparison to Construct. The specific features in question are Panel Sprites, Tilemaps, and Bitmap Text.
Panel sprites for some reason seem to dip performance? Not consistently, but I have had more than one occasion where removing a panel sprite from the interface bumped up the frame rate even though it had no collisions and was just used as an interface overlay. The margin settings on panel sprites can be troublesome as well. Where the margin is set will clip and the background will bleed through as a narrow 1px line. Makes your game feel very unpolished and there’s nothing you can do about it aside from not using panel sprites. Defeats the purpose of even having them as an option. Particularly pronounced when tweening a panel sprite which, personally, I think leads to slick and visually driven interfaces.
Tilemap support is patched together at best. It is frustrating trying to get everything set up correctly and then subsequently you need to make updates in Tiled or another external tool. I am an iterative designer. I would add a few elements, and then want to test the gameplay. While the updated file would appear correctly when the game was launched it would not in the editor. Big problem if you need to add collision or interaction points to the map. The only reliable way I’ve found to update the editor is to reload the tile map file or restart the project file. The implementation is just incomplete and janky compared to Construct’s integrated tile tool.
BBText works sufficiently in GDevelop. Compared to Construct, however, it leaves some features to be desired. Probably the most significant detail is the fact that each instance of the BBText in Construct can have a unique text value assigned in properties. Perfect for complicated interfaces where you can have one text object with multiple instances containing identifying information that is static (HP, ST, properties, notes, etc.). Yes, yes. It’s possible to change the instance of text in GDevelop, but you have to use the event sheet and ID the text you want to change. Construct handles the text of each text object almost like an instance variable meaning each instance can have a unique value that will appear without having to build out a set of events. Anything the engine can do to narrow down the complexity of the event sheet is a plus.
Aligning the text is a lot easier in Construct as well. You can simply choose the alignment you want, and the BBtext will align to that position (justified left, center, right). In GDevelop you can only add alignment for when there are multiple lines within that text. In order to center wrap BBtext around an object you need to, again, set up an action in the event sheet. Why? You just set the size and click a button in Construct. So much easier.
File Viewer
Okay. So this feature is more subjective than the others… but I would make an argument that Construct’s organization system for objects, sheets, groups, etc. is objectively better. Construct is a bit like Godot in that the entire game’s file structure is available within a project file viewer. This is so… much… better… for medium or large projects. GDevelop splits this up into multiple locations and, for some reason, you cannot have sub categories/folders for objects. I think the screenshots speak for themselves. It’s simply not easy to stay organized in GDevelop with large projects spanning multiple event sheets and scenes.
GDevelop Screenshot (Game WIP)
Construct Screenshot (Game WIP)
Those are the big reasons I prefer to devote my time and resources to Construct 3 as an engine at the moment. I’m here though, so I clearly like GDevelop. To end this I wanted to leave a list of pros and cons as I have found in comparing GDevelop to Construct 3. It is by no means complete. I’ll recap some pieces I mentioned above as well for the TLDR readers. Again - trying to make these objective advantages/disadvantages rather than the subjective preference of the interface or the way logic is handled. I think all of the Construct advantages could in some way be implemented in GDevelop as the approach to programming is VERY similar. I’m sure there are more pros/cons on both sides, but these are what I’ve come across in my experience.
GDevelop Major Positives (My Experience)
- Price makes game dev approachable to a wider community - especially those who simply cannot afford a subscription.
- OpenSource community is great and the OpenSource nature has more potential for growth.
- Extension system is wonderful and very flexible leading to loads of extensions - more than Construct Addons.
- Desktop install available alongside a web (Construct 3 is essentially web-only version - local installs are managed as a browser extension).
- Extensive behavior system with the option to quickly add community behaviors - Construct has behaviors but the options are more rigid.
- Searchability of actions and conditions - you can search across everything in one area at the same time when adding conditions or actions.
- Many more community examples of all varieties helping users get started.
- Variable ‘Structures’ are super powerful in GDevelop, and not easily possible in Construct without an addon… with that said Globals 2.0 (an addon) is more manageable than structures.
- The ability to see how extensions work and modify the root to meet your unique set of needs - Construct is more locked down.
- The GDev Wiki is actually more robust than the official Construct 3 documentation.
GDevelop Little Details (My Experience)
- ‘Resources’ view in GDevelop is great for finding where files are stored and there is not an equivalent type of interface in Construct.
- Color pallet is selectable when tinting or changing colors in the expression builder - You have to just know the RGB value in Construct.
- Timers are a bit more robust (when the work) - a single timer can have more impact.
- Raycasting is more configurable.
- More out-of-the-box effects for objects and layers.
- The logic for calling an instance of an object is a bit more intuitive.
GDev Determinant (My Experience)
- Felt impossible to identify performance issues.
- Occasional game breaking bugs that seemed to be rooted in the engine - especially when using timers.
- The lack of error handling is frustrating for new users.
- Some supported features feel janky and poorly implemented.
- Lack of a cohesive file organization system compared to Construct 3.
- On a few occasions I had a corrupt save and the autosave file worked, but it took some effort.
Construct 3 Major Positives (My Experience)
- Hyper detailed and flexible performance monitor.
- ‘Real World’ performance overall - if only due to performance transparency.
- It is possible to edit objects while in the events sheet - looking at an instance variable, updating an effect, etc. Frustrating going back and forth when in GDevelop.
- Organized project file view feels more polished and professional.
- Error handling is more effective - especially for newbies.
- Integrated Tilemap support and builder.
- Sprite sheet support - upload a single sprite sheet for animations.
- Functions in the event sheet - You can replicate this using extensions, but it’s not intuitive in GDevelop.
- Open multiple projects at the same time in one viewer interface.
- Timeline animation with a lot of great uses - simply not available in GDevelop
- Properties area is more information dense - requiring fewer clicks to find what you’re looking for (perhaps the most subjective advantage in this list, but I find myself missing it going from Construct to GDevelop)
- The Hierarchy system is far easier to work with than the linked object system in GDevelop.
- Native 3D support - I said native as I know there is a community extension for GDevelop. The fact that it’s native makes it a lot easier to work with.
- Deeper integration with distribution platforms in iOS and Android - I’ve not done this personally, but it’s very apparent and gives me more confidence in the distribution of Construct-made games.
Construct 3 Little Details (My Experience)
- Multi-monitor support - You can undock UI elements and use them outside of the main engine window. Big for me as I always have multiple monitors.
- Detailed search results across the entire tool in all interfaces - Imagine a Mac’s Spotlight search but in a game engine.
- Default hide/visible option in properties - Again, keeps the event sheet clear and I have a lot of objects that we hide by default.
- Show collision option in editor - All collision masks will appear in the editor when on.
- Ability to put comments on Variables - Great as my current project has a lot of variables and it can get complicated
- Toggle individual actions or conditions on an off - In GDevelop you can only toggle a condition and action set as inactive. It’s nice to disable only one condition/action for bug testing.
- Ability to change colors on project tabs - helps with organization.
- Undo and redo is more intuitive - easier to see what changes have taken place.
- Text of all types is MUCH easier to use and configure - see notes above about BBText as it applies to all types of text.
- Global objects can be toggled back AND FORTH very quickly.
- Ability to add descriptions to groups - great for organizing again. Sure, you can just leave comments, but it’s nice to have it integrated.
- Layer system is more robust - additional options, sublayers,etc.
- In line local variables for events where you just need one-off variables - helps keep global and object variables cleaner.
- More flexibility in tweens - Loop, Ping Pong, etc.
Construct 3 Determinant (My Experience)
- Exclusive purchase option is a subscription and the ‘free’ tier is borderline useless - It raises the barrier of entry for game development to only those who can afford it. Mind you, Construct is a business and needs to make money, but democratizing access is a clear advantage of OpenSource software.
- The fact that the installer is not native does not build confidence, and I have run into little issues the add up with the local install which is little more than a web app installed through browser’s extension system.
Conclusion
This ended up being far more of a novel than I anticipated. Originally I was just going to send a few little points to Tristan (Victris Games) as he asked me for some feedback regarding a comment I left in the GDevelop Reddit. Take or leave all of this for what it is. Just know I have faith in the creators of GDevelop and the OpenSource community that has formed around it. I’ll still be around for what that’s worth fiddling around on smaller projects, and I look forward to seeing GDevelop grow in the future.
All the best,
Matthew
