Live data from Hacker News

Godot 3.3

godotengine.org

41–50 of 138 posts

Re: Godot 3.3

#41
post #13

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…

> 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?

Re: Godot 3.3

#42
post #37

Earlier quoted context omitted.

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?

Architecturally it's perfectly fine, designing the 3D world is just as capable as the 2D world in terms of tooling. It's more a performance concern. The biggest pain is the lack of proper face culling. It does object culling, meaning if you don't see it at all, it's culled. However faces, not quite. So if you're in space, and you're flying nearby a big ship full of triangles, such as an imperial star destroyer, you r…

AFAIK neither Unreal nor Unity will frustum cull the triangles of a model out of the box and although both offer some other forms of occlusion culling they also only operate at the whole model level.

Re: Godot 3.3

#43
post #13

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…

> 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?

There is no built in occlusion system. So I would say no.

Re: Godot 3.3

#44
post #21

Earlier quoted context omitted.

Can you give some examples?

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)).

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?

Re: Godot 3.3

#45
post #13

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…

> 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?

[deleted]

Re: Godot 3.3

#46
post #13

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…

> 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?

Yes if all your walls are individual meshes and you use large slabs for the ground (not the entire map being a floor).

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)

Re: Godot 3.3

#47

Earlier quoted context omitted.

> 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?

There is no built in occlusion system. So I would say no.

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?

Re: Godot 3.3

#48
post #13

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…

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?

Re: Godot 3.3

#49

Earlier quoted context omitted.

> 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?

There is no built in occlusion system. So I would say no.

Occlusion culling is one of the big features of 4.0.

Re: Godot 3.3

#50

Godot is a really good engine but there's one thing which I cannot get to work properly: UI font rendering. The interface font is blurry across platforms. I hope they introduce a fix for it.

I seem to recall there being some hiDPI setting in the project options that fixed the blurry fonts for me (on Windows). I think the problem is just that on hiDPI screens everything, including text, is still rendered with whatever size the programmer picked and the result is just naively scaled according to the OS settings (which works ok-ish for non-text graphics). The hiDPI setting removes the automatic scaling, so developers have to account for hiDPI screens themselves (not making everything too tiny).
Post reply on HN