You're probably right. I was using the C# version. My mistake.

"Are you confusing it with something else?" - No, I'm not confusing it with anything else. It may be in version 3.x but I had a number of problems with it that made it completely unusable. Maybe the C# version was in alpha, as discussed above.

But even if I could get it to be stable enough to do work with, which I wasn't able to, it's obviously written by Android developers, it uses GLES exclusively, and it doesn't even have DirectX support on Windows - which should be the first API targeted on this platform. It's not a good Windows engine. There are several others that beat it hands down. It doesn't actually deserve it's current popularity.

3 hours ago, DeadStack said:

But even if I could get it to be stable enough to do work with, which I wasn't able to, it's obviously written by Android developers, it uses GLES exclusively, and it doesn't even have DirectX support on Windows - which should be the first API targeted on this platform.

I've not used it on windows, I'm on linux and I have a feeling that a lot of the core developers are also mainly using linux. Regarding stability I would say the graphics API side compatibility definitely needs some work.

One key thing about Godot is that it is community driven and written. This has both plus points and negatives. It does mean that developers will tend to work on aspects that interest them (usually new features) and features that are broken for them personally. There can be perhaps a bit too much focus on adding new features rather than fixing existing bugs / compatibility checking, which could be seen as less interesting to a volunteer (but of course not a problem if your salary is paying for this). It took me a bit of time to realise if you encounter a bug in the engine, it is up to you to investigate it, write a bug report (issue) on github describing it, and even to fix it yourself if you are up to it.

The decision to use GLES 3 exclusively was in retrospect, less successful than it could have been. GLES 3 offers lots of techniques and 'should' in theory be standardized, and the subset of OpenGL used should be compatible with desktop OpenGL (forget which version).

Practice is different though, and I think they found that the GLES3 drivers have been patchy, leading to the need for development of GLES2 for mobiles. Unfortunately GLES2 is even more patchy with support for features in some devices and not others, driver bugs etc, and there's currently a few of us pushing to get this fixed.

This isn't Godot's fault, they simply want to use an Open, widely and well supported cross platform API. The problem is one doesn't yet exist. One thing that DirectX does do right and OpenGL has missed out on is having feature requirements that need to be supported by the hardware in order to say 'this card supports DirectX 25' or whatever. OpenGL has been rubbish on this front so far, so as a developer you end up not being able to develop for any kind of fixed tier, you have to mix and match different features at runtime to get kind of what you intended, and it is a development nightmare.

As a result of this, the current effort is being placed on writing a Vulkan backend (reduz has started working on this very recently). The idea is that vulkan is powerful and should be in future widely supported, and there are afaik better checks for hardware conformance.

Personally I'd wonder whether writing a backend for a cross API wrapper like Dilligent Engine or BGFX would have been a nice idea and let them handle all this stuff.

I guess part of the problem is not only in writing a 'backend', it is that the different APIs might support different feature sets, and you need to expose this to the actual users somehow. You either need some kind of more abstract way of defining things in the engine (i.e. this light produces shadows, they are medium quality etc) and let the backend translate that into something more meaningful, or you need a full set of options for lots of node types depending on which renderer they are using.

Regarding DirectX as a backend, I don't think there are any plans for this in near future. On desktop I think the impression is that OpenGL support and Vulkan in future should have this covered.

Anyway, most of this mindfart is concerned with 3D, and in 2D things should be much simpler. I've not used the 2D features aside from user interface, but I get the feeling compatibility should be much less an issue as they simply don't need so many features.

Lets compare the two from the software perspective, both utilize open source development, wether you like it or not, Unity has an open branch and there is an official inofficial debian file that helps you install unity on linux, and its a great user experience, despite there being bugs and the online thing etc. so its the same as unity on windows, having said that, anything that is going to be taylored for a plattform, or developed on it will run better on said plattform, but I think Godot wins the race here! Since, it has a small file size and compared to what it offers, nearly the same, but offcourse not as professional as Unity or Unreal assets. 

(I am making two point into one here, not the smartes thing to do, sorry, I hope you still understand!)Furthermore, lets look at how Unity handles distribution of executables, it has none, it updates itself, it is freely usable, but you will have to pay royalities after a certain threshhold, thanks to competition not only market places but also I hope engine marketers have opened their eyes to better circumstances surrounding smaller developers and their ability to market to other developers and the likes, I guess Unreal wins that one

Both let the developer change stuff, I mean Nintendo has their own closed off branch of Unity for their games, so yeah, they are probably pretty open to talk to about nearly anything, cash probably speaks a better language in this department though, but still, I have heard stories of developer support being so and so, but both engines have that problem, Godot utilizes volunteers but the ones with the skin in the game are a small group! Not that optimal to react to, but very much so in reach for nearly anyone, but it doesnt hurt Monogame for instance!!!! Dont forget that juggernaut! And that framework/engine does not even have an editor, theoreticly! The XNA editor is closed source after all, but the two should be quite compatible still! 

So, to cap that off, comparing the filesize of the two editors and their engine backend, godot wins the race, and godot is highly customizable and extendable, and you dont have to answer to anybody, you are even allowed to distribute the engine itself with your project files etc. thats cool! Also, all the past executables of godot will stay free, so if they ever decide to really be a commercial product you can still use all the later versions, I have been holding on to quite a few myself, I dont throw away the zips if you are curious! 

To further my point, you can actually download version 2.4 or 2.5 because it is backwards compatible to so many old machines, so your 150 dollar bargain laptop of ebay or whatever local website you use can power all of your development and thats huge! Also a little bit about maturity, godot has been used with commercial products, mobile games and so on, the front page was littered once with a candy crush like game, their platinum sponsor is a crypto coin currency firm that wants to make in game purchases based on crypto, the value of an item for instance... They have the cash from the community too, hype is there and people dont seem to be off put by the way the project is handled, I think these are good signs for any project, and yeah, hype can turn against the project, but, you seem to forget that the team has been moving slowly implementing changes and new features while also not overpromissing, those are the perks of open development, and consice community updates. Dont bite off more than you can chew! 

