10 ms·

I've shipped a commercial game in Godot 3.2. I'm also well versed and shipped games in UE4. All I can say is working with Godot is an absolute bliss. Seriously

by keyle 6y ago

I've shipped a commercial game in Godot 3.2. I'm also well versed and shipped games in UE4. 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.

void_mint 6y ago
This matches my experience (but replace UE4 with Unity). Godot just doesn't fight you the way Unity does.
- aroman 6y ago
  Can you give some examples?
  - Hammershaft 6y ago
    In my experience Godot is a significantly more coherent 2d engine. In Unity a 2d game is running in its 3d engine, and useful functions will often be limited to operating on different pairs of dimensions ((x,y) (x,z) (y,z)).
    - aroman 6y ago
      Sure, but as someone working on a moderately sized 2d game in Unity - I’ve never really found that to be anything more than a minor annoyance. At most it’s just an extra cast here or there. Are there other examples of it being better for 2d?
      - mekkkkkk 6y ago
        One thing that makes Godot smoother in my experience is its project structure. It doesn't use traditional ECS, but relies on inheritance and composition. Combined with the "everything is a node" mindset, it makes it much easier to maintain a mental map of the game. The node hierarchy tree is much more revealing than in Unity atleast (I've dabbled in both). EDIT: This doesn't just apply to 2D, so maybe it's a weird reply.
      - lewispollard 6y ago
        It uses pixels as its units for 2D, which is the main advantage over Unity, depending on your use case (ie, it's very good for pixel perfect 2D games). If you want to move your sprite 33 pixels, you just add 33 to the translation. This also applies to physics, GUI elements, etc. You can also combine the separate 2D and 3D renderers, while maintaining 2D pixel vectors for your 2D objects, and 3D unit vectors for 3D. Yeah, there are pixel perfect cameras and so on for Unity, but it's so nice to be able to just work in 2D as if it were actually 2D. Simple things in 2D renderers like alpha handling and overdraw was slower in Unity than Godot for that reason when I last used it, since it's more complicated to render those things in a 3D engine than a 2D one (admittedly, I last used Unity properly at least a couple of years ago, may have changed). It has parallax scrolling features built in. Small thing, but there are lots of little features like that scattered in the default tools that just don't exist in Unity without writing your own, or paying for an asset. In Godot you just drop the node in and you're away. Godot has an asset store too - where everything is free and open source, and linked to their git repositories. For example, you can add a minecraft-like voxel engine, dialog editors, a Redux-like store, shaders, new GUI elements, and so on in Godot for free, in a click, without an account, or a single webview or browser page in sight. Granted, this means that older assets may no longer work or be maintained, but the same can be said of Unity (and my experience with the Unity asset store is that half the time, nothing works out of the box anyway even when you've paid a chunk for it, and rarely does a tool just do the simple thing that it says it does, and therefore takes a bunch of work just to get the thing to play nice with your code). The recent 3.3 release added a bunch of 2D renderer improvements such as BVH partitioning/batching for rendering and physics, vertex pixel snap on the GPU, The only thing that Unity has over Godot in terms of 2D imo is the Box2D physics engine (Godot uses its own 2D physics implementation that, while adequate for a lot of games, isn't quite as flexible as Unity). That said, there are at least 2 Godot plugin modules that add (partial) Box2D support just from a brief Github search. Moving away from 2D specifically - the animation player/controller in Godot is amazing - you create an animation player node, and you can then key in literally any property of any object from the editor to be animated, and draw out animations with bezier curves and so on, animating multiple properties at once, which you can then play back with a simple call to `AnimationPlayer.play("name");`. You can use a single animation to animate vectors, enums, bools, simultaneously by just drawing them into the animation editor. Last I checked Unity didn't have anything like that. You've got a complicated mesh structure with layers of materials and shaders, and you want to interpolate various properties on various materials of those mesh structures, it's as simple as creating the animation, going to the materials, and hitting the key button on the properties you want to alter. From a general design perspective, Godot's scene tree works kind of like Unity's nested prefabs - a feature they implemented long after Godot had nailed this kind of structure, and it still does it in a much simpler and less hacky way than Unity. Everything in a Godot game is already essentially a nested prefab, without the clunk of having to distinguish between regular prefabs holding nested prefabs, or ensuring your modified prefabs are in sync, and so on. You can create simple components composed of complicated structures of nodes, save them into a new scene file with a click, and drop that anywhere else in your scene tree wherever you like, as a native and expected behaviour. It's a bit like React components in that you can very easily combine and produce new combinations of your existing work, even at runtime. You can then easily share these nodes between godot projects, or even write a simple plugin to add them to Godot's list of built-in nodes. Oh, and all of those scene, node and resource files are just plain text files, easily editable in a text editor, and extremely friendly to VCS. Besides all of this, if you write a game in Godot you own 100% of the source code, both your game code and the engine supporting it. No licensing, no pricing plans, no salespeople. No official support, yet the community and contributors are extremely helpful. Engine doesn't do something you want? You can patch it and recompile, and add new third party C++ modules (eg, you can add full Javascript/Typescript/Rust/D/Python/Nim scripting support this way, as well as new engine features with native speed) by dropping them in the modules folder of the engine source. There's a legendary talk at GDC by Jeff Vogel, who's been writing obscure, ugly RPGs as Spiderweb Software since the mid-90s. One of his points is that if you want to make a living writing indie games as a solo developer, owning the source code is one of the best things you can do, since 20 years down the line you can still update and compile it, remaster, and sell more copies of work you finished long ago (which Jeff has done many times, and is still now writing those obscure games and supporting his family from it). Good luck getting Unity 2020 to work, build your game, and have the license to use it commercially in 2040 ;)
    - IshKebab 6y ago
      But that's how 2D games actually work. They're really just 3D games with an orthographic camera. It doesn't really make sense to have separate 2D and 3D engines.
      - ludamad 6y ago
        Core engines no, but Godot scene model overall fits very well for making 2D games. You end up using naturally named things, composing stuff on a 2D plane, etc. I'm sure an experienced unity user can cut through the noise.
      - Qwertious 6y ago
        Maybe HammerShaft is referring to the fact that Godot usually has separate components for 2D and 3D? Like, there's Node2D and RigidBody2D and Bone2D and Camera2D etc etc etc.
      - lewispollard 6y ago
        Not true. Something as simple as transparency in a 3D engine is far less performant than a true 2D engine because of all the depth testing, shader overdraw, lightmapping, etc. There's a pretty big overhead even if you're not using any 3D features. Plus, in a true 2D engine you just work in pixels, rather than arbitrary 3D units that you have to work out the pixels from the projection, scale, camera settings and so on, which makes life a lot easier for many 2D games. Plus, you can support a much larger range of hardware with a true 2D renderer that targets specific 2D graphics APIs, than with a cutting-edge 3D engine hacked to look 2D.
        pjmlp 6y ago
        That would make sense 20 years ago, nowdays all graphic cards are designed for 3D APIs, regardless what you do, the driver only knows about 3D stuff.
        lewispollard 6y ago
        Is that true of eg, the graphics chip in an older android phone, that only supports gles2? That's mainly what I mean by that statement.
trinovantes 6y ago
I'd like to know more about what you mean by "Godot is not good at 3D open world". Is it just a matter of performance or something more architectural?
- speeder 6y ago
  Godot wasn't intended to be used for 3D at all, it started as purely 2D engine. 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.
  - lewispollard 6y ago
    > 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. 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). https://github.com/Zylann/godot_voxel https://github.com/Zylann/godot_voxel
