Open 3D Engine: Amazon’s Old Clothes Or A Game Engine To Truly Get Excited About?

Open 3D Engine editor with Amazon Shader Language file and asset from the game Deadhaus Sonata open. (Credit: O3DE project)

Recently Amazon announced that they would be open sourcing the 3D engine and related behind their Amazon Lumberyard game tooling effort. As Lumberyard is based on CryEngine 3.8  (~2015 vintage), this raises the question of whether this new open source engine – creatively named Open 3D Engine (O3DE) – is an open source version of a CryTek engine, and what this brings to those of us who like to tinker with 2D, 3D games and similar.

When reading through the marketing materials, one might be forgiven for thinking that O3DE is the best thing since sliced 3D bread, and is Amazon’s benevolent gift to the unwashed masses to free them from the chains imposed on them by proprietary engines like Unity and Unreal Engine. A closer look reveals however that O3DE is Lumberyard, but with many parts of Lumberyard replaced, including the renderer still in the process of being rewritten from the old CryEngine code.

What Makes a Good Game Engine?

My own game development attempts started with the Half Life engine and the Valve Hammer editor, as well as the Doom map editor. This meant that some expectations were set before encountering today’s game engines and their tools. The development experience with the Hammer editor in the late 1990s was pretty much WYSIWYG, and when I was just getting started with Unreal Engine 4 (UE4) a number of years back this was pretty much the same experience, making it relatively easy to hit the ground running.

Installing UE4 takes a few steps: after installing the Epic launcher using its installer and logging in with an Epic Games account, it takes a few clicks to install any of a range of available versions of UE4. Afterwards a wizard allows for the creation of a new game project using an optional template. This then creates a dedicated editor for the project that is also the game, so you can edit it while having a live preview window you can interact with.

To build the game, you press a single button and out rolls a game for any of the wide range of supported target platforms.  At its core, this experience allows for the most essential feature of a good game engine: the ability to create games without having to pick a fight with the engine’s tools or build system. Many users are likely to be graphics artists or similar who have little interest in the internals of the tools which they’re using.

Here the UE4 experience is relatively painless: using the Blueprint object system you can wire up complicated games and game logic in a graphical editor, with no writing of code involved, although C++-based development is possible for various levels of customization.

If we take this gradated system of complexity as the gold standard for what makes a good game engine and associated tooling, how do O3DE and its primary competition (Unreal Engine, Godot and Unity) compare? At first glance, they seem rather similar, being all written in C++. The most notable difference is probably in the languages they support for extending the engine’s features.

Here Unity supports C# for its scripting API, Godot offers GDScript (Python-like) as well as C# and C++. Unreal Engine is extended using C++, as is O3DE. All well and good then, but what is using them like?

The Quick Start

Before we can install the development tools on our platform of choice, we need to check the system requirements. For O3DE these are:

  • Windows 10 1809 or higher, or
  • Ubuntu 20.04 or higher.

This contrasts with UE4’s minimum requirements of Windows 7 or higher, or MacOS 10.9 (Mavericks) or higher, both of which offer a binary installer. For Linux the engine has to be built from source, but should work with Ubuntu 16.04 LTS and up, as well as a range of other Linux distributions. For Unity the system requirements are similar, requiring Windows 7 SP1+, MacOS 10.12+ and Ubuntu 16.04+ or CentOS 7.

While Unity does not require its Unity Hub application to be used (so far), it promotes it heavily as a central way to manage Unity projects and licenses, similar to the Epic Games Launcher application for UE4. Whether this is an asset or a burden would depend largely on one’s workflow. For managing multiple concurrent projects with their own engine versions and keeping these updated, having such a central tool can be useful.

In contrast to Unity and UE4, Godot doesn’t claim any strong system requirements based on the website, and should compile on any platform that supports the required compiler and dependencies. The provided binaries come in an archive, without installer and run stand-alone, making this possibly the easiest to install of these engines.

When installing O3DE on Windows, it installs the O3DE Editor and Project Manager. For Linux (the aforementioned Ubuntu 20.04 or higher), there is a DEB package you can install after download. From the Project Manager new projects can be created and built. Other than the limited number of supported development platforms this workflow seems relatively comparable.

As there would be little point in installing a development environment if it couldn’t do the required task, we should back up a bit and look at which platforms these engines can be used to develop for. This should tell us whether we’d be interested in spending our time and energy on learning it. Here O3DE falls rather flat, at least in terms of documentation, or lack thereof.

While the Android and iOS mobile platforms are listed, finding concrete information is hard, just like for MacOS, and only some information listed for Linux as of writing. This contrasts with Godot, which lists its platforms in the feature list and includes everything from desktop, mobile, web and console platforms, including detailed information on how to build for these platforms.

For Unity and UE4 we see a similar offering of target platforms and documentation to get started. O3DE would appear to be mostly limited to common desktop platforms and mobile platforms, though the documentation is rather scarce on what features are supported. The build instructions for O3DE targets would suggest that it requires manual configuring of CMake and running this build script generator before being able to build for any target. Whether CMake is better than Godot’s use of SCons is another can of worms, but it does highlight the technical knowledge required for both U3DE and Godot.

Documentation and Support

It’s undeniable that Unity, UE and Godot are very popular for game development, with the former two having strong commercial backing as well. All of these also have a big community behind them, made possible by the (relatively) open nature of these products. All of them can be used freely and have many years of development of everything from AAA to metric loads of indie games behind them.

The result of this is that even if the documentation is unclear on something or misses some details, there’s a good chance that the community can help out with any questions. This contrasts with the engine formerly known as Lumberyard, which as the release notes for the most recent release as of writing mentions is still very much in development and that one should not expect to build a production-ready product with it.

