Live data from Hacker News

Godot Engine – A decade in retrospective and future

godotengine.org

161–168 of 168 posts

Re: Godot Engine – A decade in retrospective and future

#161
post #159
post #158

Earlier quoted context omitted.

> So let me put this in another way, neither OpenGL or Vulkan are a common API OpenGL is legacy case, so no point in bringing it. Vulkan is the only common API, there is simply nothing else for that role. With all your talk about how "great" proprietary APIs are, none of them ever can be common, because they all are the total antithesis of it - their goal is lock-in in, not something that helps developers reduce thei…

According to Khronos, OpenGL is still the API to go when one doesn't want to deal with Vulkan boilerplate. Middleware is the common API. Taking advantage of raw performance from hardware, exposed with SDK tooling that Khronos has never offered. Basic stuff like math, loading textures, material description formats,... Instead every newbie has to go through the challenge of creating their own little engine. My advocacy…

Your advocacy means "do more work just because" for engine developers. So clearly not something they'll ever appreciate.

Re: Godot Engine – A decade in retrospective and future

#163
post #37

Earlier quoted context omitted.

I'm not a Godot user, I'm a Unity user, but the fact that you don't have to pay is one of the big draws of Godot. Unity Pro is $150/month per seat. The fact that it's open source is also big, because there are often bugs in the Unity engine that I can't fix since I don't have source access. A lot of devs also like jumping on new technology because it feels good to learn new things. Oh and then because it's open sourc…

I wonder why this discussion always falls to Unity and Godot; Unity source is not available, while Unreal Engine source is. Unreal also has more features available than both engines out of the box, as far as I am aware. I don't want to sound like an advert, but the shading and Blueprint systems in UE4 are extremely intuitive and easy to work with, and the C++ is definitely managable. I've never used Godot, but the la…

History I expect, Unreal was a expensive closed engine for AAA games for something like 15 years before moving to a source provided model where you paid with revenue. Unity had a free tier for something like 10 out of those 15 years.

Re: Godot Engine – A decade in retrospective and future

#164

Earlier quoted context omitted.

Godot is worth trying. I found it easier than Unity/Unreal to pick up, especially for 2D. Also check out https://defold.com/ — it’s an excellent game engine that perfectly suits your 2D/mobile/lightweight requirements. The team behind it (at King) are very active both in listening to the community and with their release cycle. It has a bunch of features bigger engines still lack (hot reloading, fast testing cycle and…

Last I checked, Defold/King require that you let them collect analytics from players' devices in order to ship games with their engine (i.e., your game becomes a trojan horse for their data harvesting regime). It was buried in the terms and a nasty surprise when I found that out (luckily, still in the early stages of experimentation). Permanently destroyed any trust I might put in their offerings.