stolen_biscuit 6y ago
I've had a similar experience. Godot is a fantastic 2D engine, and a capable 3D engine. If your goal is shipping a fully featured 3D game I'd still recommend Unity or Unreal over Godot, unless you're comfortable with it not being an industry leader. For 2D however, I'd recommend Godot above anything. 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.
- keyle 6y ago
  To be fair, it's perfectly fine for 3D, such as traditional "isometric" style 3D. It suffers more with the lack of clever culling in first person style cameras, especially near large objects (it renders the whole object, even if 5% of it is seen).
  - onion2k 6y ago
    it renders the whole object, even if 5% of it is seen Do other engines cull parts of objects?
    - bluefirebrand 6y ago
      Absolutely. Vertex culling is a long-standing 3D engine optimization.
    - kayamon 6y ago
      No.
  - videogreg93 6y ago
    Godot 4.0 will include occlusion culling actually, so there's hope.
- Buttons840 6y ago
  And as mentioned in the article/release, they are serious about maintaining Godot 3 and won't neglect it in favor of 4.
kumarvvr 6y ago
> 3D open world / large landscape, and console development. Will it be a good choice for FPS shooters taking place primarily in closed spaces like buildings, etc?
- jay_kyburz 6y ago
  There is no built in occlusion system. So I would say no.
  - TeMPOraL 6y ago
    Wait, so if it's not good at 3D outdoor scenes, and not good at 3D indoor scenes, then... what is it good at, in terms of 3D games? That would only leave 3D models + minimal scene (e.g. top-down/isometric games), which minimizes the amount of occlusion?
    - follower 6y ago
      With regard to 3D indoor scenes, performance is entirely related to the complexity of the scenes & how much effort is put into loading/unloading non-visible areas etc. For a couple of data points, here is the official Godot third person shooter demo: https://github.com/godotengine/tps-demo https://github.com/godotengine/tps-demo And you can also find "Platformer 3D" demo here (playable in browser too): https://godotengine.github.io/godot-demo-projects/ https://godotengine.github.io/godot-demo-projects/ The showcase also has some 3D games that have been produced: https://godotengine.org/showcase https://godotengine.org/showcase Also TailQuest in development 3D Platform/Puzzle: https://www.reddit.com/r/godot/comments/gnfjn9/tailquest_so_what_is_it_our_game_tower_defense/ https://www.reddit.com/r/godot/comments/gnfjn9/tailquest_so_... Various people have experimented with voxel worlds and other things which push the limits of the engine & are viewable on YT. In short, with 3.0, Godot isn't competing with, say, Unreal in the 3D realism stakes but it still has more 3D capability than most people who start to make a 3D game will actually hit when the scope of the work required becomes apparent. :)
    - jay_kyburz 6y ago
      Any game where camera frustum culling can easily cull the number of object rendered. So when the camera is pointing in a fixed direction and you have control what moves in front of it.
