Hacker News Reader

Comment by jayceedenton | Hacker News Reader

I don't know anything about game engines, but always assumed that Godot was limited to simpler games. A lot of people seem to be pushing for Godot to replace Unity after the recent licensing shambles.

Is it really possible to build games line Cities Skylines, Subnautica, Rust, Outer Wilds, KSP, Ori... in Godot? Is this more of a long term ambition at this point, or is it possible for this kind of game to be built in Godot today?

View on HN

Unity itself was once seen as the "mobile and hobbyist platform" compared to "big kid engines" like frostbite, cryengine and unreal.

I think Godot is there, and they are seeing the start of adoption by AAA devs even before the Unity licensing shenanigans. But as Unity's own rise shows, it's not going to be a matter of flipping a switch and having comparable share amongst big games tomorrow.

It's probably also worth mentioning that it's possible to build pretty much any game in any framework, or without, it's just a matter of time and effort. Like LWJGL still is seen as a "toy" framework despite being in one of the most successful video games of all time (Minecraft). Factorio used just Allegro as a layer on top of SDL before migrating to bare SDL2. Conversely, many of the technical problems for KSP1 or Cities Skylines 2 have been attributed to Unity being a poor fit, despite being widely recognised as having "made it" into the "real engines" tier. There were also some EA developers with not very nice things to say about frostbite for games that don't look like Battlefield in the era where EA was pushing for all their devs to adopt it.

Exactly. I used Unity starting from almost the first release, and attended Unite in 2007.

Unity was seen as a hobby engine then, we used it for the web, but for desktop used Unreal. Godot today is way ahead of where Unity was in 2007ish.

I wonder whether that is because most games are projects with a clear endpoint after which development mostly stops.

That allows developers to experiment a little bit (internally or with smaller projects) and hedge their bets.

