If you want mass adoption, you need to make it financially viable for commercial indies to use your engine, and good luck convincing those people if they know they need to hire a 3rd party company to port to consoles.
Since Godot can't really go the console route, though, they basically need to do the work of figuring out how their users can make enough money on just web, mobile, and/or desktop, and then articulate and successfully sell that solution to them. Steam Deck could help for sure, but it's a big ask
https://godotengine.org/article/godot-consoles-all-you-need-...
https://godotengine.org/showcase
Looking at any of thoses games looks bad tbh it's like weekend project / low indie games.
If Godot lets you make games like that in a weekend, then it's lightyears ahead of Unity.
Here are some other games
Carol Reed Mysteries[53] (since 2021) Commander Keen in Keen Dreams (Nintendo Switch port only) Cruelty Squad Deponia (iOS and PlayStation 4 ports) The Interactive Adventures of Dog Mendonça & Pizzaboy Hardcoded Kingdoms of the Dump Sonic Colors: Ultimate
Cruelty Squad is probably one of the best selling Godot game yet its missing from that page.
The games in that showcase look pretty decent to me? Plenty of games I play look like that, lol.
- Asset store. I totally get it, handling payments, curating, etc. are a huge task... but man, I'm a coder, and I don't have the funds to pay an artist or a musician full time. Being able to just go buy a pack of trees for $20 or something is a huge timer saver.
- Animation re-targeting. It seems like there's a 3rd party plugin for this but it also seems like it hasn't been updated in a year. In unity I can buy a big pack of animations for pretty cheap and reuse it on almost all my humanoid characters. That's huge. I think this can be done in Blender or Maya, but it's so seamless in the engine compared to using a 3rd party tool.
Heh I mentioned this in another Godot thread a few days ago. It sounds like a potential YC funded startup for anyone inclined and something that could be with the knowledge and collaboration of the core maintainers of Godot as a simple means to fund Godot.
I would encourage you to try some of these! You'd be surprised how far you can get by using these, with and without modification.
These are my favorite resources, in order of preference.
- <https://www.kenney.nl/> is by far the best one and most expansive one. Everything he creates is CC0. A lot of great free assets available on his site. He also has a "Kenney Game Assets All-in-1" which can be bought on itch.io for $19.95. It has all assets he's ever made, neatly organized, and ready to use. All CC0. This also includes some music. The music and sound assets are much more limited than the 2D and 3D assets, but it's there, and it's solid.
- <https://kaylousberg.com/game-assets> has some fantastic assets also available for free, and has more available for a pretty affordable Patreon tier. Also has a CC0 license for the free assets. Mostly a specific style, which is great for consistency, but a bit more limited than the wide variety of Kenney; but I don't doubt that with time they'll build an equally strong library of assets.
- <https://quaternius.com/> has many free great assets. Also CC0. Has a high variety of styles and settings. Also has a very affordable Patreon to get easy access to everything they produce.
- <https://github.com/Miziziziz/Retro3DGraphicsCollection> is a general place linking to more assets that should be usable.
Separately from this, itch.io has a section for game assets that has a pretty wide variety.
I also prefer the separation between the engine and asset store. I would rather not have a magic button I press in my IDE to have asset show up in the game.
- Are these assets authored in a way that's friendly to my game engine of choice? IE, will the materials import correctly, will animations be correct, are things scaled properly, is the Z axis up or is it forward, etc. Having dealt with importing files between various engines and 3d modelers, seamless importing and exporting is no small thing.
- What's the license, and are the licenses standardized? Do I have to pay royalties or record attribution?
- What's the selection on these sites? Do I have to enter my payment info into like 20 different sites?
- This also only covers art/sounds. Unity has a huge selection of code assets that are incredibly useful.
None of those are insurmountable of course, but having one place that solves all those problems is great.
"You can technically do the same thing if you squint" misses the point.
Godot is an interesting engine and editor, but that's not enough to make me switch. Show me the ecosystem of services and tools that surround it, and how _utterly trivial_ they are to access, and I might consider switching.
Yeah, that'd be cool. However, there are tools like Mixamo by Adobe that provide lots of pre-made animations.
As for an asset store for paid assets, there are already a few 3rd party sites for this.
Does it need to be a tool specific to Godot? There are other tools that can do this, for example, have you tried mixamo.com?
That said, I have a _few_ items that I think are absolute showstoppers for solo-dev side projects.
1. The asset pipeline is simply not as clean as Unity's. The ability to drop a .blend file in the project in Unity is so underrated. In Godot FBX imports are unreliable, texture imports misbehave frequently, and rigging goes wrong even in the recommended file formats. There's a lot less clarity around the path to getting real assets in game, which can be a major pain point for solo devs.
2. Along the same lines, there is no equivalent of Unity's mecanim. With Unity, if you can model and rig a character in Blender, you can pull free mocap or other animations from the asset store and get to work. In Godot you're still best off authoring your own animations for each character. This drastically increases the amount of time spent making assets.
3. Godot is in a weird spot version wise for anyone who wants to use C#; the beta version of 4.0 is rapidly approaching, and guarantees to break any project you start in 3.x --- but 4.0 still doesn't come built with C# support. Hopefully this gets resolved soon.
I was under the impression that Godot had at least two full-time devs working on it. Between their patreon revenue and the grants they've received they can definitely afford a small team on payroll. It's still important to stress the comparison in scope between Unity and Godot, but the latter is definitely more than a hobby project at this point.
Either way, it seems a lot of people have contributed without sponsorship, but the main devs are (hopefully) compensated.
Myself and plenty of others at small or above size studios would have to make a huge leap into Godot and hope you don't run into any scaling issues. Not just from a project point of view, but integration on the artistic side.
LTS versions of Unity despite the known "un-fun" of it, are stable in a sense. Godot is moving fast, that isn't always a good thing for stability.
I'd love to jump on the new shiny and fun engine! But having to make the definitive choice for a company to make their next project in? Unfortunately just isn't there yet. "It's fun as a dev" just isn't a compelling argument for literally everyone else who isn't the engineer, compared to the number of all size studio pumping out Unity projects(Some even being successful!).
I switched from Unity to Godot in 2016 when 2.0 came out and I haven't looked back since. I find Godot fits so nicely with how I like to make things compared to Unity or Unreal. It has that comfy feeling like Aesprite, sxfr, and bosca ceoil where the tool itself has an artistic expression.
I agree with most downsides that people have in regards to Godot, lacking asset store, lacking in the amount of tutorials compared to other engine, lacking in completed titles at scale, etc.
However for my purposes I've never found these to be a deal breaker, and if anything I prefer being part of the smaller community that Godot has - it feels more grassroots and aligned with my personal values.
Nope. Nope. Nope. Nope, I wasted 2 hours of my life trying to get these signals to work in GD script.
I'm going to try some other open source engines, but trying to jerry-rig an extra language on top of a relatively immature engine isn't a very good idea.
Now I imagine if Microsoft decided to come out of an engine, they could rationalize supporting six or seven languages. But if you're already a small project, what ends up happening is the other language support just isn't as good
I'm looking at some other OSS engines now
It's MIT and fully written in C#.
That's my biggest complaint with Unity at this point. So much is built around the GameObject implementation that when you start using ECS you can feel the friction - you're writing a lot more code, you're doing things in a way that feel like swimming upstream, and there's less support + documentation.
How does Godot compare? Are highly threaded features out of the box? I would use Unreal but the C# Unreal interfaces I've seen are very immature.
If you're doing graphically simple games with a complex simulation under the hood (everyone loves RimWorld as an example), then you don't really benefit from an ECS that's tightly integrated with the engine. You just do all that stuff however you want, and use the engine as an I/O layer.
Maybe 3.x, but I've seen/read some exciting stuff about 4.0's graphics engine
https://github.com/GodotECS/godex
I haven't used it, though I've been curious about it. As far as better options for ECS game engines go, I'd go with Bevy (personally), but you'll have to learn Rust (which I'm a proponent of anyway).
https://bevyengine.org/learn/book/introduction/
But both of these are still in "Beta", if that's even the proper term for their development cycle, at this point. They work, technically, but they could use some help, to my understanding.
Ish. But Godot very much embraces OO. Everything is a node extending another node with messages passed between. But IMO it's OO done right.
I love Godot and I use .NET in my day job, but I feel like C# in Godot has always been a second class citizen.
> .NET (Core) -- A cross-platform and open source implementation of .NET, rethought for the cloud age while remaining significantly compatible with .NET Framework. Used for Linux, macOS, and Windows apps.[0]
[0]: https://docs.microsoft.com/en-us/dotnet/core/introduction
> At first glance, Unity is so laughably ahead of Godot in sheer number of features supported that it seems comical to compare the two.
> In practice, Unity requires 3rd party tools for tweens, timers, and networking, all of which Godot includes out-of-the-box. Still, I’d argue that it doesn’t actually matter for the vast majority of us indie game developers.
It's a framework not an engine though - more programming from scratch rather than scripting pre-existing things in a visual editor.
Is this actually true? I always figured Unity's selling point was being lighter and easier to use than unreal.
Godot looks like Unity from 2008, it's easy to boast efficiency when you have a limited product.
> Godot looks like Unity from 2008, it's easy to boast efficiency when you have a limited product.
Unity does have more features - like more obscure 3D features - but that has nothing to do with how Unity deems it necessary to rescan the project tree all the time. Also, when I used Unity, I never used these extra features, so even if this were true, how come all users have to pay the price for features that only a few of us will use?
Honestly, core Godot is very full-featured, and in my experience the central abstractions are much better thought out than those in Unity. I feel a lot of the FUD around "Unity has more features than Godot" comes from people that like seeing a long list of features, not from people who actually need those features.
- Scalable text support a la TextMeshPro (sdf-based rendering)
- the in-editor console is horrible. it frequently tells me "output overflow, print less text!". wtf? also, it doesn't let me click on a line to jump to the code
- the built-in tile editor is very painful in my experience. the UI is clunky and it's lacking important features I depend on in Unity, like tile rules.
- the built-in text editor is _very_ basic, and support for external editors is limited vs Unity (and hampered by lack of mature tooling for gdscript vs C#)
- gdscript's heavy reliance on "magic" strings and lack of type-safety throughout
- unity's UI system sucks, but it's still more capable than Godot's especially for things
I want better language support and community when working on a project. I want to use nice VSCode plugins that auto format my code (and give type hints... Untyped languages hurt me so much these days)
I can't wait for better C# integration for Godot. It's ok now but I'd love it to be rock solid.
Totally agree. Godot is the first engine I've ever used where I don't feel like I'm fighting with it the whole time to make it do what I want.
Godot is pretty clearly a solid choice for anyone making 2D games, and will eventually be a fantastic choice once we get a stable Godot 4.0 with .NET 6 and other nice features.
The 3D support will be significantly overhauled in 4.x https://www.youtube.com/watch?v=DNJXkcQxXEg and additional enhancements will reduce the need for DOTS/ECS for many. There's also Godex https://github.com/GodotECS/godex that adds ECS to the engine.
Whereas Godot opens up in literally 1 second and boom I am there.
And for 2D projects, there is very little "lacking" compared to Unity. It's way more clear what is going on.
The only two concrete things I can point to are better documentation (IMO), and the first-class signal/observer support in Godot. I'm not sure if that exists in Unity or not, but it's a really intuitive way to handle entity interaction, and I think that makes it way more easy for beginners to get started.
It's unfortunate that Epic ever let Unity persuade people that it's better suited to anything or anyone at all.
I’m not sure what it is but it’s gotten significantly worse over the past few years and I’ve stopped recommending it to new game devs.
The editor itself always seems very buggy. If you have the "Console" open (which you will if you're coding), it's pretty much guaranteed you're going to see a lot of random errors that have nothing to do with even your code. A lot of them don't even make sense or could be ignored. Like you'll get weird asset import errors if you upgrade versions, but a lot of times they're just red herrings and not important. There's also a lot of QOL stuff that's very frustrating, like arrays being annoying to edit (I'm not sure if they've fixed this yet or not). It's also easy to accidentally brick your editor on your own, with debugger shenanigans or loops that don't end.
Also, if you're trying to build a an editor extension, omg was that a nightmare. Just getting things like Undo/Redo and object serialization working correctly are difficult and in some cases impossible. And frankly, you need extensions for a lot of things to actually be useful, like until recently the builtin terrain editor was basically useless, and you have things like Odin because the builtin inspector is a nightmare.
There's a lot to like about Unity, but there's also a huge amount of pain points with it.
Then ten or twenty years pass and it becomes the thing to replace.
I'd say that yes, at least in the last 5 or so years.
I decided to make a scene which would contain a single copy of every single model that I'd like to use in a project of mine, for checking the textures, how lighting works, the scale of everything etc.
By the time I got to around 200 different objects (no high poly ones, by the way), it took like a minute to just open that scene.
I hope one of these projects takes off: https://github.com/migueldeicaza/GodotSwift https://github.com/kelvin13/godot-swift
Excited to try Godot in a couple of years when it's more mature. Hopefully they can be the Blender of game engines – where it started rough and now is better than Maya or other alternatives.
C# is a robust language with a lot of features like lambdas pattern matching etc. I also find that most of the people who know Swift are Apple developers, so I feel like there isn't a broad enough appeal especially for game devs who are going to be more Windows or Linux centric.
C# is better than many alternatives, but Swift is simply a better language in every regard.
C#'s GC is a constant issue for games, and it makes using things like LINQ nearly impossible since it does so much allocation. Swift is designed around automatic reference counting instead. C#'s structs work weirdly and are hard to use.
Swift is so much more ergonomic. C# has added a few nice things lately, but it's much more verbose than Swift.
Swift is also more focused on performance, and is always AOT compiled.
Unity has had to come up with some insane things to get C# to work across platforms – they have their own .NET IL to C++ compiler (https://docs.unity3d.com/Manual/IL2CPP.html) that doesn't always work right. They also have a SECOND custom C# compiler for high-performance programming (https://docs.unity3d.com/Packages/com.unity.burst@0.2/manual...).
I'm also very excited about Swift 6's upcoming opt-in Rust-like lower-level memory management which should help a ton for performance-critical code. (https://github.com/apple/swift/blob/main/docs/OwnershipManif...)
There are much better languages for game scripting (LUA for example)
In particular, a sibling comment mentions Kotlin. The docs[2] link to a project that adds Kotlin bindings https://github.com/utopia-rise/godot-kotlin-jvm
[1]https://docs.godotengine.org/en/stable/getting_started/step_...
[2]https://docs.godotengine.org/en/stable/tutorials/scripting/g...
What don’t you like about it?
Really, it's not the developers you have to worry about. It's everyone else. Godot is made with developers in mind, but there's much more to do than wiring signals and writing code. If you can't map things one to one from a different program or close to that through a plugin, you're either giving yourself more work, or forcing not just developers, but artists to relearn processes too.
The small stuff will get fixed over time.
I've only used Godot in a hobby context, but the full on C# support compared to other engines is pretty amazing. Just as a proof of concept I imported an open source C# library I've worked on that's designed to play old DOS music formats, created a small wrapper node with control functions, and I was able to control it as expected from within GDScript nodes right out of the box. Only issue I would have seen down the road would be cross-platform compatibility since the library itself was Windows only.
Caveat: I can't say I've ever got far enough in Unity to say if the C# support is of a similar scope. Godot just "clicks" better for me, so I've gotten way farther with it than anything I've done in Unity.
But that's the point. We're discussing things from a developer point of view. This happens almost every day by now. That's not the issue. The issue is how everyone else struggles with Godot compared to Unity, if at all. When even basic particle patterns require diving into shader logic in 3.4 or loads of trial and error, that's a pretty hard sell for non-technical people.
Context: My game project has been going since 2013, on godot since 2018.
If this was simply a matter of "Unity wants to do ads better" and they purchased an adtech company, I doubt there would be much discussion about it. That is not what happened. ironSource is not just an adtech company but a company that has built and distributed software that has been classified as malware by Sophos and Microsoft Essentials[1].
While this may be an overdramatic take, once ironSource is fully integrated with Unity and we update to the latest LTS version that includes ironSource software, I expect that we will want to virus scan our own executables built through Unity. I do not trust ironSource nor do I trust any software that integrates with it.
Now, putting the malware concern aside, I also see this as a step in the wrong direction for Unity. There are MANY uses for Unity that are not games, that will never have ads, and that will never utilize anything from this acquisition. The concern here is that recent updates of Unity have made some of these features such that you cannot disable them.
To me, this is yet another poor decision by the Unity team. As an aside, I recently started looking into their freshly released new Analytics platform and it is an absolute mess of a release. There are massive oversights in the implementation and bugs that prevent workarounds to those oversights.
Unity is not looking like software worth betting your company's future on. At best, it is looking more like prototyping software before using a better engine.
But you won't hear many "indie" developers say as much, because making money is uncool.
That said, IronSource is sketchy as hell. I'm more concerned about _who_ they merged with then that it was an ad company.
https://godotengine.org/article/godot-consoles-all-you-need-...
I'm not a professional game dev, but I can't see why you'd want to shut off that avenue.
2 - On glibc/linux target: it should generate pure and simple ELF binaries (not C/c++ binaries). It has the following implications:
a - the static libstdc++ from gcc probably has to be forked that to "libdl" everything it needs from the glibc/posix libs.
b - everything else from the system has to be libdl-ed too, even the libc symbols.
c - third party libs must be libdl-ized too.
d - ofc, usage of "-static-libgcc" and "-static-libstdc++" build options to mitigate ABI issues (got hit again by that and recently, c++ ABI nightmare).
e - no C/c++ main() function, only the sysv ABI(ELF) entry point (which is basically main anyway).
f - usage of system TLS variable, like errno, must be handled only via the sysv ABI __tls_get_addr() ABI function (I have to admit, I did not dive that much into this issue yet).
g - proton is a money sink hole, massive and horrible software microsoft grade. To make it worse, it is said to include actual real software components from doz. Only consider it if your technical debt on doz OSes is too high (basically, you started to "think" "other platform ports" too late).
If not mitigating those issues above: games using godot must be build on the oldest glibc as possible, that to avoid GNU symbol versioning issues. They should static link as much as the can, even some glibc libs (libm static linking is mandatory since GNU symbol versions here are madness). And conservatively build using the "-static-libgcc" "-static-libstdc++" options.
rant on: Godot should not have been a c++ engine but a simple C/ASM one (should be able to compile with tcc/cproc/scc/pcc/etc), using the preprocessor for namespaces in order to avoid symbol collision, and using compile-time function tables and runtime function tables (for "fallbacks", like wayland->x11).
The really guilty ppl are actually glibc and gcc devs, not the game devs. rant off.
Any time a company tries to make me feel like I'm at work, I stop wanting to make games with their product.
Would I use it if I am serious about gamedev as a job? Probably not. Version 4 is supposed to bring a lot of improvements and this is awesome. I am not sure I would invest into building a product in version 3 (as it will be deprecated if not by its team then by the plugin makers). Version 4 is not ready yet and specifically mentions to have "tons of bugs" once it's out. As a hobby game developer this is an truly great product to work with. I started with a few 2d tutorials and probably after a week felt really productive. Also it feels like 1st class citizen on Linux (tbh Ubuntu also made great progress here).
The only really thing missing for me - in order to use my C++ simulation engine I need to re-compile C++ Godot sources along with my code? A bit too much for me at this stage. But didn't investigate it enough if there is an easier solution (version 4 is supposed to give more options). Using C# is as an option too. But they mention C# in terms of "support" is "secondary" whatever this means - without more experience it is hard to understand the implications.
Unity is too mature and skills are there if you need to hire or outsource. Mobile publishers, for example (from what I've seen) only accept unity games. You can buy great plugins/assets for reasonable amount of money. Obviously with the money they have it is the product you want to base your business on if you develop professionally. If anything Unity should be compared to Unreal engine, not Godot from the perspective of developing professionally.
Anyways it is really great to see an OSS product that is so close to the mature big commercial products that people have these discussions, run benchmarks and seriously consider switching to Godot. The quality of effort and skill I've seen people put into Godot development (and its plugins) is something unreal and too awesome be true. Go Go Godot!!!
I have been a Unity dev for years and my main reason for using it is that I can build to most platforms with relative ease from the one engine.
I would be promising asset compatibility with Unity and shouting about that everywhere if I were Stride.
The point is so that I can lean on the community to create the content and I would just focus on maintaining game servers, and adding moderators.
Unity makes it much easier though.
I personally find the approach of nodes everywhere a bit odd.
In my mind, you'd typically use nodes for objects that are supposed to represent some sort of an object or concept within the scene, whereas the scripts would be the ones that actually give said object any number of behaviors, such as a certain group of functionality per script.
So you might have something like the following:
EnemyObject
PathfindingBehavior
ShootingBehavior
TalkingBehavior
Whereas in Godot you can only have one script per node, which would mean that in practice I'd have something like:
EnemyObject
PathfindingObject
PathfindingBehavior (attached script)
ShootingObject
ShootingBehavior (attached script)
TalkingObject
TalkingBehavior (attached script)
Of course, maybe that's just because I'm used to the GameObject pattern that Unity uses, an entity-component system (of sorts), though that implementation has gotten a bunch of critique as well, with DOTS apparently being a better ECS approach, though also unfinished in certain aspects.
Just felt like sharing my thoughts on that particular aspect, which some might find curious and which might take a bit of getting used to (though personally not having a separate "prefab" concept and instead having more or less everything be a node is also pretty freeing, I have to say).
With a bit of love, using C# could also be pretty amazing, since GDScript does have certain limitations (performance comes to mind, for when you need it to be decent for number crunching but don't want to/can't use C++ due to knowledge or other restrictions, C# has your back there) and curious design choices (the integration with the engine is super nice and the Python like syntax is great, but having to define singletons in the editor IIRC is a bit silly https://docs.godotengine.org/en/stable/tutorials/scripting/s...).
That doesn't mean people don't genuinely like Godot, just that it looks as if someone has an agenda to make sure that's the case.
I'm not a game dev, but its the engine King uses that they completely open sourced, and I think it can be a good alternative.
Technically it doesn't meet the open source definition because open source should allow people to commercialize the source code. Defold allows you to see the source, modify it, and make contributions, but even those modifications cannot be commercialized.
You are free to use it to make paid games, or make and sell plugins, etc.
> Devs not baking monetisation into the creative process are “fucking idiots”, says Unity’s John Riccitiello
https://mobilegamer.biz/devs-not-baking-monetisation-into-th...
If he talks in public like that, imagine how this guy talks to his employees behind closed doors...
Nobody tries to hide anymore that a lot of game companies just create skinner boxes
"mobilegamer.biz" is betting on you not reading before getting outraged, and it looks like that paid off.
Riccitiello: Ferrari and some of the other high-end car manufacturers still use clay and carving knives. It’s a very small portion of the gaming industry that works that way, and some of these people are my favourite people in the world to fight with – they’re the most beautiful and pure, brilliant people. They’re also some of the biggest fucking idiots.
People literally learnt nothing at all
Want to stay away from unity?
You should also stay away from C# and Microsoft
https://exceptionnotfound.net/the-catch-block-80-the-dotnet-...