lattalayta 6y ago
What kind of game did you ship? Was it 2D or 3D? 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?
- mekkkkkk 6y ago
  In general I'd say Godot is excellent for the average indie game. It might not be the best choice for cutting edge AAA rendering or performance. In my experience the most important aspect of an engine for a solo/hobby developer is the ergonomics and the workflow. I've found Godot to be a breeze of fresh air in this respect compared to the much more clunky Unity or UE.
- keyle 6y ago
  With UE4 you have a very large engine to deal with. With Godot you'll spend more time making your game look AAA. 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.
aflag 6y ago
Which language did you use? GDScript?
- keyle 6y ago
  Yes GDScript. Very few gotchas, very easy to learn and maintain in my head. I believe I had to recompile the engine a few times for various things, which took a bit more, but the game can be shipped entirely with GDScript. 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.
tekni5 6y ago
I enjoyed the challenge of figuring out what game you made, by deciphering your profile. :)
follower 6y ago
> console development. 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/rust-gamedev/wg/issues/90 https://github.com/EmbarkStudios/rust-ecosystem/issues/18 https://github.com/EmbarkStudios/rust-ecosystem/issues/18 https://www.reddit.com/r/rust/comments/jtqgn4/q_feasibility_of_rust_on_consoles/ 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-platforms-are-supported-by-godot https://docs.godotengine.org/en/stable/about/faq.html#which-... [1] https://docs.godotengine.org/en/stable/tutorials/platform/consoles.html https://docs.godotengine.org/en/stable/tutorials/platform/co...
- keyle 6y ago
  I shipped a game exclusive to PS4 using UE4 about 4 years ago. 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.
clarge1120 6y ago
I can’t tell if the Godot team is serious about commercial viability. 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.
- ShinTakuya 6y ago
  Well you're welcome to hire some extra engineers on Godot's behalf. They can only go so fast with shoestring budget. If it doesn't meet your requirements, consider alternative engines such as Unreal. 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.
- lewispollard 6y ago
  > I can’t tell if the Godot team is serious about commercial viability. 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...)
