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

Godot 3.5

godotengine.org

Post reply on HN
Print view View original

101–110 of 121 posts

Re: Godot 3.5

#101

Post by [deleted] »

coppolaemilio wrote: post #99
cptcobalt wrote: post #28

I've been part of shipping one of perhaps the largest used Godot projects in production. It's not a game, and you may not even realize it's Godot. Godot is below average in quality compared to Unreal, and probably about on par with various idiosyncrasies that Unity has. Unreal is winning the technical race because they ship projects and games themselves with their engine. Unity does none of that, at least nothing tha…

Hey, I'm curious to know what are some of those "weird opinions at a maintainer level". I would love to know more about your experience using it at such scale.

[deleted]

Re: Godot 3.5

#102

Post by chii »

sdkgames wrote: post #72

TLDR: The problem with Godot is that it tries to be everything to everyone. They made an engine, an editor (a text editor, resource editor, debugger ...), invented a new language. They "support" export to almost all popular OS platforms. But in my opinion it's lacking in quality. The engine is slow (old style based on OOP), the editor is buggy, the language (GDScript) doesn't have the features of a modern scripting l…

> The engine is slow

doesn't really seem that slow for me (but of course, i haven't used it in anger yet).

> the editor is buggy, the language (GDScript) doesn't have the features of a modern scripting language.

the editor is enough for small scripts, but you can also choose to use your own native editor, or switch to the C# version (and use visual studio or jetbrain rider).

I don't find the scripting language any worse or better than any modern script languages. What are the missing features?

Re: Godot 3.5

#103

Post by fergicide »

robrtsql wrote: post #4

> Physics interpolation in 3D This is huge. Initially, Godot didn't support any interpolation, which meant you either ignore fps altogether (and your game literally plays slower, and therefore differently, if the game slows down from 60 to 30 fps), or you move physics code to the _physics_process() and suffer from stutter/jitter because the physics code and the rendering code slowly drift out of sync. Amazing! EDIT:…

Not entirely true. For a long time Godot has had Engine.get_physics_interpolation_fraction, which permits smooth interpolation of visual bodies ticking at render rate while their physics bodies tick at the physics rate (2D or 3D). I can run my physics at 2 fps (or any increment) and an object will smoothly move from A to B, because rendering is happening in _process and target positions are being calculated in _physics_process.

Placing a camera under the control of a physics node is just the way most people do it because they don't know any better. Decoupling an object's physics representation from visual representation is something many devs never learn, and they pay the price with frustrating visual stuttering under any engine -- as I did for many, many months back in the day under Unity until figuring it all out.

I'm looking forward to playing with the new baked-in physics interpolation (albeit only for 3D so far) with 3.5, but this has been easy to implement in 3.x for anyone familiar with "get_physics_interpolation_fraction".

Re: Godot 3.5

#104

Post by sk0g »

seba_dos1 wrote: post #95
sk0g wrote: post #66

Earlier quoted context omitted.

That's a very bold statement, what has Godot done to warrant it? It's not even the most advanced open source 3D engine right now, considering O3DE (a fork of CryEngine) is open and backed by a fair few big players.

How relevant O3DE is in practice though?

More relevant than Godot was at a similar age. Just look at the partners, for example. If the engine picks up steam, could easily see it becoming huge - at least as a base for in-house forks for studios.

https://www.o3de.org/

Re: Godot 3.5

#105

Post by sk0g »

TeaDude wrote: post #91
sk0g wrote: post #66

Earlier quoted context omitted.

That's a very bold statement, what has Godot done to warrant it? It's not even the most advanced open source 3D engine right now, considering O3DE (a fork of CryEngine) is open and backed by a fair few big players.

O3DE requires "40-100 GB of free disk space" and a separate compiler. Godot (3.5) on the other hand requires a paltry 72.6 MB. Even less if you go for older versions or recompile it without certain features. It comes fully featured with it's own scripting language (or C# if you prefer but that requires extra disk space) and pre compiled builds for distribution with the final product. You can still use C++ if you wish…

But I was responding to claims that it will be ubiquitous in the industry, not that it's easy to get started with.

> pre-packaged with the majority of features that your average developer will need

From my minimal experience with it, I'd disagree. What's the biggest (3D) game built with Godot?

Re: Godot 3.5

#106

Post by foldr »

BoorishBears wrote: post #85
naet wrote: post #35

Earlier quoted context omitted.

Unity is still extremely popular. The Unreal vs Unity engine debate has raged with plenty of people on both sides for years now all over game dev forums. I don't have any exact stats offhand, but I believe there are plenty of big games recently published that were developed on Unity. The only examples I remember rn are Fortnite (Unreal, but sort of doesn't count because it's made by Epic Games, the makers of the engi…

