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

Godot 4.6 Release: It's all about your flow

godotengine.org

Post reply on HN
Print view View original

101–110 of 135 posts

Re: Godot 4.6 Release: It's all about your flow

#101

Post by foxygen »

BoorishBears wrote: post #95
foxygen wrote: post #93

Earlier quoted context omitted.

> dynamic types become more of liability as a project gets larger Why?

> there's always types/schema somewhere: the choice is if they'll be explicitly defined at the place of construction, or implicitly spread out across all the places data happens to flow in your application. > And the more places there are, the more spread out they'll be.

You can still have schema validation at the borders of the application(data in/out) without static typing.

I think there are many other factors that come into play when it comes to maintaniblity of large projects. I'd easily choose to maintain a large Elixir or Common Lisp codebase over a Java one, assuming they were all using the Best Practices™ of their respective languages.

There is research out there, and there is absolutely zero evidence that static typing catches more bugs than dynamic types. My experience is that immutability, functional programming, simplicity and testing pays a MUCH bigger role in maintainability than static typing.

Dynamic typing has trade-offs, and so does static typing, HUGE trade-offs by the way. But for some reason, no one seems to mention them... ever.

Re: Godot 4.6 Release: It's all about your flow

#102

Post by TulliusCicero »

cardanome wrote: post #89
TulliusCicero wrote: post #82

Earlier quoted context omitted.

Still doesn't have full static typing support to my knowledge, which is a dealbreaker to me. The other things are that it just has less support for structuring your code in different ways, and of course the performance is vastly worse. My game does some state space exploration for the enemy AI, so having code that runs an order of magnitude slower just doesn't work for me.

It has support for typing Arrays and Dictionaries these days. Yes, nested Arrays are still a problem but I am sure they will get to it. As for performance well the GDExtension support has also gotten much better. You can always go down to C++, Rust, Nim, Zig or whatever. It is really easy to set up.

But then I have to code in those other languages, languages that require manual memory management that I'm not as familiar with. C# is many times faster than gdscript, and I don't have to think about memory hardly at all. And it's easy enough to code the whole game in it.

Re: Godot 4.6 Release: It's all about your flow

#103

Post by nycdotnet »

skrebbel wrote: post #80
lagniappe wrote: post #64

Earlier quoted context omitted.

That's awesome! What type of game is your son making now?

Clone of some popular game that I forgot the name of where you're a block and you move around a maze (tile-based, 2d) but you can't take small steps or slow down, you always slide quickly in one direction until you hit a wall. It's a puzzle game, you gotta make it to the exit without hitting the kill blocks. He wants to figure out how to make an in-game level editor for it but he still only 10% groks the node/scene s…

might be geometry dash.

Re: Godot 4.6 Release: It's all about your flow

#104

Post by helterskelter »

accrual wrote: post #76
helterskelter wrote: post #71

Earlier quoted context omitted.

From Archwiki: Godot runs on Wayland using Xwayland, which causes a variety of UI issues, when not running in single window mode. [1] To get around this, start Godot with godot --single-window, then open a project, and enable single window mode in the editor settings. This issue has been resolved in Godot 4.1.1. [2] This issue seems to have recurred in Godot 4.2 [3] With Godot 4.3, Wayland can be used natively. [4] T…

Cheers, that worked! 4.6 is working great on Wayland. I created a new .desktop shortcut pointed to Godot_v4.6-stable_linux.x86_64 with argument "--display-driver wayland". Working flawlessly, thank you.

Glad it worked! Archwiki is a fantastic resource.

Re: Godot 4.6 Release: It's all about your flow

#105

Post by sfn42 »

Eric_WVGG wrote: post #85
sfn42 wrote: post #62

Earlier quoted context omitted.

As a current C# web developer I think C# is amazing. I know multiple other languages (Java, JS, Python and others) fairly well and none of them measure up to modern C# in my opinion. Visual studio is trash though.

Garbage collection hiccups are probably meaningless on a web platform. As far as real-time processing goes, one of the most significant figures in the history of C# thinks it's a bad fit. If you disagree with him, respond to the video, I guess.

Yeah sure there are some issues with game development and garbage collection. It's fine for a lot of other stuff though. He says that too, still uses C#.

I also think there's probably a lot of skill issue involved as well. I've seen the code written by the average developer, it isn't pretty. Very few developers actually write half-decent code. The vast majority write code that I'd just delete and rewrite rather than work with. Slow, buggy, messy, sloppy.

And then they write a game and there's a bunch of problems because their code is ass and there's an angle where they can blame someone other than themselves so they do. And so the authors of Mono and Unity etc are held responsible, why can't they just fix their thing so that the bad developers can write bad code and still have a functioning game? And sure, if Swift can offer that then it seems Swift is the better choice for this application.

But there's plenty of good games made with C# so clearly it's also possible to do so.

Re: Godot 4.6 Release: It's all about your flow

#106

Post by eudamoniac »

cardanome wrote: post #89
TulliusCicero wrote: post #82

Earlier quoted context omitted.

Still doesn't have full static typing support to my knowledge, which is a dealbreaker to me. The other things are that it just has less support for structuring your code in different ways, and of course the performance is vastly worse. My game does some state space exploration for the enemy AI, so having code that runs an order of magnitude slower just doesn't work for me.

