Hacker News .hnnew | past | comments | ask | show | jobs | submitlogin

I'm no game developer, but I think if nothing else, Cryengine/lumberyard/open 3D would be far superior in terms of visuals than the alternatives. I'd assume the code as a whole is clunkier and more bloated, but also more "battle hardened" than most FOSS projects too.

Godot's 3D support seems promising, but at a very different level than the "big" engines. Not sure I'd want to pick it up for a serious project just yet. The other options like Ogre seem ... kind of bad, if their industry track record is to go by. Ogre in particular seems to have had a brief golden era, where a few commercial games used it, but in every case I know of, sequels to those games abandoned Ogre for unity or unreal. Even the open source games/frameworks I know of that used it like OpenMW abandoned it.

If I was really trying to make a commercial indie game with a FOSS engine, this seems like a good candidate, even considering the questionable Amazon ties... to me, it strikes me as more "open source Cryengine" in the first place anyway, in the same way OpenSolaris indirectly open sourced a lot of older UNIX utilities in addition to Sun's novel code.

(Of course if I was only making a hobby project I'd probably stick to Godot, but I'm imagining the perspective of a small team seriously trying to make a commercial game)



> Godot's 3D support seems promising, but at a very different level than the "big" engines

While this is true, "big" games require a small legion of 3D artists. Very few indies will ever come close to maxing out Godot's 3D abilities.

If you "need" a big engine you also need a multi-million dollar budget.


Yeah, plus engines with "AAA" graphics like Unreal always look the same unless you have that legion of technical artists to build up the lighting model and set up high quality maps and stuff. The defaults look good, but in a particular way that makes it stand out as a default Unreal engine project.


With respect, that's not true. I did a two week project with one really talented artist and a lot of off the shelf assets and we made something pretty cool and distinctive in Unreal.


> one really talented artist

Ok, a legion of mediocre technical artists, or one really talented one :)

Edit: though I'd be curious to see if I'd recognise it as an Unreal title without pre-knowledge, of course :)


I find it easier to identify Unity games by their lighting, but for either engine the camera is another thing that tends to give it away to me. And even when it's a AAA game with access to legions of artists and programmers, if it's not the lighting or the camera or some gameplay element like jumping, there's often a commonality in bugs. "Freaking Unreal!" is something I've said several times this year across several games. It's nice to play games that use their own custom engine, there's still a lot of them. Though it might be time to retire some (ahem, Halo...) and get on the Unreal train anyway.


Yeah good points, or also games that include elements that don't really make sense, until you realise they're built in features of the engine that someone probably just wanted to play with. Example, I've been playing Shin Megami Tensei V recently, and the protagonist, shortly after the beginning of the story, has gloriously flamboyant hair sprout from his alter ego's head, and it's never explained (or at least, it hasn't been explained or referenced by characters so far, and I'm about halfway through). It makes no narrative sense - then you realise it's an Unreal game, and one of the artists probably just wanted to play with the Unreal hair rendering and simulation tech and came up with something ridiculous enough that it stuck.


I don't disagree visuals may be better (where better is likely "more configurable" or "more performant" in specific cases), but in many ways your art team and shader team matters FAR more than the underlying engine these days.

If you are a small indie team, you'd do well to pick and engine that has a strong community, momentum, and perhaps most importantly - one that you're willing and able to dive into the internals of to fix/debug things when they go wrong.


I mostly wanted to repeat slimsag's reply, that these days a game's visuals are largely dominated by the talent and time of the art team, not so much the underlying engine.

The recently released Sonic Colors remake should be mentioned: https://www.youtube.com/watch?v=D-RnhgZCqn4 (and on the latest Xbox, runs at 4k@60hz https://www.youtube.com/watch?v=GsMAIXVavI4) Apart from maybe using too much bloom, the visuals are great. Using a different engine wouldn't magically make them better, let alone far superior. At best different engines might give different tradeoffs to allow more efficient use of artist time (e.g. less rework like lowering poly counts due to better performance/pipeline, or having certain assets or effect shaders pre-built, or being able to have "more" per frame, etc.).

I brought it up because surprisingly they used Godot 3 for the graphics backend. Well, they seem to have modified it to some extent and have the original game's code in there, but apparently not to such a degree that vanilla Godot couldn't open up scenes. Even though the lead Godot dev doesn't even think v3 is really appropriate for such a game due to its limitations (the "just around the corner" v4 should be more suitable, though), and they've had some backlash with bugs or poor performance (especially on the Switch version) that have necessitated patches, I still think it counts. I remember being excited for v3 in the past, because it brought Godot up to par with physically based rendering like everyone else. It can still fall behind other engines in a lot of other ways (stability, performance, ease of platform porting, pre-built things...) though a lot of indies seem to find it winning in some ways too (like ease of development).

I do agree with you though that the Amazon taint shouldn't really be enough to sink Open 3D. Still, I think it's going to take a few years for it to find its place in the current ecosystem. Though it's a very real possibility that place might be irrelevance.


Ogre had its golden period at the time when game engines were becoming so complex that writing a complete engine from scratch was definitely becoming too expensive for small teams to take on and the major engines at that time still had very high price tags attached (e.g. something between 500k $ and 1M $ for UE2 or UE3 for a single title). Turn-key engines were only slowly establishing themselves (Torque had a pretty bad reputation, Unity was still in its infancy...).

In this situation, the a reasonable thing for many small studios was to cobble something together from parts that were available: bullet, Ogre, OIS etc. There was barely any out of the box tooling for these libraries and I doubt that many teams invested a lot of time to write custom editors that were better than barely workable for their immediate project.

This situation ended when Unity took over. Compared to all the half baked in house solutions, its all in one package with all the painstaking integration work was pretty attractive.


In my opinion Godot is to Unity what Unity was to Unreal a few years ago and we can see where it is now.

I may be a bit biased since we are developing one of the bigger (in terms of players not in terms of visuals) VR games made with Godot.

For example, Godot had hand tracking for the Oculus Quest, 3 months before the big two and even now with the movement to OpenXR there is already a beta that supports passthrough while I still hear my peers using Unreal complaining about being left out over Unity devs


Also consider the track record of CryEngine: Star Citizen which will never ship and MechWarrior Online, and PGI switched to Unreal after that for MW5.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: