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

21–30 of 122 posts

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

#21

Post by strictfp »

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…

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

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

#22

Post by fezfight »

M4v3R wrote: post #14
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.

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.

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

#23

Post by reactordev »

M4v3R wrote: post #14
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.

Except that we have releases of Adobe and Unity and things multiple times a year. Creatives value consistency but they also value ease of use. Improvements to UX and workflow should be allowed to break the mold of "don't touch it if it works". What they don't do is dictate the release cycle. Many patches end up in committee to be pooled together (or paywalled) into a vX.N.0 patch released when the business decides to.

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

#24

Post by jibe »

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)

A lot of games are fragile, and have poor or no test coverage. So if the engine changes, it can break or have all sorts of unforeseen consequences. So you want to be building in an engine that isn't changing.

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

#25

Post by jayd16 »

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)

Unity has bug fix releases every two weeks so no.

That said, I would say a lot of changes can be breaking because backwards compatibility is a much lower priority then code speed or size.

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

#26

Post by Cloudef »

opyate wrote: post #5
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 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

Probably not serious, just that it's the language used in unity

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

#28

Post by jibe »

reactordev wrote: post #23
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.

Except that we have releases of Adobe and Unity and things multiple times a year. Creatives value consistency but they also value ease of use. Improvements to UX and workflow should be allowed to break the mold of "don't touch it if it works". What they don't do is dictate the release cycle. Many patches end up in committee to be pooled together (or paywalled) into a vX.N.0 patch released when the business decides to…

Everyplace I've worked that's used Unity has locked into a version at the start, and only upgraded (other than minor versions/bug fixes) between projects. New projects today would use last years version.

Adobe is less an issue because the new version of Photoshop isn't going to break your PSD.

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

#29

Post by Kwpolska »

fezfight wrote: post #16
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

The telemetry isn’t in C#/.NET proper, it’s in the `dotnet` CLI utility.

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

#30

Post by colechristensen »

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)

Their users. Game engines are big and complex and the foundation of building a big and complex product. You can't have your foundation introducing fundamental changes on a regular, unpredictable basis.

Releasing big versions means your game can use version X.Y with only bugfixes to the engine added as updates and you don't have to make fundamental changes when the game engine changes.

Post reply on HN