M5x7wI3CmbEem10 6y ago
what about 2.5D? side scroller games that allow limited movement on the z-axis. think Paper Mario
jokethrowaway 6y ago
I would add tilemaps to the things that don't flow very well. Looking forward to better tilemap support in 4.0

by keyle 6y ago

void_mint 6y ago

This matches my experience (but replace UE4 with Unity). Godot just doesn't fight you the way Unity does.

aroman 6y ago
Can you give some examples?
- Hammershaft 6y ago
  In my experience Godot is a significantly more coherent 2d engine. In Unity a 2d game is running in its 3d engine, and useful functions will often be limited to operating on different pairs of dimensions ((x,y) (x,z) (y,z)).
  - aroman 6y ago
    Sure, but as someone working on a moderately sized 2d game in Unity - I’ve never really found that to be anything more than a minor annoyance. At most it’s just an extra cast here or there. Are there other examples of it being better for 2d?
    - mekkkkkk 6y ago
      One thing that makes Godot smoother in my experience is its project structure. It doesn't use traditional ECS, but relies on inheritance and composition. Combined with the "everything is a node" mindset, it makes it much easier to maintain a mental map of the game. The node hierarchy tree is much more revealing than in Unity atleast (I've dabbled in both). EDIT: This doesn't just apply to 2D, so maybe it's a weird reply.
    - lewispollard 6y ago
      It uses pixels as its units for 2D, which is the main advantage over Unity, depending on your use case (ie, it's very good for pixel perfect 2D games). If you want to move your sprite 33 pixels, you just add 33 to the translation. This also applies to physics, GUI elements, etc. You can also combine the separate 2D and 3D renderers, while maintaining 2D pixel vectors for your 2D objects, and 3D unit vectors for 3D. Yeah, there are pixel perfect cameras and so on for Unity, but it's so nice to be able to just work in 2D as if it were actually 2D. Simple things in 2D renderers like alpha handling and overdraw was slower in Unity than Godot for that reason when I last used it, since it's more complicated to render those things in a 3D engine than a 2D one (admittedly, I last used Unity properly at least a couple of years ago, may have changed). It has parallax scrolling features built in. Small thing, but there are lots of little features like that scattered in the default tools that just don't exist in Unity without writing your own, or paying for an asset. In Godot you just drop the node in and you're away. Godot has an asset store too - where everything is free and open source, and linked to their git repositories. For example, you can add a minecraft-like voxel engine, dialog editors, a Redux-like store, shaders, new GUI elements, and so on in Godot for free, in a click, without an account, or a single webview or browser page in sight. Granted, this means that older assets may no longer work or be maintained, but the same can be said of Unity (and my experience with the Unity asset store is that half the time, nothing works out of the box anyway even when you've paid a chunk for it, and rarely does a tool just do the simple thing that it says it does, and therefore takes a bunch of work just to get the thing to play nice with your code). The recent 3.3 release added a bunch of 2D renderer improvements such as BVH partitioning/batching for rendering and physics, vertex pixel snap on the GPU, The only thing that Unity has over Godot in terms of 2D imo is the Box2D physics engine (Godot uses its own 2D physics implementation that, while adequate for a lot of games, isn't quite as flexible as Unity). That said, there are at least 2 Godot plugin modules that add (partial) Box2D support just from a brief Github search. Moving away from 2D specifically - the animation player/controller in Godot is amazing - you create an animation player node, and you can then key in literally any property of any object from the editor to be animated, and draw out animations with bezier curves and so on, animating multiple properties at once, which you can then play back with a simple call to `AnimationPlayer.play("name");`. You can use a single animation to animate vectors, enums, bools, simultaneously by just drawing them into the animation editor. Last I checked Unity didn't have anything like that. You've got a complicated mesh structure with layers of materials and shaders, and you want to interpolate various properties on various materials of those mesh structures, it's as simple as creating the animation, going to the materials, and hitting the key button on the properties you want to alter. From a general design perspective, Godot's scene tree works kind of like Unity's nested prefabs - a feature they implemented long after Godot had nailed this kind of structure, and it still does it in a much simpler and less hacky way than Unity. Everything in a Godot game is already essentially a nested prefab, without the clunk of having to distinguish between regular prefabs holding nested prefabs, or ensuring your modified prefabs are in sync, and so on. You can create simple components composed of complicated structures of nodes, save them into a new scene file with a click, and drop that anywhere else in your scene tree wherever you like, as a native and expected behaviour. It's a bit like React components in that you can very easily combine and produce new combinations of your existing work, even at runtime. You can then easily share these nodes between godot projects, or even write a simple plugin to add them to Godot's list of built-in nodes. Oh, and all of those scene, node and resource files are just plain text files, easily editable in a text editor, and extremely friendly to VCS. Besides all of this, if you write a game in Godot you own 100% of the source code, both your game code and the engine supporting it. No licensing, no pricing plans, no salespeople. No official support, yet the community and contributors are extremely helpful. Engine doesn't do something you want? You can patch it and recompile, and add new third party C++ modules (eg, you can add full Javascript/Typescript/Rust/D/Python/Nim scripting support this way, as well as new engine features with native speed) by dropping them in the modules folder of the engine source. There's a legendary talk at GDC by Jeff Vogel, who's been writing obscure, ugly RPGs as Spiderweb Software since the mid-90s. One of his points is that if you want to make a living writing indie games as a solo developer, owning the source code is one of the best things you can do, since 20 years down the line you can still update and compile it, remaster, and sell more copies of work you finished long ago (which Jeff has done many times, and is still now writing those obscure games and supporting his family from it). Good luck getting Unity 2020 to work, build your game, and have the license to use it commercially in 2040 ;)
  - IshKebab 6y ago
    But that's how 2D games actually work. They're really just 3D games with an orthographic camera. It doesn't really make sense to have separate 2D and 3D engines.
    - ludamad 6y ago
      Core engines no, but Godot scene model overall fits very well for making 2D games. You end up using naturally named things, composing stuff on a 2D plane, etc. I'm sure an experienced unity user can cut through the noise.
    - Qwertious 6y ago
      Maybe HammerShaft is referring to the fact that Godot usually has separate components for 2D and 3D? Like, there's Node2D and RigidBody2D and Bone2D and Camera2D etc etc etc.
    - lewispollard 6y ago
      Not true. Something as simple as transparency in a 3D engine is far less performant than a true 2D engine because of all the depth testing, shader overdraw, lightmapping, etc. There's a pretty big overhead even if you're not using any 3D features. Plus, in a true 2D engine you just work in pixels, rather than arbitrary 3D units that you have to work out the pixels from the projection, scale, camera settings and so on, which makes life a lot easier for many 2D games. Plus, you can support a much larger range of hardware with a true 2D renderer that targets specific 2D graphics APIs, than with a cutting-edge 3D engine hacked to look 2D.
      - pjmlp 6y ago
        That would make sense 20 years ago, nowdays all graphic cards are designed for 3D APIs, regardless what you do, the driver only knows about 3D stuff.
        lewispollard 6y ago
        Is that true of eg, the graphics chip in an older android phone, that only supports gles2? That's mainly what I mean by that statement.

trinovantes 6y ago

I'd like to know more about what you mean by "Godot is not good at 3D open world". Is it just a matter of performance or something more architectural?

speeder 6y ago
Godot wasn't intended to be used for 3D at all, it started as purely 2D engine. 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.
- lewispollard 6y ago
  > 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. 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). https://github.com/Zylann/godot_voxel https://github.com/Zylann/godot_voxel

