Live data from Hacker News

Godot Engine – A decade in retrospective and future

godotengine.org

71–80 of 168 posts

Re: Godot Engine – A decade in retrospective and future

#71
post #64
post #56

Earlier quoted context omitted.

https://www.reddit.com/r/Unity3D/comments/ef8jrh/unity_in_20... Here's a meme which is actually very illuminating. Someone in the comments mentions checklist-driven development, which seems about right. Unity doesn't feel like a complete product right now, it's full of systems which are either incomplete and badly documented or outdated and buggy.

I often wondered if that's the curse of building a horizontal product where you're trying to satisfy multiple types of users with different jobs to do (typical in enterprise products) Or if it's just an inherent complexity in the actual job. Or if it's an issue with management and product managers that can't decide which users to service, so they do the easy, but wrong thing and try to service them all.

Conway's Law (which of course is not really "law") would suggest the last option is the most likely. Given that other game engines don't really have this issue the other two options seem less likely to me too.

[0] https://en.wikipedia.org/wiki/Conway's_law

Re: Godot Engine – A decade in retrospective and future

#73
post #61

Earlier quoted context omitted.

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)…

Yikes. Does Unity do forced paid upgrades, so you'd have to deal with the incompatibilities? Do they have a culture of incompatibilities so they can simplify their development and keep the best features and discard the worst?

Unity is both free and subscription based.

They make older versions of the engine available in their management app, and projects are linked to a specific version unless you explicitly upgrade.

Re: Godot Engine – A decade in retrospective and future

#74
post #41
post #6

Great post. Is there a 3-year, 5-year, even 10-year roadmap for Godot? It's a tool I'm very interested in using but the industrial backing and stability of Unity/Unreal is hard to beat. Some kind of assurance that the creators of Godot plan (or at least hope) to keep working on the project for a long time would go a long way.

If you need reliable support, you have to pay someone. It does not matter which project you are talking about.

I'm not asking for support. Godot could definitely go the for-profit route and charge for cloud builds and other features like Unity does. I just want to make sure that if I invest in learning the tool as well as I know Unity that it'll be around for the next few years.

Re: Godot Engine – A decade in retrospective and future

#75
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 that felt very incomplete, requiring us to write our own solutions, or find third party ones often at cost. An example was I believe we encountered strong limitations with the built-in AI Navigation system that made it pretty useless to us. There were third-party navigation solutions, but this sort of summarizes part of the problem with Unity: there is a lot of third party addons, but a lot of them felt like things that just overcome the often confusing limitations of the original product that I already paid money for. Lots of game engines can suffer from being particularly suited for certain genres and not others, even supposedly generic ones like Unity. So if you were making something that was kinda weird and would require a lot of bespoke special work, using Unity didn't really get you any wins.

Godot plays better with VCS systems using a nice human-readable scene format called tscn, that is swapped for a binary format on project export. I find this format is usually readable enough to review scene file changes in PRs, with the usual exception being a scene that was primarily imported geometry data. To get around that we'd import geometry data into bespoke geometry scenes, and they'd be nested by reference into the scenes that you'd like to be able to review diffs on. Additionally this scene format merges nicely in git, and has allowed me to work on team projects and have people edit scene files in their own branches without fear. Unity (and Unreal) at least at the time, had nothing approaching this. There was a Unity text-scene format, but it was a merge nightmare regularly. In practice we ended up using a VCS product (I believe perforce) that allows you to exclusively check out a scene file. Which at least stops people stepping on each others toes too much but hinders productivity.

Unity as of last I heard still does not have an out-of-the-box solution for nested prefabs, with many opting to use a commercial add-on to supplement the short-coming. This feels like it has been the single most complained about Unity pain point, so it was very confusing that nothing really seemed to be happening. Godot uses an approach that I find much more elegant. There's no distinction between a scene file and a prefab, which allows for some nice refactoring where something becomes a prefab after not initially being conceived as one. You simply have the ability to make a scene graph node that is a instanced reference to an external scene, and this nests nicely with no limit that I've ever encountered.

The Unity Editor was a bit of a dog. It regularly crashed and experienced general slowness. I find Godot much more stable snappy, and don't experience anywhere near the amount of tool frustration. But I have heard that it has been quite a bit more stable in the past year or so.

I encountered a lot more weird rigid design in Unity. IIRC if you wanted to runtime load content such as textures or models, they had to be inside of one specific subdirectory of the project. In general Unity seemed to force its philosophy of project organization onto you, while Godot will happily go along with whatever approach you want.

I still think there are reasons to use Unity. It is more mature, companies generally want access to an existing talent pool, and let's not forget that often it is worth sticking to the tool you know. But I definitely have found that I enjoy working in Godot more than I did Unity, and as a fairly experienced programmer I don't mind not having as big of a community to rely on for assistance. I don't work as a game programmer anymore, but I continue to do hobby projects near exclusively in Godot.

Re: Godot Engine – A decade in retrospective and future

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

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

Re: Godot Engine – A decade in retrospective and future

#77
post #18

Earlier quoted context omitted.

PICO-8 might be a fun starting point. https://www.lexaloffle.com/pico-8.php

TIC-80 and LIKO-12 are pretty decent open source "clones" https://tic.computer/ https://ramilego4game.itch.io/liko12 And then there's the BASIC engine: https://basicengine.org/

CHIP-8 is really cool, too!

Re: Godot Engine – A decade in retrospective and future

#78
post #62
post #51

Earlier quoted context omitted.

Every version change, even minor revisions, come with a real risk of breaking your compiled asset bundles. From shaders to light maps to referenced classes. It's a huge amount of effort to keep a project tracking Unity version upgrades.

What do people do to deal with it? Are there services / libs that help you do the conversion? Or is it that you can't fully trust them, and you'll need to do that by hand anyway, because you might be one of the exceptional cases?

From my limited experience, download the version that it was made with. Unity has a list of older versions right in it's hub.

Re: Godot Engine – A decade in retrospective and future

#79

I've been looking for a lightweight 2D engine to use on Android. Something I can use to build simple 2D games with small binaries that load quickly and run on lots of hardware. (Like I might use SpriteKit for on iOS.) Should I look further into Godot Engine, or is it more of a "heavyweight"/loads-of-features engine like Unity and Unreal?

Godot's strongest areas currently are probably its 2D engine and that it's lightweight. I'd suggest trying it first to see if it's a good fit. From the needs you describe, it might be.

Re: Godot Engine – A decade in retrospective and future

#80
post #37
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'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…

[deleted]
Post reply on HN