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.
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.
https://www.reddit.com/r/godot/comments/q25riu/hosting_on_gi...
Nice, I made a version of that game myself following the tutorials of https://www.youtube.com/@uheartbeast
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.
It took a good 20 - 30 seconds for me.
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!
[1] They're all over at https://eieio.games/ if you're curious!
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').
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’d recommend watching some vids on creating VR apps, and another great resource, if you want to grok the interface code, is godot’s xr-tools project: https://github.com/GodotVR/godot-xr-tools/tree/master/addons...
> 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.
[1] https://docs.godotengine.org/en/stable/tutorials/export/expo...
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.
This was a killer feature for Unity over Unreal. If Godot has similarly good integration, it looks like a better choice.
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.
Apart from that, I really preferred Godot over Unity. Faster, more consistent, better learning curve, etc.
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.
Here are some issues worth tracking: https://github.com/godotengine/godot/issues?q=is:open+is:iss...
> 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!
Again the number of open issues is not a good indicator of software quality anyway.
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.
[0] https://github.com/godotengine/godot-proposals/issues/3481
Certainly one of! I'm only aware of flutter/flutter and rust-lang/rust outranking it.
* 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.
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
It's only useful for latency sensitive games like FPS games or any games that involves simple physics with player versus player situations.
Pixel art editor: https://github.com/Orama-Interactive/Pixelorama
Infinite canvas drawing tool: https://github.com/mbrlabs/Lorien
Trello-style kanban board: https://github.com/alfredbaudisch/Godello
Narrative designer for games: https://github.com/mhgolkar/Arrow
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.
OpenSCAD Graph Editor is done with an earlier version and runs on Mac OS, Windows, and Linux:
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.
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.
They might be worth looking into.
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.
Excellent engine, and more and more developers are rightfully recognizing its potential.
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.
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.
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.
Do you have some examples? Seeing these 2d games made me question some assumptions I heard [1].
1. FSR2
2. Excellent Wayland Support
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...
I've got a small RPG prototype that runs in the console but would love to give it an actual GUI/sprite graphics.
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.
As someone who is switching to Godot from Unity however, I think the tutorial ecosystem for Godot is a long ways behind.
He recently put out one for Godot 4 specifically. https://www.youtube.com/watch?v=M8-JVjtJlIQ
https://www.youtube.com/playlist?list=PLwYfcDZR0fFcROLjkiyBW...
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.)
[0] https://docs.godotengine.org/en/stable/getting_started/intro...
https://godotengine.org/article/we-hired-gdquest-work-manual...
I absolutely recommend GDQuest courses, apart from the Godot engine they have a very clean idea about writing software.
That said... it's still the most comprehensively written Godot tutorial to date, so I recommend at least trying out the 2D tutorial.
I also compile Godot when I use it so I can read the source and step thru stuff if I ever have a problem.
I get paid to use Godot tho, and am a contributor, I'm not the typical user.
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."
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).
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.
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).
While any "old" symbol version is not removed...
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 :)
https://docs.godotengine.org/en/stable/getting_started/first... https://kidscancode.org/godot_recipes/4.x/games/first_2d/ind...
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.
Some background here in the context of the original play from which the name is derived - sorry about the paywall: https://www.nytimes.com/2013/11/12/theater/the-right-way-to-...
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.
Godot is much easier to learn and use imho. And being open source means you have access (unlike unity).
(What, nothing? I'll show myself out.)
Why did they have to invent GDScript? Is there any reason why they could not have chosen a existing language?
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.
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.
Yeah just like when Blender got popular, the developers sold it out and now it's a shitty piece of software.
Haha, just kidding. The above never happened and Blender is still getting better every month.
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.
I think DeFold is closer to that.
Oh god, it uses lua.