stolen_biscuit 6y ago

I've had a similar experience. Godot is a fantastic 2D engine, and a capable 3D engine. If your goal is shipping a fully featured 3D game I'd still recommend Unity or Unreal over Godot, unless you're comfortable with it not being an industry leader. For 2D however, I'd recommend Godot above anything. 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.

keyle 6y ago
To be fair, it's perfectly fine for 3D, such as traditional "isometric" style 3D. It suffers more with the lack of clever culling in first person style cameras, especially near large objects (it renders the whole object, even if 5% of it is seen).
- onion2k 6y ago
  it renders the whole object, even if 5% of it is seen Do other engines cull parts of objects?
  - bluefirebrand 6y ago
    Absolutely. Vertex culling is a long-standing 3D engine optimization.
  - kayamon 6y ago
    No.
- videogreg93 6y ago
  Godot 4.0 will include occlusion culling actually, so there's hope.
Buttons840 6y ago
And as mentioned in the article/release, they are serious about maintaining Godot 3 and won't neglect it in favor of 4.

kumarvvr 6y ago

> 3D open world / large landscape, and console development. Will it be a good choice for FPS shooters taking place primarily in closed spaces like buildings, etc?

jay_kyburz 6y ago
There is no built in occlusion system. So I would say no.
- TeMPOraL 6y ago
  Wait, so if it's not good at 3D outdoor scenes, and not good at 3D indoor scenes, then... what is it good at, in terms of 3D games? That would only leave 3D models + minimal scene (e.g. top-down/isometric games), which minimizes the amount of occlusion?
  - follower 6y ago
    With regard to 3D indoor scenes, performance is entirely related to the complexity of the scenes & how much effort is put into loading/unloading non-visible areas etc. For a couple of data points, here is the official Godot third person shooter demo: https://github.com/godotengine/tps-demo https://github.com/godotengine/tps-demo And you can also find "Platformer 3D" demo here (playable in browser too): https://godotengine.github.io/godot-demo-projects/ https://godotengine.github.io/godot-demo-projects/ The showcase also has some 3D games that have been produced: https://godotengine.org/showcase https://godotengine.org/showcase Also TailQuest in development 3D Platform/Puzzle: https://www.reddit.com/r/godot/comments/gnfjn9/tailquest_so_what_is_it_our_game_tower_defense/ https://www.reddit.com/r/godot/comments/gnfjn9/tailquest_so_... Various people have experimented with voxel worlds and other things which push the limits of the engine & are viewable on YT. In short, with 3.0, Godot isn't competing with, say, Unreal in the 3D realism stakes but it still has more 3D capability than most people who start to make a 3D game will actually hit when the scope of the work required becomes apparent. :)
  - jay_kyburz 6y ago
    Any game where camera frustum culling can easily cull the number of object rendered. So when the camera is pointing in a fixed direction and you have control what moves in front of it.

