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

71–80 of 122 posts

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

#71

Post by cardanome »

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

Godot has excellent cross platform support, just not for consoles that requires NDA's and stuff to develop for. This can't be helped on the Godot side but is the fault of the console manufactures who make the rules.

Also paying a third party to port a game to a different platform is not really that uncommon, even in the Unity world. I remember the Dev of The First Tree did exactly this.

It is not like you can just put your game in the PlayStation-store even if you use Unity or Unreal. There is a process to it and your game has to fulfill certain standards.

A good strategy is to first publish for PC and see if the game gains any traction. If it does, well the console port will pay for itself. If not, you saved yourself lot's of work.

See also: https://godotengine.org/article/godot-consoles-all-you-need-...

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

#72

Post by churnedgodotdev »

After quickly falling in love with Godot and several months of serious use I'm having to give up on it due to Godot's lack of funding to fix its more than 6000 open issues on Github:

  https://github.com/godotengine/godot/issues
Every single time a Godot bug bites me I find that a bunch of other devs reported the issue more than a year ago but no one has had time/money to fix the issue. For example, I was just bitten by #45628 opened Feb 1, 2021:

  https://github.com/godotengine/godot/issues/45628
When implementing controller support for a top-down Zelda-like game, it's normal to allow either the d-pad or left analog stick to control direction. But if you enable both at the same time in Godot then d-pad inputs cause your character to "freeze".

Eventually Godot will stabilize and be to game engines what Blender currently is to 3D modelers. If I had time to learn the Godot C++ code I would volunteer to help but I want to actually make video games instead of working on an engine.

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

#73

Post by Mikeb85 »

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, it's called the master GitHub branch. But generally if you're shipping something that doesn't get updated as often (you don't want to update via Google Play or Steam as often as a website would) you'd like a little stability...

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

#74

Post by Mikeb85 »

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.

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

#75

Post by drmidnight »

benjaminjackman wrote: post #44
drmidnight wrote: post #20

Earlier quoted context omitted.

GDScript 2.0 has had some major performance improvements. While C# will still be faster, I find GDScript in Godot 4 to be viable now for things it wasn't in Godot 3. I still rely on GDNative for really performance critical systems though.

Sounds like Godot 4 is replacing GDNative with GDExtension. Just wondering if you have tried it out and have any thoughts. Is it a smoother experience / about the same etc.

I have only briefly looked at it. All in all it looks very similar to GDNative, albeit a little cleaner. It will be nice to finally be able to expand functionality without recompiling the engine.

Right now I rely on nim bindings for GDNative so it might be awhile before I make the change over, unless I decide to port my code to C++ or update the bindings myself.

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

#76

Post by marcosdumay »

somehnacct3757 wrote: post #18
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#.

Former professional game dev getting into Godot recently for fun and maybe for hire. What are the limitations of gdscript you allude to? Let's say I want to render an infinite scrolling hex grid. Why would c# excel or gdscript struggle?

GDscript is a bit slow. It's not an issue if you use it to keep track of a reasonable amount of in-game data and control the objects to render. But it becomes an issue if you decide to write game intelligence in it, or keep track of a lot of things.

It also doesn't have an all integrated top of the market IDE, only the Godot IDE. (Although I don't think you gain anything from using a 3rd party IDE in a Godot game. Even less something like Visual Studio.)

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

#77

Post by cardanome »

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

Well, the Godot editor is actually a Godot applications, they are dog-fooding their own UI.

So it is absolutely possible to create complex applications with it.

Games engines are generally not used for apps, as games are optimized differently to apps. Games need to run smoothly at a high refresh rates at all times while apps can not hog all CPU power but need also be optimized to not needlessly drain the battery. This is no an issue in Godot specifically because it offers a low processor usage mode though.

So yes, Godot is a decent solution for apps. Only real issue is support for accessibility. There are screen reader plugins but if you want to do it properly, you might be better of with an app using native elements.

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

#78

Post by TillE »

churnedgodotdev wrote: post #72

After quickly falling in love with Godot and several months of serious use I'm having to give up on it due to Godot's lack of funding to fix its more than 6000 open issues on Github: https://github.com/godotengine/godot/issues Every single time a Godot bug bites me I find that a bunch of other devs reported the issue more than a year ago but no one has had time/money to fix the issue. For example, I was just bitten b…

I found and fixed a small Godot bug, starting from zero knowledge of the engine code, in about a day and a half free time. It's really not hard to just patch stuff yourself if you're comfortable with C++.

Godot is not beautiful modern code or anything, but it's definitely not inscrutable layers of spaghetti which require deep expertise. It's very readable and compiles reasonably fast.

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

#79

Post by meibo »

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…

> 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. .NET 6 or 7 are faster than ever, while Unity is stuck on an old version of Mono, too.

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

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

#80

Post by Mikeb85 »

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…

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

??? You can do everything in Godot in C++...

And GDScript isn't exactly a 'weird' language, it's downright ordinary in terms of semantics and features. The feature is that it's part of the engine and maps directly to C++ methods in the game engine...

Post reply on HN