I recently switched almost entirely from Unity to Godot 4.0 (not a career game dev, I just make small/indie/itch.io type stuff) and I've been absolutely loving it. It's such a breath of fresh air. It's light, fast, easy to learn, and can do 90% of what you need as a solo/indie type developer.
The only thing stopping me from swapping over entirely and giving up Unity for good is the bug that means games take forever to load on itch.io if the user has MacOS (long enough that they think it's broken and close the tab). A majority of the games I make are educational and/or targeted at kids who are using iPads or MacBooks, and being able to link them to itch.io is a LOT easier than teaching them (and convincing the device owner) to install the game locally.
They say they're working on it (quoted below), but until then I'm pretty much stuck using Unity for a few projects still. If/when they fix this, I think Godot could really take off for the itch.io/gamejam/etc type crowd.
> As of 4.1 web exports still have some limitations due to poor vendor support of certain modern features. Browsers with bad WebGL 2 support, such as Chrome on macOS, unfortunately suffer from issues which we cannot address without a fix from Google or a significant amount of effort put into supporting a dedicated WebGL 1 / GLES2 renderer.
> We are also aware of the complexity setting up web games on hosting platforms which don’t let you set the required CORS headers for SharedArrayBuffer support. This mostly depends on Safari implementing the coep:credentialless header support, while Chromium-based browsers and Firefox already work fine (especially if you publish on itch.io). There is a possible workaround that we are investigating.
I'm in a similar boat, and eventually realized that Godot 3.5.2 is still the LTS version and still exports just great for the web -- this is the example that convinced me it was time to switch:
https://yet-another-lucas.github.io/plumbing-adventure/
After I realized this, I decided to switch from Godot 4.0 C# to Godot 3.5.2 with GDScript and I've been happy ever since. I've even got it set up with a CI/CD pipeline to automatically build-and-deploy to Github Pages whenever I commit to master -- these CI/CD pipelines are pretty sweet.
This was a while ago, he recently put out a ton of new tutorials for Godot 4, good stuff for quickly getting your hands dirty. You're beyond that point I'm sure, just throwing them out here for anyone else looking for nice intro content.
Thank you for the link! I didn't make the linked example -- my work is MUCH simpler than that. :D This was what someone else built and packaged and convinced me that this performance is finally rivaling the Flash experience that I've been missing for so long.
I would say Heartbeast's courses are overall much better than your typical tutorial content, primarily because they are structured and built like courses rather than tutorials. I paid for a couple of his courses a while back after doing one of his free ones and do not regret it, they were excellent.
I've built 5 small browser-based game-jammy games (e.g. nothing that took me more than ~2 weeks) in Godot 3.5 this year[1] and have largely enjoyed the experience - I'll echo other folks and say that you might just be happy using Godot 3.5 until Godot 4 has functional web exports.
Godot 4 _does_ come with some language improvements that I'm excited about, particularly around better typing support and fewer places where you need magic strings (e.g. you can refer to signals by name!) - I suppose if that's a big sticking point for you (totally reasonable!) then waiting might just be better.
I will say that at times I've been frustrated by the Godot 4 team's perspective that the MacOS breakage is a Chrome bug and not a regression in Godot[2]. It's really a question of semantics and prioritization more than anything but it's hard for me to not see the behavior as a regression when a feature that I rely on in Godot 3 is broken in Godot 4.
That said I'm very grateful for all the work that's gone into Godot 4 (and prior versions) and I'm very excited for the day that I get to use it!
> Browsers with bad WebGL 2 support, such as Chrome on macOS.
This caught my eye. I haven't run into any WebGL2 problems so far on Chrome/macOS, would be interesting to know what specifically those problems are (however I'm also staying away from some WebGL2/GLES3 features which are known to cause trouble not just on WebGL2, mostly uniform buffers and generally some buffer update patterns that work well on native, but not on WebGL (such as 'buffer orphaning').
Any opinion on the state of VR on Godot? I’m using UE4 which I have 9 year’s experience in and not the biggest fan of Unity but would be curious to try out Godot.
It’s a dream compared to UE. I tried on and off over a couple years to power through building some toy VR apps in UE and was never really able to make much progress past their prefab maps. It’s just so freaking complex that, IME, the fun of the process gets crushed under the weight of making zero forward progress.
As I started a NixOS immersion program a few months back I was looking for a new platform that I could do 100% of my dev on Linux. Ran into godot searching vids on YouTube and was really impressed with the workflows so I installed godot and steam (home.packages = [ pkgs.unstable.godot_4 pkgs.steam ]). With openXR support built into godot 4, it automatically picked up the shared lib that stream dropped and in under an hour was walking around using my index and Vive in a VR env and could also build a package for my son’s quest.
Within a month on-the-side I had built a tabletopesque tank battle game with a custom ray-based suspension over high poly terrain, particle effects, ballistic artillery, and a unique controller input scheme based on the tilt of the controllers (left for body rotation, right for turret). The physics engine is great, rocking the body on fire was simple as an inverse impulse of the shell spawn vector, and the body properly rolls under both lateral and longitudinal axis by virtue of the damped shocks.
All that to say, I think the biggest difference is that with godot 90% of my effort, code, and time was spent writing implementation code for my game while on UE it was spent writing integration code.
You obviously miss out on hot topic things like nanite et al, but I learned a long time ago that fidelity has no correlation with an engaging game. The other con will likely be around performance, it’s passable at 90hz, but if you want to start hitting framerates like 144hz, the critical code will probably need to drop to C++ using GDExtention.
I’ve also noticed that, with the popularity gaining in gltf, that it was rather trivial to find quality assets with native support.
I just very recently started working on a VR game in Godot and the setup was very easy. They also have a project where common parts such as teleporting are implemented, which I didn't try yet, but which seems cool.
I'm a macOS user who makes games using Godot and publishes them on itch.io, and I haven't experienced this issue. Can you link to an example where this occurs, and provide some information on how the build was exported?
This is definitely a known issue that I've personally experienced but is even listed as a warning on the docs[1].
> Godot 4's HTML5 exports currently cannot run on macOS and iOS due to upstream bugs with SharedArrayBuffer and WebGL 2.0. We recommend using macOS and iOS native export functionality instead, as it will also result in better performance.
> Godot 3's HTML5 exports are more compatible with various browsers in general, especially when using the GLES2 rendering backend (which only requires WebGL 1.0).
Web exports are essentially unusable for Mac users. It's the biggest complaint I get from my games using Godot 4.x.
I have both installed and am migrating a game between them now. I don't believe I've actually exported the 4.x version for using the HTML5 profile just yet, so I'll have to give that a go.
It'd be worth your time before you get too deep. The two issues that I ran into:
* CORS issues -- deploying on some sites (esp. gitlab and github pages) runs into issues because of shared buffer requests.
* Assuming you get past the CORS issues, there is still extremely slow load on OSX Chrome -- the app eventually loads, but holy smokes it takes forever.
Both of those nearly made me give up on Godot, but I'm very happy to stay with 3.5.x until those get resolved.
Thanks for the information. I am mostly migrating the game to get a first-hand idea of some of the changes I'm most likely to run into while developing the next one.
I, too, am happy to stay with 3.5.x. It works pretty well for my purposes, though hopefully 4.x will be a viable option for me soon.
> I recently switched almost entirely from Unity to Godot 4.0 (not a career game dev, I just make small/indie/itch.io type stuff) and I've been absolutely loving it. It's such a breath of fresh air. It's light, fast, easy to learn, and can do 90% of what you need as a solo/indie type developer.
There were concepts I've used in Unity that I didn't really understand until I'd rebuilt them in Godot. Everything feels more lucid on that platform. If nothing else, it's the best Unity tutorial on the market.
It's worth noting that Godot 4 is using actual .NET instead of Mono, so you get all the tooling support that implies, including seamless debugging with Visual Studio, etc. Unity has been promising that transition for years, but I'm pretty sure they're still using some customized version of Mono.
So you can write a game with .NET 7 and everything is great. There's a little bit of extra overhead when making calls into the Godot engine, so you still may want to use bits of C++ for performance where it matters, but otherwise there are only a few rough edges left.
Unity wants to transpile it to C++ code. IL2CPP where they take the IL code of your C# and translate it into C++ for speed. So yeah, not only are they NOT using dotnet tooling but they are going the opposite direction.
It works relatively well, and actually better than in Unity (which use an older C# version), but unfortunately it does not work everywhere. For example, it's not possible to export to the web, which was to me the main show stopper. I needed C# due to some libraries, and I needed that it runs in a browser, so that was game over, no pun intended.
Apart from that, I really preferred Godot over Unity. Faster, more consistent, better learning curve, etc.
Are you sure it can't export c# to web? I would have assumed that as true but Godot's documentation does not list that as a limitation, and in fact offers c# code on how to use the JavaScript interop, something that would be pretty meaningless without support.
> Note that as of this release projects made with C# still cannot be exported to mobile and web platforms. We are working on providing the support as soon as possible, but the resolution of this limitation will likely depend on the release of .NET 8 at the end of 2023. This means that the work on enabling mobile and web platforms can only truly start later this year.
It's still a bit janky compared to their own GDScript, but C# is supported yes. Because there are two languages though, and C# is the second class citizen, you won't find as many examples on how to do things in C# as in GDScript.
Thanks for the input. Given my background, I think I can figure out the syntax just fine if necessary. I am just sceptical of languages where typing is not strictly static (and I give a hard pass on pure dynamic typing).
FYI a lot if not all of the core docs actually have tabs on any code samples to switch between c# and gdscript so while tutorials from third parties tend to focus on one or the other, the core docs are a bit better.
I've started going through a tutorial on youtube from I think finepointCGI about a horror game in Godot, he is actually doing it twice, once with GDScript and once with c#, so if you want to see someone with some godot experience using c# give it a look.
> ...who are using iPads or MacBooks, and being able to link them to itch.io is a LOT easier than...
The instant game streaming service I develop targets Unity (see https://appmana.com/watch/virtualtestdrive for an example) and I was considering supporting Godot. But it would probably make more sense to fix web exports.
Other than time and money, what obstacles did you face contributing a web export fix for Godot? I am not saying that you should, but I'm sure it crossed your mind.
In the game services business, it's my opinion that in order to thrive, you target people who pay. Because Unity costs money, it attracts developers who pay. It's the halo effect. I wonder how the Godot ecosystem attracts developers who pay.
Godot is a super impressive piece of kit. I'm waiting for a reason to start a new game project so that I can get to grips with it more firmly, but what they've been able to do with a relative small team puts Unity to shame. (Even more than Unity puts itself to shame)
> This update fixes over 900 issues that users have reported from using Godot 4 or while helping contributors test 4.1 with pre-release builds.
Fixing that many issues while further improving performance and stability is itself worthy of commendation. Well done Godot team!
Godot's issue tracker is very popular! There have been ~4700 issues created this year, more than half of which have been closed, with ~2000 currently open.
Also of note, there's an open proposal[0] 'Automatically close old issues in a way everyone should be happy with' attempting to deal with the significant backlog.
Actually it's 8000+ open issues on Github. It seems the number is capped at 5k in the header of the Github webpage. On the other hand, it's got 34k closed issues, so it's not as if the devs weren't working on this
* gdscript is not python, it's lacking several small python things that makes python awesome: list/dict comprehension, .items(), sets, although gdscript is quite enough and still quite a good language for game dev as it does just everything well, especially for natives types etc.
* I tried gdnative and I still need to try gdextension, but so far writing C++ for godot seems quite hairy and the programmer must use godot types and "new()" everywhere, which is not really easy to deal with, so godot is not really a C++ engine, C++ is only usable if you want to optimize something a bit tedious, which is fine, but important to remember, and it confirms the whole "use a scripting language 99% of the time, and use C++ only if scripting is not fast enough"
* I would still want to inspect the real potential performance of gdscript compared to other languages, and I don't know if mono/.net is faster. It seems like a very good language especially because it integrate perfectly with how the environment is designed, but I'm still curious if they plan to improve it.
* I'm planning to make a multiplayer FPS game, but I don't think godot provides network prediction, and I wish it did.
* I'm a bit worried about opengl support in the future, it's not entirely done yet, and I'm afraid it's too difficult to properly implement because new API like vulkan or DX12 are so radically different.
Overall godot is the greatest thing that ever happened to open source and game development, game development is one area where open source has trouble making its teeth, and the lightweight design of godot makes it just such a big relief when you compare it to monsters like unreal and unity.
> gdscript is not python, it's lacking several small python things that makes python awesome: list/dict comprehension, .items(), sets, although gdscript is quite enough and still quite a good language for game dev as it does just everything well, especially for natives types etc.
This is my biggest issue with Godot, although not that GDScript isn't python, its that it isn't a "real" language (or I guess general purpose might be a better word). In fact its probably the only thing I miss from Unity.
To be fair I'm not sure I'd pick Python myself, as much as I love the language I'd probably pick something with a bit more focus on performance. Go might be a good choice, I dont know.
It's not even that GDScript is bad, in fact without comparing it to other languages its pretty great, but you just lose so much when compared to general purpose languages. I know theres bindings, but having done the same with Raylib the support for non-official languages is pretty much non-existent. Its pretty bad for Mono, which is an official binding
The docs have c# examples, but the community by and large uses gdscript, it's the "default" language. Again, it's the same with Raylib, bindings have documentation but it's difficult to find anything using that language outside the docs.
Yes, .NET is faster.
Though even AAA games often use slow scripting languages for game logic. Many games, the game logic just isn't a big CPU hog so it doesn't matter.
What does network prediction from a game framework look like? You describe what properties of objects should be interpolated and the engine handles it for you?
I tried this when Substance was aquired by Adobe. Surprisingly I found it much easier and enjoyable to use. Substance Designer feels very clumsy.
Of course Substance Designer has one unique feature, which is it's integration with Substance Painter. MM has some manual painting capabilities, but it's not a full-fledged painting app.
Material Maker is surprisingly alone in the PBR material department for FOSS, I have started thinking about diving into the PRs just to get it up to snuff with Substance. I can hardly pay for Photoshop, Adobe!
Expanding on this, Godot has its own 2D widget framework that's fairly straightforward to use, though it doesn't use native widgets.
Note that the Godot editor itself is written in the widget framework, so you can get a sense for how well it works just by opening Godot and clicking around.
The 2D framework, especially for UI, is pretty awesome. But the learning curve on the layout system is quite sprinkled with head scratching and frustration in my opinion.
Yeah it's brutal. I've been using Godot professionally for years. I have effectively mastered the layout system but it was annoying to learn. It tries to be like Unity's system but they made a few mistakes with Pivot, Grow Direction and Size Flags imo.
I made a tool to position nodes in a way modelled after Cocos2D, with a position, pivot and anchor point.
I've made a series of small tools to help me lay stuff out.
One really good thing about Godot Ui is the "StyleBox" which simply allows coders to make rounded rectangles, which are so frequently used in UI it's nice to not need an artist to make a .png
As someone who has never made a game, I really want to make a tower defense game that fixes shortcomings I find in others - where would one complete beginner delve into Godot to accomplish starting to learn the system - there are a number of tuts on YT - one of which is ~11 hours long.
Can you make some suggestions to avoid/pre-empt any said headscratchings and frustrations?
You are going to scratch your head and be frustrated. Just keep going! Imagine your asking "I want to make a rock song that is better than the other rock songs. What youtube video can I watch to learn how to play the guitar?"
I usually recommend GDQuest on YouTube. Just start! Keep going! You'll figure it out.
Start with something small/easy to get the basic concepts and just keep going from there, like you'd do with any other skill. Making a Flappy Bird clone (for example) has become the Hello World of game programming.
Godot is just AWESOME, I am very impressed with the progress the team makes and the overall direction of the project.
I was always excited about Game Dev (even started learning Computer Science and became a Software Engineer largely because I wanted to make games), dreamed of making my own small games but never really got to it. After I became a full-time Software Engineer, I never really found time or the right tools for making my own small games for fun. I recently discovered Bevy and gave it a try. ECS is a nice concept, but Bevy is more of a library and it's quite hard to make full-featured games using it (just like using SDL/something similar).
When I discovered Godot and gave it a try, I was so impressed: it's really nice for beginners, yet performant enough and has amazing community. This is exactly what I wanted to find, so I'm incredibly happy it exists and am very excited about the future development of Godot.
One thing I wish was different is choosing a different language as the native and "official" one. GDScript is OK and arguably pretty good Python-like language for beginners and rapid prototyping, C# is OK and is probably very nice to have because many people would be happy to switch from Unity, but I personally would be happier with either better C++ support (which I know exists in GDNative interface which was improved in 4.0) or something else.
C# is a fine language, but I have a feeling it has so much presence in GameDev just because of Unity. It's way too verbose and the tooling isn't as good (outside of full Visual Studio which I have no desire to use), but maybe "actual programming" part of GameDev isn't as important and I should just give in/use GDScript.
Yeah, I've seen those and I'm happy Godot moves in this direction, but using these tools would steer me away from the "default" and "primary" behavior, I'd potentially face more bugs/awkward development setups.
It might be worth if I'm serious about Game Development and ready to invest time and effort into customizing the tools, but what I'm looking for is "out of the box" experience which will make it easier for me to solve problems that I face (e.g. if I ask questions more people would be able to answer/help), the tutorials/resources I find will be more applicable etc.
As others mentioned in this thread, having first-class support for a language isn't the same as providing API for plugins and custom scripts.
I wish Godot chose a real existing programming language instead of building their own DSL. Even Lua might have been a decent choice, although I hate the syntax.
Unity is it's own beast like Unreal but in a different way, Unity as a platform supports mobile monetization in a way other platforms don't and Godot won't be cutting their lunch in that ecosystem any time soon.
But I suspect you mean for indie dev, in which case I totally agree. Godot is the lightweight, get out of your way and build shit framework that people want Unity to be. Godot is better at that task by a long shot.
It's very telling that Unity is where it is because of monetization.
Godot on the other hand is being picked up because it's an excellent engine. Maybe it's not going to kill Unity, but it's certainly going to relegate it to a shovelware low effort money grab engine.
> It's very telling that Unity is where it is because of monetization.
No, it's absolutely not. It may happen to have mobile monetization features built in but it's where it is because it's been the best general game engine for everything other than AAA 3d games, although Godot is catching up.
> It's very telling that Unity will keep getting used because of monetization.
Once upon a time it was a good engine.
Nowadays it's an absolute mess, and it's been that way for a long time now.
I am not a game developer, I develop prototypes in my spare time because I have fun tinkering with engines, and with Unity it doesn't take long before it becomes borderline unusable. I don't even want to imagine the struggle devs need to go through to make a full scale game playable, and those struggles prevent them from focusing on making the game actually fun to play. But, thanks to the deeply integrated monetization system, Unity is THE standard if you just want to make a game quickly to shove ads in people's faces every time they die in your simple, yet extremely buggy mobile game with stock assets. Is that a good thing? It depends, but I'd lean towards no.
It would be insane to even try to compete with Unreal, an engine focused on AAA games that's been around for decades, with a large full-time staff. No open-source project will ever match them, because it's a moving target.
Fortunately Unreal Engine is a poor choice for many types of games, and Godot is doing a great job carving out its niche with 2D games and simpler 3D games. There's still a big market for 2D games, and surprisingly there aren't a ton of engines which do a good job supporting them. Godot is easily among the best.
I mean the problem is 2d game tools isn't getting loves for some time. Paper2d which is the main component of UE for 2d games still haven't updated with UE 5 last time I checked. So it misses a lot of feature parity.
Godot is really turning good release by release. I'm very happy for Godot and the team. I'm interested in these features from Godot in future. I hope they implement them in Future Releases.
1. FSR2
2. Excellent Wayland Support
3. LLM Integration. It might make NPCs more realistic
> 3. LLM Integration. It might make NPCs more realistic
Not sure. That doesn't seems game engine related and more game specific. I think integrating LLM is just some scripting in your game.
In terms of AI integration, I would be more interested in AI supported design. Like you describe a map, character or scenario, and the AI will generate something for you, which you then can customize and adapt. But even that is probably best done outside of the core game engine...
Disclaimer: I'm the founder of the company that produced this course, but the tutorial is free and the custom assets used in the tutorial are liberally licensed.
A lot of tutorials you'll find will be for Godot 3 so be sure to search for Godot 4 specifically as a filter. Otherwise be willing to take into account that you'll have to figure out how to make the tutorial code work for your version of Godot (which can be an educational experience in and of itself.)
I've done both the official 2D/3D game tutorials in the official documentation, and although the 2D game tutorial wasn't that bad, the 3D tutorial was quite disappointing as a learning experience. It's still not ported to Godot 4, and they use some weird hacky code to achieve some basic gameplay stuff. (And the finished game itself isn't really that interesting...) Even the 2D tutorial leaves something to be desired, since it just dumps heaps of instructions/code at you without explaining you a more general picture first (which wouldn't be a problem for more experienced programmers, but beginners would definitely struggle)
That said... it's still the most comprehensively written Godot tutorial to date, so I recommend at least trying out the 2D tutorial.
gamedev.tv has a godot course updated for 4.0. I haven't gone through that one but their other stuff is really good. Just wait for sale. they usually go down to $10-$15 for a course.
I have shipped two small projects using Godot 3. It's a cool engine but to me it can improve on the following points to be considered a mature engine for a new indie project:
* GDscript is cool but lacks features such as better typing and lambdas over generic nodes.
* I have encountered many bugs in the Engine more than when I was using GameMaker.
* It lacks native mobile monetization.
Other than that I'm much more enjoying working with Godot than Unity.
The focus in this release was on bringing feature parity between C# and GDScript.
When using GDScript, you can define a new node type to use in the editor by adding a global class name to your script.
Starting from Godot 4.1, this is also possible in C# by adding the [GlobalClass] attribute to your file, thanks to Raul Santos and Will Nations. You can also use the [Icon] attribute to give your global class a unique icon.
Note that as of this release projects made with C# still cannot be exported to mobile and web platforms. We are working on providing the support as soon as possible, but the resolution of this limitation will likely depend on the release of .NET 8 at the end of 2023. This means that the work on enabling mobile and web platforms can only truly start later this year."
Until godot devs don't forget the "-static-libgcc -static-libstdc++" compile/link options, should be fine, that linking with the oldest set of glibc libs as possible (I saw games carefully using the glibc from debian ubuntu 12.04).
I guess godot has proper vulkan->GL fallback.
What's now really missing is from sourceware binutils: fine grained control of the versions of the symbols to use while creating binaries. And then, robust game binaries would be much easier to produce: it would let the devs use the latest elf/linux distro and still produce compatible binaries with old elf/linux distros (easy planned obsolescence workaround) avoid the current massive mess (build an old glibc, and reconfigure the toolchain to use it for linking, PAIN).
> What's now really missing is from sourceware binutils: fine grained control of the versions of the symbols to use while creating binaries.
I did actually prototype an idea for attempting to fix this. The tool would take a list of symbols from a text file and produce a (non-functioning) .so file that ld can link against. The newly created .so file can be injected in via an environment variable (LIBRARY_PATH iirc).
Since the list of symbols is just text, it's easily modified to contain only the one's that you want to target.
It's not a complicated tool to write, but there are some issues like how to reliably get ld to pick the correct .so file when you're overriding an existing on, LIBRARY_PATH is not 100% reliable. The other issue was if it's nessassary to recreate all the symbol types (like weak, etc..) exactly, I'm not sure exactly what's required for ld.
The text file would map simply a symbol to a version, to be overridden in the generated ELF binary (exe or SO).
That way, the game devs don't need to build the "old" SOs and reconfigure the toolchain to use them, which is unreasonable to ask them (but this is expected from game engine elf/linux devs like unity/unreal/godot/etc) and a MASSIVE PAIN to make work properly (exponentially proportional on the abstraction level of the game/engine build system).
I correct myself: just overridding is shabby, once the linker has selected the the version of a symbol, it will pick the binary objecti(.o) where the this version is. And the semantic/dependency can vary from one version to another. See libc_start from glibc 2.34.
So I think we may have our solution to make the life of developers of binary-only distribution on elf/linux (for instance games) much better.
sourceware binutils ld need a "version selection" file which will define binary compatibility of the produced binaries.
Could someone advise if this is a suitable platform and language for 10 year olds to learn Game programming ? My kid feels that he has outgrown Scratch and he is looking for a better platform . Will GDscript be easy for him to learn ?
I haven't used Scratch but I think Godot might be one of the easier engines to get into compared to Unity and Unreal Engine. GDScript (https://gdscript.com/) is a custom language created for Godot and is similar to Python so it will be more complicated than creating games with Scratch since you will be writing out code explicitly rather than dragging blocks together. GDScript is immensely easier to use than C# (Unity) and C++ (Unreal), though.
It might be worth looking at GD Quest (https://www.gdquest.com/tutorial/godot/learning-paths/gettin...) to determine if it's something your kid would want to learn and get into. As a developer, I found it very easy to start to get started with Godot versus Unity and Unreal so it might be a fun adventure for your kid to start learning :)
I've been doing Godot development with my 9yo and he loves it. If you're looking for something with less emphasis on text based programming Construct and GDevelop are engines I've heard good things about as a continuation from Scratch.
To add to this I found these tutorials good starting points for a structured lesson with my kids. Would do about 30m-1h a day (mostly up to whenever they get bored). When we started off we'd focus on letting them run the GUI changes and I'd work on the code and explain the concepts to them until they started wanting to do the coding themselves.
After that my son wanted to switch to making his own game so we've been re-implementing boss fights from cuphead and lately he wants to make an idle game.
I've also found its fun to just get them to be part of the design process in game jams. It's really great to see the creative ideas that come out of young kids and game making with kids has been super fun and educational.
Great to see a focus on reliability, I moved back to Godot 3.5 as 4 kept crashing for me so I've been missing out on some of the new features (suprisingly, the one I was most excited about is the improvements to procedural skyboxes, and they certainly lived up to the hype)
If you're using WorkerThreadPools or HTTPRequests be careful - some change they made to threading broke one of my projects. Nothing else seems to be affected so far.
I like the engine, but the name is essentially one that has no consensus on how it should be pronounced (emphasis on the first syllable, emphasis on the second, or equal emphasis on both).
Unreal has everything in 3D game development. On the downside, Unreal has everything in 3D game development. Godot can definitely make 3D games, but if you need Unreal level tooling, there is only one choice. 3D games are definitely possible in Godot.
I see the 2D comparison much stronger for Godot. The biggest draws for Unity are if you already know it, you are already excellent with C#, or if you need to deploy to consoles.
Godot has everything I've wanted in 2D development (as a serious hobbyist). I can get straight into the source code and modify the engine as needed. I really, really like the composition model of building out nodes, Godot and it leads to excellent code reuse. No licensing issues at all.
Asset stores are definitely better for Unreal and Unity.
As a hobbyist I'm incredibly happy with Godot. I could definitely see it for 2D PC development. If I had consoles in mind Unity.
Anything 3D I would invest my time in Unreal. Godot might be able to handle a current 3D project, but as I move on from that project I would be looking at Unreal with envy.
Well done. Just tried it. Perfect causual game and even if I recognize the game play (not a bad thing) it was actually more fun hitting shoppers with my cart!
I'm going to guess they set a requirement of C#/.NET to help their move from Unity, which currently isn't supported for iOS and Android as of right now.
"As of Godot 4.0, exporting .NET projects is supported for desktop platforms (Linux, Windows and macOS). Other platforms will gain support in future 4.x releases."
i have seen a lot of folks talk about switching to godot due to unity “selling out”. but if godot gets popular enough, money will be waved in the maintainers’ faces, and it will follow the same trajectory.
meanwhile, there are alternatives like love2d, which is a more straightforward game engine written in c++ built on popular open source libs like sdl2 with a extended with lua(jit). it’s lightweight enough that you could probably maintain it yourself.
There are four differences between Godot today and Unity circa 2007 that make this unlikely:
1. The Godot trademark is owned by the Software Freedom Conservancy, and not the original authors or their company.
2. The founders do have a consulting/support company, W4Games, but it is not Godot Inc, and because of point 1, can never be. Secondly, it is not afforded any special place in the project leadership structure. W4Games employees account for 2 of 9 leadership positions in the Godot project leadership. This is overseen by the SFC who would not permit a company to have too many seats.
3. The founder's company also does not have overwhelming control of contributors. Of the top 10 contributors, numbers 1, 2, and 7 are part of W4 Games inc, but all of the top ten have significant contributions.
4. It's open source. This is less of a deterrent than the above, since it's MIT licensed so someone could make a closed source fork, but they would have to compete with the community in that case.
Actually the reason that most people don't like Unity is because the goal of the company seems to be to create a million half-baked, fancy-looking ideas rather than creating a solid experience with the core engine. Even today there are still very weird and difficult to circumvent bugs that come up in almost every project, even in trivial ones. Also, the last time I used it all of the old forum threads had been partially corrupted.
with regards to love2d, they are no on the same "market" (I have made hobbyist game in both)
love2d is really the most minimalist things you can call a game engine, i.e quickly you have to resort to 3rd party library , even for something as simple as 2d collision or the ECS system. If you know perfectly what you are doing it's probably better.
Godot is much more battery include so for an experienced programmer it may feel too opinionated.
my own experience was that, while I'm a web developer for 10+ years, I'm really new at game development, and love2d was easy at first but soon a pain because I hit a ceiling glass of "my game has become too complex and I don't know the design pattern of game developement". At the opposite Godot was a pain at first, especially as a Vim user, i.e why do I have to use this GUI, but once I got used with the tool by following some step by step tutorial, I felt like sky was the limit.
The only thing stopping me from swapping over entirely and giving up Unity for good is the bug that means games take forever to load on itch.io if the user has MacOS (long enough that they think it's broken and close the tab). A majority of the games I make are educational and/or targeted at kids who are using iPads or MacBooks, and being able to link them to itch.io is a LOT easier than teaching them (and convincing the device owner) to install the game locally.
They say they're working on it (quoted below), but until then I'm pretty much stuck using Unity for a few projects still. If/when they fix this, I think Godot could really take off for the itch.io/gamejam/etc type crowd.
> As of 4.1 web exports still have some limitations due to poor vendor support of certain modern features. Browsers with bad WebGL 2 support, such as Chrome on macOS, unfortunately suffer from issues which we cannot address without a fix from Google or a significant amount of effort put into supporting a dedicated WebGL 1 / GLES2 renderer.
> We are also aware of the complexity setting up web games on hosting platforms which don’t let you set the required CORS headers for SharedArrayBuffer support. This mostly depends on Safari implementing the coep:credentialless header support, while Chromium-based browsers and Firefox already work fine (especially if you publish on itch.io). There is a possible workaround that we are investigating.