As someone who's been following that debate since the Unity 2.x days, I'd say Unreal might start to pick up steam once "Verse" drops That's their purported scripting language for Unreal. By far the most "serious hobbyist" unfriendly aspect of Unreal has always been the heavy macro based C++. They tend to be people who don't like the idea of visual programming, so hate Blueprints (no hat in this race, I think they're…

IIRC the early versions of the Unreal engine used another custom scripting language, UnrealScript. It's interesting how engine developers go back and forth on the costs/benefits of embedded scripting languages. I think something similar happened with the Quake engine too (Quake 1 had QuakeC, whereas Quake 2 onwards was C/C++ all the way down).

Re: Godot 3.5

#107

Post by seba_dos1 »

sk0g wrote: post #104
seba_dos1 wrote: post #95

Earlier quoted context omitted.

How relevant O3DE is in practice though?

More relevant than Godot was at a similar age. Just look at the partners, for example. If the engine picks up steam, could easily see it becoming huge - at least as a base for in-house forks for studios. https://www.o3de.org/

Partner list doesn't indicate any kind of relevance, and Godot's history is very different, so you're comparing apples to oranges. How many teams are using O3DE to build stuff? How healthy is the user community? How hard is it to find outsourcing and porting houses that work with O3DE? Learning resorces? Extension and asset market? Do you personally know anyone who works in it? Those are all things that Godot does reasonably well these days, while I don't know the answers for O3DE without actively searching for them despite of being in the industry for years and knowing about O3DE since its announcement, hence my question.

O3DE was a code drop that needed to pick up steam almost from scratch, while Godot has already acquired it over years. Also, they're not exactly targeting the same market segment, O3DE being more of an Unreal Engine-wannabe, which is much more challenging. I wish it well, but it doesn't seem like it's anywhere near "relevant" just yet. It's more like a last chance given to Lumberyard to not fall into total obscurity.

Re: Godot 3.5

#108

Post by IshKebab »

spacehunt wrote: post #80
IshKebab wrote: post #76

Earlier quoted context omitted.

Why couldn't you just run physics at the graphics frame rate (or double it if the graphics becomes too slow)? I don't think many games need fully deterministic physics do they? Like x += v * dt draw(x) Or is that what this does?

Collision detection is a major reason. If you only sample positions at the frame rate, you're going to have bullets go through walls without hitting anything. Also, physics is costly to run, so usually it's not run on every frame.

You only need physics to run at a "fast enough" rate. Let me rephrase:

Why not just snap physics frames to graphics frames?

Re: Godot 3.5

#109

Post by sk0g »

seba_dos1 wrote: post #107
sk0g wrote: post #104

Earlier quoted context omitted.

More relevant than Godot was at a similar age. Just look at the partners, for example. If the engine picks up steam, could easily see it becoming huge - at least as a base for in-house forks for studios. https://www.o3de.org/

Partner list doesn't indicate any kind of relevance, and Godot's history is very different, so you're comparing apples to oranges. How many teams are using O3DE to build stuff? How healthy is the user community? How hard is it to find outsourcing and porting houses that work with O3DE? Learning resorces? Extension and asset market? Do you personally know anyone who works in it? Those are all things that Godot does re…

Please re-read the context of the conversation you're replying to - if Godot is not targeting the same market as Unreal, then you're agreeing with my point, not disagreeing. I'll recap anyway.

> Unreal is winning the technical race because they ship projects and games themselves with their engine.

> Godot is definitely going to win the race long term

> what has Godot done to warrant it?

---

It's been open source for around a year. It doesn't take a genius to figure out it's not ready for prime-time, and does not have a community built around it yet. You're also dodging the question of what the biggest game built in Godot was, considering Godot has been around for so much longer.

Deadhaus Sonata is using O3DE, and already looks bigger than any game on the Godot showcase page.

> O3DE was a code drop

With mostly Amazon working on it currently, it's got around the same LoC changes being made to it currently. There's others working on it too, and as more games start using this engine (announced just over a year ago, mind you), the contributors will increase. Games take a long time to even announce - a few years after the start of the project is the typical time-frame. This excludes indie games that Godot typically targets of course.

Re: Godot 3.5

#110

Post by sdkgames »

chii wrote: post #102
sdkgames wrote: post #72

TLDR: The problem with Godot is that it tries to be everything to everyone. They made an engine, an editor (a text editor, resource editor, debugger ...), invented a new language. They "support" export to almost all popular OS platforms. But in my opinion it's lacking in quality. The engine is slow (old style based on OOP), the editor is buggy, the language (GDScript) doesn't have the features of a modern scripting l…

> The engine is slow doesn't really seem that slow for me (but of course, i haven't used it in anger yet). > the editor is buggy, the language (GDScript) doesn't have the features of a modern scripting language. the editor is enough for small scripts, but you can also choose to use your own native editor, or switch to the C# version (and use visual studio or jetbrain rider). I don't find the scripting language any wo…

>I don't find the scripting language any worse or better than any modern script languages. What are the missing features?

lambdas, closures, support for error handling, constructor overloading, list comprehension, packing/unpacking (arguments/lists), varargs

Post reply on HN