by proxybop on 7/14/22, 2:35 PM with 222 comments
by Zhyl on 7/14/22, 3:19 PM
by overgard on 7/14/22, 8:05 PM
- 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.
by wkirby on 7/14/22, 8:06 PM
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.
by disintegore on 7/14/22, 3:25 PM
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.
by Mattish on 7/14/22, 4:33 PM
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!).
by rubychill on 7/14/22, 11:07 PM
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.
by 999900000999 on 7/14/22, 6:56 PM
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
by debacle on 7/14/22, 6:39 PM
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.
by citizenkeen on 7/14/22, 7:37 PM
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.
by marcodiego on 7/14/22, 6:28 PM
> 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.
by 202206241203 on 7/14/22, 6:00 PM
It's a framework not an engine though - more programming from scratch rather than scripting pre-existing things in a visual editor.
by pipeline_peak on 7/14/22, 3:19 PM
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.
by luxuryballs on 7/14/22, 9:00 PM
by binarynate on 7/14/22, 6:48 PM
by wilg on 7/14/22, 7:11 PM
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.
by BlargMcLarg on 7/14/22, 3:36 PM
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.
by arminiusreturns on 7/14/22, 8:40 PM
Context: My game project has been going since 2013, on godot since 2018.
by hitpointdrew on 7/14/22, 8:15 PM
by dcow on 7/14/22, 9:46 PM
by throwawaycuriou on 7/14/22, 7:45 PM
by daveoc64 on 7/15/22, 1:32 PM
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.
by curioussavage on 7/14/22, 5:05 PM
by sylware on 7/15/22, 12:49 PM
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.
by plaguepilled on 7/15/22, 4:55 AM
Any time a company tries to make me feel like I'm at work, I stop wanting to make games with their product.
by rfrerebe on 7/14/22, 9:01 PM
by democracy on 7/15/22, 8:32 AM
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!!!
by jayd16 on 7/14/22, 5:20 PM
by everyone on 7/14/22, 9:07 PM
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.
by T-A on 7/14/22, 9:19 PM
by prophesi on 7/14/22, 6:47 PM
by languageserver on 7/14/22, 6:50 PM
by yomkippur on 7/14/22, 8:31 PM
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.
by TaupeRanger on 7/14/22, 6:46 PM
by viktorcode on 7/14/22, 7:56 PM
Unity makes it much easier though.
by pleb_nz on 7/14/22, 6:07 PM
by KronisLV on 7/14/22, 9:04 PM
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
Unity kind of vaguely got that "right" (e.g. in a way that's subjectively intuitive to me) with its component system.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)
It kind of feels like it would be nicer to be able to attach a number of scripts to the object that I actually want to control, instead of having Nodes that I don't really see much of a use for, apart from them being script containers.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...).
by seneca on 7/14/22, 8:47 PM
by mbrodersen on 7/18/22, 1:22 AM
by JetAlone on 7/15/22, 1:04 AM
by didibus on 7/14/22, 9:23 PM
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.
by aikah on 7/14/22, 6:35 PM
> 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...
by jsiaajdsdaa on 7/15/22, 1:52 AM
by Shadonototra on 7/14/22, 7:55 PM
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-...
by aschearer on 7/14/22, 6:47 PM