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)]