💾 Archived View for dioskouroi.xyz › thread › 29426656 captured on 2021-12-04 at 18:04:22. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
________________________________________________________________________________
I would encourage anyone looking for an open source game engine to first consider Godot, Ogre3D, Panda3D, etc.
Rebranded as "Open 3D" and backed by the linux foundation, O3DE appears to be little more than an open sourced version of Amazon's Lumberyard (which was itself just a purchased copy of CryEngine.)
Ultimately this came from the same Amazon that had this clause in employment contracts of people NOT working in game-related parts of Amazon:
"I grant to Amazon a royalty free, worldwide, fully paid-up, perpetual, transferrable license to any and all of my intellectual property rights associated with the Personal Game and my Personal Game development."
From the same Amazon Game Studios that has failed to release several titles with YEARS of development in them including: Breakaway, Crucible, Lord of the Rings MMO, Intensity, Nova, etc.
The same Amazon Game Studios whose "New World" MMO had health and gold client-side, allowed inserting arbitrary HTML+JS code into the game chat that would run on other's computers, could kick players from the game, etc.
I don't doubt that this is open source by definition. I don't doubt that the Linux Foundation has allowed this project to live under its umbrella. But the way this came about is a far cry from being in the spirit of open source in my opinion, and rebranding it as "Open 3D" seems just a brilliant marketing trick.
In the best case scenario, Amazon's intentions are to convince the FOSS community to develop their engine to subsidize costs long-term while maintaining ownership of the project broadly, and having full control/ownership of the new "Open3D Foundation" that they can use readily for marketing[0] similar how they do to the Rust foundation[1] to hire talent.
It might not be the worst thing in the world, but seriously, just use any of the other open source engines out there. Godot is great.
[0]
https://aws.amazon.com/blogs/gametech/open-3d-engine/
[1]
https://news.ycombinator.com/item?id=28513130
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.
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.
This is just pointless drama. The fact is the code was open sourced under Apache or MIT and that's a great thing for everyone.
You're free to fork the code, remove all the AWS code and build your own community around it without ever caring about Amazon.
For what it's worth, as a former Amazonian who wanted to release games, the games clause did prevent me from attempting to create a commercial game, but it didn't stop me from working on games for fun.
Why? It looks like an open contract for me, because price is an essential part of the contract. A contract with 0 price for all future labor is just slavery. Slavery is forbidden by law. Thus, you can make a game and then ask for reasonable compensation for your labor, e.g. $1000 per line of code.
Since you're not forced to contribute the changes back to their repo, or even tell anyone that you made any changes, the slavery metaphor makes no sense to me.
> Ultimately this came from the same Amazon that had this clause in employment contracts of people NOT working in game-related parts of Amazon:
> > "I grant to Amazon a royalty free, worldwide, fully paid-up, perpetual, transferrable license to any and all of my intellectual property rights associated with the Personal Game and my Personal Game development."
That seems ... sucky, but what does that have to do with O3DE? AFAICT, the Apache 2.0 license doesn't force such employment contracts upon users.
> From the same Amazon Game Studios that has failed to release several titles with YEARS of development in them including: Breakaway, Crucible, Lord of the Rings MMO, Intensity, Nova, etc.
Are these failures due to using a particular game engine?
> The same Amazon Game Studios whose "New World" MMO had health and gold client-side, allowed inserting arbitrary HTML+JS code into the game chat that would run on other's computers, could kick players from the game, etc.
Are these failures due to the game engine?
I get it, you hate Amazon. Fine. So what?
> I don't doubt that this is open source by definition. I don't doubt that the Linux Foundation has allowed this project to live under its umbrella. But the way this came about is a far cry from being in the spirit of open source in my opinion, and rebranding it as "Open 3D" seems just a brilliant marketing trick.
> In the best case scenario, Amazon's intentions are to convince the FOSS community to develop their engine to subsidize costs long-term while maintaining ownership of the project broadly, and having full control/ownership of the new "Open3D Foundation" that they can use readily for marketing[0] similar how they do to the Rust foundation[1] to hire talent.
My guess is that they figured it doesn't make economic sense to develop and maintain their own engine vs using an off the shelf existing one like Unreal or Unity. So instead of just writing it off they open sourced it. In the best case it'll become a successful open source project like the Linux kernel or Blender, where the industry as a whole can save money by collaborating on a common open source engine. In the worst case it'll be a 'throw it over the wall' open source dump that will never acquire a development community and will thus eventually fade away. Time will tell.
The employment contract point I made calls into question whether or not Amazon understands indie gamedevs, and by extension whether O3DE (as both software and a community) is developed for indie gamedevs.
The game failures I highlighted call into question whether or not Amazon Game Studios produces high quality software, and by extension whether or not O3DE is likely to be high quality.
Just look at the contributors to O3DE and search for "AMZN", nearly every contributor is an Amazon employee[0].
Your argument seems to be that as long as the code is open source, the rest doesn't matter. It does.
My intent isn't to shit on people's work, but rather to call out that to me this feels far from some "open" initiative like Blender, GIMP, the Linux Kernel, etc. It feels more like how Android is "open source".
[0]
https://github.com/o3de/o3de/graphs/contributors
Some OSS advocates get too caught up in "community" and feelings. At the end of the day OSS is only about the licence. It's just about code ownership. Everything else is noise.
As long as it's an OSS license it's good to go.
Also, Blender used to be a commercial, closed source project (a very long time ago). Look how it's grown.
As long as the code does what you want, you don't hope to receive any advice on how to do things, you expect no help in debugging the issues you encounter, and you don't expect to collaborate with others building on top of the same platform - then yep, community and momentum doesn't matter.
Those are all independent of license considerations.
For example, Unreal engine ticks all those boxes. But it's not OSS.
> Are these failures due to the game engine?
That's usually hard to say because IME the engine is _always_ blamed first in a dysfunctional team :)
But from my experience with Lumberyard (around 2016), it's definitely one of the messier legacy codebases I've seen. But I don't know how much code from this era actually still exists (the team at Amazon was just in the middle of a big rewrite to implement a traditional Unity-style workflow/object model and and break systems out into optional modules).
(also I can't shake the feeling that's it's actually Denis Dyack pulling the strings in that whole O3DE endeavour - at least he seems to be the public face of the project, which doesn't inspire much confidence that this will be an actually community-governed project).
_Are these failures due to the game engine?_
In the case of users being able to insert HTML+JS in to the in-game chat to kick other players, yes. The game engine should be authenticating the source of API calls.
In that case it's more a question of why that heck a chat UI inside a game cares about HTML and JS in the first place. Someone clearly overdesigned something here.
There was probably a "chat needs to support emojis" in the requirements list and things escalated from there until the "easiest" solution was a webview widget.
> But the way this came about is a far cry
Several, in fact! ;)
Dropping by to second Godot as a good choice for game development in 2021:
I'd say that its advantages are:
- small download size, easy to get started with - has a pretty shallow learning curve - decent documentation and tutorials: https://docs.godotengine.org/en/stable/ - their GDScript language is pretty reasonable: https://docs.godotengine.org/en/stable/getting_started/scripting/gdscript/gdscript_basics.html - they also support C# (even though less convenient than Unity), the performance of which is better - they also support C++, if need be (though probably a bit less convenient than in Unreal) - really good for 2D games, more convenient than Unity - unlike certain engines (Unity, which deprecated HLAPI and LLAPI), it seems feasible for multiplayer: https://docs.godotengine.org/en/stable/tutorials/networking/index.html - the node based approach to scenes composes really well, not the kind of mess that Unity's prefab system is
Its current downsides are:
- current stable versions are underwhelming for 3D games (and no functionality like automatic LOD in the engine, it's really nice in Unity) - a lot of the development is focused on the upcoming Godot 4 release, which isn't quite ready for being a stable release yet (e.g. wait for using it for 3D in larger projects) - GDScript is nice to get started with, but the performance can be underwhelming (for certain types of games), it has similar fragmentation to how Unity used to have with C#, Boo and ECMAScript - if you use GDScript, some patterns might be harder than others to implement, e.g. having game global services and singletons (e.g. like IaC) that handle common logic regardless of what scene is loaded - if you use GDScript, the ecosystem (e.g. package management) that's available to you is severely limited, you won't be parsing YAML or formats like that anytime soon, nor will you be talking with SOAP/gRPC APIs if the need ever arises, nor will you be sending stuff to RabbitMQ/Kafka or anything else, which in general purpose languages would be a library import (not a dealbreaker, just something to consider) - the asset store is still new, no realistic chances of being able to earn money from submitting packages there yet: https://godotengine.org/asset-library/asset (it cannot compete with the asset store of Unity) - their node based model can seem cumbersome and inconvenient for some, where each node can only have a single script: contrast that with Unity where you could have separate components for the same game object, e.g. HealthAndManaContainer, GenericEnemyAIController, SpellCastingAIController, PathfindingController, EnemyVoiceController, ... (just a random example i thought of, thinking in terms of nodes instead of having the separation between objects/behaviour takes some getting used to) - there is lots of hype surrounding the engine, but it's still relatively new, expect fewer resources than the likes of Unity have and more outdated ones because of the pace it's moving ahead at - platform support is falling behind the proprietary alternatives in regards to consoles, due to the console publishing landscape being an anti-developer dumpster fire due to the large corporations wanting to protect their IP
Depending on what you want to do, those may or may not be relevant concerns.
Overall, though, it's a lovely engine and i see a bright future ahead of it.
I just wish that other open source engines also got more love, for example, jMonkeyEngine:
Seeing how underfunded that one is made me throw some money in its direction, too (since there aren't any other 3D Java game engines with high level tooling):
https://opencollective.com/jmonkeyengine
Personally, i'm torn. For commercial projects or industry employment prospects, i'd just go with Unity. The other engines are probably good too, especially for smaller indie projects that you develop for your own enjoyment, but other than that i'd maybe revisit Godot in about 5 years, to see how far it has progressed, rather than take the long way round and experience lots of breakages along the way (seeing as how Unity is past that, because they've broken everything that can be broken, from the rendering, to input systems, to networking, to ECS).
Of course, if i wanted to actually be happy, i'd also look at Xenko/Stride, which was extremely promising, yet also half baked because it seems like the financial backing behind the project just died down and therefore it ever getting competitive with the larger engines just wasn't meant to be:
AFAIK one other advantage of Godot is that it seems to be one of the few to have at least basic multi language support
To solve some of these challenges, we introduced the Lumberyard game engine in 2016. Lumberyard provided a completely free (no royalties or seat licenses), source-available, real-time 3D development engine that made it possible to build, deploy, and scale quickly with cloud integrations. Over the past 5 years, we continued evolving the product for our customers.
...That’s why the Linux Foundation has announced the Open 3D Foundation, with AWS seeding the foundation with the Open 3D Engine (O3DE). O3DE is a AAA-capable, cross-platform open source game engine. As part of an open source community, O3DE can expand 3D development for games and simulations by providing all the tools that developers need to bring their real-time 3D environments to life.
ie. This is lumberyard, which is "Amazon Lumberyard is a now superseded freeware cross-platform game engine developed by Amazon and based on CryEngine (initially released in 2002), ..."
https://aws.amazon.com/blogs/gametech/open-3d-engine/
...but, love it or not, the source is Apache 2.0 (
), so there's sure to be some stuff you can grab there to use in other things.
It would seem, that Amazon "donated" the Lumberyard/CryTec Engine to the Open 3D foundation, which is a newly created subsidiary of the Linux foundation.
It's available under very permissive licenses - Apache 2.0 or MIT, whichever you prefer - no strings attached.
With Amazon being just one of 20 different founding members, and under the stewardship of the Linux foundation, it might just be, that this project is sufficiently independent from AWS now, to stand on it's own.
Does anyone know if the foundation does grant any special "founding member" rights to AWS? Could AWS theoretically still pull some crazy stuff, like Microsoft recently did with the .NET foundation?
Despite ~20 members in the Open3D Foundation, it's nearly impossible to find any impactful contributor that is not an Amazon employee[0]
[0]
https://github.com/o3de/o3de/graphs/contributors
That does not seem particularly unusual to me?
This is a piece of formerly proprietary software, that is now being made open source. So of course almost all contributors would be employees of the former owner of the proprietary version of the software.
Just like for example Doom was still 100% made by id software, at the moment of it becoming open source.
How this evolves/develops remains to be seen, of course. But as of right now, I'd say that's to be expected.
>Does anyone know if the foundation does grant any special "founding member" rights to AWS? Could AWS theoretically still pull some crazy stuff, like Microsoft recently did with the .NET foundation?
Why does it matter ? It's Apache 2.0, they can't pin you for using it on patents or copyright. For a 3D engine it should be more realistic to fork if you don't agree with the direction.
> Could AWS theoretically still pull some crazy stuff
They could but they won't. In my experience Amazon doesn't care about anything except wanting people to use their infrastructure. While they haven't shown Google levels of goodwill towards OSS they also have never shown MS levels of contempt.
Well, Microsoft is contractually the ONLY founding member of their foundation, and the statutes define that the executive officer has to come from the founding member, and that every decision the foundation makes has to be approved by the executive officer. That setup gives Microsoft 100% control over the foundation.
So, unless this new foundation's statutes grant special privileges to AWS - they can't possibly exert the same level of control over it, that Microsoft has over the .NET foundation.
If those 20 founding members all have some voting and veto power, then AWS can't make unilateral decisions.
That's what my question was about - how is the foundation set up, and how much power does Amazon have over it? If the foundation is sufficiently independent from AWS, then we are golden.
What are some properties of this that differentiate it from other open source 3D engines (or closed ones)? Platform and language support support also seems absent from web site or GitHub readme.
I'm wondering the same, particularly how it compares to Blender and Houdini.
It seemed very strange. Many big partners, but social media accounts less than a year old.
Turns out, it is the evolution/opensourcing of AWS Lumberyard. Wikipedia cites <
https://venturebeat.com/2021/07/06/amazons-lumberyard-become...
discussion when it was originally announced 4 months ago:
https://news.ycombinator.com/item?id=27751358
How does it compare with Unreal Engine or Unity?
Godot is the open-source equivalent, and for 2D is absolutely the best engine I've used out of the UE, Unity and Godot. 3D is having big improvements coming in 4.0. Worth checking out:
https://github.com/godotengine/godot
"the open-source equivalent" to what? How does this answer the question it responds to?
Amazon did finally release New World this fall, so that brings the grand total of released games built with Lumberyard to... three.