GDevelop [Official Site] is an open source cross-platform event-driven game engine that's quite promising. It's currently closing in on a new major release and it's also now on itch.io. GDevelop 5 is currently in Beta and has been for a while with the 55th iteration released around 10 days ago.
What do I mean by event driven? Well, instead of writing out vast lines of code you drag things around in a visual editor and attach events to various actions and behaviours. Here's an example, a screenshot I took from the events section of their space shooter example game (many more examples here):
It can be compared to Clickteam's Fusion or Scirra's Construct, unlike those tools GDevelop is free and open source.
There's plenty of built-in behaviours to help you make various types of 2D games, along with an extensions system that's used for the built-in features.
The developer of GDevelop sent word that the game engine can now be grabbed on itch.io, so you can install it and keep it up to date using the open source itch app. There's something satisfying about download an open source game engine using an open source downloads app…
After trying it out some more today, after not following GDevelop for a while I'm genuinely surprised at how far it has come. It looks a lot better, it's a lot more stable and it seems to be quite a bit more powerful too. Looking forward to watching this continue to progress.
Guessing it's just for simplistic arcade games ?
Am curious how limited this is compared to other game editors.
Guessing it's just for simplistic arcade games ?
I believe it's limited to 2D games only, but other than that, virtually any type/genre of game should be possible to create within it. The visual/event driven programming isn't really a limiting factor in that regard.
Games like;
- The Next Penelope (Top-down racer made w/ Construct)
- Enviromental Station Alpha (Metroidvania)
- Wild Light (2D Minecraft clone)
- The Escapists (Prison Escape Simulator)
- Fading Suns Noble Armada (Real-time tactical space shooter)
Were created with the equivalent engines mentioned in the article (Clickteam and Construct), so GDevelop should be just as capable and versatile.
It's definitely more limited compared to the Godot engine, but for those who don't know a programming language, it's almost certainly the best option available on Linux at the moment. :)
GamesFromScratch does a more in-depth video on GDevelop here, if you're interested.
Last edited by Incandescent on 1 November 2018 at 4:17 pm UTC
Am curious how limited this is compared to other game editors.
Guessing it's just for simplistic arcade games ?
I believe it's limited to 2D games only, but other than that, virtually any type/genre of game should be possible to create within it. The visual/event driven programming isn't really a limiting factor in that regard.
Games like;
- The Next Penelope (Top-down racer made w/ Construct)
- Enviromental Station Alpha (Metroidvania)
- Wild Light (2D Minecraft clone)
- The Escapists (Prison Escape Simulator)
- Fading Suns Noble Armada (Real-time tactical space shooter)
Were created with the equivalent engines mentioned in the article (Clickteam and Construct), so GDevelop should be just as capable and versatile.
It's definitely more limited compared to the Godot engine, but for those who don't know a programming language, it's almost certainly the best option available on Linux at the moment. :)
GamesFromScratch does a more in-depth video on GDevelop here, if you're interested.
Thanks for the examples. Seems interesting.
I've had Game from Scratch bookmarked for literal YEARS. Sadly never got around to watching his vids. :(
Thanks GamingOnLinux for the article :)
Concerning what can be done with the engine, while everything is made to be as accessible and understandable as possible, it's actually a full-featured WebGL/JavaScript game engine running. Events are I think the best of what can be done in terms of "visual" programming, as they allow to recreate almost anything that can be done in an usual programming language.
Latest versions even bring the functions, which allow to extend events by declaring actions, conditions or expressions that are actually events themselves (something that was never seen in this area of visual programming I think).
Best thing is that if you want, you can add arbitrary JavaScript code blocks in events (you could write an entire game like this... or just a few functions to still keep the clarity of events). I think we're hopefully reaching the sweet spot between visual programming and traditional programming (you can create your own "visual events" to keep the rules of your game easy to read, while implementing them in JavaScript). For the record, the rendering is done using Pixi.js (http://www.pixijs.com/) which powers professional games and is super performant.
A few larger games were also made with GDevelop (I personally made this one: https://www.kickstarter.com/projects/iamlilbub/lil-bubs-hello-earth-a-retro-8-bit-mobile-video-ga :D )
Happy to give your more insights!
Last edited by 4ian on 1 November 2018 at 7:19 pm UTC
isnt that what package managers suppose to do...
sigh.
yeah, looks like the fragmentation leads yet again to people reinventing the whell, because its too hard to support all distros otherwise.
steam became the norm, since we were busy competing instead of cooperating
not only that, but the famous channel, games from scratch covered it recently.
they dont give an special atention for an tool just because its free/opensource, they are purely "meritocracy" based, but even they think that this is an good solution, maybe better than construct.
i sugest the community to donate a lot for this project and the godot project, contrary to proprietary software, open source tends to grow exponentially once it hit the critical mass, but only if it hits it.
just as an reminder, construct 1 was open source, but the developers found then selves in a situation were, make the program as open source was not economically viable, they didnt get much help from the comunity so the code was evolving as fast as it would if it were only made by the 2/3 employees , but they didnt saw an income from it either since it was free in price and some times its tricky to monetize open source.
as an result they remade construct from scratch, this time as closed source, construct 2 had less features and still were more sucessfull due to more money to evolve it advertise it etc.
gdevelop came later to the party and had trouble growing against the already established clickteamfusion and construct 2, still, it is evolving fast and may have surpased construct already, if we dont support it now, it may never hit the critical mass its required to enter the exponential growth.
one thing that gdevelop need to change, is that they are entirely based on html5, it sounded like an good idea to make it easy to make it multiplatform back then, but now with web assembly, all the benefits are going south
Last edited by elmapul on 2 November 2018 at 5:19 am UTC
Thanks for this :) Donation are very welcome. It's indeed a matter of hitting the critical mass.
> one thing that gdevelop need to change, is that they are entirely based on html5, it sounded like an good idea to make it easy to make it multiplatform back then, but now with web assembly, all the benefits are going south
You mean for the editor or for the games? The editor is already partially based on WebAssembly ;) I even made a talk at React Conf about it as this is a kind of unique approach.
As for games, for now HTML5 games seems to be viable, but as WebAssembly becomes more widespread and interoperable with JavaScript it will be an option (Firefox recently made the overhead for calls from JS to WebAssembly and vice-versa cheap, but there are still some overhead in other browsers that may make things harder for a game engine where you would have lots of JS <-> wasm calls). In particular, re-implementing only core algorithms (like collision handling or pathfinding) could be interesting to keep things easy to evolve.
" There's something satisfying about download an open source game engine using an open source downloads app…"Maybe I just haven't experimented much, but these days isn't there basically
isnt that what package managers suppose to do...
sigh.
yeah, looks like the fragmentation leads yet again to people reinventing the whell, because its too hard to support all distros otherwise.
steam became the norm, since we were busy competing instead of cooperating
1) A large family of distros using apt with a graphical front end, whether Synaptic or something called "Software manager" or something
2) Red Hat
3) A smaller family of distros using whatever Arch does
That isn't a whole lot really.
But I'm not sure it's relevant. Games are different from other stuff, package management wise. Culturally, and because most Linux games are closed source and cross-platform, whereas most other Linux software is open source and often Linux-only, or even if cross-platform dominated by its Linux use. This game engine is open source, and no doubt the developers have a fondness for Linux because Linux is the centre of gravity of open source stuff, but it probably isn't primarily for Linux users. So its main method for being acquired isn't going to be through Linux distros, it's going to be through portals that Windows and maybe Mac people use, and because it's a game-related thing, that will be a game portal.
Long story short: Normal Linux software comes from your distro's software manager thingie, game stuff comes from Steam or GoG or Itch. There is nothing to be upset about here.
Last edited by Purple Library Guy on 2 November 2018 at 4:00 pm UTC
" There's something satisfying about download an open source game engine using an open source downloads app…"Maybe I just haven't experimented much, but these days isn't there basically
isnt that what package managers suppose to do...
sigh.
yeah, looks like the fragmentation leads yet again to people reinventing the whell, because its too hard to support all distros otherwise.
steam became the norm, since we were busy competing instead of cooperating
1) A large family of distros using apt with a graphical front end, whether Synaptic or something called "Software manager" or something
2) Red Hat
3) A smaller family of distros using whatever Arch does
That isn't a whole lot really.
But I'm not sure it's relevant. Games are different from other stuff, package management wise. Culturally, and because most Linux games are closed source and cross-platform, whereas most other Linux software is open source and often Linux-only, or even if cross-platform dominated by its Linux use. This game engine is open source, and no doubt the developers have a fondness for Linux because Linux is the centre of gravity of open source stuff, but it probably isn't primarily for Linux users. So its main method for being acquired isn't going to be through Linux distros, it's going to be through portals that Windows and maybe Mac people use, and because it's a game-related thing, that will be a game portal.
Long story short: Normal Linux software comes from your distro's software manager thingie, game stuff comes from Steam or GoG or Itch. There is nothing to be upset about here.
1) A large family of distros using apt with a graphical front end, whether Synaptic or something called "Software manager" or something
out dated softwares, with an outdated list of what is avaliable for linux.
"This game engine is open source, and no doubt the developers have a fondness for Linux because Linux is the centre of gravity of open source stuff"
that explains why construct didnt had an version for linux? sigh
"There is nothing to be upset about here."
except that canonical made 0 dollars on their store, and now they dont care about the desktop anymore, the ones who do is valve.
I'm not clear what point you're making." There's something satisfying about download an open source game engine using an open source downloads app…"Maybe I just haven't experimented much, but these days isn't there basically
isnt that what package managers suppose to do...
sigh.
yeah, looks like the fragmentation leads yet again to people reinventing the whell, because its too hard to support all distros otherwise.
steam became the norm, since we were busy competing instead of cooperating
1) A large family of distros using apt with a graphical front end, whether Synaptic or something called "Software manager" or something
2) Red Hat
3) A smaller family of distros using whatever Arch does
That isn't a whole lot really.
But I'm not sure it's relevant. Games are different from other stuff, package management wise. Culturally, and because most Linux games are closed source and cross-platform, whereas most other Linux software is open source and often Linux-only, or even if cross-platform dominated by its Linux use. This game engine is open source, and no doubt the developers have a fondness for Linux because Linux is the centre of gravity of open source stuff, but it probably isn't primarily for Linux users. So its main method for being acquired isn't going to be through Linux distros, it's going to be through portals that Windows and maybe Mac people use, and because it's a game-related thing, that will be a game portal.
Long story short: Normal Linux software comes from your distro's software manager thingie, game stuff comes from Steam or GoG or Itch. There is nothing to be upset about here.
1) A large family of distros using apt with a graphical front end, whether Synaptic or something called "Software manager" or something
out dated softwares, with an outdated list of what is avaliable for linux.
"This game engine is open source, and no doubt the developers have a fondness for Linux because Linux is the centre of gravity of open source stuff"
that explains why construct didnt had an version for linux? sigh
"There is nothing to be upset about here."
except that canonical made 0 dollars on their store, and now they dont care about the desktop anymore, the ones who do is valve.
Last edited by Purple Library Guy on 4 November 2018 at 7:13 am UTC
I'm not clear what point you're making.I'm not either, they lost me completely.
See more from me