Live data from Hacker News

Godot Engine – A decade in retrospective and future

godotengine.org

121–130 of 168 posts

Re: Godot Engine – A decade in retrospective and future

#121
I keep debating whether I want to commit time to doing a hobby project in Godot or Unity (yes, I know I should just pick one and do it). Unity has made massive strides but I just find Godot so damn pleasant to work in, especially with code editing being built right into the editor and GDScript being such a nice language.

I can really see Godot becoming the Blender of game engines. Kudos to the team!

Re: Godot Engine – A decade in retrospective and future

#122

Earlier quoted context omitted.

> In a final note Unity, has dropped JavaScript. The thing that Unity dropped wasn't really JavaScript, and nobody in their right mind actually used it. It was called "UnityScript", and it was just a thin veneer over CLR that looked a bit like JavaScript, but exposed the CLR object model and C# APIs to arrays and dictionaries, etc, instead of supporting standard JavaScript APIs. The biggest problem was that most Java…

As I am not a Unity developer, I thought the differences between US and JS were superficial and I wasn't aware they're incompatible in that degree. UnityJS seems interesting. What is its status? Is it a draft or usable already?

UnityJS is open source, and I've been using for various projects and developing it actively, most recently on WebGL.

Here's the original github repo:

https://github.com/SimHacker/UnityJS

I recently refactored that monolithic repo into a bunch of smaller nested repos, to make it much more modular and layered, so that different projects for different platforms can pick and choose which modules to use.

Here is the root repo of the new version:

https://github.com/SimHacker/UnityJS_UnityJS_Deployment_WebG...

I'm still in the process of documenting how to install it (now that you have to wrangle git submodules it's tricker), and how to use it (there are a lot of moving parts, and different platform specific pieces). But here is some high level stuff:

Anatomy.txt: https://github.com/SimHacker/UnityJS_UnityJS_Deployment_WebG...

Architecture.txt: https://github.com/SimHacker/UnityJS_UnityJS_Deployment_WebG...

InterestingFiles.txt: https://github.com/SimHacker/UnityJS_UnityJS_Deployment_WebG...

(Some of the paths in the above file have changed in the name of modularity.)

Since Unity insists that you put different kinds of files in certain fixed directories like StreamingAssets (for all the .js files and web content) and WebGLTemplates (for the WebGL wrapper that loads your JavaScript code), you can't make a module with one single github repo that has different sub-directories that would straddle the fixed Unity directories. (And symbolic links don't work on all platforms, so you can't fudge it.) So it is necessary to split some modules up into different repos, so the one with C# code can go into Libraries, and the one with JavaScript code can go into StreamingAssets, and the one with the html wrapper can go into WebGLTemplates.

Here's the repo with all the C# code and resources:

https://github.com/SimHacker/UnityJS_UnityJS_Library

For example, here's the C# side of the JavaScript/C# bridge:

https://github.com/SimHacker/UnityJS_UnityJS_Library/blob/ma...

Here's the repo with all the latest UnityJS JavaScript code:

https://github.com/SimHacker/UnityJS_UnityJS_StreamingAssets

And here's the JavaScript side of the JavaScript/C# bridge:

https://github.com/SimHacker/UnityJS_UnityJS_StreamingAssets...

Send me email if you want to know more! I'm happy to answer questions and help you get it working, and to hear your feedback, which will help me write more and better documentation.

Re: Godot Engine – A decade in retrospective and future

#123
post #38
post #31

Earlier quoted context omitted.

They are migrating several modules from C++ to C#, by making use of their Burst compiler stack, and have introduced a new ECS based framework named DOTS, on the quest to appease to AAA studios.

I don't think its a AAA request, per se. Unity seems to constantly need features to slap on the box. At this point it feels like DOTS is significantly influenced by the marketing team. I mean, engineers would spell out the features and not wrap it up into this vague concepts of "DOTS."

An almost constant criticism of Unity that I hear is that it's "too slow", that games made with it run slower than what their visuals would suggest. This has been such a common criticism of Unity for so long. So I don't think it's solely a response to requests from AAA studios either. My impression is that the current Unity model just doesn't scale by default (as in, yes it can be made to work but it's not the default and you'd be fighting with the architecture to do it). Or perhaps a much better way of saying it is that the default Unity architecture encourages less-experienced developers to write slower code. I've heard them say that "performance by default" is a goal for DOTS in a number of talks.

Re: Godot Engine – A decade in retrospective and future

#124
post #53

I wonder if Godot has a chance of becoming the Blender of game engines. From the way it is growing it's starting to look like a real long-term possibility to me, especially for the smaller game studios.

