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

61–70 of 122 posts

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

#61

Post by unsafecast »

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

gdscript is dynamically typed. If you have the large arrays of structs common in gamedev, then all data members are boxed, significantly increasing memory usage compared to something like C#.

C# objects are boxed too.

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

#62

Post by Mikeb85 »

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

This is ridiculous. You absolutely can write a full game with GDScript or GDScript and C++. Keep in mind Godot has first class support for C++.

In fact, I'd argue C++ is far better than a bolted on C#...

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

#63

Post by detuur »

deworms wrote: post #60

Godot is effectively not accepting contributions, and masquerades as open source. List comprehension, one of the most sought-after features and requested by dozens of people, is repeatedly undermined by maintainers, because they happen to dislike the syntax. Godot offers nothing similar in terms of processing arrays, so it makes any code involving them ugly and more complex than it needs to be. There was even a pull…

I find it a bit untrustworthy when someone frames a language design issue as representative of the way the project is run. List comprehension is a feature that comparatively few languages have, and I can easily imagine that the GDScript team has other things they consider a priority.

For a programming language, 5 years is not at all an unusual delay when we're talking about an extension to the basic syntax.

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

#64

Post by rng_civ »

deworms wrote: post #60

Godot is effectively not accepting contributions, and masquerades as open source. List comprehension, one of the most sought-after features and requested by dozens of people, is repeatedly undermined by maintainers, because they happen to dislike the syntax. Godot offers nothing similar in terms of processing arrays, so it makes any code involving them ugly and more complex than it needs to be. There was even a pull…

Open source != open contribution.

Don't like how they run it? Fork it. The maintainers have ZERO obligation to merge your PRs, especially when they don't actually agree with it.

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

#65

Post by seba_dos1 »

deworms wrote: post #60

Godot is effectively not accepting contributions, and masquerades as open source. List comprehension, one of the most sought-after features and requested by dozens of people, is repeatedly undermined by maintainers, because they happen to dislike the syntax. Godot offers nothing similar in terms of processing arrays, so it makes any code involving them ugly and more complex than it needs to be. There was even a pull…

> That's no way to run an open source project.

The way contributions are accepted (or not) is completely unrelated to the project being open source or not. It's always up to the maintainer to decide whether a feature should be merged or not. Open source projects are not popularity contests.

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

#66

Post by TheAceOfHearts »

Mikeb85 wrote: post #62
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#. This is ridiculous. You absolutely can write a full game with GDScript or GDScript and C++. Keep in mind Godot has first class support for C++. In fact, I'd argue C++ is far better than a bolted on C#...

I don't have experience with GDScript, so please forgive the ignorant question.

Does GDScript have good debugging, linting, and profiling tools?

I'm not a game developer, but I'd love to hear your perspective on some of the criticisms I've encountered on the topic of scripting languages for game development.

One of the main criticisms I've heard of using scripting languages for game development is that they tend to be lacking when it comes to tooling.

The second form of criticism I've heard is that type issues become a serious problem as the size of game code growns past a certain point.

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

#67

Post by jayd16 »

Mavvie wrote: post #50
jayd16 wrote: post #8

Earlier quoted context omitted.

Well you could always go with C++ but C# has a solid balance of high level features, good libraries, good tooling, a feature full (if not slick) threading mode, performance features when you need them and good interoperability with native code. Its not always fun or sexy to rewrite a reference type to a value type to get around your GC but you _can_ do that in C#. Its a have your cake and eat it sort of language.

Can you elaborate on that? Do you mean rewriting existing classes as structs so they go on the stack?

Yes, just an example of one of the many performance minded complications that C# brings to the table. You can even use raw pointers if you want to.

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

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

#68

Post by Mikeb85 »

TheAceOfHearts wrote: post #66
Mikeb85 wrote: post #62

Earlier quoted context omitted.

> but to write a serious game you really want C#. This is ridiculous. You absolutely can write a full game with GDScript or GDScript and C++. Keep in mind Godot has first class support for C++. In fact, I'd argue C++ is far better than a bolted on C#...

I don't have experience with GDScript, so please forgive the ignorant question. Does GDScript have good debugging, linting, and profiling tools? I'm not a game developer, but I'd love to hear your perspective on some of the criticisms I've encountered on the topic of scripting languages for game development. One of the main criticisms I've heard of using scripting languages for game development is that they tend to b…

I mean, GDScript doesn't exist outside of the Godot engine. Debugging for it is the same as debugging a Godot game. All GDScript functions are C++ methods. Also, there are type hints if you want.

If you're going to be doing a very large, ambitious game, odds are you'll also be creating your own C++ methods and thus debugging using C++ tools and the game engine tools...

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

#69

Post by mrtksn »

devmunchies wrote: post #41

Is there a reason you wouldn't use a game engine to create general purpose cross-platform apps? Is it cumbersome to create textual, structural interfaces (e.g. a twitter clone, google sheets clone, or an ecomm checkout flow)?

Flutter is essentially just that. Its graphics are built on Skia Graphics Engine and the tooling is designed to cater for UI interaction needs instead of gaming needs.

Apple's own UI libraries use their graphics engines too(SpriteKit, SceneKit), unfortunately supported only on Apple platforms.

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

#70

Post by cardanome »

TheAceOfHearts wrote: post #66
Mikeb85 wrote: post #62

Earlier quoted context omitted.

> but to write a serious game you really want C#. This is ridiculous. You absolutely can write a full game with GDScript or GDScript and C++. Keep in mind Godot has first class support for C++. In fact, I'd argue C++ is far better than a bolted on C#...

I don't have experience with GDScript, so please forgive the ignorant question. Does GDScript have good debugging, linting, and profiling tools? I'm not a game developer, but I'd love to hear your perspective on some of the criticisms I've encountered on the topic of scripting languages for game development. One of the main criticisms I've heard of using scripting languages for game development is that they tend to b…

> Does GDScript have good debugging, linting, and profiling tools?

Yes, everything is provided for. No need for separate tools, Godot comes with everything out of the box. (Of course "good" needs to be defined but I personally had no problems.)

> The second form of criticism I've heard is that type issues become a serious problem as the size of game code growns past a certain point.

GDScript has gradual typing support. You get at least TS-level of type safety if you want (but without the headache of TS.)

Also C# is not traditionally a game development language. It has automatic garbage management for which game development happens to be on of the few areas where that is not exactly ideal.

C# is mostly interesting for people already knowing C# or when there are specific performance needs where C# still outperforms GDScript (though personally I would rather write the performance sensitive parts in C++ or Rust).

Most people are highly advised to at least try GDScript. (Also it is very easy to mix and match languages. You can have parts in C#, parts in GDScript, parts in C++, no need to commit early to a specific language.)

Post reply on HN