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

81–90 of 122 posts

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

#81

Post by deworms »

Mikeb85 wrote: post #74
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…

Why would you want list comprehensions in a game engine? It's just sugar to make looping over a list or array look more functional but not particularly useful in a game.

What's so special about games that makes it not useful? Python has it and it's bread and butter, and Godot language is basically a gimped, less expressive, and less useful knockoff of python

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

#82

Post by lewispollard »

benjaminjackman wrote: post #48
b33j0r wrote: post #36

Earlier quoted context omitted.

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…

In the docs for Node.remove_child(Node node)[1] it says "Removes a child node. The node is NOT deleted and must be deleted manually." Do you still have to queue_free the top node that was removed from the tree, or else how is it being deleted. Or is there a different method to call for removing it from the tree. BTW: I really like the `_init` / `_enter_tree` / `_ready` / `_exit_tree` lifecycle as was described. 1: ht…

queue_free removes the node from the tree and frees it.

remove_child just deactivates it, but keeps it around in memory for later.

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

#83

Post by cardanome »

meibo wrote: post #79
cardanome wrote: post #70

Earlier quoted context omitted.

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

> 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. Are you forgetting about the now decades worth of games made with Unity? C# works perfectly fine for games, GC behavior can be optimized, it can be transpiled to native code, it has a huge ecosystem and is very easy to pick up. .N…

Did I say, you can't make games in C#? Why do you feel the need to defend C#? You are arguing against a straw man.

It is simply a fact that a large part of the professional gaming industry uses C++. That one might be better off using a language without automatic garbage collection for performance critical parts in many cases is pretty standard wisdom. Not sure what there is to argue about.

> It's certainly easier for devs coming from C++ or Java than "weird python-like scripting language that we had to invent and are now stuck with".

So you have never used GDScript but feel qualified to have a strong opinion on that matter, why is that?

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

#84

Post by Mikeb85 »

deworms wrote: post #81
Mikeb85 wrote: post #74

Earlier quoted context omitted.

Why would you want list comprehensions in a game engine? It's just sugar to make looping over a list or array look more functional but not particularly useful in a game.

What's so special about games that makes it not useful? Python has it and it's bread and butter, and Godot language is basically a gimped, less expressive, and less useful knockoff of python

> gimped, less expressive

That's the point. Lots of what Python does isn't required in a game engine and is slow.

It's basically visual scripting but quicker to produce, the whole thing is C++ underneath.

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

#85

Post by jamesgeck0 »

ClawsOnPaws wrote: post #59
modeless wrote: post #42

Earlier quoted context omitted.

You certainly could. You would probably run into a lot of issues in areas that games don't care about that much like multiple windows, smooth window resizing, fancy text layout and input, fast initial load times, matching OS themes and widget behavior, low resource usage at idle, copy/paste/drag/drop, software rendering, etc.

Add accessibility to that list. Screen readers, magnifiers, switch controls, etc. Usually game engines don't support these while your native OS UI probably does, and the web is also not bad in that regard.

IIRC there is actually an ongoing Godot accessibility effort.

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

#86

Post by r_hoods_ghost »

somehnacct3757 wrote: post #57
jmcgough wrote: post #47

Friends in the industry all say it's a nonstarter that it does not (and will not) have cross platform support, as much as they hate Unity. Godot's official stance on it is that you should hire a team to port it for you lol...

If you're long on the games industry we are probably in the last generation of game console architecture. Everything is going to be Windows or Linux boxes with PC hardware next gen. I could see Nintendo bucking this trend but they have enough IP to be their own island. It might be smart for Godot to punt; it lets them go faster than Unity and catch up

I've been hearing that since the first Xbox came out (which used an x86 architecture before the Xbox 360 moved to powerpc) and it still hasn't happened.

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

#87

Post by cardanome »

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…

GDScript went through a major rewrite for Godot 4, so they avoided adding lots of new features in the meantime and focused on getting it stable.

The rewrite should make it easier to add new features now.

Also the design of Godot values ease of use and simplicity to an great degree. They are very conservative about adding new features and I think they have a point there.

Also list comprehension is an odd example, I wouldn't really rank it that highly when it comes to features I miss. More annoying for me is not having traits or interfacse. You are expected to go full in with "everything is a node" and are a bit limited when it comes to more advanced abstractions. I understand why they are reluctant adding them though and I respect their commitment to keeping things simple.

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

#88

Post by meibo »

cardanome wrote: post #83
meibo wrote: post #79

Earlier quoted context omitted.

> 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. Are you forgetting about the now decades worth of games made with Unity? C# works perfectly fine for games, GC behavior can be optimized, it can be transpiled to native code, it has a huge ecosystem and is very easy to pick up. .N…

Did I say, you can't make games in C#? Why do you feel the need to defend C#? You are arguing against a straw man. It is simply a fact that a large part of the professional gaming industry uses C++. That one might be better off using a language without automatic garbage collection for performance critical parts in many cases is pretty standard wisdom. Not sure what there is to argue about. > It's certainly easier for…

> So you have never used GDScript but feel qualified to have a strong opinion on that matter, why is that?

I have, which makes me feel confident in stating that it's a language that didn't have to exist, doesn't have a healthy ecosystem backing it, which pulls focus from the actual good (or to be good) bits of Godot, which there are a lot of, and in the end makes people doubt that the language they would actually be productive in is a first class citizen for the engine vendors.

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

#89

Post by throwaway675309 »

cardanome wrote: post #70
TheAceOfHearts wrote: post #66

Earlier quoted context omitted.

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

Between XNA, monogame, Unity, etc. there a metric f###-ton of games written using the C# language.

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

#90

Post by jbluepolarbear »

katamaritaco wrote: post #34
nemothekid wrote: post #3

Earlier quoted context omitted.

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

Unity uses their own AOT compiler IL2CPP that translates C# code to C++. Mono is an option in builds, but most projects are using IL2CPP nowadays and have been moving to .Net core. Although C++ is king, C# has quickly caught up to be a close 2nd. Unity is used to make 50% of all mobile, pc, and consoles games (according to Unity https://unity.com/our-company).
Post reply on HN