(I'm the Defold product owner)

There's not a shred of truth in the above statement. We offered an OPT-IN analytics services that provided you, the developer, with install and retention numbers for your game. No one at King or in the Defold team ever looked at any data. King has hundred of millions of monthly active players of their own games. That's enough data. No need to try and steal data from anyone else...

The optional analytics service along with the optional project hosting was shut down four months ago.

We do use Google Analytics for www.defold.com and the editor. This is clearly stated in the terms and conditions. And it's pretty standard stuff in the industry to keep track of product usage like that.

Re: Godot Engine – A decade in retrospective and future

#165
post #164

Earlier quoted context omitted.

Last I checked, Defold/King require that you let them collect analytics from players' devices in order to ship games with their engine (i.e., your game becomes a trojan horse for their data harvesting regime). It was buried in the terms and a nasty surprise when I found that out (luckily, still in the early stages of experimentation). Permanently destroyed any trust I might put in their offerings.

(I'm the Defold product owner) There's not a shred of truth in the above statement. We offered an OPT-IN analytics services that provided you, the developer, with install and retention numbers for your game. No one at King or in the Defold team ever looked at any data. King has hundred of millions of monthly active players of their own games. That's enough data. No need to try and steal data from anyone else... The o…

Um, okay. I'm not sure what I'm supposed to say to that. I remember this clearly from when I trialed Defold immediately after the public launch. I'm glad if things have changed, but the analytics were not opt-in back then.

Re: Godot Engine – A decade in retrospective and future

#166
post #126

I am coming back to Unity for a side-gig VR thing after not touching it for a couple years. Unfortunately the timing is not great since they are still sorting out all the new offerings (XR Plugin vs. Player settings, Input systems, ECS from prefabs, etc.) Is anyone doing VR with Godot? I have a couple questions: 1. What's the development cycle look like? In Unity I can hit play and put on the headset (Oculus Quest w/…

I have done some VR with Godot and I'm very pleased with it. I also did a VR game in Unity for a course at university 2 years ago so I have some experience in both engines for VR.

In terms of performance & lag of the implementation of VR I didn't notice any differences between the two engines.

From my experience with Godot :

1. The dev cycle is I press play and then everything just works instantly. The game automatically connects to the headset and I can see the game both on the screen and in the headset. No build, no exports, nothing. It just works. From what I understood this is mainly thanks to Bastiaan Olij' work, so big thanks to him !

Also VR support in Godot has a "native" feel, you have AR/VR nodes ("ARVRCamera", "ARVRController", etc.) in the engine. I spent less time setting up VR in Godot than in Unity.

2. I never used wireless headset so I can't compare battery usage. For wired headset at least, in terms of performance Godot is far sufficient for making games like any of the popular VR games out there.

As a big rewrite of the rendering engine is going to happen for 4.0, I think we should wait for this before making comparisons of rendering perfs.

3. Godot has support for GDScript , C#, and "others" (via NativeScript). In others we have C++, Rust, Python, JS, etc. I never used any of those other languages with Godot so I can't tell. It seems the setup of NativeScript is quite complicated and much less convenient to use than C# & GDScript, but I'd also like to hear from someone who used that.

However it's a UI problem and I don't see why in the future NativeScript couldn't be just be as convenient (maybe we indicate once the path to GCC and Godot automatically download the NativeScript headers, set up everything and compile automatically on play)

Also for performance intensive tasks there should be compute shaders in 4.0 and it was also mentioned that compiling GDScript AOT (maybe by transpiling it to C or targeting LLVM) should be doable (GDScript' static typing is a first step in that direction).

From my personal experience, Godot is such a breath of fresh air compared to Unity where everything seems messy and overengineered. There is no prefab or other wierd things. Just nodes in trees and scenes. It makes everything so much cleaner and more enjoyable to develop with. Unity seems to pile up the latest shiny features on top of each other but without thinking about overall coherence.

However the popularity and $$$ of Unity gives it many advantages in terms of support , tutorials, asset store, more features, etc.

So I would recommend Godot :

- if you like clean architecture

- if your VR game is not more graphically ambitious than popular VR games or if you're okay to wait for 4.0 (then it should be on par with other engines)

- if you don't need YouTube tutorial for everything and you're okay with reading the doc API.

- if you are used to code your own logic & assets and not to rely heavily on the Unity asset store (you can consider Godot asset store is basically nonexistent in comparison)

Re: Godot Engine – A decade in retrospective and future

#167
post #164

Earlier quoted context omitted.

(I'm the Defold product owner) There's not a shred of truth in the above statement. We offered an OPT-IN analytics services that provided you, the developer, with install and retention numbers for your game. No one at King or in the Defold team ever looked at any data. King has hundred of millions of monthly active players of their own games. That's enough data. No need to try and steal data from anyone else... The o…

Um, okay. I'm not sure what I'm supposed to say to that. I remember this clearly from when I trialed Defold immediately after the public launch. I'm glad if things have changed, but the analytics were not opt-in back then.

I've been with the Defold team since before the public launch, but I'm not going to debate you over this :-)

As you say, things have changed and we have worked hard since the launch three years ago to show our community of developers that we are serious about Defold as a professional choice for game developers and that we do not have any hidden agenda with giving Defold away for free.

Re: Godot Engine – A decade in retrospective and future

#168
post #152
post #137

Earlier quoted context omitted.

You compile the next version of the compiler using the previous version. That does mean that the first version of the compiler cannot be written in the target language. Once you've got that working you can write a new compiler in the target language and compile it with the previous compiler. Back in ye olden days the first assembler was written in machine code. The first C compiler was written in assembly, and the fi…

The first C compiler was written in BCPL IIRC, the D compiler was written in C++ up until about 2016-ish

I figured someone would point out that I missed a few steps ;)

The explanation of how a compiler can be implemented in its target language still holds though.

Post reply on HN