One thing that I think would hugely shift godot's market share is a standardized asset format, similar to what Unity and Unreal have, so asset developers could offer assets in Godot-compatible format. It would be even more amazing if there was an easy way to import Unity resources. Maybe I just needed to do more research, but last time I tried, I had to pull out individual files, mess around with them in Blender, then import the model and the mesh into Godot separately, where I needed to arrange them together afterward. I think if the asset management was as simple as Unity's, Godot would be a no-brainer in many projects, especially smaller ones.

As long as it doesn't follow Unity's approach (asset bundles). Unity's favourite thing to do is break asset bundle compatibility between versions.

Well, it supports glTF which is supported by Unity and Unreal too. Most 3D packages like Blender support it too IIRC.

They even have a blog article on why it's the future (like JPEG for images) and how many big companies have started supporting it.

Maybe, but let me question that. What standardized asset bundles also do is create a market for asset bundles, which is good for the company they support. They also let new people buy a package of assets. Those aren't big issues for me, but I have never tried to make a commercial scale game in Godot.

Versioning is the nightmare of Unity. So many assets and plug ins only work with certain versions.

A friend of mine is developing a commercial game with unity, and that's been a big issue. It's either don't get big fixes or rework parts to upgrade unity

I'm not sure what you mean. Godot has asset formats that translate from project to project.

I've used both Unity and Godot at a hobby level and what I found was that with Unity, I spent almost all my time playing around with game mechanics. With Godot, I always spent a considerable amount of time importing resources and fiddling with them before being able to do anything useful other than add basic shapes to the screen. I think it's probably a problem of being the underdog with a much smaller asset market, but that's literally the one thing that made Unity worth checking out for me. I've downloaded most releases of Godot to play around with them as they come out though, so I'm really excited about it growing further.

There are some issues with the 3D importing pipeline, GLTF is the best supported file format, but they recently added .fbx support so thats good.

I agree that there could be further improvements made there but I've had good luck with .gltf.

Additionally, I've had problems with materials or animations importing into Unity as well. Seems like its a big, common problem.

Unity imports started getting smoother in recent years because marketplaces and artists started specifically targeting unity.

Wow. I just downloaded and installed it (on Linux).

Hands down the best install experience of any similar tool.

* Unzip one binary and run it. * The app auto-detects everything you need, and uses the best version it finds * Its project layout requirements are "open an empty directory" * The example projects install and work!

Seriously, the biggest difficulty I had was finding the "run project" button. It took me a little bit of hunting.

It's getting there, I think it's missing the top layer of polish. I've been working with it for a couple years now and it has some bugs that really hinder development speed.

That being said, once those issues are fixed I think it'll be a hard choice to not use Godot (for what I do, more 2D work).

> I've been working with it for a couple years now and it has some bugs that really hinder development speed.

What bugs do you think hinder dev speed?

I am vastly more productive in Godot than in Unity.

Currently I think the only criticisms I have are the 3D renderer is bad (whoop 4.0 lets go!), and there is not a strong community/asset marketplace.

I _love_ the workflow, though.

I'm a full time game dev and started a fairly large 3d project in Gotdot last September, I worked in it for about 2 months full time before moving to another project with another team.

The bugs that hindered my productivity were mostly "land mines" that I discovered along the way.

1. I thought having my scripts as internal scripts sounded good for a week until I realized there are all kinds of undocumented problems with storing your scripts that way. I had to refactor.