This Beta-feel persists heavily in the documentation as it exists today, with none of the verbosity of the documentation by the other engines. Considering the lack of popularity of the Amazon Lumberyard engine over the past years, none of this is perhaps all too surprising. Regardless, these findings mark out what one should expect from diving into O3DE today.

All of which raises the question of what the future for this project may be like. Will it become a competitor for Godot, Unity or – heavens forbid – UE4/5?

Paying the Bills

The biggest asset of products like Unity and UE is perhaps that they can coexist in the divide between AAA games and small-time developers as well as hobbyists. Most of this is handled by the licensing system of both. For UE4 this means free to use and no royalties if the engine is used for anything other than game development. If you make a game with UE4 that grosses over $1M (USD), there is a 5% royalty fee for any amount over that first million.

For Unity, the Personal plan is free, as well as the Student plan. If revenue is over $100,000 in a year, the Plus plan applies, for $399 per seat. These plans ramp up with increasing revenue (next >$200k/year). Like with UE4, if you do not commercialize the software, no payment is needed. This contrasts with Godot, which does not have commercial plans, but does receive monetary rewards and donations, in addition to code contributions.

Although many studios have their own in-house game engine, both Unreal Engine and Unity see their products used in a variety of commercial software, all of which ensures that even small developers and hobbyists get to benefit from bleeding edge features implemented for these commercial customers.  While Lumberyard could theoretically have become something similar to Unity and UE4, it would seem that it didn’t get nearly the same level of funding as those two products do.

Yet Another Engine

Despite the lofty claims about O3DE, it’s hard to ignore the elephant in the room. After Amazon’s game development ambitions got scaled down a lot, its Lumberyard-based New World game received only middling reviews while in the background Lumberyard got de facto axed. It would thus seem that O3DE is more of a cynical way to cut the costs of developing a game engine that’s seemingly on its last legs.

Perhaps the best thing to come out of this is that an existing project like Godot can take the useful bits from O3DE engine, which would give users the best of both worlds: a fully free and open source game engine, with decent tooling and a large community supporting it. Whether this would include porting over the AWS Cloud Support module in O3DE is anyone’s guess.

At the end of the day, however, developer time in the OSS world is precious. Splitting it up between more and more similar projects would not seem to be very beneficial. Pooling resources would seem to be the wisest course there.

As for what works best for people who just want to make a game, by themselves or with a couple of buddies? UE4 or Unity if you aren’t interested in tinkering with the guts of the build system and tooling, otherwise Godot would seem to be a platform that might be decent for anything from simple mobile games to significantly more complicated desktop or even console games.

But O3DE? We’ll probably see over the coming months or years where it ends up and whether it becomes something capable for creating production-ready games with. It’s not over until the last beaver sings its swansong.

[Heading image: Open 3D Engine editor with Amazon Shader Language file and asset from the game Deadhaus Sonata open. (Credit: O3DE project)]

14 thoughts on “Open 3D Engine: Amazon’s Old Clothes Or A Game Engine To Truly Get Excited About?

    1. *did* make games. They rushed out a garbage MMO. It’s littered with bugs that shouldn’t be in a game of it’s scale and budget. Like, it isn’t smart to put out a client that can authenticate data. That’s always been a server side thing because it means someone can hack their client to send arbitrary data of their choosing. In this case, you can stop receiving damage by simply moving the game window. Once the player stops wiggling the window, all the damage from the server racks up. You could actually win a match by just wiggling till a timed match ends. It’s amateur hour stuff.

  1. I think another game engine in the OSS community is a good thing. It uses the Apache license and has AWS bits, so there is a good chance someone will cut out some parts and replace them with new GPL code, thereby re-licensing the project as GPL.

      1. Exactly. Apache is a permissive license, and that’s the problem. GPL helps a lot of OSS projects survive – it ensures that companies using a project continue to contribute back to it. You can imagine how helpful this can be for a game engine – if some relatively big studio decides to use it, they’re bound to put some money into fixing any bugs they might encounter.

    1. This is just plain wrong and shows a lack of understanding of how open source licenses work. Only the original copyright owners can relicense the code base. Even forks have to retain the Apache license.

        1. The GPL doesn’t give you any right to take someone else’s code.

          If the code is not already under the GPL, then you can’t (in general) take it and put it under the GPL.

          There may be provisions in some license that allows you to relicense code, but in general only the copyright holder can change the license.

          The Apache license does not allow wholesale relicensing of code placed under it. If you modify code that is under the Apache license, then you can distribute the modified code under any license or other terms you like – but the unmodified parts stay und the Apache license.

          The GPL say what permission the copyright holder has granted to you, and it says what conditions you must meet to continue using the GPL code. Nowhere does the GPL say “take anything you want from any place you want and call it your own by placing it under the GPL.”

    1. Are you not aware of the “Continue reading –>” link under each article on the main page? Or maybe you’re talking about something else? I’m confused (doesn’t take much, tbh)…

        1. I’ve noticed that sometimes if you’re not on the homepage but on the second page of articles, the “break” isn’t always shown. I figured it was a “if you wanted to go past the first page, you probably want the full articles too” design choice, didn’t occur to me they might be missing a “break” annotation…

  2. Everything revolves around their cloud centric services, instead of forcing people to use cloud they simply allow their software and services the extra incentive to be plugged into their data centers. On the other hand it is good that they open sourced it, whatever their reasons or short comings. Can we really say the same for Unreal or Unity, who are so absorbed with quarterly financials that their only ever used in terrible projects or licensed as middleware for their better options.

  3. After watching most of the O3DCon videos, I think that this engine still has some support. Version 22.10 has improved a lot, though it still lacks documentation and usability. I was planning to use it in my current project but we had to discard it due to hardware issues. Maybe in a couple of years it will be a serious contender for Godot or Unity.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.