Live data from Hacker News

Godot Engine – A decade in retrospective and future

godotengine.org

111–120 of 168 posts

Re: Godot Engine – A decade in retrospective and future

#111
I've been using Godot engine for the past two months now, I evaluated both Unity and Unreal Engine of course, and in the past I've built my own 3D engine (took me 2 years, C++ with Lua scripting, OpenGL 3.3+).

What got me started with Godot was the fact that it is completely open source, and I was evaluating also writing my project with Rust, and Godot had already support for interfacing it's scripting interface NativeScript even with Rust already (although much work in progress).

Ultimately I decided to develop the project with mostly C++, but during learning the engine I noticed that GDScript is very capable and seems even faster than Lua at least according to my 2 month experience, mostly coming probably from the fact that it has native types like vectors and matrixes and so on integrated directly into the scripting language and implemented with C++.

I was pleasantly surprised how easy and logical the engine is to use, they've made a lot of correct decicions when it comes to the technical viewpoint, for example getting engine scripts written with C++ was very easy, which surprised me.

The documentation is also very well written, with up-to-date examples and I haven't seen any missing information yet.

Only thing I've been missing is more complete examples of games utilizing C++ for example, and more complete projects to be looked at as an example. Most of the projects I could see were written mostly with GDScript, so I would have wished to see more indepth and professional examples in how to write performant projects using Godot.

But mostly GDScript even seems to enough to implement most of the game or application logic.

For me though, the fact that the engine is open source and that people are actively fixing issues in it, and I can even contribute myself is a big factor. The MIT license also grants me to do whatever I want with the end product, which is a big plus.

I hope to contribute to the project as I go along, been looking at the source code and it's really readable also, the architecture is pretty solid and clean at least according to my quick evaluation of the project.

I'm projecting great success for Godot in the next year, especially with the upcoming Oculus Quest support already well under way, this could be a easy and more flexible way for people to get into VR development possibly.

Re: Godot Engine – A decade in retrospective and future

#112
post #107
post #76

Earlier quoted context omitted.

the real reason is that godot feels lightweight to devigners and they want to use it. there were tons of other html5/js game engines, some who have been there longer, but none have had support from mozilla!!

How come it feels lightweight? Would you be able to articulate it?

Godot doesn’t just feel lightweight, it is lightweight: the entire program is a single modestly sized executable, it takes very little time to go from startup to making something, and it runs well even on lower spec computers. It’s also not very mentally imposing: once you get the hang of nodes, the scene tree and signals, you’re pretty much set.

Re: Godot Engine – A decade in retrospective and future

#114

What's Godot's C# support like nowadays? I remember there being some criticism of the early implementation, but I haven't checked back recently. I keep on getting really curious about Godot, it seems like an engine that should be up my alley, and I really am in the market for Open Source engines. I don't want to keep coding everything myself. But I'm a little thrown off by the idea of learning a new scripting languag…

Felt the same way about the scripting language at first but dug in anyway and it's so close to Python it wasn't too bad to use in practice. Has some short hand for referencing nodes via $ that C# version didn't have.

Re: Godot Engine – A decade in retrospective and future

#115
post #89

Earlier quoted context omitted.

>These are all fine changes but they could all happen on their own. They really couldn't all happen on their own. They wanted to write more code in C#, so of course it makes sense that they'd start with the new systems they were making for the ECS. To support being able to write more in C# they developed the burst compiler. And the jobs system is a huge part of the way they developed their ECS system. DOTS really jus…

IMHO there is a basic error they're making, which is to do all of this in one product. When they have two internal architectures sharing one interface, the overall scope bloats up, which leads to some miserable UX. With most game projects, the point is to ship them once and then start anew with the next one - long-term maintenance isn't the primary decision driver, and the games for which that is the case are rather…

>IMHO there is a basic error they're making, which is to do all of this in one product.

If they were to start from scratch, DOTS would be missing so much functionality that it wouldn't really be useful. By essentially using the strangler pattern, they are allowing people to get access to the newer architecture immediately, and then gradually adding more and more over time. Eventually, years from now, they will completely replace the old architecture. I'm sure there will be some version of what you're talking about here

>as long as the previous engine has the proverbial lights kept on

with the old architecture.

> long-term maintenance isn't the primary decision driver, and the games for which that is the case are rather exceptional and sit at the top end of the business

That's less the case these days with plenty of indie games produced by very small teams that are in early access release/development cycles for years. It's also very common to reuse existing codebases for new games.

>The majority of users in contrast are equally as likely to welcome clean breaks as they are to despise them; as long as the previous engine has the proverbial lights kept on, there isn't an issue.

The outcry over Unity abandoning the old way of doing things is pretty loud. Many people use Unity for multiple projects, and they get mad when Unity makes big changes that invalidate their knowledge, which is one reason Unity is making the changes so slowly.

Re: Godot Engine – A decade in retrospective and future

#116
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…

The Unity portion of this comment is very out of date. UnityScript ("some JS variant") and Boo ("some weird Python style thing") had support dropped years ago.

Re: Godot Engine – A decade in retrospective and future

#117
post #30

It seems like some of you have some real love for Godot. How come you decided to use/recommend Godot over Unity when it was less mature? Was it much better along some axis that Unity didn't provide? What makes it better along that axis? Usually happens when something is 10x better at something new that people care about that the incumbent is blind to or is structurally incapable of addressing. I'm just wondering what…

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

Re: Godot Engine – A decade in retrospective and future

#118

Earlier quoted context omitted.

Unreal has dropped their scripting language for a visual alternative called Blueprints. It is possible to make an entire game with it not writing any C++ and is possible to make one completely in C++. The best is of course using them together. And exactly the same applies to Godot. Just swap Blueprints for GDScript a Python-like scripting language. In a final note Unity, has dropped JavaScript. Though C++ can somehow…

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

Re: Godot Engine – A decade in retrospective and future

#119
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…

You are not allowed to publish any information about console APIs. That is part of the agreement for getting access to the SDK.

You can't publish any code that calls non-standard APIs. So therefore any code that interacts with those APIs cannot be open source.

You would have to publish a seperate extension to the engine that is not open source and make it only available to those who have signed the Developer Licence Agreement for the platform. Depending on what licence you chose or how the code is structured that might break your own open source licence.

Re: Godot Engine – A decade in retrospective and future

#120
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…

You are not allowed to publish any information about console APIs. That is part of the agreement for getting access to the SDK. You can't publish any code that calls non-standard APIs. So therefore any code that interacts with those APIs cannot be open source. You would have to publish a seperate extension to the engine that is not open source and make it only available to those who have signed the Developer Licence…

> You are not allowed to publish any information about console APIs. That is part of the agreement for getting access to the SDK.

Sounds very much like paranoid '80s - '90s approach where everything including development tools was viewed as some kind of super guarded secret. But I guess incumbent consoles are stuck in that mindset. They should realize it's been a different century for two decades already. Hiding an API is not helping anyone.

Post reply on HN