2. There is no selection outline around mesh in the editor window. Makes it impossible to build a 3D scene in Godot. My guess is that the developers expect you to build the scene in Blender then import it as one big FBX. (But that's not ideal for some things)

3. Then I hit the dangling reference bug and that was a heavy blow to my enthusiasm. The fact you can save a reference to an object in a variable, and that the engine can then change what object your variable is pointing to under the hood. It's such a fundamental bug it makes me wonder what other massive issues are there waiting for me to run into. My work around was to listen for signals for when object references were removed from the scene and manually clearing them, but its a real drag.

There were a few other things, but those ones stand out in my memory as examples of why I don't think I can work in it yet.

The reference bug won't be fixed until 4.0, so have another look at Godot then.

Update: Here are the bugs I logged.

https://github.com/godotengine/godot/issues/31758 https://github.com/godotengine/godot/issues/32383

If we're thinking of the same dangling Variant bug, a fix was backported to 3.2.2 (releasing soon): https://godotengine.org/article/dev-snapshot-godot-3-2-2-bet...

Good news!

Update: Although if I had continued with my project from September I would have shipped with this bug. That's quite a long turn around.

Wow these are some wild bugs.

I have never used a built in script and agree it should be removed.

I have never hit the dangling reference bug, and I agree it is critical. Good thing its fixed now.

I have been laying out scenes in 3D without the selection outline. It seems like a good feature to add. What I truly love about Godot is that you or I can actually add that feature. I know that turns some people off, but it actually is very attractive to me.

I think although it is missing that layer of polish, the underlying foundation layer is so much better built.

Would you recommend Godot for making a 2D bullet hell type game?

I actually built a fairly functional combination of bullet hell and tower defense game in Godot about two years ago. Beware, though: the 2D lighting system for Godot is extremely slow, so if you want a buttery smooth FPS, don't do any crazy lighting.

Godot will do the job quite well, although there are plenty of alternatives that may also be worth a look (some open source, some source available): Defold, Solar2D, Heaps.io, etc. There are many good choices nowadays, although Godot gets the most love on HN.

I played with it about 2 years ago (even contributed some code to godot-cpp!) and it was pretty good, but it did have some gotchas and issues. Many are likely fixed now. You should just give it a try, its easy to get started and then you can judge for yourself.

Yes, Godot would handle that very well.

Yes I downloaded it last week. I got bored doing a Unity tutorial (how to best explain ... what I was doing all felt a bit disconnected from the games I guess?).

I dived right into the Godot tutorial "Your first game"[0] and had something basic running really quickly and I understood most of it without any further reading.

[0] https://docs.godotengine.org/en/stable/getting_started/step_...

I clicked on the doc link from within the native editor. It is less of a tutorial than I had hoped. Do you have a suggestion for getting started with it?

The step by step docs have been very useful for me: https://docs.godotengine.org/en/stable/getting_started/step_...

If you're a "work bacwards from a finished project" kind of person, this tutorial is quite great as well

https://docs.godotengine.org/en/stable/getting_started/step_...

That's great. And, I love that the examples all specify /home/ubuntu as the home directory, so the author is clearly using Linux. This is really cool.

Yes "Your First Game" is a fine place to start even if it tells you to read some other things first. I'm a big fan of diving in to get something running, then searching or backtracking to learn the fundamentals if you need to.

There were a couple of typos in there that I ran into, it shouldn't be too hard with a little programming experience to notice these. I didn't download the finished files because I think typing it out is a much richer learning experience.

I recently got started by following couple videos on YouTube which are not hard to find. I've just followed very basic lessons, mainly to get familiar with non-programming aspects (scripting part is very easy if you already know programming).

There is also a Humble Bundle out there right now where you can get some basic lessons as low as $1[1]

[1] https://www.humblebundle.com/software/learning-game-coding-a...

How does it compared to Unreal? I've been using it a little to try and make a VR game and it's generally quite good I'm finding there are loads of bugs, or at least weird behaviours with materials and the OpenGL ES3 mode. And every time you change a setting it compiles like 3000 shaders which takes half an hour. Quite frustrating!

Check out my game https://vrworkout.at for a VR game made with Godot. I am not a graphics designer so the models are bad which means that the rendering capabilities do not matter that much, but you have to stick to GL ES2 for the moment. Here is a video https://www.youtube.com/watch?v=mknXbyVJm3c

One of my favorite parts about Godot is that it gets away from those crazy load times / lockup you experience in Unity/Unreal. The .import file it associates with your asset is plaintext. Definitely running into fewer merge conflicts.

Ya way fewer.

The scene file is actually _readable_!!!!

The node and resource systems are vastly more accessible than Unity IMO.

Workflow feels so much better in Godot than Unity.

Godot's problems are in it's 3D renderer. It's not very performant nor good looking and has some shadow bugs...

Godot 4.0 should fix all that stuff.

The renderer is fine for my indie/low poly style, but is pretty limiting for advanced post processing and realistic designs.

The particle system isnt very good in godot 3.x so far either.

Godot has some a noticable lag spike when shaders compile as well.

So, there's lots of issues related to rendering and advanced stuff, but for my purposes, godot is way more productive than Unity for me. And thats because:

- the scene hierarchy has a superior design

- the keyboard hotkeys are better

- compilation time is non existant

- hot reloading works

- gdscript is faster to write than C#

- scene & resource files are more git friendly

- documentation is local and in-editor

- gdscript has opinionated & accessible apis for things that other languages make hard (string manipulation, encryption, file system access)

Godot is the future. I promise you this.

Hi! I work on Godot Engine closely, improving the 3d asset pipeline.

Things move slowly in any large project.

Changes that were made for Godot Engine to make glTF2 import acceptable were done in October 2019.

However, a feature request to make the official glTF2 importer (Blender) import standard glTF2 properly will take until Blender 2.83 (LTS) to arrive in the next few weeks.

Three.js is also able to import standard glTF2. There is an amusing chart of failures on Github. https://github.com/KhronosGroup/glTF-Sample-Models/pull/243#...

FBX 3d asset import support in Godot Engine is the same struggle.

Supporting standard FBX is the goal because of the focus on open source ecosystems. Even when the current Godot Engine fully supports FBX (Godot Engine does not currently), it will take significant time to get Blender's incompatible variation of FBX to be patched in stable releases of both Blender and Godot Engine.

Other people are working on Godot Engine rendering for the next version, but I am joyed at reviews of the glTF2 work.

I hope for future success in Godot Engine projects.

Bro we know each other ;)

