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

31–40 of 122 posts

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

#31

Post by stu2b50 »

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…

I find it hard to imagine whatever glue language you choose for an engine like Godot would really matter that much. All you’re implementing is the business logic. Even the slowest language can run through basic business logic in the blink of an eye relative to the heavy duty that the Godot systems are doing.

Eve Online runs on *python*, for instance. So does Blender. For a glue language, I am highly doubtful that the .net is that much faster than v8 or any other runtime to make a difference.

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

#32

Post by tpxl »

b33j0r wrote: post #19
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 call…

How do you remove objects if you don't queue free them? Just remove them from the tree?

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

#33

Post by b33j0r »

strictfp wrote: post #21
b33j0r wrote: post #19

Earlier quoted context omitted.

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 call…

Thanks. Do you setup an artificial tree during testing? If so, how?

I’m not sure your mental model matches mine, but in my “real job” I deal with the shadow and virtual DOM. Maybe that’s the metaphor you’re looking for?

I’ll have to be a little practical and hope it makes sense. The tree in the editor is the same tree. Godot engine is written in Godot engine, so what is the distinction between being in the editor and being in the game?

The answer is that godot will ignore all project scripts by default while you are in the editor, but it offers mechanisms to enable them. The main way is a keyword in GDScript.

In Godot 3, you put `tool` as the first line of a script, and it will be loaded. Godot 4 has grown a pre-processy decorator syntax, so it’s the same, but `@tool`.

In your scripts, you can detect whether you are in the editor by checking `Engine.editor_hint`. You can do amazing things with this.

Then you can take it a step further, and convert your tool scripts into an addon. With an addon, which is just a directory structure for assets, your custom in-editor functionality becomes indistinguishable from native godot behavior.

https://docs.godotengine.org/en/stable/tutorials/plugins/run...

PS: I created a virtual node tree a few times to wrap UI components. Much like react. But honestly, I usually find a more idiomatic pattern later.

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

#34

Post by katamaritaco »

nemothekid wrote: post #3
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#.

> but to write a serious game you really want C# I haven't followed game development in a long time, but has the industry moved to C#? I thought C# was limited to Unity and everyone else was still using C++?

You're correct, the industry has not moved to C#. Not even close.

The biggest player that uses it is Unity, but even they have their own special fork of Mono to get it to play nice.

Full Disclosure: I work for a Microsoft/Xbox Studio.

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

#35

Post by omoikane »

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…

Probably not the most efficient way to do it, but I setup test scenes for just the functionalities I wanted to test and run those manually.

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

#36

Post by b33j0r »

tpxl wrote: post #32
b33j0r wrote: post #19

Earlier quoted context omitted.

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 call…

How do you remove objects if you don't queue free them? Just remove them from the tree?

Yes, or they are free’d automatically as the parent is free’d recursively. If you have called `add_child` on a node you created dynamically, godot will handle its lifecycle from there.

If you don’t add a dynamically-created node to the tree, you are responsible for `free`.

That almost never comes up, because I eventually figure out how to decompose everything into a tree Node, or! A Resource.

Resources are managed in a separate memory pool, and don’t need to be added to the tree for godot to take care of it. Go ahead, you just try and `free` a resource! ;)

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

#37

Post by wongarsu »

fezfight wrote: post #22
M4v3R wrote: post #14

Earlier quoted context omitted.

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.

This especially true since this is a FOSS tool so there's no need to ship product bumps to sell units or anything like that. They can just release stuff when its ready.

Major version bumps with major features are still a great marketing tool; like this article making it to the HN frontpage. That attracts users and developers, both desirable for FOSS.

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

#38

Post by tpxl »

b33j0r wrote: post #36
tpxl wrote: post #32

Earlier quoted context omitted.

How do you remove objects if you don't queue free them? Just remove them from the tree?

Yes, or they are free’d automatically as the parent is free’d recursively. If you have called `add_child` on a node you created dynamically, godot will handle its lifecycle from there. If you don’t add a dynamically-created node to the tree, you are responsible for `free`. That almost never comes up, because I eventually figure out how to decompose everything into a tree Node, or! A Resource. Resources are managed in…

Damn, I didn't know that. Time to remove queue_free from my project :)

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

#39

Post by [deleted] »

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

[deleted]
Post reply on HN