All I can say is working with Godot is an absolute bliss. Seriously, it's fun, it's "easy" and it gets out of the way. Within a couple of weeks, you can be focusing on making your game, rather than a constantly evolving tech-demo.
There are only two caveats: understand what Godot is not good at, 3D open world / large landscape, and console development.
Godot 4.0 was a total mess the last time I tried it though. The Vulkan stuff was completely half baked and the UI was acting out. Godot 3.2 though, solid fun.
Godot 4.0 still has a long way to go before it's ready for everyday use fortunately, not even in alpha state yet so I wouldn't judge it too prematurely.
Do other engines cull parts of objects?
facebook is a large financial contributor to the godot project. I think they do some dev work too. I get the impression they really want more VR games to exist, and work well on their device, no matter how they get there.
Godot just doesn't fight you the way Unity does.
So if you're in space, and you're flying nearby a big ship full of triangles, such as an imperial star destroyer, you run your framerate down to the ground if you render even only 5% of it, as it renders everything else as well.
You can mitigate that to some degree by breaking up objects, but even the shell being plain would still cause massive issues.
For first person, open world, or large environment type game, I'd recommend Unreal. For 3D isometric style games, it's perfectly suitable with knowing the caveats and minimal adjustments from an asset creation perspective.
There is limiting of overdraw (not rendering the same pixel multiple times) which is easy with Z-buffers. There is frustum culling (not rendering triangles that are outside your FoV or facing away from you) already of course.
The final type of culling is occlusion culling which is avoiding rendering that starship because it's on the other side of a planet from your viewpoint (for example). That's not a feature of 3.X but it's a feature of 4.0. The technical details are pretty interesting, it uses Intel Embree (the raytracing library) to do a low-res raytrace to find the occlusions.
The 3D it can do is kinda... "shoved" into it. It works but it wasn't designed from the ground up like other native 3D engines are.
Last I checked the editor has no advanced 3D scene editing features, and the engine itself has no basic capabilities that are needed for large open world 3D games, like being able to load tons of stuff on the fly as the player moves in a way the player doesn't notice.
I mean, yes and no? In that the 3D renderer is a completely separate system to the 2D renderer. But, that means that the 3D renderer... was designed from the ground up to do 3D. Unlike the other direction with Unity, where 2D support is a hack of the 3D engine.
I've been using Godot 3's 3D features for quite a while now, and obviously as a single indie developer I'm not using it for AAA features, but it's still as competent as any other renderer I've used for my use cases.
> Last I checked the editor has no advanced 3D scene editing features, and the engine itself has no basic capabilities that are needed for large open world 3D games, like being able to load tons of stuff on the fly as the player moves in a way the player doesn't notice.
You're going to have to be more specific about "advanced 3D scene editing features", as the editor is actually very good, besides which, I compose most of my 3D scenes in code. Meanwhile, Godot supports everything needed to stream assets at runtime, from multi-threading support, to async resource loaders, LOD, and so on. Granted, you have to kind of roll your own.
The main issue people bring up for large, open world 3D games (which may be a dream of most developers who've not really made a game yet, but in any engine quickly becomes a "one day" project and not something feasible for most people) is the 3D renderer itself, which doesn't have occlusion culling, but again in most realistic cases you wouldn't ever notice this (and it has been added as a feature to Godot 4 already).
For example, recently I was messing around with voxels, and recompiled the engine with a C++ module called "Voxel Tools"[^1]. This supports level streaming and movement throughout large levels without floating point errors (ie, you have a VoxelViewer node that gives the illusion of moving through a large space, while actually not moving further from the origin than you can see).
It doesn't seem like they've made much progress in Godot 3.3 - seems like a grant ran out so they had to let their C# dev go, so I don't expect any major changes for the foreseeable future.
Keep in mind that I'm obviously quite soured by the experienced - Godot might still be the right choice for anyone who is considering. I'd just recommend anyone to factor the very rough C# support into their choice, especially for anyone planning to use it for a more involved project.
My company cannot afford to wait until Godot 4 to build product. And since we’ve got a big investment in prior work, there is little chance we will switch that work over to a platform that will be brand new in a short period of time.
Don't get me wrong, I'm not saying you have no right to complain. But the way you're going about it is off-putting. Godot's devs are working hard and what you're saying isn't constructive.
I mean, it's MIT licensed. So no, not really. It's designed to make games, and the commercials are left to you.
My advice: don't bother waiting for Godot 4 just because it sounds nice. You'd be surprised at how many of the "limitations" of the 3.x branches are not actually problems at all for most use cases (granted, your company may have a very niche use case...)
Will it be a good choice for FPS shooters taking place primarily in closed spaces like buildings, etc?
If you're keen on this, I recommend using Trenchbroom for level design and the plugin that goes with it in Godot, it's pretty cool! (Qodot)
That would only leave 3D models + minimal scene (e.g. top-down/isometric games), which minimizes the amount of occlusion?
I was starting to make a 3D game for mobile and was planning on using UE4, but I've heard a lot of good things about Godot. Are there any pain points or blind spots in Godot's feature set?
for 2D I'd definitely go Godot.
I mostly do 3D games with fixed or limited range cameras (not first persons) so Godot works nicely.
Overall you'll need to understand well the engine you choose going forward. They all have their pros and cons.
As an example, it takes 3-4 hours to recompile the UE4 engine source code (for customization). Godot, about 4-12 minutes, in its entirety.
Having used C++ and Blueprints extensively, GDScript is really a breeze. Of course games perform better if made entirely in low level C++, but as an indie you have to make a choice and you have to ship a game.
Looking forward to better tilemap support in 4.0
Curious if you had a direct experience with the console side of things with your game?
Also, can I provide you an opportunity to promote your game by asking you to tell us more about the game you shipped? :)
(The rest of this isn't directed at you but more trying to clarify the Godot console situation for anyone else interested.)
I've noticed there seems to be a lot of misunderstanding (particularly by "less commercially experienced" game devs) in relation to Godot's "console support" or apparent lack thereof.
Godot do now at least have a page[1] to directly address the issue and clarify the situation which can be mostly summed up with:
"... there is no engine that is legally allowed to distribute console export templates without requiring the user to prove that they are a licensed console developer."
and:
"Console ports of Godot are offered by third-party companies (which have ported Godot on their own)."
I seem to recall there was one FLOSS game engine that got a grant or something to incorporate support for some XBox initiative (that wasn't "full devkit support" level) but for every other major console there's no engine that has FLOSS code supporting it--and if it did then no one could probably tell anyone about it because of NDAs. :D
As a side note[0]:
"Additionally, there is some unofficial third-party work being done on building for some consoles. However, none of this is included in the default build scripts or export templates at this time."
The situation is also the same for other FLOSS projects, e.g. the Rust language, where the issues tracking game console support basically say "if you have the ability to develop for (current) game consoles, you also know we can't talk about it here where others aren't under manufacturer NDA":
https://github.com/rust-gamedev/wg/issues/90
https://github.com/EmbarkStudios/rust-ecosystem/issues/18
https://www.reddit.com/r/rust/comments/jtqgn4/q_feasibility_...
Hope your game is selling well. :)
[0] https://docs.godotengine.org/en/stable/about/faq.html#which-...
[1] https://docs.godotengine.org/en/stable/tutorials/platform/co...
Godot by default does not support consoles. Yes, you can to employ another company to port it for you, but that is a no go for me. UE4 on the other hand you can do it all yourself once you get the developer kit and access (legally) to the platform of your choice.
On the other hand you can easily do mobile with Godot.
I'm curious because i'm dabbling in some gamedev and wanting to eventually ship mobile and console. I'm more focused on bleeding edge tooling though, Rust gamedev specifically, but i'm curious if the reasons Godot doesn't ship to console also means any Rust project won't be able to ever, either.
Is there something preventing opensource lowbudget projects from shipping to console? Are you forced to go UE4/etc if you want to ship consoles?
And, yeah, that's fair enough--although I imagine if you offered one of the companies enough money they might be willing to license their port under similar terms to those Epic offers UE4 console support under. :D
(And given at least two companies have apparently ported Godot so far, porting it oneself is presumably also an option & one would have full source to work with.)
And of course on the blue website /r/godot and /r/madewithgodot
[0]https://www.youtube.com/watch?v=yRHN_WEulLc
[1]https://www.youtube.com/channel/UCrHQNOyU1q6BFEfkNq2CYMA
[2]https://www.youtube.com/c/Gdquest/videos
[3]https://www.youtube.com/watch?v=iDEcP8Mc-7s&list=PLS9MbmO_ss...
I really enjoyed his style and he does a good job hitting all the important points.
It was a very simple process, there were one or two typos I found in the code that an experienced programmer should be able to resolve themselves if they haven't been fixed yet.
I haven't done more yet since but would like to. Unfortunately playing games is too fun.
I'm very impressed with the quality of Godot and its continuous improvements.
I say this because I've shipped physics simulation games and Godot has been the simplest most reliable engine for that.
I haven't played around with other engines that much so I can't comment on how they work.
[0] https://stride3d.net/ [1] https://vvvv.org/ [2] https://janet-lang.org/
This feels so satisfying for some reason, it feels like it set ups a great feedback loop where improvements needed to improve the editor also result in improvements to the whole platform
I have no issues with current fonts. Enable filter in your font settings, can try importing at a massive size designing at a high render scale, and using the viewport scaling to scale it down.
Native viewport (no scaling) and using no scale on your labels should make it all render as you'd expect, however.
The animation support is also excellent, allowing to key every node property and even adding code calls perfectly adjustable in the timeline. I never used Flash to create things myself, but I hear people comparing Godot to it in terms of being able to do stuff. And from my own experience I believe it.
For 2D games I can't quite think of anything better. My own stuff has plenty of 2D visual effects (think of a discount version of the Super Robot Wars series in terms of looks), shaders, a zillion explosions and even my former computer (already a toaster circa 2014) barely registered CPU activity. 3D wasn't as good, although I was able to do little things that looked fine and performed okay in my former computer, it was noticeably more intensive, and the 3D demos by other people with full effects and high poly counts went at like 5FPS (they run smooth in my new machine, but gotta think of the weakest link). Godot 4.0 promises interesting upgrades on that field, though.
Since my game is going to need 3D for dungeon navigation I think I'll try to wait until 4.0 is released to finish that part, even if I have to port my code to accommodate for breaking changes. I did it with an earlier game in the transition from 2.x to 3.x and was a bit tedious but not really difficult. I'm not in a hurry and I can improve plot and features while at it, I'm just going to release it as FOSS when done, so I can wait and see if the improvements are worth it.
That's a preamble to recommending to check out popular open source games like OpenTTD, 0 A.D., or Cataclysm: Dark Days Ahead. None of them use Godot, but they all use game development principles that you would apply in Godot if you were using it.
Might be third party companies out there that could be hired to do the porting, but I don’t know.
This is an open source project, so they can do what they want.
Isn't it a bit onerous to ask the users to build/rebuild the whole engine/toolchain if we want to use the c++ version in Windows.
I don't compile Intellij for my environment to use if, for example.
All builds (except for server/headless build which is Linux only) are available for Linux, macos and Windows as binaries. This includes the standard build and the Mono build. All builds are also capable of loading dynamic libraries at runtime which you can write in C++.
Compiling the whole thing definitely seems onerous but it's surprisingly easy, even for me who barely knows C++. If you're interested you can read about it here: https://docs.godotengine.org/en/stable/development/compiling...
Most people don't compile the engine themselves though, but it's a very viable option if you know how to use a command line.
I don't even see what you mean by it being "a c++ available for linux". You got the same choices for all systems. Just download the editor/engine and start programming. No need to compile anything, except your own scripts/logic if you choose to use a compiled language.