I don't know, to me the choice of their own NotPython as the main language seems like an incredible misstep to me. It's lacking in features (last time I checked they didn't even support basic things like lambdas), tooling and libraries.

There's a reason why both Unreal and Unity moved away from providing their own language.

I thought it was a massive misstep until I started using it heavily.

Now I really like it.

As to lack of lambdas, yes there are no lambdas, but coroutines are a first class citizen in gdscript, and network libraries, like Nakama for instance, use coroutines heavily. I prefer coroutines to lambdas anyways, and I think the industry is moving towards coroutines.

There are a ton of good things about gdscript. I was a hater on it until I started using it, and then I realised how quickly it allows me to do stuff.

Besides, I'm staring at the worlds worst Unity project right now.

Languages dont matter as much as system design.

Coroutines and lambdas are orthogonal features. if the language supports it, a lambda can be a coroutine. Arguing that one will replace the other strikes me as nonsensical.

And I don't hate gdscript, I just think it's incredibly half-baked and feels very immature. It's understandable that they only have limited resources, but that doesn't make my experience with it better.

Languages matter an incredible amount because of how heavily they influence system design. You can design an awful system in any language, but if you have to treat everything like a nail because you only have a hammer, you're bound to make a lot of awful decisions.

Edit: also, good IDE support really is incredibly helpful for working on larger projects

Im thinking of both lambdas and coroutines as techniques for asynchronous programming - like the 'complete' callback for a network call, for instance.

For functional programming, yeah there's no equivalent to a lambda in gdscript, but again, I think it's exceptionally well suited for the kinds of things you do in typical, run of the mill, game dev.

Seems lambdas are coming in 4.0.

https://github.com/godotengine/godot/issues/2684#issuecommen...

It's a common fact that Godot's 3.x[0] renderer is lacking but if it can achieve these[1][2] then 4.0 will be a game changer

As a side note I like your comment ^^

[0] didn't say current because master branch to be the current branch and it already migrated to Vulkan [1] https://www.youtube.com/watch?v=HQYZBZybP9M [2] https://www.youtube.com/watch?v=cKtwW9yU6QU

All these things. GLTF and godot have been amazing to me, though I do sometimes struggle with the asset flow but I'm getting better.

I've been using 4.0a and havent found anything with major breaks so far, and Vulkan really shines compared to opengl3.

It makes me so happy that I can have a game editor that aligns with my RMS-esque views (pro gpl). Now if I can just get my friends on board, many of them have invested so much time in unity or ue they don't want to switch. My goal is to have a prototype cool enough to draw them in eventually.

Have you tried it on a package of similar size? Yes I hate the Unity/Unreal start up issues. On the other hand they are doing a ton of stuff for you. Compiling 100s or 1000s of shaders for for particular GPU, compiling all the code, processing all the assets for your particular platform. Those all get cached but the first open is painful. But I can't imagine Godot is any different. Those steps have to happen and they are all heavy steps. If Godot is faster it's more likely because it's doing less for you than because it's actually faster.

Godot seems to be a recommendation only for 2D projects. It's 3D support is lacking to the big engines. You can also see it in the showcase - it's 99% 2D projects.

Yes my understanding is 2D is first class while in the U engines you tend to turn a 3D scene sideways to get 2D and have to deal with vector mathematics rather than points in various functions. At least that's one reason a few people cited for the switch since they wanted to focus on 2D and it works without extra layers or abstraction.

As I understand it, orthogonal-view 3D as 2D is faster in the GPU than "real" 2D in the CPU, which is why it tends to be used.

My comment was more around tooling and complexity as seen by the programmer. You can have functions that look 2D but are really 3D behind the scenes, like glVertex2f in OpenGL. AFAIK Godot uses GPU acceleration still for 2D scenes like all games these days should.

Godot is a bad 3d engine, performance is abysmal.