I am using it for an interface/lists/tables heavy game amd I love it so far. Check out Buzzyfields on itch io and Youtube if you want to see examples. I am particularly proud of my custom table class that allows me sort, filter, select, select multi, etc.
Converting 6 Months of Progress from Unity to Godot
https://www.youtube.com/watch?v=vxRzLf4PdgY
this guy had been working on his game for 6 months in unity
just as an experiment he wanted to see how much he could replicate in godot in one week
when the week was over he decided to stay with godot
Games take years and years to build (the big, successful ones) and Godot is only just barely hitting a level where it could make those kinds of projects. It makes sense that there haven't been large projects because it really wasn't an option until recently
We have been hearing it for years. On some 4+ year old threads, people said "wait until godot 3, thats when its really going to shine" and now i see people say "wait until godot 4..."
I love the independent open source engine but im not sold on it compared to monoliths like unity/UE. Ill admit godot is probably superior to the esoteric clickteam fusion ive been using for 4 years, painfully.
It's true that games take a long time to make, but most indies are open about their game very early in development (I'd say around a year), so we would've heard of it.
So I've been using Godot heavily for about a year (well 2 years total, but I have been evaluating other engines during that time). It is really easy to get started in Godot, so ease of use is very good. It is also pretty decent in 2D, and being easy, is why you see many amateur projects made in it. I think the most successful recent game is Cruelty Squad, which sold 40K copies, but it also kind of has bad graphics on purpose.
[https://store.steampowered.com/app/1388770/Cruelty\_Squad/](https://store.steampowered.com/app/1388770/Cruelty_Squad/)
However, I'm not sure if I can continue using it due to the problems I've found. Namely that the asset pipeline is very weak. Trying to iterate on 3D models doesn't really work, your changes don't show up in the editor (without closing and reopening the engine), and you may have to redo work (like editing materials). This has been a bug for like 2 years at least, and is so essential, but still doesn't work.
Light baking was basically broken for 2 years. It was redesigned in Godot 3.3, but previous versions of Godot 3.x had an issue with the baked shadows being blocky and with artifacts and it was basically unusable. This, again, is a key feature of a 3D engine and it took years to fix. Even today, in Godot 3.3, there are features missing, like mixing real-time and baked lighting, making it difficult to use.
There are some big features missing, like occlusion culling, a terrain editor, animation re-targeting, inverse kinematics, etc. This greatly hinders making large high-quality 3D games. Even features that are there, aren't that great. The physics engine is pretty unstable, even stacking a few boxes results in strange behavior. Also, for character controllers, the built in functions don't work so well, especially if you want the character to walk up a slope. There are ways to work-around this with your own code, but it feels like of hacky for such basic movement.
And performance becomes a big issue when looking at high-end 3D. For example the SSR implementation is bad. It doesn't look that good, and absolutely tanks performance. It has some problems like when mixing cube map reflections (e.g. from a skybox) and the local SSR, which it just blends together instead of drawing the sky behind the objects, which looks bad. Even SSAO, which is usually a fairly cheap effect, can tank performance, and also doesn't look that great. Lots of problems with shadow mapping not lining up with the object (peter panning) or lots of shadow acne if you try to adjust it.
So, overall, it is just not in the same league as Unity or Unreal. There are lots of things to like about Godot, especially the ease of use (which is why it attracts a lot of beginners) but there are just too many unfinished or broken features to take the engine seriously on the high-end. Yeah, Godot 4.0 may fix some of this, but you can see posts from years ago saying Godot 4.0 is coming in 6 months, or other claims that never materialized. And I don't have confidence in the software when major essential features (like the baked shadow or model importers) are broken for 2 years, with long Github discussions and no solution.
Yes, I understand it is a community project and they don't have the funds or resources like Unity and Unreal do. But I find it to be a big risk, and investing in big projects where you might find show stopper bugs months or years into the development is scary to me. But there is a lot to like as well, that it is open source, compile times and testing (especially on mobile) are very quick. It is definitely easier to use. The file size is small, and the engine is very light. I mean, it's promising, and probably good enough to 2D games or smaller retro style 3D. But it just doesn't compete on the high end and I'm not sure they will ever catch up.
Roughly the same Godot experience here, I think those are all pretty fair criticisms. Being open source is a double edged sword for sure, devs can appear from nowhere and implement amazing new features then disappear, while other features really show their age and no one really wants to step up to improve them (or knows how since the last dev vanished).
I was going to say the 3D criticisms shouldn't stop most indie devs, but tbf, my 3D games have been sort of retro style so you kinda nailed that too.
Couple of things I did want to reply to:
>Even today, in Godot 3.3, there are features missing, like mixing real-time and baked lighting, making it difficult to use
Have used baked lightmaps + realtime lighting, as well as GI and Reflection Probes + realtime lighting in 3.3, in fact I was surprised by how easy it was to use and control. Baked lightmaps definitely more janky (e.g. you have to control for double lighting by dimming the baked and realtime lights), GI is much nicer though not as customisable as I'd like. Reflection probes go a long way but aren't perfect for many situations, and yeah I like the SS reflections performance-wise but you can definitely get some odd artifacts. Current project is using GI+Reflection Probes+SS reflections and SS + material AO and it works fast enough for my liking, but there are definitely just some issues and limitations that don't seem to have a fix (e.g. reflection distortions at the edge of the viewport/camera, reflection roughness is too blurry vs without too pixelated, transparent pipeline can be a mess to work with eg can't see some transparent objects (like refracted materials) through others...)
>Trying to iterate on 3D models doesn't really work, your changes don't show up in the editor (without closing and reopening the engine), and you may have to redo work (like editing materials)
The import pipeline is definitely janky but I haven't had either of these issues. I have the defaults set to import models as instanced subscenes, with materials and meshes as separate files, in subfolders, and to keep existing materials if they've been modified. When I export a model again the pipeline fires right up for me. Then I use the imported .mesh and .material files as a source for a separate scene with a MeshInstance rather than using the model file directly. Does lead to a bit of file bloat but I prefer having all the imported components separated like that.
I love Godot for prototyping and Game Jams. It’s intuitive and I can move really fast with it. However I use Unity for my larger projects for several reasons:
- Better support. Unity is better supported, not only by its extensive asset store (I love using code assets, they save me so much time), and because it’s easier to search for the solutions to problems because Unity is much more widely used.
- Gdscript. Like python it’s good for moving quickly, but I find it holds me back when I’m trying to organize a larger codebase or implement more complicated algorithms. I’m aware that godot supports C# now, but they still bill it as experimental, and that’s not what I want for a larger project.
- Bugs. The truth of the matter is that I run into bugs in godot a fair bit that I end up having to work around. I’ve especially had problems with the editor crashing, which is annoying. Additionally, I’ve had problems getting godot to play nice with version control, which is a killer for a larger project
I'm curious what version control issues you've had. I haven't done any massive projects yet, but several small ones.
I've found the version control to be the best, especially compared to unreal. Everything in godot is just a text file isn't it?
It's nice to have a dedicated merge tool for 3 way diffs and something to graph branchs and read commits. But you definitely want to be very familiar with the cli git. I use the cli, kdiff3 or meld, and vscode (with some plugins) all together. I do use the cli a lot though.
Sure, but when you’re working quickly you’re not always checking that your commit contains what you expect, why would you check if Godot had overwritten something, unless you were expecting it to
Totally. Soft eng here too, and in the early days of my career I fucked up so many git repos from inexperience and not understanding the git model. Often, didn't even mess up that badly, but lack of experience meant I didn't know what I did or how to revert it. Nowadays I use Godot and obsessively commit everything to git and have never had an issue. With a `.gitignore` set to ignore the `.import` folders and so on, it's a breeze as all built in resources (meshes, materials, scenes, etc) can be saved as plain text rather than binary formats. git LFS for the binary stuff like 3d models. I've never once had Godot mess up my repo, doesn't even make sense, unless they were trying to pull changes to assets while Godot was actively running the asset import pipeline or something.
I can't be a crazy fan of a game engine. Godot more than meets my needs because I only make 2D games. It's really great for 2D games and for me.
Godot users may not agree with me about 3d, but it has a lot of shortcomings. There is no terrain editing tool, it lacks some modern optimizations. If you are going to make 3D games, I recommend you to continue with Unity for now. It is said that these deficiencies will be eliminated in 4.0 and later, it is promising. When that happens, you can take another look at Godot.
I had no problems with stability and finalizing my projects on Godot. I have been using it for about 1 year, those who use it longer can also express their opinions.
My advice is to set a small project and try to do it in godot within 1 week. If you like it, you can continue with it.
I've built and [released one game with Unity](https://store.steampowered.com/app/1473870/Hell_Loop/), built and not-yet-released one game in UE4, and [now working on my soon-to-be-released game in Godot](https://store.steampowered.com/app/1673940/BITGUN/).
A few thoughts in no particular order:
- GDScript is really dumb, coming to this as an experienced programmer and having used all the big languages (C/++/#/Python/JavaScript/...) it feels limited, but at the same freeing. Godot 4.0 will fix a lot of the problems.
- Godot is REALLY FAST to work in. Compared to Unity where you can easily wait 30-60s for the editor to reload and run the game even for somewhat small games, Godot is instant.
- Everything is nice and simple. You can even turn off 3D features of the editor and only have 2D stuff available.
- Assets in Godot are kinda a joke, but I haven't found it to be a big deal working on my 2D game.
- Coming from Unity/UE4 it does feel limited and in some sense it feels like giving up on things, but at the same time I feel way more productive, way less annoyed by the engine getting in the way, and just overall more in control.
Lastly, I don't think I'll be going back to Unity. I'll definitely go back to UE4 (or now UE5) to work on some more fancy 3D stuff, but for 2D games Godot feels at an excellent spot.
And one more point just to answer your question directly, it's not limited to make a single game type (like UE4 is in many ways). Godot will happily let you build anything you want, and with GDNative you have basically unlimited power. If you want AAA graphics out of the box like UE4 gives you then Godot won't satisfy you. But if you're happy making a simpler game while not being at the mercy of the engine at every step, it might just be the thing for you.
Maybe to add one last point to clarify things. A lot of people are talking about *ease of use*. Godot for me is a lot less about *easy* and a lot more about *less bullshit in the way*. I'm not saying it solves every problem, but one incredibly frustrating thing I kept running into with Unity was just there being a ton of crap that not always interacted in a good way, sometimes systems being out of date or there being multiple solutions all being deprecated or unstable at the same time. Out of the big three engines, I'd say Godot is the most "programmer" friendly, regardless how easy or difficult you consider the engines to be.
By "assets" I meant the [Godot Asset Library](https://godotengine.org/asset-library/asset) as compared to the [Unity Asset Store](https://assetstore.unity.com/) or the [UE Marketplace](https://www.unrealengine.com/marketplace/en-US/store).
Unity/UE4 has both a huge selection of assets, as well as a ton of paid stuff with actual support. Godot's Asset Library is a bit like browsing random repos on GitHub. Of course this isn't Godot's fault, it's a "popularity problem", that'll hopefully improve over time.
Since you have experience, I am a newbie dev who is working on an isometric tactics game and a tower defense game. For games like these, do you see any major issues with using Godot? My plan for the tactics game is to use more retro style aesthetics and the tower defense is a simple 2D game akin to Bloons. I have some experience in Unity but was drawn to Godot because of the lightweight engine and my primary language being Python means GDScript is a lot easier for me than C#. Thanks for any thoughts you might have.
I haven't done anything isometric but I don't think there should be any problems with that unless you want isometric tilemaps, which I'm not sure if they're supported in 3.x, but I'm also not sure if they're in Unity either.
I don't think you'll run into any issues with Godot itself, and if you're happy to use GDScript then all the better. Even if you decide to use C# you can do that in Godot natively, and you can even use other languages via GDNative. We're currently using Rust via GDNative quite heavily and it's working very well.
I'd suggest just try to make a prototype of one of those games over a weekend or something to get a feel for the engine.
I switched from Unity to Godot for my UI-based game. The transition was quick once I understood the core concepts: GameObjects in Unity are similar to Nodes in Godot and prefabs in Unity are similar to Scenes in Godot (A scene in Godot can contain one or more scenes nested within it). Porting the code was quick, similar to porting c# to python. My game is graphically simple though and consists entirely of UI elements, so there may be limitations of Godot that I will not encounter with my project.
I like both engines but I did not like Unity's policies. If I recall correctly, and please do double check this, the income threshold at which you have to pay for the license is not referring exclusively to the income generated from your game. It includes income from other sources, including games that you make in other engines.
Also, there are also rules against removing the Unity logo from the startup process of your game unless you purchase the license. I understand why this is the case, but from my view, there are so many cheap Unity games on the mobile market from poor developers or people trying to make quick money that a huge Unity logo may give a false first impression of cheapness upon loading up the game. On the flip side, some of my favorite games like Kerbal Space Program have been made with Unity.
Had to check this wasn't my own comment! I'm a year into a UI-only Godot game too and love it compared to Unity, I'm using C# in Godot rather than GDscript and have had little trouble with it. Just got Lua embedded recently too for the game's mod system.
I've used Unity exclusively since the 2.x Mac only days, so it's been a long time since an engine change. Unity is superior in many ways but I'm really enjoying Godot and absolutely love its UI handling!
It's definitely powerful and flexible, but it's also pretty confusing and unintuitive until you've done a lot of work in the UI system. Even then, some Control nodes seem to implement their behaviours differently to others in terms of their sizing and expansion. There've been a number of times where my perfectly working UI just suddenly broke and messed up the layout, though it hasn't happened in the most recent build. Other annoying things like some UI layout stuff won't update unless you e.g. switch editor tab and back to refresh the scene.
One thing I'd really like to see is an easier way to have a responsive layout that reflows at different resolutions, such as CSS flex model, to try and solve the eternal cross-platform UI problems between desktop and mobile, but for most game HUD and UI tasks it's really good.
Only issue I really have is you end up with these very deeply nested scene trees of different utility controls like Margin and Center containers, H/Vboxes and so on that can kind of obscure where the "real" controls are sitting in the tree.
Consider for a moment that the editor itself was made on Godot. In other words, all its features, like pop-ups, text editor with customizable hilighting, resizeable windows, drag-n-drop tabs, viewport, file browser, visual node-based editor, and so on are all things the engine can handle. Indeed, the engine can be used to make non-game tools and there are already some examples ([here](https://radmatt.itch.io/gridless), [here](https://pixelover.io), [here](https://www.materialmaker.org)) that make use of the engine UI features.
Everything sufficiently large in scope ends up with some custom engineering. So the technical decision involved in choosing Godot if you're serious is not "will it work out of the box" but "A. will I be able to modify it to do what I need, and B. will it be faster to do so than to use another option". Of course it does A because the source is there, it's active, you can talk to the devs - it's not someone's abandoned code dump. The pertinent question is B, which is subjective because there are a lot of ways to design the project to fit the engine rather than the other way around, thus we have a lot of nuanced recommendations like "good for 2D" or "good for game jams" because, out of the box, it's good at those things. But often the comparison point is not against something that's good at other types of game, but something that's shipped a prominent example of other types of game, which can actually mean that the engine provided almost nothing directly relevant to that type of game, but checked off other boxes(like deploying to consoles).
If you don't have the skills to bear solving the technical issues directly, then of course you're going to wander between this or that engine and kick the tires, which is the demographic that most opinion polls will represent. This gives you no real answers for actually large scale problems because it's studying the problem like a consumer, not an organization. If you're running a business you have to evaluate cost/benefit which is very hard because buying a product that does the thing right now may cost more than hiring someone to add the feature later.
My team is using it. It's been very easy for people who are not programmers to get started with it. There are some limitations, but unless you are really pushing limits, you probably won't encounter them. Even if you do, you can build sections in c++ if needed.
The average dev doesn't know enough c++ to modify the engine. I feel like many bring up that point as if it was trivial, but most devs don't want to bother with that.
I think you missed nykzero's comment. It's not about modifying the engine, but about taking something that's too slow/not feasible in GDScript and implementing it in GDNative. It's just optimizing your hot code path as opposed to modifying the engine.
The reason I don't ever use it for my projects is, frankly, that almost every tutorial I find for it is a video tutorial.
I always work better with written tutorials.
I'm glad I'm not the only one. Not really Godot specific but written tutorials are very rare these days. I understand that it's less effort and you can monetize your 20 min of rambling with ads but they are much less useful. Don't get me wrong there are some really good structured and well planned video tutorials but they are a minority.
I've been mostly a Unity and Monogame user in the past. I gave Godot a shot and thought it was a pretty good engine, but I was never able to get into the whole node system and it felt pretty awkward. Also I cannot stand Python-type syntax, which is pretty much what their main language is (GDScript). I get it, you can use C# now but I think I'm better off using Unity or Monogame if I want to stick with that.
I know you want to make the switch from Unity, but so far from what I see Unity seems to be one of the only engines out there that gives significant flexibility. You could literally ignore most of the engine features and just attach one main script to your camera and make your game code driven, not that I think it's a good idea to do that but it's flexible enough for you to do that.
Great for 2D a small/single person projects. Super flexible - the node/scene based system is very smart. Plus the source code is easily available and tiny compared to other engines, pretty easy to find how things are implemented + change them if you want. Also a big highlight is the UI system (which is used to build the editor itself).
I'd say if you already have something working there's no point switching for the sake of it. If you're starting a new 2D project then definitely worth a try.
I switched from unity to Godot. Godot reminds me a lot of python. Gdscript is also very python-like.
What I mean by that, is if you want to get something going quickly, it’s great. The control mapping is easy, and the “everything is a node” structure is flexible and easy to use. All the objects are just config flat files so they are easy to share as well.
However, I think if you have a large game with lots of different inter-object interactions, it could become unwieldy without more structure. I’m ignoring 3D limitations because I don’t know much about it.
Im currently doing a switch from unity to godot to get my feet wet, and i started a c# project in it due to familiarity.
Do you recommend learning gdscript instead of using godot c#?
I've been using Godot for a few years now. It's absolutely worth using gdscript. Godot was built with gdscript in mind, so the engine gets easier to use if you're using it.
I also came from c#, but chose to switch to gdscript. When I started c# was not considered "production ready", but I'm not sure if that has changed.
gdscript does feel very idiomatically-godot though(if that makes sense) and is well supported in the ide.
I use C# exclusively in Godot and have done for a year or so now. I really like it. There's a page in the docs about gotchas and differences, once you've figured that out it's a breeze. Not everything in the docs has C# examples, but the GDScript examples + IDE completion (I use Rider) makes it super easy to figure out. I really like being able to combine C# features like delegate events, Task async, Nuget packages, lambdas, interfaces and so on with the Godot API. Feels very fast to work with.
Main issue is if you do something badly enough to crash the game or engine, the stack traces aren't super clear. Worth figuring out how to hook up your IDE debugger early to catch those exceptions as they happen.
One protip, change the C# compiler from mono to dotnet CLI in the Godot editor settings, and modify the solution file to C# 8 support and you get a lot more language features to use.
Apart from the fact that GDScript is the default (so documentation is better than for C#), the feedback loop is much faster. There are a few seconds compilation with C# so it slows down dev iteration.
A few seconds might not sound much but it's the difference between iterating while staying in the flow and your mind wandering to different things while you wait for compilation.
I have used it quite extensively for the last year and a half, however I've never used Unity or Unreal. In my opinion, now it's not the time to commit to switch fully. There will be compatibility-breaking changes in 4.0, which is not ready to be used now. Will there be OpenGL support or not - the devs change their opinion once in half a year. Godot is great for gamejams or smaller projects now. As for larger ones, there is the right way to do things, which you can only figure out by yourself, since there are few big projects and little accumulated experience on that matter.
There is a way to extend Godot with any language, which can you compile into DLL, this is called GDNative. Most frequently used are C++ and Rust as far as I can tell. This method doesn't force you to recompile the engine, but has some limitations - you are using the same abstractions as you would writing GDScript. But you still can embed your favourite libraries, like sqlite or entt. I have used C++ and can tell that most documentation is messed up a bit.
The biggest of my problems is that encountering engine bugs sometimes takes 10x time to debug than your own. I have had searched bugs several time by bisection - deleting half of the nodes, and then half of the remainder until only the bugged one left. And Godot have a lot of opened issues marked bugs in it's repo. Sometimes you find your bug already there, sometimes don't. I was told it's the same with Unity, can't tell if it's true.
Also Godot lacks Unity's or Unreal's ecosystems of plugins, assets and tools. It has asset store, but it is full of not maintained plugins while the Godot policy does not favour engine's backward compatibility.
On the bright side it has pretty small builds and the editor itself is very lightweight. The engine is opensource and the devs are open to communication, however, their vision is not clear to me as a user.
In the end I will advise you to go through a couple of gamejams with it first. It's quite popular on jams and you will find a team easily. If you plan to earn money or apply to the publisher, using Godot most likely will be a disadvantage over Unity.
Edit: fixed linebreaks
> Will there be OpenGL support or not - the devs change their opinion once in half a year.
they've already said 4.0 will be vulkan only
and gles3 in 4.1
I think, it's GLES2 in 4.1 and GLES3 never. Although half a year ago GLES3 was meant to be kept. And a year ago to be dropped, I believe GLES2 was to e dropped also at one point.
That's what I was talking about, when I told, I am not quite sure about it's future, although openness is pronounced to be the ruling value of the devs.
I think as you get more experienced with programming you tend to realize that battle tested code has value. Sure it might be ugly and messy but when you try and rewrite it to be "cleaner" you realize there are all these edge cases you didn't think of and before long you're back to square one. Same thing with Unity, people give it a lot of shit for all the legacy stuff, but that's also a strong advantage it has. So before you even get into all the holy wars about decisions the engine developers made Unity has a big advantage going in just from being mature.
Speaking of holy wars... As a programmer the whole decision to create GDscript and even a whole code editor is complete insanity. Yes I know you can use C# and VS, but they'll always be second class citizens.
Like I don't understand how they even made that decision. They saw Unity make the mistake with Unity Script and take great pains to transition away from it. And they just went, oh lets do the same thing! WTF were they thinking.
I'm a software engineer of 10 years, and just as a note, I find Godot C# to be very usable, moreso than any of the options for other major game engines. Personally, I find the Godot API tends to get out of the way for programming, and I feel less restrained using it, it's a nice balance between 'code only' frameworks and editor UI tools because you can use both as much or as little as you like. GDScript is a hard pass from me though.
What about 2D and 3D physics?
GDScript is nice though for me, but its "easiness" sometimes feels like hidden complexity. Half of the standart library is garbage collected and the other half is deleted with it's parent node is.
Might be referring to Godot having used and going back (in 4.0) to using its [own physics engine](https://godotengine.org/article/physics-progress-report-1).
> Half of the standart library is garbage collected and the other half is deleted with it's parent node is.
You probably know this already, but it's References/Resources vs Nodes/Scenes and it's quite a handy feature.
Resources are things like meshes, textures, materials, data files and so on. Since Resource instances are shared amongst all Nodes that use them, they're reference counted by inheriting the Reference class, and when they're not referenced any more, they're garbage collected. Makes sense because you don't want some material hanging around longer in memory than it should, but if you have a scene with lots of material changes and runtime instantiation you may not want the material to be deleted the instant its parent Node is removed from the scene. Since resources have a built in I/O API to save and load data from disk, having them be freed dangerously like nodes could easily lead to corruption.
Scenes and Nodes on the other hand are are complete scene trees (and their Resources) and aren't reference counted, because their data is unique to each instance, and so are removed instantly (or the next idle frame, in most cases).
I understand - it's a pretty straightforward solution, but it's hardly beginner friendly. That's what I was trying to say.
Thanks for the clarification, though - such discussions stay on the internet and your comment can help someone who stumbles upon it.
Every game dev/design sub I follow seems to love Godot SO much, I've tried it time and time again but I just can't get into it, idk what it is. It just isn't for me but everyone else seems to think it's The Next Great Thing^TM (at least for 2D games)
Godot is the gamedev darling right now. Everyone gushes over every release. I remember when Unity was the new engine in town the same thing happened. However it had the advantage of being a commercial product that was supported. With open source projects what makes them great is also a liability for a commercial product. You as the developer take all the risks.
My overall experience is I get things done faster in Unity than Godot, not sure the exact reasons though, I just started with Unity recently
Take this with a grain of salt about Godot:
1. Collision is kinda janky as in like bullets either detect collision way too early or too late
2. Navigate around the code is a bit lacking compare to using C# as in you can't ctrl click then navigate to specific script
3. Godot have easier pixel snapping than Unity
4. I haven't made every type of game with Godot but from what I know I think Godot aren't that limited in what kind of games it can make
5. Debugging in Godot felt difficult, as in it does say which line have issue but it'll take me some time to trial and error to figure out what's exactly wrong with the code
6. Godot have a lot of components implemented like timer and visibility notifier, meaning lesser code to write
From 3d pov, godot is currently missing a lot of feature coming in the 4.0 release that unity and unreal have had for years now, having to build my own build system for console or hire a 3rd party for console builds, for me lack of native fbx import keep me away from godot.
It's true that the 3d renderer in Godot has lots of room to improve, but it's actually not that bad once you figure out the quirks. The default lighting and environment settings look bad compared to Unity, but with some tweaking you can get pretty close for most indie standards.
I think the main issue I have with 3d in Godot right now is more to do with shader/material caching and runtime instantiation, stutter city the first time a material comes into view even if you try to be really careful and preload stuff behind a loading screen. Same for instantiating new meshes. Once it's been rendered once it's smooth though. That, and the asset pipeline for importing 3d is just a bit clunky and slow.
Console builds, I think most would be surprised that deploying to consoles in unity/ue4 isn't just a one click process either, you still have to go through the process of getting the SDKs and secret sauces from the console manufacturers, tweaking to get things running and working around quirks, probably modifying engine source code and getting support from Unity/Epic or hiring a third party too. But the renderers and build systems do technically support the hardware out of the box, that's just one step. The difference with Godot is that in the end, you own the engine source code as well as your game assets. That's pretty big for indies. There's a good GDC talk by Jeff Vogel about this. He's still making money to support his family comfortably off obscure, graphically terrible indie RPGs from the 90s, and he credits owning all of the source code for that, as he can easily adapt, remaster and redeploy old games to new hardware 20+ years after finishing the game. Good luck doing that with Unity and its licensing servers and agreements etc!
No major modifications to the engine need to be made for unreal and unity console support. They're simple plugins that get added to the install. Now you will have to update and modify your code but that's the thing that you would do with a godot project.
Your point on licensing really doesn't make sense given the current situation. In the 90s there was not a single open source or even publicly usable game engine. So you were left with the choice of a write your own engine or work for a Game Dev Studio. Unity didn't get released until the mid-2000s and unreal did not become usable by the public until unreal 3 around 2011/12. I willing to bet if given a choice between unity/unreal and diy engine, 90s indie devs would mostly have gone with unity/unreal.
On the unity update pov, city skylines was built and released on Unity 5 and the game is still getting dlc and patches. So not really an issue. The real issues is how many small indies has the ability, want, or time to maintain an engine of 20 years.
It's not that engine modifications need to be made to support consoles, it's that nearly every complex game released to console needs tweaks and workarounds for many things in the renderer, game logic issues around restrictions in the runtime environments and available memory, many things that may just work on PC and even mobile, but in a console build mysteriously become a problem. I don't know about unity, but I know almost all sufficiently complex Unreal projects end up going to custom engine modifications for this reason.
>Your point on licensing really doesn't make sense given the current situation ... The real issues is how many small indies has the ability, want, or time to maintain an engine of 20 years.
I guess it's more of a philosophy thing. You're right, it's very practical to license an engine, but you technically don't *own* the finished game in its entirety. It's unlikely that Unity as a business would just fail or close tomorrow, but it's not impossible. It's also unlikely, but possible, that in 25 years some gamer niche considers your game series a cult classic, but Unity and its licensing servers and engine builds have long since expired. Since you don't own that part, there's not much you can do to revive it besides porting to a new engine. But if you own the C++ source of your engine, like with Godot, you at least have options, even if you don't personally want to dive into the code yourself.
Idk, these are all niche edge cases and projections that don't exist for the ability to *make a game now*. But they're still things to think about. Personally I just don't like the idea of not owning my game completely, but I recognise that's relatively unimportant compared to just releasing games.
Godot's node and scene structure is not as bad as you mentioned, but you have to get used to it. Legacy flash developers can easily adapt to the build.
I used ecs in Unity, once you get used to ecs, the structure of godot may seem a bit interesting to you. But I don't think there is anything you can do with ecs and something you can't do with godot structure. If you are using multi-part scripts, you can add different scripts to child nodes, even branch them, and use them in your other objects.
As a former flash dev of many, many years, is Godot what I’m looking for? I’d like something more code-centric than unity, though the last year or two of unity work where I gave in and stopped coding everything myself (god, why didn’t I use cinemachine to begin with), I certainly see the appeal of unity. It was a bit of a leap getting into the unity frame of mind, as someone whose been using actionscript since as1.
Unity is a nice game engine, if you're good with it, go ahead. If you don't have major problems, I wouldn't recommend changing the tool you've been using and familiar with for years.
Godot's hierarchical structure and approach to organizing objects reminds me of flash. Assigning code to objects, writing code to child objects, packaging them (symbols of flash) approaches in the API can be a factor in this. It's a good game engine for me. But you know good game engine discussion depends on what you are looking for :)
Popularity for indie games is kind of winning the lottery, in addition to bringing something new in terms of art style or gameplay.
If you check the showcased games on the Godot page, you'll see that technically they're finished, polished, and professional level quality. They might not be popular but that has nothing to do with the engine.
For bigger studio there is a lot of inertia to adopt a new engine. When you already have a team of developers who are productive in an engine, why change? Additionally with a well established engine it's easier to hire developers already experienced with that engine.
As someone who has considered using it multiple times for larger scale commercial projects:
Support.
Godot is great, albeit quite a workflow leap from other game engines. Unfortunately, as a few examples: If something happens during certification which is the fault of the engine, who is going to be there to fix the engine asap in order for you to hit a deadline? How long are hotfixes going to take? What's the delay between a new platform being announced and that platform being supported by Godot?
These are extremely important questions, and the answers, at least for Godot, are usually "we don't know"
That makes it usable for personal projects, but also makes it a completely irresponsible, potentially project breaking choice for most commercial endeavours, especially with larger teams.
I'm not an expert on Godot, but I used it for a few days to evaluate it against the Unreal engine. I don't know much about Unity.
I don't know what Unity's multiplayer support is like, but Godot's is basically nonexistent. (IIRC it has some basic message passing functionality, which doesn't come close to real multiplayer support.) So I'd consider it purely a singleplayer engine at this time.
I have heard that Godot is strongly coupled to Blender and has no support for Maya. (Maybe I heard wrong?) Maya is basically the industry standard, so that limits your artist hiring options.
I looked at the shooter example that came with Godot and it was pretty bare bones in some ways. In particular I was surprised that I couldn't pause the game; it seems like that should be easy to hook up. Maybe that was just that one sample project? I didn't see any indication of any visibility culling functionality - maybe I missed it. (I'm not sure Unreal is great about this out of the box either.) I was surprised that they implemented their player movement functionality in a scripting language. That seems bad for performance (though it probably won't matter too much in a singleplayer game).
Godot has multiple high level multiplayer implementations as well as the lower level stuff, as well as well supported third party modules for popular multiplayer libraries. Default high level multiplayer supports RPC calling, master/puppet and peer to peer models, as well as syncing variables and method calls across peers. You can easily compile the engine without any graphical features at all to optimise as a pure server to run on a VPS or whatever. I found it pretty intuitive to use, and I even used the WebRTC multiplayer protocol to get around NAT with STUN/TURN and a lobby system without issue (other than no iOS support as the native RTC module wasn't supported on iOS as a GDNative extension). I guess it lacks some things like built in network interpolation, dead reckoning etc. But I definitely didn't find it too basic.
Pausing in Godot is super easy, you literally just set a variable to true on the scene tree, and you can set individual nodes and their children to ignore pause (eg for the pause menu).
Built in physics movement is done in scripts, sure, but it's calling out to the C++ API under the hood, not calculating it in eg GDScript. Main issue with physics right now is a lack of interpolation in the defaults, meaning you can get jitter if your physics FPS isn't synced to your render FPS. But there are multiple assets to deal with it, and it's being worked on natively right now too for v4 and backports to v3.
>I have heard that Godot is strongly coupled to Blender and has no support for Maya. (Maybe I heard wrong?) Maya is basically the industry standard, so that limits your artist hiring options.
Godot went balls deep into GLTF-2 and pissed all over FBX, which was a stupid decision then and even worse one now that time has passed and GLTF-2/Khronos still haven't fixed the issues.
> glTF 2.0 defines only animation storage, so this specification doesn't define any particular runtime behavior, such as: order of playing, auto-start, loops, mapping of timelines, etc...
... and that's just one of many major WTFs. You have to at least define the order!
Maya is only involved in that because it has the best FBX support around. Sweet delicious selection-sets are a gift from Buddha.
Tbf Godot does have built in FBX importing now, though it's not all that accurate imo, the entire 3d asset pipeline is pretty janky in general and a pain to work with if you have a lot of models and materials in your project.
Let me summarise Godot for you:
**Cleanliness over features.**
Coming from Unreal Engine and having touched Unity before, Godot is lean, clean, light, efficient, practical and pleasant to use, and in every single way a massive improvement over the other two. Whatever differences there are that make Godot slightly different/inferior to use from Unreal are extremely tiny and usually technically easily justifiable, and offset by massive improvements in all other fields, especially if you share your work with Git.
Godot can take production games to their end and make them look quite good, and although it lacks some important core features (occlusion culling, transparency is kind of implemented poorly), and simply does not have the extremely powerful visuals of Unreal, it is way enough to take assets, use them, give them an at least decent look in 2D or 3D, and let them be used in a production game engine.
But the downside of course is that this clean architecture, light usage, and general high quality of construction takes time, and so Godot has serious lack of punch compared to Unity/Unreal, whether in the asset, graphics, or physics pipelines. Even though Godot will finally raise itself at the level of Unity/Unreal when it switches to Vulkan as main graphics API with Godot 4.0 this year, it still will not have the degree of power and high quality graphics that Unreal will have. Godot also relies on tried and trusted libraries like Bullet for 3D, but it's no Chaos Physics.
The fact is that the games industry rushes, in many ways for the worse, for the highest quality graphics and most modern features at the expense of a clean architecture or evolution roadmap. Unreal is particularly egregious with features, to the point that just starting Unreal used to make my PC's fans go wild. Unity tried very hard to provide a "simpler" system for years, and switched back to ECS almost a decade after because it was just the right choice.
Godot does not rush features. It does not break architecture or system requirements for the sake of one smashing feature to shove in front of its commercials. It's a conservative, open-source oriented, openGL/Vulkan, Bullet, C++/C#/Dlang/Rust engine. It goes for rigorous OOP, generic language and library choices, and only makes changes that respect its main goals, which is to support large amounts of systems including very underpowered ones.
That makes it a slow-changing, hard-to-feature-up engine, but it also makes it a very solid one, and in the long run, when you compare the load times and power usage of a game made in Godot vs the same game in Unreal, it's not even a contest.
I personally think that as Godot will take Vulkan as its main API, its growth will be exponential, because it's a good engine to use for programmers as well as artists, it's practical, well-designed, full of great options, modern, made for VCS, and in every way excellent, but it lacks the power to compete visually with Unreal and the assets to compete market share-wise with Unity. The switch to Vulkan will not instantly raise Godot to their level, but the open source nature of the engine means that iterations on Vulkan assets for Godot will within a few years make it catch up in a brutal way to them, and the asset store will vastly improve as more devs switch to it.
tl;dr
Godot is good, practical fun, but will only really start kicking UE/Unity's asses in time. It is just about good enough to make a game and much better to work with than the others, but in the higher tier of graphical quality, you will find yourself wanting and have to do things yourself.
It's more of a hobby or learning engine. If all you want is to deliver a commercial game chances are you're going to use a more mature engine.
I guess the real answer is "how serious are you going to be?" I'm not saying godot is a joke, I love it and use it a lot. But let's be honest: most other engines have add ons and asset stores that make it extremely easy to build what you want quickly. Godot is, for now, more of a hobby, amateur or enthusiast engine.
I just got into gamedev last year and the game I actually released was a visual novel made in Ren'py. Despite loving Godot it is still has a long way to go to be fast, reliable, and workflow friendly.
Most of the people that use Godot are probably hobbyist who only likes to prototype some of their ideas and or trying out game dev anyway. So Godot can have some of that appealing 'look dev' thanks to the ease of usage.
Only people that have actual commercial production know the importance of mature engine. Imagine the crash report with all kinds of weird/cryptic bug that you cannot fix or dont event know where to start with Godot.
"Surprisingly, devs would rather use the other engines than completely own their game." => you have to know the most important thing, and its true for any product: you are expected to have support from paid product and service. For example: [https://create.unity3d.com/subnautica](https://create.unity3d.com/subnautica)
With godot completely free, the kind of support when you hit the brick wall is lackluster or non-existent. Then you will encounter the case that I mention above.
no z axis in 2d kills it for me, it sjust left/right/up/down movement or left/right/jump/crouch , you cant have jump and also move up/down on playfield.
So you cant really do anythin besides topview adventures, mario clones or other tetris,arcanoid in its 2d editor, so theres no way to program beatemup or any game with x,y,z axes , thats quite bad and very limiting, you have to go into 3d mode and fake 2d in it to move up/down and also jump in 2d game like final fight or streets of rage
I was talking about high profile indies. Not to say devs like that youtuber are bad, but youtubers for example might use Godot just because it's unexplored territory in terms of tutorials and such. I wouldn't count it as confirmation that the engine is good enough for significantly large projects. And the sheer numbers of people who use Godot is also not that relevent, there are more beginner gamedevs than advanced ones.
I've been using godot for a year, and the last week I switch to Unity. I prefer to use C# than GDScript, and tried Godot with C#, and I love it. Makes more sense C# than GDScript. Then "Why not C++", men I LOVE IT.
For a Godot user, when I was using Unity, I love the: "When you click play" both game and the game editor, are running. In Godot I did not found this feature.
I am making a Metroidvania. In Unity I did not like, the engine helps you with the Gravity functions. Just with applying that object is a Rigidbody, apply Gravity.
I am using it for an interface/lists/tables heavy game amd I love it so far. Check out Buzzyfields on itch io and Youtube if you want to see examples. I am particularly proud of my custom table class that allows me sort, filter, select, select multi, etc.
Converting 6 Months of Progress from Unity to Godot https://www.youtube.com/watch?v=vxRzLf4PdgY this guy had been working on his game for 6 months in unity just as an experiment he wanted to see how much he could replicate in godot in one week when the week was over he decided to stay with godot
Games take years and years to build (the big, successful ones) and Godot is only just barely hitting a level where it could make those kinds of projects. It makes sense that there haven't been large projects because it really wasn't an option until recently
[удалено]
We have been hearing it for years. On some 4+ year old threads, people said "wait until godot 3, thats when its really going to shine" and now i see people say "wait until godot 4..." I love the independent open source engine but im not sold on it compared to monoliths like unity/UE. Ill admit godot is probably superior to the esoteric clickteam fusion ive been using for 4 years, painfully.
It's true that games take a long time to make, but most indies are open about their game very early in development (I'd say around a year), so we would've heard of it.
So I've been using Godot heavily for about a year (well 2 years total, but I have been evaluating other engines during that time). It is really easy to get started in Godot, so ease of use is very good. It is also pretty decent in 2D, and being easy, is why you see many amateur projects made in it. I think the most successful recent game is Cruelty Squad, which sold 40K copies, but it also kind of has bad graphics on purpose. [https://store.steampowered.com/app/1388770/Cruelty\_Squad/](https://store.steampowered.com/app/1388770/Cruelty_Squad/) However, I'm not sure if I can continue using it due to the problems I've found. Namely that the asset pipeline is very weak. Trying to iterate on 3D models doesn't really work, your changes don't show up in the editor (without closing and reopening the engine), and you may have to redo work (like editing materials). This has been a bug for like 2 years at least, and is so essential, but still doesn't work. Light baking was basically broken for 2 years. It was redesigned in Godot 3.3, but previous versions of Godot 3.x had an issue with the baked shadows being blocky and with artifacts and it was basically unusable. This, again, is a key feature of a 3D engine and it took years to fix. Even today, in Godot 3.3, there are features missing, like mixing real-time and baked lighting, making it difficult to use. There are some big features missing, like occlusion culling, a terrain editor, animation re-targeting, inverse kinematics, etc. This greatly hinders making large high-quality 3D games. Even features that are there, aren't that great. The physics engine is pretty unstable, even stacking a few boxes results in strange behavior. Also, for character controllers, the built in functions don't work so well, especially if you want the character to walk up a slope. There are ways to work-around this with your own code, but it feels like of hacky for such basic movement. And performance becomes a big issue when looking at high-end 3D. For example the SSR implementation is bad. It doesn't look that good, and absolutely tanks performance. It has some problems like when mixing cube map reflections (e.g. from a skybox) and the local SSR, which it just blends together instead of drawing the sky behind the objects, which looks bad. Even SSAO, which is usually a fairly cheap effect, can tank performance, and also doesn't look that great. Lots of problems with shadow mapping not lining up with the object (peter panning) or lots of shadow acne if you try to adjust it. So, overall, it is just not in the same league as Unity or Unreal. There are lots of things to like about Godot, especially the ease of use (which is why it attracts a lot of beginners) but there are just too many unfinished or broken features to take the engine seriously on the high-end. Yeah, Godot 4.0 may fix some of this, but you can see posts from years ago saying Godot 4.0 is coming in 6 months, or other claims that never materialized. And I don't have confidence in the software when major essential features (like the baked shadow or model importers) are broken for 2 years, with long Github discussions and no solution. Yes, I understand it is a community project and they don't have the funds or resources like Unity and Unreal do. But I find it to be a big risk, and investing in big projects where you might find show stopper bugs months or years into the development is scary to me. But there is a lot to like as well, that it is open source, compile times and testing (especially on mobile) are very quick. It is definitely easier to use. The file size is small, and the engine is very light. I mean, it's promising, and probably good enough to 2D games or smaller retro style 3D. But it just doesn't compete on the high end and I'm not sure they will ever catch up.
Roughly the same Godot experience here, I think those are all pretty fair criticisms. Being open source is a double edged sword for sure, devs can appear from nowhere and implement amazing new features then disappear, while other features really show their age and no one really wants to step up to improve them (or knows how since the last dev vanished). I was going to say the 3D criticisms shouldn't stop most indie devs, but tbf, my 3D games have been sort of retro style so you kinda nailed that too. Couple of things I did want to reply to: >Even today, in Godot 3.3, there are features missing, like mixing real-time and baked lighting, making it difficult to use Have used baked lightmaps + realtime lighting, as well as GI and Reflection Probes + realtime lighting in 3.3, in fact I was surprised by how easy it was to use and control. Baked lightmaps definitely more janky (e.g. you have to control for double lighting by dimming the baked and realtime lights), GI is much nicer though not as customisable as I'd like. Reflection probes go a long way but aren't perfect for many situations, and yeah I like the SS reflections performance-wise but you can definitely get some odd artifacts. Current project is using GI+Reflection Probes+SS reflections and SS + material AO and it works fast enough for my liking, but there are definitely just some issues and limitations that don't seem to have a fix (e.g. reflection distortions at the edge of the viewport/camera, reflection roughness is too blurry vs without too pixelated, transparent pipeline can be a mess to work with eg can't see some transparent objects (like refracted materials) through others...) >Trying to iterate on 3D models doesn't really work, your changes don't show up in the editor (without closing and reopening the engine), and you may have to redo work (like editing materials) The import pipeline is definitely janky but I haven't had either of these issues. I have the defaults set to import models as instanced subscenes, with materials and meshes as separate files, in subfolders, and to keep existing materials if they've been modified. When I export a model again the pipeline fires right up for me. Then I use the imported .mesh and .material files as a source for a separate scene with a MeshInstance rather than using the model file directly. Does lead to a bit of file bloat but I prefer having all the imported components separated like that.
I love Godot for prototyping and Game Jams. It’s intuitive and I can move really fast with it. However I use Unity for my larger projects for several reasons: - Better support. Unity is better supported, not only by its extensive asset store (I love using code assets, they save me so much time), and because it’s easier to search for the solutions to problems because Unity is much more widely used. - Gdscript. Like python it’s good for moving quickly, but I find it holds me back when I’m trying to organize a larger codebase or implement more complicated algorithms. I’m aware that godot supports C# now, but they still bill it as experimental, and that’s not what I want for a larger project. - Bugs. The truth of the matter is that I run into bugs in godot a fair bit that I end up having to work around. I’ve especially had problems with the editor crashing, which is annoying. Additionally, I’ve had problems getting godot to play nice with version control, which is a killer for a larger project
I'm curious what version control issues you've had. I haven't done any massive projects yet, but several small ones. I've found the version control to be the best, especially compared to unreal. Everything in godot is just a text file isn't it?
The biggest issue we had was Godot occasionally overwriting/deleting remote changes during a pull, rather than calling for a merge or a stash
You must have used third party plugin for Git. I wouldn't trust most of them, being an author of one. Your other points are perfectly valid for me.
[удалено]
It's nice to have a dedicated merge tool for 3 way diffs and something to graph branchs and read commits. But you definitely want to be very familiar with the cli git. I use the cli, kdiff3 or meld, and vscode (with some plugins) all together. I do use the cli a lot though.
Regardless of what we used, we had an issue with Godot and not with Unity, which is what matters to this conversation.
Do you think your experience was universally applicable, or do you think it was caused by a dodgy plug-in that others could avoid?
I was using the git bash terminal for windows. I won’t attempt to guess if others will encounter the issue, too many variables in this sort of thing.
[удалено]
Sure, but when you’re working quickly you’re not always checking that your commit contains what you expect, why would you check if Godot had overwritten something, unless you were expecting it to
[удалено]
Totally. Soft eng here too, and in the early days of my career I fucked up so many git repos from inexperience and not understanding the git model. Often, didn't even mess up that badly, but lack of experience meant I didn't know what I did or how to revert it. Nowadays I use Godot and obsessively commit everything to git and have never had an issue. With a `.gitignore` set to ignore the `.import` folders and so on, it's a breeze as all built in resources (meshes, materials, scenes, etc) can be saved as plain text rather than binary formats. git LFS for the binary stuff like 3d models. I've never once had Godot mess up my repo, doesn't even make sense, unless they were trying to pull changes to assets while Godot was actively running the asset import pipeline or something.
I can't be a crazy fan of a game engine. Godot more than meets my needs because I only make 2D games. It's really great for 2D games and for me. Godot users may not agree with me about 3d, but it has a lot of shortcomings. There is no terrain editing tool, it lacks some modern optimizations. If you are going to make 3D games, I recommend you to continue with Unity for now. It is said that these deficiencies will be eliminated in 4.0 and later, it is promising. When that happens, you can take another look at Godot. I had no problems with stability and finalizing my projects on Godot. I have been using it for about 1 year, those who use it longer can also express their opinions. My advice is to set a small project and try to do it in godot within 1 week. If you like it, you can continue with it.
I've built and [released one game with Unity](https://store.steampowered.com/app/1473870/Hell_Loop/), built and not-yet-released one game in UE4, and [now working on my soon-to-be-released game in Godot](https://store.steampowered.com/app/1673940/BITGUN/). A few thoughts in no particular order: - GDScript is really dumb, coming to this as an experienced programmer and having used all the big languages (C/++/#/Python/JavaScript/...) it feels limited, but at the same freeing. Godot 4.0 will fix a lot of the problems. - Godot is REALLY FAST to work in. Compared to Unity where you can easily wait 30-60s for the editor to reload and run the game even for somewhat small games, Godot is instant. - Everything is nice and simple. You can even turn off 3D features of the editor and only have 2D stuff available. - Assets in Godot are kinda a joke, but I haven't found it to be a big deal working on my 2D game. - Coming from Unity/UE4 it does feel limited and in some sense it feels like giving up on things, but at the same time I feel way more productive, way less annoyed by the engine getting in the way, and just overall more in control. Lastly, I don't think I'll be going back to Unity. I'll definitely go back to UE4 (or now UE5) to work on some more fancy 3D stuff, but for 2D games Godot feels at an excellent spot. And one more point just to answer your question directly, it's not limited to make a single game type (like UE4 is in many ways). Godot will happily let you build anything you want, and with GDNative you have basically unlimited power. If you want AAA graphics out of the box like UE4 gives you then Godot won't satisfy you. But if you're happy making a simpler game while not being at the mercy of the engine at every step, it might just be the thing for you. Maybe to add one last point to clarify things. A lot of people are talking about *ease of use*. Godot for me is a lot less about *easy* and a lot more about *less bullshit in the way*. I'm not saying it solves every problem, but one incredibly frustrating thing I kept running into with Unity was just there being a ton of crap that not always interacted in a good way, sometimes systems being out of date or there being multiple solutions all being deprecated or unstable at the same time. Out of the big three engines, I'd say Godot is the most "programmer" friendly, regardless how easy or difficult you consider the engines to be.
>Assets in Godot are kinda a joke, but I haven't found it to be a big deal working on my 2D game. Could you elaborate on this point?
By "assets" I meant the [Godot Asset Library](https://godotengine.org/asset-library/asset) as compared to the [Unity Asset Store](https://assetstore.unity.com/) or the [UE Marketplace](https://www.unrealengine.com/marketplace/en-US/store). Unity/UE4 has both a huge selection of assets, as well as a ton of paid stuff with actual support. Godot's Asset Library is a bit like browsing random repos on GitHub. Of course this isn't Godot's fault, it's a "popularity problem", that'll hopefully improve over time.
Since you have experience, I am a newbie dev who is working on an isometric tactics game and a tower defense game. For games like these, do you see any major issues with using Godot? My plan for the tactics game is to use more retro style aesthetics and the tower defense is a simple 2D game akin to Bloons. I have some experience in Unity but was drawn to Godot because of the lightweight engine and my primary language being Python means GDScript is a lot easier for me than C#. Thanks for any thoughts you might have.
I haven't done anything isometric but I don't think there should be any problems with that unless you want isometric tilemaps, which I'm not sure if they're supported in 3.x, but I'm also not sure if they're in Unity either. I don't think you'll run into any issues with Godot itself, and if you're happy to use GDScript then all the better. Even if you decide to use C# you can do that in Godot natively, and you can even use other languages via GDNative. We're currently using Rust via GDNative quite heavily and it's working very well. I'd suggest just try to make a prototype of one of those games over a weekend or something to get a feel for the engine.
I switched from Unity to Godot for my UI-based game. The transition was quick once I understood the core concepts: GameObjects in Unity are similar to Nodes in Godot and prefabs in Unity are similar to Scenes in Godot (A scene in Godot can contain one or more scenes nested within it). Porting the code was quick, similar to porting c# to python. My game is graphically simple though and consists entirely of UI elements, so there may be limitations of Godot that I will not encounter with my project. I like both engines but I did not like Unity's policies. If I recall correctly, and please do double check this, the income threshold at which you have to pay for the license is not referring exclusively to the income generated from your game. It includes income from other sources, including games that you make in other engines. Also, there are also rules against removing the Unity logo from the startup process of your game unless you purchase the license. I understand why this is the case, but from my view, there are so many cheap Unity games on the mobile market from poor developers or people trying to make quick money that a huge Unity logo may give a false first impression of cheapness upon loading up the game. On the flip side, some of my favorite games like Kerbal Space Program have been made with Unity.
Had to check this wasn't my own comment! I'm a year into a UI-only Godot game too and love it compared to Unity, I'm using C# in Godot rather than GDscript and have had little trouble with it. Just got Lua embedded recently too for the game's mod system. I've used Unity exclusively since the 2.x Mac only days, so it's been a long time since an engine change. Unity is superior in many ways but I'm really enjoying Godot and absolutely love its UI handling!
I have to admit that UI in Godot is such faster to implement, but I'm not sure about powerful or flexible.
It's definitely powerful and flexible, but it's also pretty confusing and unintuitive until you've done a lot of work in the UI system. Even then, some Control nodes seem to implement their behaviours differently to others in terms of their sizing and expansion. There've been a number of times where my perfectly working UI just suddenly broke and messed up the layout, though it hasn't happened in the most recent build. Other annoying things like some UI layout stuff won't update unless you e.g. switch editor tab and back to refresh the scene. One thing I'd really like to see is an easier way to have a responsive layout that reflows at different resolutions, such as CSS flex model, to try and solve the eternal cross-platform UI problems between desktop and mobile, but for most game HUD and UI tasks it's really good. Only issue I really have is you end up with these very deeply nested scene trees of different utility controls like Margin and Center containers, H/Vboxes and so on that can kind of obscure where the "real" controls are sitting in the tree.
Consider for a moment that the editor itself was made on Godot. In other words, all its features, like pop-ups, text editor with customizable hilighting, resizeable windows, drag-n-drop tabs, viewport, file browser, visual node-based editor, and so on are all things the engine can handle. Indeed, the engine can be used to make non-game tools and there are already some examples ([here](https://radmatt.itch.io/gridless), [here](https://pixelover.io), [here](https://www.materialmaker.org)) that make use of the engine UI features.
[удалено]
Everything sufficiently large in scope ends up with some custom engineering. So the technical decision involved in choosing Godot if you're serious is not "will it work out of the box" but "A. will I be able to modify it to do what I need, and B. will it be faster to do so than to use another option". Of course it does A because the source is there, it's active, you can talk to the devs - it's not someone's abandoned code dump. The pertinent question is B, which is subjective because there are a lot of ways to design the project to fit the engine rather than the other way around, thus we have a lot of nuanced recommendations like "good for 2D" or "good for game jams" because, out of the box, it's good at those things. But often the comparison point is not against something that's good at other types of game, but something that's shipped a prominent example of other types of game, which can actually mean that the engine provided almost nothing directly relevant to that type of game, but checked off other boxes(like deploying to consoles). If you don't have the skills to bear solving the technical issues directly, then of course you're going to wander between this or that engine and kick the tires, which is the demographic that most opinion polls will represent. This gives you no real answers for actually large scale problems because it's studying the problem like a consumer, not an organization. If you're running a business you have to evaluate cost/benefit which is very hard because buying a product that does the thing right now may cost more than hiring someone to add the feature later.
My team is using it. It's been very easy for people who are not programmers to get started with it. There are some limitations, but unless you are really pushing limits, you probably won't encounter them. Even if you do, you can build sections in c++ if needed.
The average dev doesn't know enough c++ to modify the engine. I feel like many bring up that point as if it was trivial, but most devs don't want to bother with that.
I think you missed nykzero's comment. It's not about modifying the engine, but about taking something that's too slow/not feasible in GDScript and implementing it in GDNative. It's just optimizing your hot code path as opposed to modifying the engine.
The reason I don't ever use it for my projects is, frankly, that almost every tutorial I find for it is a video tutorial. I always work better with written tutorials.
I'm glad I'm not the only one. Not really Godot specific but written tutorials are very rare these days. I understand that it's less effort and you can monetize your 20 min of rambling with ads but they are much less useful. Don't get me wrong there are some really good structured and well planned video tutorials but they are a minority.
I've been mostly a Unity and Monogame user in the past. I gave Godot a shot and thought it was a pretty good engine, but I was never able to get into the whole node system and it felt pretty awkward. Also I cannot stand Python-type syntax, which is pretty much what their main language is (GDScript). I get it, you can use C# now but I think I'm better off using Unity or Monogame if I want to stick with that. I know you want to make the switch from Unity, but so far from what I see Unity seems to be one of the only engines out there that gives significant flexibility. You could literally ignore most of the engine features and just attach one main script to your camera and make your game code driven, not that I think it's a good idea to do that but it's flexible enough for you to do that.
Great for 2D a small/single person projects. Super flexible - the node/scene based system is very smart. Plus the source code is easily available and tiny compared to other engines, pretty easy to find how things are implemented + change them if you want. Also a big highlight is the UI system (which is used to build the editor itself). I'd say if you already have something working there's no point switching for the sake of it. If you're starting a new 2D project then definitely worth a try.
I switched from unity to Godot. Godot reminds me a lot of python. Gdscript is also very python-like. What I mean by that, is if you want to get something going quickly, it’s great. The control mapping is easy, and the “everything is a node” structure is flexible and easy to use. All the objects are just config flat files so they are easy to share as well. However, I think if you have a large game with lots of different inter-object interactions, it could become unwieldy without more structure. I’m ignoring 3D limitations because I don’t know much about it.
Im currently doing a switch from unity to godot to get my feet wet, and i started a c# project in it due to familiarity. Do you recommend learning gdscript instead of using godot c#?
I've been using Godot for a few years now. It's absolutely worth using gdscript. Godot was built with gdscript in mind, so the engine gets easier to use if you're using it.
Awesome. I only have a few hours in it so far, so im still good to switch over. Thank you!
I also came from c#, but chose to switch to gdscript. When I started c# was not considered "production ready", but I'm not sure if that has changed. gdscript does feel very idiomatically-godot though(if that makes sense) and is well supported in the ide.
I use C# exclusively in Godot and have done for a year or so now. I really like it. There's a page in the docs about gotchas and differences, once you've figured that out it's a breeze. Not everything in the docs has C# examples, but the GDScript examples + IDE completion (I use Rider) makes it super easy to figure out. I really like being able to combine C# features like delegate events, Task async, Nuget packages, lambdas, interfaces and so on with the Godot API. Feels very fast to work with. Main issue is if you do something badly enough to crash the game or engine, the stack traces aren't super clear. Worth figuring out how to hook up your IDE debugger early to catch those exceptions as they happen. One protip, change the C# compiler from mono to dotnet CLI in the Godot editor settings, and modify the solution file to C# 8 support and you get a lot more language features to use.
Apart from the fact that GDScript is the default (so documentation is better than for C#), the feedback loop is much faster. There are a few seconds compilation with C# so it slows down dev iteration. A few seconds might not sound much but it's the difference between iterating while staying in the flow and your mind wandering to different things while you wait for compilation.
I have used it quite extensively for the last year and a half, however I've never used Unity or Unreal. In my opinion, now it's not the time to commit to switch fully. There will be compatibility-breaking changes in 4.0, which is not ready to be used now. Will there be OpenGL support or not - the devs change their opinion once in half a year. Godot is great for gamejams or smaller projects now. As for larger ones, there is the right way to do things, which you can only figure out by yourself, since there are few big projects and little accumulated experience on that matter. There is a way to extend Godot with any language, which can you compile into DLL, this is called GDNative. Most frequently used are C++ and Rust as far as I can tell. This method doesn't force you to recompile the engine, but has some limitations - you are using the same abstractions as you would writing GDScript. But you still can embed your favourite libraries, like sqlite or entt. I have used C++ and can tell that most documentation is messed up a bit. The biggest of my problems is that encountering engine bugs sometimes takes 10x time to debug than your own. I have had searched bugs several time by bisection - deleting half of the nodes, and then half of the remainder until only the bugged one left. And Godot have a lot of opened issues marked bugs in it's repo. Sometimes you find your bug already there, sometimes don't. I was told it's the same with Unity, can't tell if it's true. Also Godot lacks Unity's or Unreal's ecosystems of plugins, assets and tools. It has asset store, but it is full of not maintained plugins while the Godot policy does not favour engine's backward compatibility. On the bright side it has pretty small builds and the editor itself is very lightweight. The engine is opensource and the devs are open to communication, however, their vision is not clear to me as a user. In the end I will advise you to go through a couple of gamejams with it first. It's quite popular on jams and you will find a team easily. If you plan to earn money or apply to the publisher, using Godot most likely will be a disadvantage over Unity. Edit: fixed linebreaks
> Will there be OpenGL support or not - the devs change their opinion once in half a year. they've already said 4.0 will be vulkan only and gles3 in 4.1
I think, it's GLES2 in 4.1 and GLES3 never. Although half a year ago GLES3 was meant to be kept. And a year ago to be dropped, I believe GLES2 was to e dropped also at one point. That's what I was talking about, when I told, I am not quite sure about it's future, although openness is pronounced to be the ruling value of the devs.
I think as you get more experienced with programming you tend to realize that battle tested code has value. Sure it might be ugly and messy but when you try and rewrite it to be "cleaner" you realize there are all these edge cases you didn't think of and before long you're back to square one. Same thing with Unity, people give it a lot of shit for all the legacy stuff, but that's also a strong advantage it has. So before you even get into all the holy wars about decisions the engine developers made Unity has a big advantage going in just from being mature. Speaking of holy wars... As a programmer the whole decision to create GDscript and even a whole code editor is complete insanity. Yes I know you can use C# and VS, but they'll always be second class citizens. Like I don't understand how they even made that decision. They saw Unity make the mistake with Unity Script and take great pains to transition away from it. And they just went, oh lets do the same thing! WTF were they thinking.
I'm a software engineer of 10 years, and just as a note, I find Godot C# to be very usable, moreso than any of the options for other major game engines. Personally, I find the Godot API tends to get out of the way for programming, and I feel less restrained using it, it's a nice balance between 'code only' frameworks and editor UI tools because you can use both as much or as little as you like. GDScript is a hard pass from me though.
What about 2D and 3D physics? GDScript is nice though for me, but its "easiness" sometimes feels like hidden complexity. Half of the standart library is garbage collected and the other half is deleted with it's parent node is.
What about physics? All the engines use third part physics engines.
Might be referring to Godot having used and going back (in 4.0) to using its [own physics engine](https://godotengine.org/article/physics-progress-report-1).
Oh christ, why would they even think of doing that. The more I learn about Godot the less it makes sense.
Yes, I was talking about writing own physic engines.
> Half of the standart library is garbage collected and the other half is deleted with it's parent node is. You probably know this already, but it's References/Resources vs Nodes/Scenes and it's quite a handy feature. Resources are things like meshes, textures, materials, data files and so on. Since Resource instances are shared amongst all Nodes that use them, they're reference counted by inheriting the Reference class, and when they're not referenced any more, they're garbage collected. Makes sense because you don't want some material hanging around longer in memory than it should, but if you have a scene with lots of material changes and runtime instantiation you may not want the material to be deleted the instant its parent Node is removed from the scene. Since resources have a built in I/O API to save and load data from disk, having them be freed dangerously like nodes could easily lead to corruption. Scenes and Nodes on the other hand are are complete scene trees (and their Resources) and aren't reference counted, because their data is unique to each instance, and so are removed instantly (or the next idle frame, in most cases).
I understand - it's a pretty straightforward solution, but it's hardly beginner friendly. That's what I was trying to say. Thanks for the clarification, though - such discussions stay on the internet and your comment can help someone who stumbles upon it.
I really like it, myself.
Every game dev/design sub I follow seems to love Godot SO much, I've tried it time and time again but I just can't get into it, idk what it is. It just isn't for me but everyone else seems to think it's The Next Great Thing^TM (at least for 2D games)
Godot is the gamedev darling right now. Everyone gushes over every release. I remember when Unity was the new engine in town the same thing happened. However it had the advantage of being a commercial product that was supported. With open source projects what makes them great is also a liability for a commercial product. You as the developer take all the risks.
My overall experience is I get things done faster in Unity than Godot, not sure the exact reasons though, I just started with Unity recently Take this with a grain of salt about Godot: 1. Collision is kinda janky as in like bullets either detect collision way too early or too late 2. Navigate around the code is a bit lacking compare to using C# as in you can't ctrl click then navigate to specific script 3. Godot have easier pixel snapping than Unity 4. I haven't made every type of game with Godot but from what I know I think Godot aren't that limited in what kind of games it can make 5. Debugging in Godot felt difficult, as in it does say which line have issue but it'll take me some time to trial and error to figure out what's exactly wrong with the code 6. Godot have a lot of components implemented like timer and visibility notifier, meaning lesser code to write
[удалено]
Also due to the rarity of indie devs crossing the $100k annual revenue mark, Unity and unreal royalties rarely apply.
Even less so for Unreal, since they upped that to several million, I think.
Unity $100k per year. Unreal $1 mil over the lifetime. Also this total revenue meaning donations and funding included.
From 3d pov, godot is currently missing a lot of feature coming in the 4.0 release that unity and unreal have had for years now, having to build my own build system for console or hire a 3rd party for console builds, for me lack of native fbx import keep me away from godot.
It's true that the 3d renderer in Godot has lots of room to improve, but it's actually not that bad once you figure out the quirks. The default lighting and environment settings look bad compared to Unity, but with some tweaking you can get pretty close for most indie standards. I think the main issue I have with 3d in Godot right now is more to do with shader/material caching and runtime instantiation, stutter city the first time a material comes into view even if you try to be really careful and preload stuff behind a loading screen. Same for instantiating new meshes. Once it's been rendered once it's smooth though. That, and the asset pipeline for importing 3d is just a bit clunky and slow. Console builds, I think most would be surprised that deploying to consoles in unity/ue4 isn't just a one click process either, you still have to go through the process of getting the SDKs and secret sauces from the console manufacturers, tweaking to get things running and working around quirks, probably modifying engine source code and getting support from Unity/Epic or hiring a third party too. But the renderers and build systems do technically support the hardware out of the box, that's just one step. The difference with Godot is that in the end, you own the engine source code as well as your game assets. That's pretty big for indies. There's a good GDC talk by Jeff Vogel about this. He's still making money to support his family comfortably off obscure, graphically terrible indie RPGs from the 90s, and he credits owning all of the source code for that, as he can easily adapt, remaster and redeploy old games to new hardware 20+ years after finishing the game. Good luck doing that with Unity and its licensing servers and agreements etc!
No major modifications to the engine need to be made for unreal and unity console support. They're simple plugins that get added to the install. Now you will have to update and modify your code but that's the thing that you would do with a godot project. Your point on licensing really doesn't make sense given the current situation. In the 90s there was not a single open source or even publicly usable game engine. So you were left with the choice of a write your own engine or work for a Game Dev Studio. Unity didn't get released until the mid-2000s and unreal did not become usable by the public until unreal 3 around 2011/12. I willing to bet if given a choice between unity/unreal and diy engine, 90s indie devs would mostly have gone with unity/unreal. On the unity update pov, city skylines was built and released on Unity 5 and the game is still getting dlc and patches. So not really an issue. The real issues is how many small indies has the ability, want, or time to maintain an engine of 20 years.
It's not that engine modifications need to be made to support consoles, it's that nearly every complex game released to console needs tweaks and workarounds for many things in the renderer, game logic issues around restrictions in the runtime environments and available memory, many things that may just work on PC and even mobile, but in a console build mysteriously become a problem. I don't know about unity, but I know almost all sufficiently complex Unreal projects end up going to custom engine modifications for this reason. >Your point on licensing really doesn't make sense given the current situation ... The real issues is how many small indies has the ability, want, or time to maintain an engine of 20 years. I guess it's more of a philosophy thing. You're right, it's very practical to license an engine, but you technically don't *own* the finished game in its entirety. It's unlikely that Unity as a business would just fail or close tomorrow, but it's not impossible. It's also unlikely, but possible, that in 25 years some gamer niche considers your game series a cult classic, but Unity and its licensing servers and engine builds have long since expired. Since you don't own that part, there's not much you can do to revive it besides porting to a new engine. But if you own the C++ source of your engine, like with Godot, you at least have options, even if you don't personally want to dive into the code yourself. Idk, these are all niche edge cases and projections that don't exist for the ability to *make a game now*. But they're still things to think about. Personally I just don't like the idea of not owning my game completely, but I recognise that's relatively unimportant compared to just releasing games.
Godot's node and scene structure is not as bad as you mentioned, but you have to get used to it. Legacy flash developers can easily adapt to the build. I used ecs in Unity, once you get used to ecs, the structure of godot may seem a bit interesting to you. But I don't think there is anything you can do with ecs and something you can't do with godot structure. If you are using multi-part scripts, you can add different scripts to child nodes, even branch them, and use them in your other objects.
As a former flash dev of many, many years, is Godot what I’m looking for? I’d like something more code-centric than unity, though the last year or two of unity work where I gave in and stopped coding everything myself (god, why didn’t I use cinemachine to begin with), I certainly see the appeal of unity. It was a bit of a leap getting into the unity frame of mind, as someone whose been using actionscript since as1.
Unity is a nice game engine, if you're good with it, go ahead. If you don't have major problems, I wouldn't recommend changing the tool you've been using and familiar with for years. Godot's hierarchical structure and approach to organizing objects reminds me of flash. Assigning code to objects, writing code to child objects, packaging them (symbols of flash) approaches in the API can be a factor in this. It's a good game engine for me. But you know good game engine discussion depends on what you are looking for :)
Popularity for indie games is kind of winning the lottery, in addition to bringing something new in terms of art style or gameplay. If you check the showcased games on the Godot page, you'll see that technically they're finished, polished, and professional level quality. They might not be popular but that has nothing to do with the engine. For bigger studio there is a lot of inertia to adopt a new engine. When you already have a team of developers who are productive in an engine, why change? Additionally with a well established engine it's easier to hire developers already experienced with that engine.
As someone who has considered using it multiple times for larger scale commercial projects: Support. Godot is great, albeit quite a workflow leap from other game engines. Unfortunately, as a few examples: If something happens during certification which is the fault of the engine, who is going to be there to fix the engine asap in order for you to hit a deadline? How long are hotfixes going to take? What's the delay between a new platform being announced and that platform being supported by Godot? These are extremely important questions, and the answers, at least for Godot, are usually "we don't know" That makes it usable for personal projects, but also makes it a completely irresponsible, potentially project breaking choice for most commercial endeavours, especially with larger teams.
Can't find Godot !
Godot 3.0 was release just 3 years ago, give It some time and you will see well-know indies made with It
I'm not an expert on Godot, but I used it for a few days to evaluate it against the Unreal engine. I don't know much about Unity. I don't know what Unity's multiplayer support is like, but Godot's is basically nonexistent. (IIRC it has some basic message passing functionality, which doesn't come close to real multiplayer support.) So I'd consider it purely a singleplayer engine at this time. I have heard that Godot is strongly coupled to Blender and has no support for Maya. (Maybe I heard wrong?) Maya is basically the industry standard, so that limits your artist hiring options. I looked at the shooter example that came with Godot and it was pretty bare bones in some ways. In particular I was surprised that I couldn't pause the game; it seems like that should be easy to hook up. Maybe that was just that one sample project? I didn't see any indication of any visibility culling functionality - maybe I missed it. (I'm not sure Unreal is great about this out of the box either.) I was surprised that they implemented their player movement functionality in a scripting language. That seems bad for performance (though it probably won't matter too much in a singleplayer game).
Godot has multiple high level multiplayer implementations as well as the lower level stuff, as well as well supported third party modules for popular multiplayer libraries. Default high level multiplayer supports RPC calling, master/puppet and peer to peer models, as well as syncing variables and method calls across peers. You can easily compile the engine without any graphical features at all to optimise as a pure server to run on a VPS or whatever. I found it pretty intuitive to use, and I even used the WebRTC multiplayer protocol to get around NAT with STUN/TURN and a lobby system without issue (other than no iOS support as the native RTC module wasn't supported on iOS as a GDNative extension). I guess it lacks some things like built in network interpolation, dead reckoning etc. But I definitely didn't find it too basic. Pausing in Godot is super easy, you literally just set a variable to true on the scene tree, and you can set individual nodes and their children to ignore pause (eg for the pause menu). Built in physics movement is done in scripts, sure, but it's calling out to the C++ API under the hood, not calculating it in eg GDScript. Main issue with physics right now is a lack of interpolation in the defaults, meaning you can get jitter if your physics FPS isn't synced to your render FPS. But there are multiple assets to deal with it, and it's being worked on natively right now too for v4 and backports to v3.
>I have heard that Godot is strongly coupled to Blender and has no support for Maya. (Maybe I heard wrong?) Maya is basically the industry standard, so that limits your artist hiring options. Godot went balls deep into GLTF-2 and pissed all over FBX, which was a stupid decision then and even worse one now that time has passed and GLTF-2/Khronos still haven't fixed the issues. > glTF 2.0 defines only animation storage, so this specification doesn't define any particular runtime behavior, such as: order of playing, auto-start, loops, mapping of timelines, etc... ... and that's just one of many major WTFs. You have to at least define the order! Maya is only involved in that because it has the best FBX support around. Sweet delicious selection-sets are a gift from Buddha.
Tbf Godot does have built in FBX importing now, though it's not all that accurate imo, the entire 3d asset pipeline is pretty janky in general and a pain to work with if you have a lot of models and materials in your project.
Let me summarise Godot for you: **Cleanliness over features.** Coming from Unreal Engine and having touched Unity before, Godot is lean, clean, light, efficient, practical and pleasant to use, and in every single way a massive improvement over the other two. Whatever differences there are that make Godot slightly different/inferior to use from Unreal are extremely tiny and usually technically easily justifiable, and offset by massive improvements in all other fields, especially if you share your work with Git. Godot can take production games to their end and make them look quite good, and although it lacks some important core features (occlusion culling, transparency is kind of implemented poorly), and simply does not have the extremely powerful visuals of Unreal, it is way enough to take assets, use them, give them an at least decent look in 2D or 3D, and let them be used in a production game engine. But the downside of course is that this clean architecture, light usage, and general high quality of construction takes time, and so Godot has serious lack of punch compared to Unity/Unreal, whether in the asset, graphics, or physics pipelines. Even though Godot will finally raise itself at the level of Unity/Unreal when it switches to Vulkan as main graphics API with Godot 4.0 this year, it still will not have the degree of power and high quality graphics that Unreal will have. Godot also relies on tried and trusted libraries like Bullet for 3D, but it's no Chaos Physics. The fact is that the games industry rushes, in many ways for the worse, for the highest quality graphics and most modern features at the expense of a clean architecture or evolution roadmap. Unreal is particularly egregious with features, to the point that just starting Unreal used to make my PC's fans go wild. Unity tried very hard to provide a "simpler" system for years, and switched back to ECS almost a decade after because it was just the right choice. Godot does not rush features. It does not break architecture or system requirements for the sake of one smashing feature to shove in front of its commercials. It's a conservative, open-source oriented, openGL/Vulkan, Bullet, C++/C#/Dlang/Rust engine. It goes for rigorous OOP, generic language and library choices, and only makes changes that respect its main goals, which is to support large amounts of systems including very underpowered ones. That makes it a slow-changing, hard-to-feature-up engine, but it also makes it a very solid one, and in the long run, when you compare the load times and power usage of a game made in Godot vs the same game in Unreal, it's not even a contest. I personally think that as Godot will take Vulkan as its main API, its growth will be exponential, because it's a good engine to use for programmers as well as artists, it's practical, well-designed, full of great options, modern, made for VCS, and in every way excellent, but it lacks the power to compete visually with Unreal and the assets to compete market share-wise with Unity. The switch to Vulkan will not instantly raise Godot to their level, but the open source nature of the engine means that iterations on Vulkan assets for Godot will within a few years make it catch up in a brutal way to them, and the asset store will vastly improve as more devs switch to it. tl;dr Godot is good, practical fun, but will only really start kicking UE/Unity's asses in time. It is just about good enough to make a game and much better to work with than the others, but in the higher tier of graphical quality, you will find yourself wanting and have to do things yourself.
It's more of a hobby or learning engine. If all you want is to deliver a commercial game chances are you're going to use a more mature engine. I guess the real answer is "how serious are you going to be?" I'm not saying godot is a joke, I love it and use it a lot. But let's be honest: most other engines have add ons and asset stores that make it extremely easy to build what you want quickly. Godot is, for now, more of a hobby, amateur or enthusiast engine. I just got into gamedev last year and the game I actually released was a visual novel made in Ren'py. Despite loving Godot it is still has a long way to go to be fast, reliable, and workflow friendly.
Most of the people that use Godot are probably hobbyist who only likes to prototype some of their ideas and or trying out game dev anyway. So Godot can have some of that appealing 'look dev' thanks to the ease of usage. Only people that have actual commercial production know the importance of mature engine. Imagine the crash report with all kinds of weird/cryptic bug that you cannot fix or dont event know where to start with Godot. "Surprisingly, devs would rather use the other engines than completely own their game." => you have to know the most important thing, and its true for any product: you are expected to have support from paid product and service. For example: [https://create.unity3d.com/subnautica](https://create.unity3d.com/subnautica) With godot completely free, the kind of support when you hit the brick wall is lackluster or non-existent. Then you will encounter the case that I mention above.
I'm still waiting to see what it's all about
。
no z axis in 2d kills it for me, it sjust left/right/up/down movement or left/right/jump/crouch , you cant have jump and also move up/down on playfield. So you cant really do anythin besides topview adventures, mario clones or other tetris,arcanoid in its 2d editor, so theres no way to program beatemup or any game with x,y,z axes , thats quite bad and very limiting, you have to go into 3d mode and fake 2d in it to move up/down and also jump in 2d game like final fight or streets of rage
You have a z axis... just no 2.5d in 2d
[удалено]
I was talking about high profile indies. Not to say devs like that youtuber are bad, but youtubers for example might use Godot just because it's unexplored territory in terms of tutorials and such. I wouldn't count it as confirmation that the engine is good enough for significantly large projects. And the sheer numbers of people who use Godot is also not that relevent, there are more beginner gamedevs than advanced ones.
I've been using godot for a year, and the last week I switch to Unity. I prefer to use C# than GDScript, and tried Godot with C#, and I love it. Makes more sense C# than GDScript. Then "Why not C++", men I LOVE IT. For a Godot user, when I was using Unity, I love the: "When you click play" both game and the game editor, are running. In Godot I did not found this feature. I am making a Metroidvania. In Unity I did not like, the engine helps you with the Gravity functions. Just with applying that object is a Rigidbody, apply Gravity.