Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Godot 4.0 development enters feature freeze ahead of the first beta

godotengine.org

Post reply on HN
Print view View original

11–20 of 122 posts

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#11

Post by sfteus »

_aavaa_ wrote: post #4
TillE wrote: post #2

It's not clear to me whether .NET 6 (and therefore C# support) is going to make 4.0 freeze. It's really just been one guy working on the dotnet6 branch, which is unfortunate. I'm really excited for many features of Godot 4, and GDScript is perfectly adequate for UI glue code and stuff, but to write a serious game you really want C#.

The Wiki page says it already supports C#. As completely on the outside, what is missing?

Godot ~3.2+ has support for a slightly older version of C# via Mono, I think it's the equivalent of .NET 4.8.

IIRC (and this could be wrong / have changed since I last looked into it) the idea was to re-work this in Godot 4 to provide more like bindings, so that users could opt to use Mono, .NET 6, CoreCLR, NativeAOT, or whatever version they preferred.

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#12

Post by strictfp »

How do you people feel about the Godot object and lifetime model? I found it hard to test my code because of how objects are tied to the tree, that emulating the tree isn't easy during testing, and that initialization during live use is different than if you instantiate manually, making it hard to rely on a constructor, since you might not be able to use it live.

I can't remember the exact details around this, since I only used Godot for a couple of jams and the last time was a year ago. But I was wondering if others have had the same reaction, perhaps this could be fixed? I love the engine in general, but this thing irked me.

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#14

Post by M4v3R »

mkw5053 wrote: post #13

Is there something inherent with game engines that prohibits small, frequent software delivery? (call it agile or lean, if you want)

They do small, frequent software updates, it's called minor and patch versions. But when you're making a tool for creative professionals you don't want to release major versions of the tool every year, because these professionals care more for consistency and using their current skillset more than shiny new features in the next version.

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#15

Post by tmp_anon_22 »

Waterluvian wrote: post #6
opyate wrote: post #5

Earlier quoted context omitted.

> but to write a serious game you really want C#. I asked someone on Twitter about this the other day [0], and I'm genuinely curious: what is it about C# that makes game development serious? 0. https://twitter.com/LegatXyotic/status/1552219744723402756

I won’t use the word “serious” but my limited personal experience is that C# feels like the right balance between flexibility and performance. Rust is a joy to write in but I personally find that it asks a lot from you when you just want to ship a game that doesn’t need to be safety rated. C++ is a great choice but it’s C++ and I’m just not good enough to enjoy a language with fewer guardrails. It also has similar ve…

> isn’t fast enough for anything major.

I think it could be fast enough if portability to different platforms wasn't such a high priority for game studios these days. Nobody wants to write typescript and then pay $50M for someone to port it for Switch or whatever.

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#16

Post by fezfight »

TillE wrote: post #2

It's not clear to me whether .NET 6 (and therefore C# support) is going to make 4.0 freeze. It's really just been one guy working on the dotnet6 branch, which is unfortunate. I'm really excited for many features of Godot 4, and GDScript is perfectly adequate for UI glue code and stuff, but to write a serious game you really want C#.

Does Godot's implenetation of C#/.net include the .net temeletry?

https://github.com/dotnet/sdk/issues/14556

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#17

Post by blamestross »

strictfp wrote: post #12

How do you people feel about the Godot object and lifetime model? I found it hard to test my code because of how objects are tied to the tree, that emulating the tree isn't easy during testing, and that initialization during live use is different than if you instantiate manually, making it hard to rely on a constructor, since you might not be able to use it live. I can't remember the exact details around this, since…

/sarcasm/ Why would game devs write tests?

On a more serious note, I do expect test-ability isn't a high customer priority for Godot. Godot is self-hosted, maybe check how they run their tests?

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#18

Post by somehnacct3757 »

TillE wrote: post #2

It's not clear to me whether .NET 6 (and therefore C# support) is going to make 4.0 freeze. It's really just been one guy working on the dotnet6 branch, which is unfortunate. I'm really excited for many features of Godot 4, and GDScript is perfectly adequate for UI glue code and stuff, but to write a serious game you really want C#.

Former professional game dev getting into Godot recently for fun and maybe for hire.

What are the limitations of gdscript you allude to? Let's say I want to render an infinite scrolling hex grid. Why would c# excel or gdscript struggle?

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#19

Post by b33j0r »

strictfp wrote: post #12

How do you people feel about the Godot object and lifetime model? I found it hard to test my code because of how objects are tied to the tree, that emulating the tree isn't easy during testing, and that initialization during live use is different than if you instantiate manually, making it hard to rely on a constructor, since you might not be able to use it live. I can't remember the exact details around this, since…

It’s something that’s pretty nice once you’ve implemented these lifecycles a bunch.

The tree turns out to be a great place to keep things, and you get several levels of control. Here’s how I think about it now.

`_init`: constructor. I usually use this to create dynamic child nodes

`_enter_tree`: now we have a parent; subscribe to signals, copy initial config, etc

`_ready`: I can be sure that all child nodes have called _ready, so anything I depend on there is… er, ready

`_exit_tree`: cleanup, especially anything we did with the parent and other ancestors. usually symmetric to `_enter_tree` if I’m using them

I just did a find all in my biggest recent project, and I never actually use `queue_free` or `free` for explicit memory management. Most of the times when I’ve thought I needed to, I actually was creating a bug

Re: Godot 4.0 development enters feature freeze ahead of the first beta

#20

Post by drmidnight »

TillE wrote: post #2

It's not clear to me whether .NET 6 (and therefore C# support) is going to make 4.0 freeze. It's really just been one guy working on the dotnet6 branch, which is unfortunate. I'm really excited for many features of Godot 4, and GDScript is perfectly adequate for UI glue code and stuff, but to write a serious game you really want C#.

GDScript 2.0 has had some major performance improvements. While C# will still be faster, I find GDScript in Godot 4 to be viable now for things it wasn't in Godot 3.

I still rely on GDNative for really performance critical systems though.

Post reply on HN