I'm seeing Godot mentioned a lot: one major distinction between O3DE and Godot is that O3DE is "ECS-based" while Godot is "OOP-based" [1][2].
This makes little difference for the hobbyist gamedev, but it has ramifications for large projects with many interacting systems. Proper ECS architecture better supports the latter case [3].
That link says O3DE uses EC, not ECS. These are terribly named and often cause confusion, but they are different.
In "Entity Component" systems (think Unity), entities own components that give them data and behavior.
In "Entity Component System" systems (think Unity DOTS), components are just data, and behavior is driven by systems that live outside entities.
They are similar in some aspects and both are radically different than a deep OOP hierarchy, but ECS is quite more hardcore on decoupling. It's been a few years and it's still not unanimous whether adopting Unity DOTS over regular Unity is easy or even worth it, for instance.
Still, Godot isn't very OOP either, working mostly with composition of behaviors.
It's less confusing when written "Entity−Component−System architecture". That is, it's a list of the three concepts -- Entities, Components, and Systems -- that predominate in the architecture.
Do you have an good references for implementing an ECS? I've only found very high level descriptions but they all are a bit handwavey and avoid the implementation details.
I know Entt is a highly praised library, but I'd be interesting in folding in ECS as a general design pattern in my programming.
ECS was popularised with http://enwp.org/Dark_Engine in 1998. The architectural style probably existed already earlier, but I have no evidence I can point to.
Are you sure about the Dark Engine bit? I remember comments from people who've seen the code saying that it was an OOP mess with weird macros over C++ features that looked like COM on a bad day, which sounds completely antithetical to what people call ECS nowadays.
Perhaps it was confined to some part of the engine? ECS didn't come out of thin air after all, it is a generalization of practices people already used for things like particles, etc.
Reading the source codes, I think this is due to no one yet having requested the ability to do so. To me it feels like implementing this is possible, but tedious.
The simple work-around for the problem would be to rebless the instance. Example:
class Structure {}
role Floatable {}
role Inhabitable {}
class Houseboat extends Structure with Floatable with Inhabitable {}
$hb = Houseboat new
$s = Structure new
$s apply Floatable, Inhabitable # houseboat at run-time
# stop swimming
### NYI
### $s unapply Floatable
# make a new house that cannot swim
$s1 = Structure new
$s1 apply Inhabitable
$s1 = $s rebless_into $s1
But note that the point of an ECS is being able to dynamically change roles without recreating new entities. If changing a house into a houseboat means creating a new entity, then everyone who had a reference to the house would need to be informed of the new reference.
I'm not sure I follow. In ECSs that I'm familiar with, entities are integer IDs, not class objects. So adding or removing components (roles) to an entity doesn't make use of any language-level features, it's just calls to the ECS library. E.g. in JS:
var id = ecs.createEntity() // returns an int
ecs.addComponent(id, 'house')
ecs.addComponent(id, 'boat')
So, very different from the class-based approach being floated a few comments ago. Does that answer your question?
Godot's head developer admits that if you want to do anything performance-intensive (e.g. thousands of interacting entities, AAA stuff) with Godot, you will likely end up hacking the low-level engine code or even using a separate ECS/DoD implementation. At that point, why not use a proper ECS engine?
I've played maybe one game with entities in that count range (Planetary Annihilation) and I think you'd need a lot of low level engine work for something like that anyway (since it's doing all sorts of neat stuff with interpolation, weird coordinate systems, networking, etc.)
Hardly any game needs "thousands of interacting entities" though (outside of special subsystems like particle systems). Arguably, (DOTS-style) ECS makes it harder to incrementally build a game by adding features, because you need to put more effort into designing the data layout upfront. And if there's just a few dozen instances of each thing that's definitely overkill, moving to ECS won't make a noticeable performance difference in that case.
> Hardly any game needs "thousands of interacting entities" though (outside of special subsystems like particle systems).
This is an example of survivorship bias. How many ambitious game concepts have collapsed under performance/architecture issues that lead to productivity-killing refactoring? Impossible to say, but no doubt many.
> Arguably, ECS makes it harder to incrementally build a game by adding features, because you need to put more effort into designing the data layout upfront.
OOP bakes these decisions into the inheritance hierarchy, which ends up being more thorny than adding a component, or migrating an existing component's schema. ECS will make it straightforward to determine which Systems will be affected when a particular Component's schema is altered.
Speaking from experience, the hardest part about game development isn’t figuring out how to (efficiently) build something, it’s deciding what to build in the first place. The second hardest problem is getting everyone on board with the answer to that. The third is figuring out how to build the content 1000x to support that. Way, way down the list is the runtime performance for a gameplay system.
True ECS systems - and not frameworks that just have things called “entities” which own things called “components” - are hard to work with, almost by definition (ie you have to be very explicit about data layout and dependencies). They add a lot of friction upfront to solving the important and hard problem(s) while purporting to solve something that isn’t actually an issue in most cases (guess what, your N is likely < 10, modern cpus go brrr, etc). If you are working in a domain where you already know something about the performance and input size characteristics - particle systems are the go to example - then maybe ECS makes sense as a framework. Otherwise, I’d advocate for simpler oop approaches with heavy composition.
> just have things called “entities” which own things called “components” - are hard to work with, almost by definition (ie you have to be very explicit about data layout and dependencies).
My experience has been completely the opposite to this. In fact being explicit about data layout and dependencies is a hallmark of a OOP rather than ECS.
In compiled languages the dependencies in object hierarchies are fixed at compile time and can only support tree designs, so you have to plan ahead for all possible combinations to even build relationships with OOP, even with composition (because its static).
With ECS everything is decoupled so you can write a system that does X and it affects nothing else.
This leaves you free to design by isolated processes rather than by code structure, and entities naturally do whatever processes their data supports dynamically.
Makes iterating designs incredibly rapid and offers design options that are convoluted and fragile with OOP such as completely changing what an entity does at run time.
For instance you can move the keyboard input component from a player entity to a monster or even something as random as a building and it just works - you didn't have to design for it, you don't even need to change any code. Remove the health component, now the entity is invincible, remove the gravity component and now it can fly, add a homing component and now it seeks a target. All this is trivial and can be done at run time. Want flying flaming lampposts the player can control? Just combine the appropriate components. Need to drastically pivot the design? Vastly less work than OOP - sometimes just a case of changing the data in components or their combination in entities without touching systems. Don't need this flexibility? Still gives you a more modular and less coupled design.
As a nice bonus this flexibility comes with more cache friendly performance than static hierarchies to boot.
All of what you describe in terms of data driven entity composition is possible without a true ECS framework. That is what I was referring to and more or less what Unreal or Unity (base, not dots) offer.
ECS is one of the better examples of something that sounds good on paper but in practice, and crucially in production, doesn’t provide the sort of benefits that outweigh the friction it imposes.
There seems to be a myopia online around things like ECS, data oriented programming generally, writing games in C (as opposed to that horrible high level monstrosity C++…), optimization, etc. Those are all fine things in and of themselves (though I’ve never understood the opposition to C++ as anything other than nostalgia), but they are often discussed without being ground in the considerations of building a game. If you want to build a tech demo, great! However, the needs of building a game with hundreds of people, most of whom aren’t engineers, and to a quality/production level that even “simple” things become complicated, demand other things take precedence. I lead a team that facilitates a creative project, not to satisfy my technical desire to have optimal cache or thread utilization in every piece of code. The right tool is the one that gets you closer to the creative goal, and for gameplay code most of the time it probably looks like what Epic or Unity are shipping with their entity frameworks.
It's a "where are the bullet holes on the planes that survived" kind of problem. The thing that overwhelmingly kills game projects is overscoped design, which manifests into a need for very detailed, configurable entities with rich scripting functionality. So if you pursue scalability at the level of the entity system itself, as a thing you should invest substantial engineering resources to - you are effectively saying, "yeah, I have a team of 100 people to throw at the game's implementation and they are going to add literally every feature we brainstormed and also stuff we haven't". Because if you actually don't intend to do that, then you can instead adopt a pattern of prototyping it in whatever works well for authoring, followed by profiling and hardcoding a fast path as necessary. "Fast from the beginning" is just guessing about the bottlenecks.
And that doesn't mean OOP is definitely good at the authoring task, either. It just happens to be good at kicking the can down the road and letting things work inconsistently, which may be correct in a prototype when you don't know if you're actually shipping that feature, and only poses an issue if you've tied the authoring to the runtime implementation in a deep fashion. Godot doesn't assume this; while it does have hierarchical relationships of objects, it has some boundary points with respect to reuse(scenes and scene instancing) that make the path of least resistance be to make separate authoring and runtime versions of entities, with one spawning the other.
> This is an example of survivorship bias. How many ambitious game concepts have collapsed under performance/architecture issues that lead to productivity-killing refactoring? Impossible to say, but no doubt many.
Probably less than you think. The games industry knows how to wring performance out of hardware. Data oriented design is common in most game engines where it matters. It’s just it’s not usually the gameplay code that is particularly a bottleneck.
There are also plenty of examples of games where the gameplay layer is a perf concern that not only have been released but were big sellers. For example Factorio and City Skylines. It’s just I’m those examples it makes more sense to worry about data model and access patterns for the actual problem at hand rather than try to generalise it with all the attendant problems that causes. Not least slowing down workflows when you don’t actually need it.
Most game engines are also composition based rather than using much inheritance these days.
> This is an example of survivorship bias. How many ambitious game concepts have collapsed under performance/architecture issues that lead to productivity-killing refactoring? Impossible to say, but no doubt many.
I'm reminded a bit of Minecraft, whose infinite and completely mutable voxel world was really novel at the time -- and which was (and maybe still is) the source of a lot of performance woes.
I've been wondering something, though: wouldn't it be possible to implement regular EC-style components on top of an ECS system?
You can't implement ECS on top of EC, but if it's possible the other way around, Godot's argument that most people won't need it would seem a bit weak — just let them use fat components on top of an ECS core, and if/when they need the performance there's still room to push it without side-stepping the whole engine.
You can implement ECS on top of EC. Entitas is and example of a really good ECS on top of Unity’s default EC.
I’m currently writing and designing a serialization/networking library that I’m using to build an ECS framework on top of regular Unity EC. Why not use dots? Well, I hate the restriction of using only blittables for component data, I want to have access to the already existing ecosystem of Unity packages, and the biggest is that I am designing it for networking first. It’s slow going (I’m a dad and I have a full time game dev job), but I’m making good steady progress. My serialization library currently features composition, quantization, no reflection, and no garbage collection. I plan on releasing the first version under the MIT license hopefully in the next couple months.
I have a prototype that I’ve been building to test my stuff. Check it out it’s only 30s.
https://youtu.be/p4v3ZnS2KBM
Your demo reminds me of a problem that M&B 2 Bannerlord had, they created a destructable castle, but couldn’t get performance network enough to sync the destruction (bricks and stone walls) to all players.
Thanks so much for posting these! I did get interested about physics, I recently did Space Engineers scripting and it really is cool to play with all kinds of variables.
After working too long with stateless API:s on the backend and one state container to rule them all react-redux kind of architectures on the front end the OOP code style kind of makes my skin crawl. When I try to learn Unity I find it so hard not to turn my code into spaghetti.
Unity has always been more "ECS" than "OOP" though (traditional Unity has Entities and Components for composition instead of inheritance, modern Unity moves Component data and logic into Systems for performance).
Yeah, kinda. But the term ECS definitely already existed before the "data-oriented revolution" for engines that used components attached to game entities to achieve "feature composition". Not sure what the "S" stood for at the time, probably not "Entities/Components/Systems" (because "Systems" is the new thing that actually matters), maybe simply "Entity-Component System" as in "this is an Entity-Component system".
The only major difference (in regards to code organisation) between Unity's old classes and ECS is that in Unity the logic ("Systems") is coupled with the data ("Components") in the same class.
Entities in Unity are already not concrete implementations (probably just a "handler" ID) as far as the user is concerned. This is pretty much like ECS.
Would either Godot or O3DE be a good choice for a CAD-type application? It looks like Godot deals well with a scene graph which seems like a good way to organize data for that kind of application.
Neither is designed for a CAD engine. CAD uses generally NURBS and a scene graph based around constraints. Game engines are not constraint based but rather about independent behaviour agents interacting using triangle meshes. Quite different.
For NURBS modelling there is OpenNURBS [1], made by the guys who made Rhinoceros 3D, an excellent NURBS 3D modelling program. However, although Rhino is available on Windows and macOS, it is not available on Linux and the authors seem pretty against making a Linux version. OpenNURBS is only available on Windows.
I desperately want open source CAD to be a thing. I would suppose that Freecad is probably a very good starting point. I don't think the lack of good open source CAD is due to a lack of a decent codebase so much as the fact that good CAD software is a very large project and we have just not directed enough efforts towards it. I am speculating however and may be wrong.
Rather than "just" Open source CAD I would like to see Open Source CAD-like applications. Well, at least in my mind CAD is something kind of specific and carries a lot of design assumptions with it.
I feel there is a lot of cool stuff you can build in the space of building shapes using constraints. Like visual programming languages made to visualize mathematical relationships using geometry.
Interesting. In my case I am specifically talking about mechanical design CAD for engineering. We have a huge need for that in my opinion. Freecad might be the closest thing but I suspect it needs more investment.
However what you’re talking about sounds important as well.
> I don't think the lack of good open source CAD is due to a lack of a decent codebase
I think the problem is exactly that. A good constructive solid geometry (CSG) is a difficult thing to make and there are no open source alternatives to the ones powering the mainstream CAD packages.
Closest thing would be a level editor, which is very much a CSG-based CAD program with roots going back to the Quake 1 generation. It's just not geared towards typical production applications where real objects are being machined.
It's hard to avoid the segfaults. I've tried to use it many times for simple projects. Some workflows it's every 10min or so, and often you get into corrupted states where you can tell it's about to happen, but of course if you save you risk your files completely.
It's also slow, onshape in my browser beats it at roughly everything.
Graphics-wise, the assumptions are quite different. Game scenes are a large collection of low-detail objects that are constantly moving and not all visible at once. CAD scenes are a small collection of high-detail objects that don't move except in response to input events.
If the CAD project is big and serious, I would be afraid of eventually hitting some limitation of the game engine that is hard to work around due to such different assumptions.
Both game engines and CAD applications have some type of level of detail node in their scene graph so that zoomed in items are high fidelity and items further are simplified.
I work on an application that uses the geometry kernel from PTC (GRANITE) for modeling and OpenSceneGraph for display. I'm a little worried about OpenSceneGraph because it's 100% OpenGL which feels like it's at the end of it's life and we need to find something built on Vulkan or Direct3D for the future.
Think I'ma just stick with Godot Engine + Blender 3D. The 4.0 release of Godot should be somethin' really worthy, as even the 3.x releases are already amazingly usable and their plans for 4.x and beyond are quite impressive stuff.
Edit: Oh, and Godot already supports all the major platforms right outta the box. Bonus! Totally in favor of another open source 3D engine tho. Can't be a bad thing to have more options available in that space.
Godot is such a pleasure to work with too, compared to other engines I've used. It also depends on the type of game you're creating, but 2D has been a more pleasant experience in Godot vs Unity.
I think that the opinions here will probably be split between the people who enjoy the simpler workflows of Godot (as well as its more reasonable distribution size, somewhat more convenient 2D implementation, amongst other things) and those who are used to the benefits of using Unity, especially in 3D.
For example:
- the ECS and DOTS models in Unity feel way better to work with as a developer, since components can be freely attached to GameObjects to give them behaviours vs the node based structure of Godot, where each object can only have one attached script (though their approach to everything being a scene feels better than prefabs in Unity)
- the support for IDE integrations, such as JetBrains Rider giving code hints about certain API methods being slow, as well as other API things that can sometimes slip by, seems really useful to have in Unity; furthermore the C# API being the primary one feels way more usable and documented than Godot's efforts to add C# support (which, while a great idea, still needs a bit of work to be fully mature)
- Unity also seems way better when it comes to importing assets, such as Blender scenes directly into it, without having to export to Collada, glTF or another format, or having to install a separate exporter for Blender as a plugin which may not be supported in future versions
- on that note, there are also a variety of useful solutions built into the engine, such as light mapping, navigation meshes, pretty optimized occlusion culling, LODs (which i'd say are critical for any larger project, or game genres like RTS) among others, which are either missing from Godot entirely for the time being, or which will need to be installed as separate plugins (like terrain editing functionality, for example)
- the support for a variety of tools and other integrations is pretty great in Unity, thanks to the asset store - for example, if you'd like to automatically generate the aforementioned LODs, then you can just get https://assetstore.unity.com/packages/tools/utilities/poly-few-mesh-simplifier-and-auto-lod-generator-160139
- furthermore, the amount of tutorials and materials for Unity is still probably a bit larger than Unity, as well as its market share will be hard to content with for at least a number of years
That said, Unity also lacks in some other areas, such as there not being a decent networking solution at the time, DOTS not being fully finished, the render pipelines being a bit messy to work with (while there are benefits to using URP and HDRP, it's a bit like the Python 2 vs 3 situation with support varying), as well as Unity just generally trying to implement a whole bunch of functionality that's not exactly production ready. Also, their reliance on Unity Hub doesn't feel like a good sign and it feels like a larger and larger part of their offerings will be cloud based, which is understandable from a business perspective, but also concerning.
I do hope that Godot gets support for the things that i've mentioned that are missing and perhaps even gets things like networking right, rather than going the path of Unity and jumping around various solutions.
Just my 2 cents on those engines, both seem pretty usable!
My own personal experience with Unity tryin'a import models from Blender bein' a huge pain in the butt was what led me to try out Godot after hearin' about but ignoring it for the longest time.
Turns out that Godot ended up auto-importing my Blender models with pretty much zero hassles (drop 'em in a project folder, save 'em back out as a Godot scene), and it was a short time after (under an hour, including the time it took to read some docs to familiarize myself with GDScript) I already had mouse/controller clicky code attached to them and a first person camera controller in place. Since then, the more I learn about Godot the more I enjoy workin' with it, pretty much like my experiences with Blender. :)
Of course a large part of my affinity for Godot could be influenced by my love of Python and the similarity of GDScript to Python code.
Since Blender made Godot its default game engine, their integration really has become almost seamless. I hate to say it, while I learned Godot on GDScript, which is similar to Python, you do get a bit of a performance boost by switching over to C#. I'm not sure it's enough to learn, if it means not making games, don't get me wrong. Hating the language and the process can mean the difference between producing and not producing, so do what you're happy with =)
I've heard and had similar experiences with imports, but nothing major. Right now I'm only working on a 2D side scroller for personal experience. Creating a TileSet, and either using Godot or the Tiled Map Editor and importing back to Godot, everything is a breeze.
I wanted to try Godot for the simplicity, and the ability to use Rust at a later time to experiment with.
Godot's got simplicity in spades, that's for sure. So far I've been nothin' but pleased with my Godot experience. Every time I open it up to learn a new thing about it, it's generally gone pretty much silky smooth. Helps that I've chosen to approach it the way I learned to approach Blender tho. In bite-sized chunks, as I need a new feature, rather than tryin'a learn it all at once. That held me back for the longest time tryin'a learn Blender. Kept overwhelming myself with how crazy powerful it was because I wasn't focusing on just my current need. Kept gettin' sidetracked and lost, and then I'd give up for a while because it felt too complicated. ;)
I'd say Godot is the Unity of Unreal Engine.
It might not have started in the pole position but it's gaining a lot of steam and catching up in strides.
With the new Vulkan renderer in 4.0 the 3D performance should make some leaps as well.
Not sure yet how it will impact the VR performance but hopefully it helps there as well. I can live with the performance for now but I am still staying at the original 72hz on the Quest to keep a performance buffer (especially since high frequency hand tracking limits the available resources even further)
Godot is great for the hobbyist but ECS-based O3DE may be worth a look for ambitious devs or those who want to make a career from it. Godot's strict OOP-style object hierarchy is a practically guaranteed source of friction for more complex game behaviors that touch multiple data/logic domains.
Why would you say something like that? Most of the large and small games of the past 20 years have been built with the kind of composition patterns that Godot favors.
Plenty of successful software, including the currently most popular game engines, are designed with strict OOP principles. That doesn't mean there aren't well-documented flaws with it as behavioral complexity increases.
I'll wager that if O3DE sees an actual release with real documentation, it will herald a new generation of ambitiously-scoped games that actually realize their ambitions instead of crumbling under OOP-induced technical debt.
There are a couple of reasons; performance is one.
Besides that, games have an (un)surpring level of coupling between entities. Even a simple, few hundred lines game, is a tangle. The ECS designs decouples the entities, which is a very significant design improvement.
What has been done in the past is not really indicative, as ECS is relatively new (in the grand scheme of things).
Something that can be said though, is that ECS is frequently considered overkill for small projects.
I can assure you, lots of "classic EC architecture and even OOP architecture" games also have many Systems in the ECS vein, when they need them. Not for the performance (that's tied to memory layout in ECS) but when it's easier to implement a given piece of logic that way. Traffic, pedestrians, opponent AI, weather, mission flow, encounters, are a few typical examples.
I think one doesn't need to reach that complexity in order to benefit from ECS design.
On the other hand, most of the games have somewhat-throwaway code, so the code design may not be so important indeed (VVVVVV was for example discussed on HN).
I guess Amazon just started to understand they have no clue about how gamedev industry works. They invested heavily in this, but nobody wanted their proprietary tech with cloud lock-in.
Now they changed strategy to compete with Epic's Unreal by making the engine actually royality-free and open source. It's very logical step that to compete with source-available product you need one under proper open source license with patents grant.
I wouldn't go as far as calling it a complete rewrite. The renderer (called Atom) is completely new, but many other things stayed the same. Our Lumberyard Gem required some work to port over, but that was mostly replacing old CryEngine stuff with the equivalent in the Lumberyard/O3DE API.
Browsing through the code, there's a pretty sizeable chunk of old CryEngine stuff (CryCommon and CrySystem), it's in a directory called "Legacy", but I guess that doesn't mean that it isn't needed anymore.
No, not really. Besides a bunch of video guides, there's barely anything that you can read. Highly disappointed with the launch, maybe it'll pick up later..?
Same. I went poking around the documentation area and found only YouTube videos in the examples area and noped right out. The API refs seem extremely terse as well. Just a handful of prototypes with no explanation as to what the parameters are or how to use them.
If I can’t read your documentation - e.g. not video - I’m not interested. It’s the principle of the thing. Especially for coding. Sometimes I just want to copy and paste something rather than retyping it all.
My favorite thing about Unity is how seriously they treated documentation and education. There are whole, elaborate tracks of educational material. It's really irritating that they walled a lot of it off behind a high paywall (seems awfully short sighted to charge up and coming developers $200+ to learn one aspect of how to use your product; I can feel the touch of an ambitious middle manager in that move), but what's free is still a great introduction, and the competition doesn't compare.
I have found the Unity docs to be atrocious. Missing info. Not well cross referenced. Important details buried as notes under other topics. Examples in docs out of date. Are you saying if I pay $200 I get access to better docs?
I don't know; I didn't pay the $200. I just really liked the "Junior Programmer" track on Unity's "Learn" website and was very irritated when I found out that there were dozens of hours of followup videos and course materials associated with their "Unity Certification" product that I couldn't see.
I will say that the thing that was most annoying about the videos I could see was that they were out of date. You had to install a previous version of Unity if you wanted to load the assets that the course used.
Didn't they move all of the learning stuff to free last year? Initially on a temporary basis then permanently later in the year. I haven't looked at their learning stuff for a while but I swear I remember that.
This feels to me like Amazon is departing the space and they're dumping and running. As in, where they were previously pouring money into starting their own studio and platform, they're now cutting their losses.
I'm only drawing this conclusion based on the announcement article and video - maybe I'm missing something.
Why do you say CryEngine is not very good? I don't have any experience with the dev side, but I used to follow engine tech and CryEngine was (historically, at least) ahead of the competition in rendering large, luscious outdoor environments. These are generally regarded as difficult in software compared to the more static, geometric indoor environments common in earlier technology.
A good renderer is only a small part of a game engine. The rest of CryEngine was a heaving mess for actually trying to make a game in without direct access to the people making it.
The rendering story was over 15 years ago, CryEngine is pretty much an abandoned engine, I only know 2 games using a variant of it which are StarCitizen and the new game from Amazon ( both using Lumberyard ).
The engines used for Ubisoft's FarCry and WatchDogs series are derivatives of CryEngine. The fork was a while back, but as a basis for large open world games, the legacy lives on
Niantic and Adobe as members is a huge boon though - 3D engines are obviously great for games but we need better rendering in tons of software. Intel + AWS + Huawei at least means it's a serious effort to bootstrap this thing too.
Context: O3DE is an open source (Apache 2) AAA game engine based on an updated Amazon Lumberyard
I've had the opportunity to work with O3DE over the past few months at work and I'm very excited to see where it goes.
There are two pieces of context if you don't work in the games industry (when I came in from an 'open source' background these surprised me):
1. the best game engine tech in the industry is proprietary (the biggest players are Unreal and Unity, lots of studios have purpose-built ones), there's relatively little open source [0]
2. in a games studio, the workflow of your company orients around the workflows of the game engine [1]
These two things combine in quite unfortunate ways, to the point where EA mandated the use of its own in-house engine...with mixed results so far [2][3]. Smaller players have three options: a) suck it up, b) use an open source alternative (i.e. Godot), c) get caught in the tarpit of "build your own engine"
O3DE has an opportunity to shake things up - particularly because of how modular it aims to be. At Hadean, our interest is in the networking layer (to drop in as netcode for Aether, our distributed simulation engine) as well as the 'core' simulation layer (to integrate with Aether in order to scale O3DE games/simulations across multiple machines). While doing all this, we will probably 'get involved' and contribute, so that our usage doesn't drift too far from mainline.
Anyway, this is all very early days - it's just a developer preview, and the flows are a bit rough. It'll be a while before we see if this changes things (I'm hopeful!), but major credit to the people at Amazon who have made it happen so far!
p.s. a checkout with deps, plus fresh compile of O3DE, plus a new project that you've opened once (to process assets) will set you back 100-150GB at my last check - not unexpected if you're used to compiling Unreal!
After having dealt with and released projects with Unreal/Unity and done some experimenting with Godot throughout the years I've completely ditched the idea of using a 3rd party engine for any serious project of mine. I think they're fine for quick prototyping, but I'd take the full control and learning experience of having a custom engine for whatever I want to do than to a) try to fit my design/vision in whatever paradigm the engine is made to work for b) in the chance of a hit (unlikely) give out what could be a substantial amount of money to Unity/Epic (this doesn't cover Godot obviously) and c) I want to own my source and not have done obscene amounts of work in basically closed source environments that don't guarantee future support etc.
I don't recommend this to the general user or game dev though. Most people just want to create their game. I want to do that and have the control. Yeah, I can't make AAA engine by myself, but then again even if I could the assets for a AAA game are staggering. I think the industry should actually pull the reigns a bit on these enormous budget pieces of entertainment software for it's own good and scale back a bit, but anyways, that's another discussion.
As for Amazon and this initiative I wouldn't touch it based on principle since I don't want to support Amazon and their business practices.
Your still using frameworks like Open GL though right ?
I think this ultimately depends on if you want to ship or not. I think Unity is the best option for most people due to its ease of use. But I also respect wanting full control, sometimes Unity feels like a magic black box.
> Your still using frameworks like Open GL though right ?
Correct. OpenGL, Vulkan and libs like SFML, SDL, Allegro are some of the choices that people like me use. Of course there are million media frameworks with bindings for a lot of languages. You can do whatever you want really.
And I'd agree with you. I think of the 3 engines I wrote about in my original comment Unity is by far the most painless to work with and I like the UI of the engine itself the most.
Quite the reverse. We are committing supporting the community and contributing to the software. With over 25 partners, I'm not sure how you could see it as "giving up".
It might have started at AWS, but it seems they really want it to have a broad set of contributors under the Linux Foundation umbrella.
"We [at AWS] invested over a year to recruit partners with the right mix of resources, expertise, and above all, motivation to foster a self-sustaining community. We partnered with Linux Foundation as our trusted expert open-source organizational home because it stands as one of the best on the planet at managing large open-source projects. The Linux Foundation can provide the level of expert management demanded by such a large open-source effort. We are thrilled for the backing of a range of partners who feel just as strongly as we do about empowering choice for games and simulations developers. These partners include: Accelbyte, Adobe, Apocalypse Studios, Audiokinetic, Backtrace.io, Carbonated, Futurewei, GAMEPOCH, Genvid Technologies, Hadean, Huawei, HERE Technologies, Intel, International Game Developers Association, Kythera AI, Niantic, Open Robotics, PopcornFX, Red Hat, Rochester Institute of Technology, SideFX, Tafi, TLM Partners, and Wargaming." [1]
"Besides Amazon AWS being involved with the Linux Foundation's new Open 3D Foundation, other notable vendors involved include AccelByte, Adobe, Apocalpyse Studios, International Game Developers Association, Niantic, PopcornFX, Red Hat, and Wargaming, among others."
Does this means linux gaming improving beyond steam/proton?
I always thought developing/maintaining an entire game engine just to hopefully get some AWS revenue from the web part seemed like a dubious business model.
If a big company is going to adopt your engine they want your main incentive to be making it the best engine possible, not selling you more SaaS integrations.
The question with these engines is how scalable they are. This is in terms of team size, ease of use, project size and complexity, editor performance/scalability, runtime performance, quality of presentation...
Unreal, Unity, CryEngine, Frostbite etc. have shown that they are tools capable of supporting huge productions. This means that the engine teams have invested a lot of work to remove a lot of barriers that the game teams ran up against when scaling their productions up. New users now get to profit from that when they start out on one of these engines.
As far as I know, Godot hasn't been thrown into that particular gauntlet yet (please correct me if I'm wrong here!). From experience with complex projects like this, I can tell you that you will always find new bugs when you stress them in novel ways. For a game production, this means that you take on a higher risk that you need to dive into the engine and bend it to your will, costing engineering resources.
I have the opinion that the needs of web based games is fairly different than native games and that it's unlikely any game engine targeting native games is going to do a good job with for web games.
Native games, downloading 50meg to 50gig is before you can play is not uncommon. Web games you probably want to keep under 1-2meg (just a guess). Of course you can try to use an engine designed to make native games but use small resources but, AFAICT, most of those engines, just their code, is already too large to really be a web game.
I know Unity was trying to make a smaller runtime for web games but since shipping a few demos a few years ago I haven't heard much about it.
For a big engine like this there's a lot more work involved then cross-compiling the code to WASM. All lower-level parts that sit on top of OS APIs like IO, 3D-rendering, audio, networking, etc... need to be ported over, and the browser is a very different runtime environment than native OS APIs, so sometimes it's not even possible without a lot of compromises which may "drag down" other parts of the engine.
Hmm, I was under the impression that there already are tools that automatically convert system API calls (IO, audio, networking) to web-compatible APIs.
Consider for example that TCP sockets are not available in the browser. There are other protocols available, but no simple TCP sockets. So you can see there are fundamental differences there that cannot simply be abstracted over.
WebAssembly alone is not enough, you need access to the canvas and WebGL JavaScript APIs in order to actually perform the rendering. WASI may change this in the future, but for now, it means that integration with the emscripten toolchain is a must.
Game engines have a unique cycle where cutting edge tech in one year has often turned into a kind technical debt a few years down the road. Thankfully, that cycle has slowed down a lot and things have started to stabilize in major areas like asset pipelines and editing (the true core of modern engines). But it still means that the decades of head start that one might assume shrink down because of the churn.
If you can fund and build a huge skilled team for about five years, you can still catch up enough to cover some game genres competitively and expand from there. But how do you recoup these costs in a market that is now clearly in a race to hit rock bottom?
They also have decades of unavoidable baggage. "Disruptive Innovation" theory allows for new competitors to surpass incumbents despite inferior products and lack of depth. We, including you, don't know if there is room for such a disruption. There could be. All we can do is wait and see.
I've never used Unreal, but the GP is absolutely correct in regard to Unity. It is subject to so much churn, and the main architecture is so flawed, the best way to use the engine is to use it the least possible, as basically a glorified renderer and main loop.
The best quote I've seen comes from a comment on a feedback request thread [0] on the Unity Reddit, from andybak:
> It seems that everything that's working is deprecated and everything that's current is unfinished.
The features touted to be the "correct"/"current" way to use the engine are supremely half-baked, and the "old" ways are so inefficient and still buggy after all these years, that I have no words to describe.
I'm basically on the prowl to jump ship to Godot immediately when 4.0 arrives with the new renderer (the current release is not terribly efficient for 3D). It has its warts too, but at least it's architecturally sound, and the source code is very agreeable for someone not very familiar with C++.
Heck, there is literally no builtin solution for networking. There is a HTTP client, sure, but if you want any sort of realtime multiplayer, you have to use either a separately-billed paid third party, roll your own from sockets directly (good luck supporting WebGL), or use a community-maintained version of the deprecated networking system which frankly is not very good.
> roll your own from sockets directly (good luck supporting WebGL)
I'm sorry (not experienced in graphics) but why would you need WebGL for a multiplayer? Can't you have a normal 3D renderer that has a connection to server?
By "WebGL" they meant build of their game for web browsers that Unity let you create OOTB. So if your game is cross-platform and also support playing it in browser you have a problem: sockets that you can use elsewhere wont work in browser.
Sorry, the Unity crowd calls the browser target "WebGL". Yeah it's a bit silly but such is life.
It's not that you need to care about WebGL-the-technology for your networking, but that there are no provided tools to use, say, WebSockets, when creating games that will run on the browser.
Sure, you could use WebSockets through JS interop and create your own socket library encapsulating that, but it's hella annoying.
It's not new so that's how they are getting caught up. It's more like a new major version of Lumberyard which itself was a fork of Crytek, which was able to ship AAA games (as painful as it was to do).
I know the devs say it's a major rewrite but... come on. You and I have both seen that code monstrosity before.
I was thinking initially that this is not very useful in a world where we have unreal and unity. Then I thought about the coming world of game streaming, and reconsidered. Any average joes making a startup could nvenc or amf this engine up. Just like that, no more streaming licensing fees to unity or unreal.
That's actually attractive.
Of course, a set of joes or janes capable of writing a server supporting enough concurrents to make an economically viable service is probably not a set of "average" joes. But you get the idea. These ancillary open source engines are probably the place where indies will end up having to operate in a hypothetical future where game streaming is important. Provided the engines are fast enough.
I'm not saying we'd see a python or javascript engine serving as a streaming server, but the C++ and Java open source engines could well be where we'll see the first indie hits in that space. And in that sense, O3DE might be useful.
> Just like that, no more streaming licensing fees to unity or unreal.
What makes you think streaming a game made in Unity requires licensing fees to Unity or Unreal? Where in the terms of service does it say that?
> Provided the engines are fast enough.
What do you mean by this? If the game engine is fast enough to push 60fps to the monitor, then it's fast enough to push 60fps to the network.
> indie hits in that space
Why do you think there will be 'indie hits in that space'? Game streaming (ie Stadia, Nvidia, Playstation, etc) already exists and seems to primarily target heavy AAA games that players dont have the beefy hardware to run. Why should we expect there to be an 'indie hit' on a service like stadia?
Having a machine support one user at 60 is trivial. Having a machine support 100 users or a 1000 users at 60 is a different issue entirely. (Assuming you want to make money.)
> Is it better or worse than providing periodic multi-GiB updates to every player?
Not everyone can afford a 3090. But imagine even higher tiers that really only make sense for data centers to purchase. How much GPU time sits idle at home?
As much as I hate thin client-ization of everything, rendering moving offsite makes sense.
> What do you mean by this? If the game engine is fast enough to push 60fps to the monitor, then it's fast enough to push 60fps to the network.
Whilst this is true the more efficiently it pushes 60 FPS the less hardware grunt you need. Which could be the difference between a project that works financially or not.
This makes little difference for the hobbyist gamedev, but it has ramifications for large projects with many interacting systems. Proper ECS architecture better supports the latter case [3].
[1] - https://docs.o3de.org/docs/welcome-guide/key-concepts/#the-c...
[2] - https://godotengine.org/article/why-isnt-godot-ecs-based-gam...
[3] - https://www.youtube.com/watch?v=W3aieHjyNvw