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

61–70 of 121 posts

Re: Godot 3.5

#61

Post by EarthLaunch »

iFire wrote: post #50
EarthLaunch wrote: post #12

Earlier quoted context omitted.

I think three.js is that. - All of the above except language - Library rather than engine I've had really good luck with it versus Babylon or Unity.

Let's be fair to three.js, the comparison would be to aframe. https://aframe.io/ or similar projects. (Godot Engine Maintainer)

Thank you so much for your work on Godot.

You are right, though I think all three can be compared, depending on the type of project. Unity is on the decline and I would be happy for Godot to become the future for those types of games.

Re: Godot 3.5

#62

Post by arran-nz »

Stoked! I think I'll continue on my Godot VR Project now that Label3D and Textmesh are implemented - Text within the scene is vital for VR Debugging.

Re: Godot 3.5

#63

Post by EarthLaunch »

peoplefromibiza wrote: post #26
EarthLaunch wrote: post #12

Earlier quoted context omitted.

I think three.js is that. - All of the above except language - Library rather than engine I've had really good luck with it versus Babylon or Unity.

> I think three.js is that. three.js doesn't produce native multi platform apps for desktop and mobile.

The mobile builds are its killer app, in my view as a gamedev. Unity has lost the plot in many ways. Desktop builds are important too, but there's competition there if you consider browser/electron as a desktop platform, plus Unreal. But Godot is the exclusive up-and-coming competition in mobile builds (that I am aware of; granted I am not a mobile dev).

Re: Godot 3.5

#65

Post by ChadNauseam »

UnpossibleJim wrote: post #48
TheMagicHorsey wrote: post #13

Godot is a fantastic project. But, I really wish it was written in something other than C++. I really can't bring myself to go back to programming C++ again after a decade away using more recent languages like Go and Rust. I even find deciphering the types of variables to be painful when reading C++ code these days.

If you're looking to an up and coming game engine project, there's "Bevy", which is an ECS game engine (like Unreal) that's also open sourced, which is Rust based: https://bevyengine.org/learn/book/introduction/ They aren't at first release yet. I think they're at 0.8, and I'm unsure as to their contribution structure, but read their documentation. It's in there I hope.

I've contributed to bevy, you can just make a PR for something small, or an RFC for something big.

While I'm here, I might as well give my $0.02 about bevy. It's got an amazingly sturdy foundation, but it lacks essential game engine features like asset preprocessing and render postprocessing stacks. Those are both slated to land in time for 0.9, which should put it ahead of most OSS engines.

Currently, there's also some very annoying stuff related to managing when and in what order systems run. There's a mostly-done big refactor called "stageless" which totally fixes this, but it touches a lot of code and needs to be merged. I'll quite be happy if that makes it into 0.9 too.

There are lots of other features missing, like everything UI, but these are the near-term changes and should put it in a good place for future growth.

Re: Godot 3.5

#66

Post by sk0g »

fezfight wrote: post #57
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…

It's small enough of a code base that you can change things to suit your needs, too. Godot is definitely going to win the race long term, just like blender. People can use whatever they like, of course, but if you want future developer talent, youre going to need to use Godot.

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.

Re: Godot 3.5

#67

Post by httpsterio »

fezfight wrote: post #59
naet wrote: post #53

Earlier quoted context omitted.

Can I ask what it is you're using godot for if it isn't a game?

You can build really fancy UIs in it so you can use it for basically anything.

what's the lowest hardware requirements you would say you could run a Godot built UI on (not necessarily your product, just generally?)

Re: Godot 3.5

#68

Post by barnabask »

naet wrote: post #53
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…

Can I ask what it is you're using godot for if it isn't a game?

Not OP but educated guess: Tesla's mobile app. https://twitter.com/AlexGuichet/status/1528149807709048833

Re: Godot 3.5

#69

Post by sprkwd »

httpsterio wrote: post #67
fezfight wrote: post #59

Earlier quoted context omitted.

You can build really fancy UIs in it so you can use it for basically anything.

what's the lowest hardware requirements you would say you could run a Godot built UI on (not necessarily your product, just generally?)

Think folks have used in on a Raspberry Pi

Re: Godot 3.5

#70

Post by zlsa »

MrYellowP wrote: post #40

I've looked at 3.4, 3.5 and 4.0a ... and while 4's scripting engine is definitely faster than the others before, it's still way too slow to consider using it.

I can concur - the stated position is that GDScript should only be used for non-performance-critical tasks, but even with a hundred objects running a simple script every frame, performance absolutely tanks in 3.x. The performance wall is so easy to hit that GDNative is almost a requirement to get good performance in non-trivial projects.
Post reply on HN