It has support for typing Arrays and Dictionaries these days. Yes, nested Arrays are still a problem but I am sure they will get to it. As for performance well the GDExtension support has also gotten much better. You can always go down to C++, Rust, Nim, Zig or whatever. It is really easy to set up.

This line of reasoning is silly, because no one in their right mind would choose to use gdscript for any program that was not in Godot. You can't even type a nested array, among many other issues. That is because gdscript is a bad language objectively. It being part of Godot doesn't change that. Why would I choose to write my game, the thing that is very hard and will take years, in an objectively bad language? I would not choose that, because that doesn't make any sense to do. Writing code is like 90% of the work if I hire artists. I am not going to do 90% of years of work in a shitty language, because I don't have to do that, being a skilled developer in real languages.

So when people come out and defend gdscript for being not that bad, it's like, okay, but it's still really shitty compared to any normal language like C# or even Python. It is made by a game engine, used by thousands of people, instead of being made by gorillions of dollars poured into it by tech companies and used by millions of people. I'm just going to use good languages instead.

Re: Godot 4.6 Release: It's all about your flow

#107

Post by krapp »

pwdisswordfishs wrote: post #70
_rousbound wrote: post #34

Earlier quoted context omitted.

I wonder the same thing, but with an emphasis on app mobile development. Godot from project setup to running on my Android is way more effortless/lightweight experience than doing the way of AndroidStudio and/or Flutter stuff. What I dream of is making a Lua binding for essential godot GUI control nodes using GDExtension and using this LibGodot to own the engine loop, so I can do all the app code in Lua. So, I may ha…

The future of cross-platform toolkits for graphical apps is Godot ("GDTK"?), instead of Electron?

A fork of Godot optimized for native apps would be a good idea. Especially if it learned the lessons of the web stack and used basic text-based formats for describing layout and theming (like HTML and CSS). Maybe something like QT. Something simple, flexible and portable that's as easy to use as Electron but doesn't require lugging around a 60mb Chromium instance for every application.

Some work would need to be done improving text rendering, layout and to add more GUI elements. Probably a lot of stuff removed from the backend that isn't necessary (apps won't need physics or lighting, probably.)

I made a basic theme loader for a project ages ago based on the config file format because dealing with theming and fonts was a pain at the time. Nothing novel, it was just a dictionary that had node paths as keys and set values. It is possible, I don't know why Godot makes some things more complicated than they need to be.

Re: Godot 4.6 Release: It's all about your flow

#108

Post by BoorishBears »

foxygen wrote: post #101
BoorishBears wrote: post #95

Earlier quoted context omitted.

> there's always types/schema somewhere: the choice is if they'll be explicitly defined at the place of construction, or implicitly spread out across all the places data happens to flow in your application. > And the more places there are, the more spread out they'll be.

You can still have schema validation at the borders of the application(data in/out) without static typing. I think there are many other factors that come into play when it comes to maintaniblity of large projects. I'd easily choose to maintain a large Elixir or Common Lisp codebase over a Java one, assuming they were all using the Best Practices™ of their respective languages. There is research out there, and there i…

Silly me for falling for the bait after two one-word replies in a row.

If I need to specify this is about data flow inside your application when we're talking about typing, I don't want think we're having the same conversation.

Hopefully someone else will want to mud wrestle on this.

Re: Godot 4.6 Release: It's all about your flow

#109

Post by cardanome »

TulliusCicero wrote: post #102
cardanome wrote: post #89

Earlier quoted context omitted.

It has support for typing Arrays and Dictionaries these days. Yes, nested Arrays are still a problem but I am sure they will get to it. As for performance well the GDExtension support has also gotten much better. You can always go down to C++, Rust, Nim, Zig or whatever. It is really easy to set up.

But then I have to code in those other languages, languages that require manual memory management that I'm not as familiar with. C# is many times faster than gdscript, and I don't have to think about memory hardly at all. And it's easy enough to code the whole game in it.

You can use C#. It is well supported except for the (currently) missing web target and Microsoft is funding C# support so it will not get abandoned.

You can also use other garbage collected languages. I once tried the Lua bindings and they worked fine.

The problem with C# is that its garbadge collection is not really suited for game dev. The creator of the Mono runtime actually calls using C# his Multi-million dollar mistake and instead works on swift bindings for Godot: https://www.youtube.com/watch?v=tzt36EGKEZo

But if you really love C# nothing is stopping you. I prefer GDScript.

Re: Godot 4.6 Release: It's all about your flow

#110

Post by krapp »

skrebbel wrote: post #81
lynndotpy wrote: post #41

Earlier quoted context omitted.

I would bet SDL; it's a C library that a ton of other libraries are influenced by or based on. It's not usually thought of as an engine on its own nowadays

Nah, like you said, SDL is just window creation and a bit of audio etc. If that counts as a "game engine" then so does every web browser. EDIT: Sorry if I seem grumpy, I'm not actually grumpy at you, I'm grumpy at PyGame for calling itself a game engine when really it's just SDL + the ability to blend images.

> SDL is just window creation and a bit of audio etc.

It's a bit more than that, especially the current version. You're right that it isn't an engine in and of itself but you could probably build a decent engine on top of it. SDL3 + WASM + Lua would be chef's kiss.

Post reply on HN