lattalayta 6y ago

What kind of game did you ship? Was it 2D or 3D? 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?

mekkkkkk 6y ago
In general I'd say Godot is excellent for the average indie game. It might not be the best choice for cutting edge AAA rendering or performance. In my experience the most important aspect of an engine for a solo/hobby developer is the ergonomics and the workflow. I've found Godot to be a breeze of fresh air in this respect compared to the much more clunky Unity or UE.
keyle 6y ago
With UE4 you have a very large engine to deal with. With Godot you'll spend more time making your game look AAA. 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.

aflag 6y ago

Which language did you use? GDScript?

keyle 6y ago
Yes GDScript. Very few gotchas, very easy to learn and maintain in my head. I believe I had to recompile the engine a few times for various things, which took a bit more, but the game can be shipped entirely with GDScript. 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.

tekni5 6y ago

I enjoyed the challenge of figuring out what game you made, by deciphering your profile. :)

follower 6y ago

> console development. 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/rust-gamedev/wg/issues/90 https://github.com/EmbarkStudios/rust-ecosystem/issues/18 https://github.com/EmbarkStudios/rust-ecosystem/issues/18 https://www.reddit.com/r/rust/comments/jtqgn4/q_feasibility_of_rust_on_consoles/ 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-platforms-are-supported-by-godot https://docs.godotengine.org/en/stable/about/faq.html#which-... [1] https://docs.godotengine.org/en/stable/tutorials/platform/consoles.html https://docs.godotengine.org/en/stable/tutorials/platform/co...

keyle 6y ago
I shipped a game exclusive to PS4 using UE4 about 4 years ago. 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.

clarge1120 6y ago

I can’t tell if the Godot team is serious about commercial viability. 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.

ShinTakuya 6y ago
Well you're welcome to hire some extra engineers on Godot's behalf. They can only go so fast with shoestring budget. If it doesn't meet your requirements, consider alternative engines such as Unreal. 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.
lewispollard 6y ago
> I can’t tell if the Godot team is serious about commercial viability. 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...)

M5x7wI3CmbEem10 6y ago

what about 2.5D? side scroller games that allow limited movement on the z-axis. think Paper Mario

jokethrowaway 6y ago

I would add tilemaps to the things that don't flow very well. Looking forward to better tilemap support in 4.0