Lets talk about development, a side of godot I have been not that acustomed with but my little experience will do, for my point! In the beginning the engine and the editor had allready a pretty mature documentation and usage, but the two did not go well together, you cant just use the documentation to learn about godot, I mean you can but there were still hickups, theory and execution are two pair of shoes, and probably there are now still some things that need experience to solve, you need to be an experienced developer to really kick it off with godot if you dont want to just emulate outdated video tutorials, hardened programmers wont cut it, but theres allways the community around it! Its not as smooth as unity, but unity is slow with its introduction to things! I think in this department both engines have drawbacks! There is no clear winner! Making it work in unity when you want to solve with source and you shouldnt and visce versa with godot is a pain, unity is better at introducing workflow to new users, because they have planed their UI out a little better to acustom the engine, there is a clear intended way to do things and godot has changed in the past to make that clear with warnings, but the documentation probably still does not reflect that, and honestly, thus is the drawback of interpreted languages like python, which is very similar to godots very own GDScript! Execution while running is kinda flawless, but the build up and less wiggle room when it comes to interpreting what the language wants from the humand behind the keyboard has its drawbacks with python and similar languages! Still the simplistic structure of languages like python, lua and of similar vain make them very efficient, and thus making the developer reach the breaking point even faster -> maturity as a developer! But maybe you should just stick with GDScript, theres REALLY NO SHAME about it, its definately a big boy language, being caged in the editor, but thats a good thing, having just brushed over the C# documentation for godot it seems that GDScript just takes away all the "bad" things associated with non interpreted languages, I dont know what C# is, its also a scripting language! SEW ME! What I mean is, while you need the right imports, you need the right class names, etc. with C# in godot, that has been lifted from you in GDScript, have I looked that up earlier, oh how much smarter would I have been ;( 

So, to compare the two, from the perspective of using an external code editor to make scripts... its handled crapily in unity, or I have not found a better way, either you let the developer edit  in engine and you distribute one version of the editor, in this case critisism towards godot, or you let the developer edit in engine and compile also in engine, while in the external editor, critic towards unity! I dont know, point being, the unity coding experience is bad, or I havent found a better way, and thats a commercial product, that probably needs other commmercial products to work, i.e. Visual Studio, but you can get the VScommunity version. In any case, I dont understand why godot went the unity route with this, but I also learned this today, so it might be pretty amazing! I think I have rambled toooooooooo long! Final point being! No royalties with godot! Programming can be a chore with GDScript, it breaks earlier than you are used too, but I think thats good! Yeah thats good, but not when you are working on some idea... ok, choose godot please, I think its friendlier towards your situation.

@SIr Pep What did you end up doing? I've been using unity because of the relative ease of deploying on multiple platforms, but my games are so light I'm wondering if it's time to look around…and now that Godot has more language support (as an old Java programmer--several careers ago--the easy transition to C# was part of what attracted me to Unity.

Multiplayer/networking in your plans? Thoughts (the fact that there is little Godot talk here is a bit discouraging--plus I'm old enough to prefer something with more physical books to help newcomers.)

I am thinking about using an engine for the tedium as well. Yesterday i downloaded unreal but it is 40 bloody gigabytes ! That's more than my whole OS ! Not sure if that's healthy. Will have another look at Godot. First time i did was when i started with all this, it was in late 2 and i had no idea about C++, it's sources looked like Egyptian hieroglyphs (1st dynasty) to me. That has changed in the meantime … :-)

I've been messing with Godot recently. I think it has a lot going for it, even if it is not quite to the level of other popular engines. It's definitely stronger in 2D than 3D. Though, I've found a number of small and not so small bugs, and they don't always get fixed right away.

It's understandable that the developers (aside from some funding they have gotten more recently) are basically donating their time to an open-source project. You can't complain too much. But I did find some major blocking issues with Github history going back years and that are still unresolved.

That said, a lot of progress is being made, and the new Vulkan renderer looks to be shaping up nicely (more important for 3D of course). I think it's going to be an important project, but I'm not sure it's competitive for 3D at the moment. I think for 2D you'll probably be okay for retro 16-bit titles. Even 3D can work with a low-poly aesthetic. But they have a ways to go to get to the kind of current-gen graphics you would want.

Even considering that, there is a lot to like. The engine is super small and light-weight. You can open the editor in seconds for a blank or simple project, and probably like around 30 seconds to 1 minute for something more complex. The editor is very stable, I've tried on Linux and Windows and it works well and does not crash. It would probably work better on low-end dev hardware. I was even able to open it on my Chromebook. Granted, it was slow, and I could barely get 5 fps playing a game, but it worked.

The whole philosophy makes sense, the API is clean and (mostly) well documented. Sadly, the API has changed pretty drastically over the years, so many Stack Overflow answers are incorrect now. Best to search in the updated docs and figure things out yourself.

And the community is pretty helpful, especially on Reddit there is lots of action unlike some smaller FOSS engines that seem to be dead (or on life support). This engine is under active development and the community is growing and getting larger.

I'm still trying to figure out what the heck I'm doing, was working on a custom engine for a while, though that got pretty daunting and I'm exploring whether any existing tech meets my needs (it all seems to be a compromise).

I would definitely recommend just downloading Godot and trying it with some simple projects (like Pong, first level of Mario Bros, etc.) and seeing how you like it. Everyone has different needs and requirements, and the range of games you can make means that an engine that works for me may not work for you. So try it out.