If there is language compatibility (e.g. C# ) and your reusable components are somewhat sensibly designed (if only to mitigate update risks in your initial engine) it's feasible to think about switching for your next game (unless say in with service product that is expected to run indefinitely)

The counterpoint to this is many studios are sequel factories, or producing games that are at least broadly in the same genre continuously, and each game starts as a fork of the last, which is how you end up with things like the COD engine or Source 2 having a direct lineage to engines from 90s quake games. So "Assassins Creed: Odyssey" may not be an ongoing service, but "Assassins Creed" is, and tech carries forward from one to the next.

> Is it really possible to build games line Cities Skylines, Subnautica, Rust, Outer Wilds, KSP, Ori... in Godot? Is this more of a long term ambition at this point, or is it possible for this kind of game to be built in Godot today?

This might be a bit silly, but when it comes to engines and tools in regards to graphical fidelity and larger projects, I like to think of it in 3 broad categories:

  * Impossible - you're not making the next Crysis in GameMaker, Construct, or RPG Maker. Period.
  * Unviable - you could technically rip out and replace 50% of jMonkeyEngine or NeoAxis with something more performant and better, if you had near-unlimited resources; except we both know it's not happening.
  * Viable - you could take an off-the-shelf engine like Unity or Unreal and with a large amount of work achieve your goals, with varying degrees of success.

Godot was strictly in the "unviable" group during its 2.X and 3.X releases, but is getting better now (new renderer, nice LOD functionality, good C# support in addition to GDScript when you don't want to program gameplay in C++) and thanks to community efforts missing functionality is also getting added (like the terrain plugins, the older of which were sometimes quite broken): https://godotengine.org/asset-library/asset It still doesn't have that big of a commercial ecosystem around it (like Unity does) and still feels a bit half baked at times and getting the same things you could get out of Unity or Unreal working would take more work for larger projects... but it feels more and more doable.

Then again, currently Godot is hands down better for smaller projects, a lot of indie games, game jam games and quick prototyping, both Unity and Unreal feel too sluggish and heavyweight for that (and Unity in particular is a mess because of the whole legacy pipeline/URP/HDRP situation, DOTS, multiple input systems, multiple UI solutions and just so much fragmentation). Not every game needs to have the scale of the ones previously listed, actually most don't and should better manage their scope and could still be wildly successful.

Overall, it feels trending upwards and I'm curious to see where Godot will be in 5-10 years. If you tried right now, you'd just have all the normal early adopter struggles.

To replace Unity? Yes, and if there is something missing, you just clone Godot and fix it yourself. I can compile the whole engine in 2 minutes. There are currently some limitations for AAA games in the rendering pipeline, see Clay John's nice talk about this, from the last Godot con[1]. For example, at the company I work for we use Godot 4 to recreate Google Earth with OSM data :)

[1] https://www.youtube.com/watch?v=MW3IFMvDTCY

> if there is something missing, you just clone Godot and fix it yourself

"just"?

Well, I mean source code is easier to read that Unreal. And Unity does not even provide source code, so you have to wait until they fix the issue for you. In addition, the Godot community is really helpful, if you provide an example project with your problem.

Unity sells source code access, it's in the "contact us for quote" category. But that's how many B2B services work, including some of the most widely used commercial game middleware.

Also large portion of first party Unity subsystems which you install through builtin package manger (I am not talking about third party asset store stuff) is available in source code form under relatively nonrestrictive Unity Companion License to anyone. Don't need the Enterprise plan or additional payments for that. For those modules you can not only read and modify the source code, but you can even openly distribute your modified versions. The biggest restriction of this license is that you can only use that source code in combination with Unity, you can't port it to different engines. And in many cases where I read it, to better understand how to correctly use the library or avoid a bug, it was quite readable.

So overall access to source code isn't the main obstacle for game developers to fix the problem in Unity, spending time fixing things and afterwards maintaining a modified version is.

I have personally had issues where I wanted to read the Unity source code but couldn't. And I suspect it wouldn't have been worth the cost in my case. There's really no substitute for shared source. Truly open source isn't necessarily better; modifying it is not often realistic, but having to pay just to read it is a big stumbling block.

Much easier than waiting for a suitable job opening at Unity, getting a job at Unity, and then just cloning Unity and fixing things yourself.

Oh yeah, haven't you heard? All open source software is intrinsically flawless because you can just fork it.

I think patching a game engine is fairly common in the industry. Games are not on a dependency update treadmill. They pick a version, and barring some external crisis, there is no reason to upgrade anything ever. If there is one bug affecting rendering or speed from the underlying engine, it can be worth finding it yourself.

I would guess medium term, short term if there's a specific roadblock that happens to get a lot of attention. My understanding is that Unity's got certain things in a more sophisticated but less elegant form, where Godot seems to want to do everything 'correctly' even if it imposes performance penalties.

Making Godot, less 'klugey' but less performant.

The trouble with maximizing Unity the way professional devs do, is that you have to know which kluges to use and which to avoid. It's somewhat impractical and the end result still isn't that awesome: some of those games you mention are hitting a performance wall even though they're in Unity.

I don't think Godot is really on par with Unity in the 3d performant space in all respects, but I think that could change quickly, and what will happen is that it'll catch up over the medium term without going totally klugey. I'd give it a couple years to get there. Right now I think you'd have to design around what's not currently performant enough.

As far as I am aware, there is nothing intrinsically preventing people using it.

I have no experience in building big titles or even commercial games, but I see no obvious "blockers" to building a large and complex 3d game. It's not like Godot itself limits you to only doing basic 2d platformers or whatever - it seems as flexible and power as unity.

Sure you might not have all the same eye candy as the very latest unreal engine or whatever, so AAA quality titles might be out, and I am not sure what the multiplayer stack is like, but it seems like the fundamentals are there and so there is nothing to hold people back.

From a cursory search it seems there are large games build in Godot. Sonic Colors: Ultimate seems to be an example.

It's the only example so far (if we consider this poor remake a "large" game). And the team behind (Blind Squirrel) didn't use Godot as-is, they had to rewrite most of the core graphics area.

It will be a while until we see AA / AAA games in Godot, it's missing too much right now to be viable in the 3D space (again, for AA/AAA. For indies, sure, why not). One day, certainly, I hope so, but not today nor tomorrow.

I think no large games use an engine as-is, they will always extend and change it in some ways to make it fit their game. Besides the question was not about AA/AAA games. Unity also did not fill that segment. The question was whether Godot will be able to fill the space Unity has. And I don't think it can currently. But with more development it definitely could. The last time I used unity I was very appalled by how bad it actually was, I admit this is something like 5 years ago but I doubt it has changed.

Reply on news.ycombinator.com