I'm keeping my eyes on O3DE as Godot's designs aren't conducive to high performance operations, or lots of actors (at least, I haven't had a need for a lot of actors, but I do find myself needing to use Observers). But in terms of trivial design, Godot is much closer to Unity, and in a lot of ways, its Node system gives it an edge for extendibility and ease of use.
Godot is optimized for easy of use and common game dev problems.
It should be able to handle several 10s of 1000s of actors without a hiccup, but once you get into the millions, you may need to write some of your own modules.
Luckily godot’s codebase is just about as pleasant as c++ can be for a project as complex as a multi platform game engine with multiple rendering backends.
Did Godot finally migrate from c++03? I know it's pretty subjective but c++03 doesn't make for a super pleasant codebase imo. Doesn't detract from your point, I'm just wondering if they completed the switch to a more recent standard. I remember they were planning on doing it
O3DE is based on Amazon Lumberyard which in turn is based on the industry-proven CryEngine 5 from Crytek. The codebase has been modernized to C++17 and the parallel rendering engine "Atom" supports Vulkan, DirectX 12, and real-time ray tracing.
"Industry-proven" isn't the endorsement that you think it is - I've used engines that have shipped games that have made hundreds of millions of dollars, and you couldn't pay me enough to use them again.
Just because a game ships doesn't mean that the underlying tech is good or pleasant to work with - I would say the majority of games are shipped not via good code but via sheer force of will.
It's strange that there's a AAA-level FOSS game engine that most of the gamedev community is seemingly just sleeping on. Wonder what glaring downside this engine has that's keeping everyone away.
I worked with it quite a bit on my last job, and for me it's really the quality that is not there yet. One example is prefabs: They worked just fine in Lumberyard years ago. The first few releases of O3DE broke them (that was in 2021 I believe), because like almost every other subsystem, Amazon wanted to rewrite it from scratch. Seems like they released the new version in the latest release, but as you can see in this video from Gamesfromscratch, it still doesn't work: https://www.youtube.com/watch?v=5PAuR-pEz1w
Also, they are not great at marketing. For example, in the latest release notes, the main headline talking point is robotics, and not games.
I think the tech is actually good, I prefer both the component system and ScriptCanvas over Unreals component mess and Blueprints. It just needs much more polish. And a big game company trying to actually make a game.
If you ever had to work with Lumberyard you would understand why ;)
The whole thing is a massively big hairball of C++ code that was started in the mid-90's by Crytek as CryEngine and has since gone through multiple hands, all with different opinions on how a game engine should be designed leading to various rewrite attempts. Nothing good can come out of such a situation, this is actually a rare case where starting from scratch would have made more sense.
Amazon first wanted to make a game, so they bought Double Helix, a game company. With virtually unlimited budget, they started making a game, until a correction came from high up top that Amazon should actually make an engine, not a game, so that they could collect royalties from other people making games.
Double Helix says fine, we can make one in 5-6 years. The plan travels slowly across Amazon, until it hits one particular individual that doesn't like it. Executives then start to look for an engine. First they talk to Unity, which was surprisingly receptive to the idea, but not much happened in the end (should be around 2014, around the time John Riccitiello became CEO). Cue in Crytek and Amazon becoming aware of their financial troubles, and the rest is history.
The press release hits, and that's how Double Helix learns of what's going on. Now they are not only supposed to make an engine, but merge the older version of CryEngine as well. That went as well as you would expect. It took them 2 years just to make something workable.
O3DE came to being once Amazon realized Lumberyard didn't have any mind-share at all. Nearly no part of the CryEngine code base is left, from my understanding. A lot of the original plan from Double Helix finally materialized in form of Atom, and other gems.
Though CryEngine was a major hindrance, and some of its effects can still be felt, O3DE is now its own thing. Still leashed to Amazon mind you, and all their bright minded executives. But at least all of the CryEngine code has been ~~purged~~ removed.
Having said that, it basically has nothing in common with the mid-90's code, either in details nor design. It's dysfunction is almost entirely modern by now.
Essentially, while CryEngine was a detour and got us where we are more slowly, it's ended up basically where they were aiming for in the original start-from-scratch scenario.
There is an argument that the more direct approach may have lead to less turnover and a more coherent engine. But IMO, the dysfunction is more likely the result of systemic problems at Amazon organizationally.
I’ve only used CryEngine and back then it was a bit of a mess to use in comparison to the better organised Unreal Engine. It was obviously extremely capable but it had a learning cliff rather than curve. I’m not sure Lumberyard improved on that reputation.
Free doesn’t mean pleasant to use. CryEngine/Lumberyard are quite high friction engines, without much in the way of learning resources and very little high level ergonomics.
Reminiscent of the animation industry and OpenToonz. Marketing as well as grass roots advocacy of new and shiny things makes Toonz a bit obscure unless you're a little familiar with the industry.
New world was created on Lumberyard, and it have excellent graphics and sound desinge but overall floped cause of no endgame content and tons of game breaking bugs (plus small max server populations).
Not sure about which one of (sound/graphics) are more dependend on engine.
So, to say Lumberyard is a fork of Cryengine is actually missing some important details.
Basically, Amazon started building a new engine and plugin architecture. After acquiring the CryEngine code, it was pretty heavily refactored to fit into the new LY design and plugin (gem) architecture.
Overtime they had slowly replaced gems that were originally of Cry design, with LY's origin design untill finally the last major piece of Cry was it's renderer.
With the release of O3DE, it finally includes their own new renderer Atom, finishing their transition off of CryTech developed system.
So, while it's strictly true that LY is a CryEngine fork. And I don't think CryEngine 5 code was ever imported. It's really for the most part irrelevant, as it exists as an almost entirely original piece of technology now that has almost entirely lost it's Cryengine heritage by now.
I was thinking as well why nobody talks about his. I think the entire history of the engine is interesting. I think Cryengine really fall off and does not perform that well for modern games. I played Hunt Showdown, it look quite OK but that THAT good and it rather performs badly, I think trees is what really causes massive performance. I also played Sniper Ghost Warrior 3 (I think) also use Cryengine and it seemed it performed better and also looked better in a way even though I love Hunt Showdowns art direction, something about Ghost Warrior make it look "better". Anyway there was a part of a level with a lot of trees and the performance really noticeably went down.
But Cryengine to this day is close source so I am really curious what kind of insane deal Amazon had with Crytek that they could build their Lumberyard engine based on Cryengine and later open source it and rename it o3de. From what I read they mainly just put lots of Amazon cloud stuff integrations into it rather then focusing on the actual 3d rendering parts of the engine.
This seems like a pretty decent engine that is open source that is something really special, yet nobody does anything with it, nobody talks about it. They do not no showcase that shows anything known or good for some reason on the site.
New World uses the engine and I did not even saw it mentioned. Should that not be the big showcase? I mean the game seems not super good and it also not looks very impressive but still, at least its a major title that is build with it.
> From what I read they mainly just put lots of Amazon cloud stuff integrations into it rather then focusing on the actual 3d rendering parts of the engine
Feel free to see my other post, it's a misunderstanding to think Amazon hasn't focused on the other parts of their engine, including the renderer.
It was Cryengine 2 when Amazon bought the rights? Cryengine 3 is used in Wolcen for example, it seems some devs still chose Cryengine 3 over o3de, at least the Wolcen devs did. I would be curious what the differences are by now between o2de engine and the latest Cryengine version because there is quite some time past after "the split".
It's a not-terrible solution if you ship lots of dependencies which you don't want to install as available system-wide. And at some number of them, it's easier to ship your deps than to ensure every version of the system is compatible enough.
They place everything under /opt/OD3E/<version>, which is fine for support files but also place their binaries there rather than installing under /usr/bin or even /opt/OD3E/bin.
What I find weird about it is that you don't typically install multiple versions of the same software globally that way, if you have a .deb package you would have one version with its binaries going in /usr/bin, libs in /usr/lib, headers in /usr/include, and support files in /usr/share. Or supporting XDG so you can control where those files go if you want multiple versions installed, or if you want to support multiple versions directly.
It's just an odd install path for a Debian package to use, I don't think I've seen it before.
In game dev updating the engine is not an easy task. You could easily end up supporting multiple games on slightly different versions and need them all installed side by side. Unreal and Unity expect side by side installs as well. As for the exact implementation, I can't really speak to that.
I’m guessing it is because devs might need to have one version of the engine installed per project.
Game devs are probably more interested in having everyone on the release they plan to ship than in continuously updating to the newest version of each dependency.
Apt doesn't really support multiple versions of the same software installed side by side. Other package managers like Conan and Nix do.
If your software needs to support multiple versions installed in the same user space it doesn't make sense to support package managers not designed for that use case.
It's odd to me that when the whole Unity fiasco happened, everyone was basically looking at either Godot or Unreal, but pretty much nobody mentioned or cared for something like O3DE, though maybe the plentiful comments in regards to ease of use also had something to deal with that.
Unless people just care about the options that are popular enough to warrant their attention and the features that they provide, whereas the licensing is actually a boon, rather than the main factor, given that Unreal also did some slight price increases a while later as well: https://www.unreal-university.blog/post/unreal-engine-5-pric...
Either way, it's still nice to have lots of options available regardless of the licensing details (though this kind of does fragment developers among bunches of different projects), be it Godot, O3DE, Stride, Unreal or even something like jMonkeyEngine (one of the rare Java engines/editors with 3D) or NeoAxis (that one had a cool voxel LOD solution, but performance on AMD hardware was bad).
> though maybe the plentiful comments in regards to ease of use also had something to deal with that.
It's an engine with almost no community that's based on an engine that's notoriously difficult to use.
It would not surprise me if O3DE was more capable than Godot but choosing an engine is more about matching your team to the engine, and it feels like most indie groups will have a hard time with O3DE.
Important to note I'm only relaying what I've read, I haven't looked too closely at it myself. Also, development looks pretty active so there's definitely potential for things to change.
I really, really want O3DE to be successful. I have looked into it some. Right now it just isn't something your average small Unity team could pick up and use. A larger studio with a good established dev team could maybe use it.
The documentation and tooling for O3DE needs a lot of work compared to Godot. The community needs to grow, but in order to do that, they need to improve the documentation and the tooling.
In the end, I want to see both Godot and O3DE succeed, I support both projects, and I have tried to bring O3DE into these discussions. But if I had the time to start a game today, as an indie dev, I would probably choose Godot. But both engines have a lot to offer!
Finally- I really think the O3DE devs (mostly Amazon, and folks complain about Amazon not contributing to Open Source....) are aware of its weaknesses and are trying their best to refactor the code and make improvements to tooling and documentation to make it easier to use. I think it is going to take some time, and I hope they get the support from the community and continued support from Amazon to see it bare fruit. I want to thank Amazon for their many contributions to Open Source, I don't agree with everything the company does, but I disagree strongly with the idea that they aren't contributing anything back.
The Apache 2 license is incompatible with GPL2, you cannot have code under those two licenses in the same project. So they dual licenses it under MIT, which is compatible with GPL2.
The Rust project has the same problem, it's also dual-licensed under Apache2 + MIT.
You want Apache 2 because of the explicit patent grant, but at the same time you also want to allow GPL2 projects to use your code.
MPL2 is great for something like this. It's not Apache 2 or MIT, but is compatible with them (if that's how you wished to license your stuff, for example, or if you wished to use libraries that are)—as well as being compatible with GPLv2 by default.
In practice, the fact that MPL2 is not as permissive as Apache 2 or MIT and has copyleft-like reciprocal terms is not a problem, because it's a file-based license, and few (if any) developers tend to be interested in changing the source files for the upstream project, and those who are are usually people doing so because they're in the process of trying to submit a fix upstream, anyway. For the fraction of a fraction of a minority of folks for whom it still would be a problem, it's as simple as the upstream project either declaring Apache 2 as a compatible Secondary License or just saying that they won't enforce MPL2's reciprocal clauses against downstream folks who are using the project in a way that is permitted by Apache 2.
MPL2 is an extremely underused and underappreciated license.
In my experience, people do hack game engines all the time for game specific optimizations, fixes and special features. At least in the bigger AA/AAA games I've seen. We tried to sell our plugin as binary only (C++), but basically everybody wanted the source code to hack and extend it. So people wouldn't be happy with MPL.
I agree for other things, e.g. webdev, I never had to hack Django or Vue.js.
The game industry is notorious for using, but not contributing back to open source. I don't want to know how often the same bug in recast/detour has been fix in different games, and never upstreamed.
I agree with this mostly. I would love to see the MPL2 used more often instead of the GPLs. I think it is a superior license in almost every way. I also love the Apache and MIT licenses for their own reasons, I don't really see MPL as a replacement for Apache/MIT, more as a replacement for the GPL.
Not exactly what I was going for with my initial remarks.
> I don't really see MPL as a replacement for Apache/MIT, more as a replacement for the GPL
That doesn't really make sense. GPL is a hard copyleft license, and MPL2 is not. The latter can be seen as a replacement for the former perhaps in the sense that a person who is being charged $20+/mo for streaming video might like to see their provider to offer a $0 "replacement" instead—i.e. a change clearly to the benefit of one party with regard to narrowly delivering something it sees as desirable, to the detriment of the other party (or more accurately: without regard to the benefit or detriment to the other).
MPL2 is a great alternative for the use cases I described—where the constraints/conditions of the license are agreeable to both upstream and downstream due to the way it matches how they already interact in practice (and expect to continue interacting).
> I would love to see the MPL2 used more often instead of the GPLs
I don't see GPL as overused at all in 2023. If anything, it, too, is underused.
MPL2 and GPLv2/GPLv3/LGPL/AGPL are underused relative to the fairly new tendency to reflexively reach for e.g. the MIT License and then get stung by the consequences of doing so, resulting in formerly libre codebases getting locked down in future revisions under a regressive, non-FOSS, shared source license (or fully proprietary), when the reality is that e.g. GPL would have better suited the project from the beginning and wouldn't have led to the circumstances that ended with the owner pulling back from FOSS entirely.
The reason I avoided O3DE is because its based on Amazon Lumberyard which itself was based on CryEngine which are notoriously rigid with the shipped tools. If you look at the development struggles even Amazon's own internal teams had using Lumberyard it doesn't really inspire confidence.
I think open sourcing it was the right decision though, and I hope it will only improve from here.
No one wants to use O3DE because the installation process is a pain. Isn't simple as Unity or Unreal. Plus the installation process takes a lot of times. Outside of that the asset pipeline is another pain, not sure if they improved that. O3DE is lumberyard engine from amazon that is a fork of cryengine.
It takes up a ton of space, and takes forever to install, which would be fine if it were as polished as Unity or Unreal, but in practice the engine seems to have problems out of the box.
O3DE seems to live in its own bubble. GameFromScratch covers it from time to time and has always had trouble getting the advertised features to work, not to mention they completely blew the first impression because when it was announced there was no installer and that took many many months to be done (just to leave a half-functional engine until they fixed it later on).
Also it just fails every vibe check: AI art in the homepage and they had some drama by publishing a quote saying that they were "the only real open source game engine"[1] (which has been retracted since)
At first glance, it does not appear to have support for game consoles. I'd wager that the kind of teams that are looking at making heavier or advanced 3D games are more likely to also need to take that into consideration.
I found a rip of the 3D model and an archived page for the beach demo, but the actual browser plugin was never archived and I don't want to setup decade-old build systems for obsolete browser plugins. How I miss those days...
In the big samples.zip [1] there's an "o3d-webgl" folder which seems to be an API bridge between the two worlds. The examples pointing to these scripts work in a modern browser without requiring the plugin.
It's funny, there's a comment on the video from 14 years ago that says, "Wow, all the demos look a LOT like Unreal Engine 3, although it runs somewhat smoother". It's funny how some technologies die out and others survive.
Oh, that reminds me of the Epic Citadel UE3 demo for Android/iOS, ported to asm.js and WebGL (https://www.youtube.com/watch?v=MyAcKgr6mZU)... funny how that turned out, mobile gaming turned into a cesspool of pay-to-win, and WebGL gaming never replaced desktop apps, and the demo doesn't even load anymore (if you try archive.org, it fails to fetch resources over JS XHR). Books last centuries, but digital history can die in merely a decade.