A real draw for me is working with C++ in it, since both Unity and Unreal appear to favour managed languages (C#, some JS variant, some weird Python style thing, etc.) No real reason for preferring C++ except I want to learn it, and my pet project is a little game rather than yet another web app/thing that renders DB records to HTML/thing that takes one JSON blob and turns it to another. I never did computer science…

> yet another web app/thing that renders DB records to HTML/thing that takes one JSON blob and turns it to another

Ouch, this is currently my "pet" project. I totally get what you mean though. I'm honestly not sure if it can even considered a pet project anymore, as it works way better than I expected.

Re: Godot Engine – A decade in retrospective and future

#125
post #99

> The new rendering architecture will also allow companies working on console ports to more efficiently port the engine and offer our users the possibility of running their games on the most popular game consoles (something we will, unfortunately, never be able to offer officially due to legal reasons, thus forcing us to cooperate with companies porting it on their own). I didn't quite understand that part. What lega…

[deleted]

Re: Godot Engine – A decade in retrospective and future

#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/ Link, so essentially a Rift). No need to export a full build or go through multiple steps. Honestly this is the single most important factor for me since it allows quickly figuring out other problems. Does Godot support it?

2. Unity has made a big deal about DOTS and from initial tests it's legit. For VR on low-powered headsets (ultimate target is Oculus Go) these performance savings matter. How does Godot compare?

3. I don't know C++ and worried that I wouldn't be able to squeak by from bad usage of it. GDScript looks interesting but in this use case performance matters. I am doing a significant amount of Rust these days esp for hobby projects and would LOVE to be able to code in that. Are the Rust bindings to Godot good? Does it interfere with quick iteration? (looking at the repo it's hard to see what's going on and what the impact is on a real project)

Re: Godot Engine – A decade in retrospective and future

#127
post #99

> The new rendering architecture will also allow companies working on console ports to more efficiently port the engine and offer our users the possibility of running their games on the most popular game consoles (something we will, unfortunately, never be able to offer officially due to legal reasons, thus forcing us to cooperate with companies porting it on their own). I didn't quite understand that part. What lega…

Their console APIs already offer the lowlevel control from Vulkan and are much older than Vulkan, so no, it is not from the begining.

Re: Godot Engine – A decade in retrospective and future

#128
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 know quite a few game devs (side-effect of both living in Malmö and being active on the TiGsource forums) and if there is one common thing I hear about Unity it's how it does not seem to care at all about backwards compatibility, and how upgrades can completely screw over projects. I don't know what the story is with Godot (beyond the breaking changes between 2.0 and 3.0 that was mentioned in the linked blog post)…

What's funny is I think all of the major game studios that I know of essentially lock game engine per project once they're coding along. It's just expected that you stick with it for the rest of the project. Maybe 1 upgrade mid project. I had heard bungie used to, in the halo days, lock the engine 8-11 months out and the core tech team started working on the next game. The AAA studio I worked for essentially did that 3-6 months out.

But those were 2-3 year game cycles. Maintaining a project would be less fun. But it'd be like choosing to do a rails or react upgrade.

Re: Godot Engine – A decade in retrospective and future

#129

As a side project to get me back into lower-level programming, I've had the pleasure of working on a personal fork of Godot. The engine's simply fantastic from a programmer's perspective. The code is readable, the architecture is quite intuitive, and with the exception of a few engine components, you don't run into much in the way of incomprehensible spaghetti code. Adding features is more or less trivial, as has bee…

> But among the projects I've seen where performance has been an issue, it's largely been the product of a developer's failure to understand how the engine is processing their content, and by extension their failure to architect their game around that.

What are some pitfalls everyone is falling into and what needs to be understood conceptually about how the engine processes scenes?

I’ve found a lot of good documentation and videos on getting started and particular workflows (eg animating), but haven’t see any regarding performance optimization or what Godot is doing “behind the scenes”.

Re: Godot Engine – A decade in retrospective and future

#130

Earlier quoted context omitted.

I used Unity in a work environment for about a year and a half, so I feel like I have a reasonably informed, if potentially a little outdated opinion, since that experience was some years ago. Whilst Unity is generally more mature there definitely are areas where I strongly prefer Godot. (Disclaimer: I am a FOSS nerd) First up the added Unity maturity isn't always as helpful as you'd expect. There were many areas tha…

Unity has had nested prefabs for over a year. https://docs.unity3d.com/Manual/NestedPrefabs.html

Sweet. Thanks for the correction there because, as I mentioned in the comment, there was room for my opinion to be outdated.
Post reply on HN