[HN Gopher] Open 3D Engine
___________________________________________________________________
Open 3D Engine
Author : fdb
Score : 124 points
Date : 2021-07-06 17:08 UTC (5 hours ago)
(HTM) web link (o3de.org)
(TXT) w3m dump (o3de.org)
| cryptoboid wrote:
| Isn't Godot Engine really similar? It's open source as well
| gmueckl wrote:
| 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.
| [deleted]
| arduinomancer wrote:
| 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.
| bilbo0s wrote:
| 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.
| nightowl_games wrote:
| > 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?
| marshray wrote:
| > If the game engine is fast enough to push 60fps to the
| monitor, then it's fast enough to push 60fps to the network.
|
| How much is that in bandwidth costs?
|
| Is it better or worse than providing periodic multi-GiB
| updates to every player?
| meheleventyone wrote:
| > 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.
| bilbo0s wrote:
| 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.)
| makepanic wrote:
| So this seems to be amazon giving lumberyard to the linux
| foundation in hopes that a community builds around it?
|
| edit:
|
| > It's definitely not - it's a complete rewrite, with some useful
| parts of Lumberyard ported over.
|
| https://twitter.com/derekreese/status/1412475974428463107
| flohofwoe wrote:
| 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.
| fotcorn wrote:
| 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.
| SXX wrote:
| 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.
| cropcirclbureau wrote:
| Found this post on the AWS blog to be more...informative.
|
| https://aws.amazon.com/blogs/gametech/open-3d-engine/
| thrower123 wrote:
| Has anyone built anything with this? I've looked at Lumberyard a
| few times over the years, but even Amazon hadn't actually done
| much with it.
| croes wrote:
| So Amazon has given up on Lumberyard and hopes the open source
| community builds something interesting?
| audiojak wrote:
| 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".
| SXX wrote:
| It's great to see some competition for source-available Unreal.
| Now there is finally real AAA open source game middleware.
| blooalien wrote:
| 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._
| daypay wrote:
| 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.
| KronisLV wrote:
| 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!
|
| Also, if anyone wants another C# engine to look at, consider
| Stride ( https://stride3d.net/ ) or NeoAxis (
| https://www.neoaxis.com/ ). Or maybe if you're more into
| Java, look at jMonkeyEngine ( https://jmonkeyengine.org/ ),
| which seems underappreciated but nice. Or just look at the
| "Gamesfromscratch" YouTube channel, which i personally use
| for keeping up with this stuff:
| https://www.youtube.com/channel/UCr-5TdGkKszdbboXXsFZJTQ
| blooalien wrote:
| 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.
| pphysch wrote:
| 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.
|
| https://godotengine.org/article/why-isnt-godot-ecs-based-gam...
| Jare wrote:
| 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.
| pizza234 wrote:
| 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.
| pphysch wrote:
| 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.
| teawrecks wrote:
| All the games you are referring to didn't target
| increasingly parallel hardware. ECS is made to scale in
| ways OOP will not be able to.
| grenoire wrote:
| Solid and helpful documentation, should get you started off
| really quick! https://o3de.org/docs/api/gems/camera/
|
| 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..?
| jandrese wrote:
| 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.
|
| For example:
| https://o3de.org/docs/api/frameworks/azgameframework/class_a...
| lostgame wrote:
| 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.
| Thaxll wrote:
| Cryengine is not very good so we'll see. Also it seems that they
| don't have the backing from any major studio.
| mikeyouse wrote:
| 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.
|
| https://venturebeat.com/2021/07/06/amazons-lumberyard-become...
| vngzs wrote:
| 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.
| pizza234 wrote:
| > ahead of the competition in rendering large, luscious
| outdoor environments
|
| It was also very slow at doing so, although, without
| technical knowledge, it's hard to know whether this was
| actually inefficiency.
|
| I find it very ironic that Crytek's evil geniuses very
| successfully managed to market low framerates as a feature.
| /shrug
| meheleventyone wrote:
| 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.
| gmueckl wrote:
| To quote a former Crytek employee who had a sarcastic
| streak: "There's a reason it's called _Cry_ Engine!"
| Thaxll wrote:
| 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 ).
| teamonkey wrote:
| 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
| ipsum2 wrote:
| They've rewritten the engine from scratch, it supposedly
| doesn't use any Cryengine components in it.
| fotcorn wrote:
| There is still some CryEngine related stuff left:
| https://github.com/o3de/o3de/tree/development/Code/Legacy
|
| But it's getting less and less every day.
| suyash wrote:
| Sucks that this is an AWS project, you know how well they treat
| the open source community. I would stay away from it as much as
| possible.
| troymc wrote:
| 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]
|
| [1] https://aws.amazon.com/blogs/gametech/open-3d-engine/
| tmikaeld wrote:
| Could a new engine really catch up with Unreal Engine and Unity?
| They have decades of a head-start here...
| topspin wrote:
| 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.
| tmikaeld wrote:
| I really hope you're right.
| kroltan wrote:
| 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++.
|
| [0]: https://www.reddit.com/r/Unity3D/comments/e5g5u2/top_5
| _unity...
| kroltan wrote:
| 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.
| gnulinux wrote:
| > 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?
| SXX wrote:
| 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.
| [deleted]
| gmueckl wrote:
| 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?
| ChrisLomont wrote:
| >race to hit rock bottom?
|
| How so? Unity revenue is north of $500B a year, and I'd
| expect Unreal Engine to pull similar numbers for Epic
| annually.
|
| If anything, as the gaming market expanded, these companies
| have made serious footholds in the revenue stream.
| thrower123 wrote:
| I'm still surprised Microsoft hasn't bought Unity yet.
| waffenklang wrote:
| Actually its a fraction of that. First Quarter of '21 Unity
| made around $230M.[1]
|
| Epic (total) is in the ballpark of around $5B, but the
| engine alone - I estimate - around 1-5% of it, so also
| around $50M-$250M.
|
| [1] https://investors.unity.com/news/news-
| details/2021/Unity-Ann...
| chrisseaton wrote:
| > Unity revenue is north of $500B a year
|
| Is that 2x Apple's revenue?
|
| They're making sales of over a billion dollars every day?
| waffenklang wrote:
| No, Op seem to have mistaken B and M.
| dontparticipate wrote:
| 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.
| 10000truths wrote:
| Will there be support for building for HTML5/WebGL?
| astlouis44 wrote:
| Our startup is working on it!
| XCSme wrote:
| Native support for this would be good, but I think you can
| already compile most desktop apps to HTML5/WebGL using
| WebAssembly.
| 10000truths wrote:
| 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.
| XCSme wrote:
| Yes, I was referring to compilation using emscripten, but I
| couldn't remember the name, thank you!
| flohofwoe wrote:
| 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.
| XCSme wrote:
| Hmm, I was under the impression that there already are
| tools that automatically convert system API calls (IO,
| audio, networking) to web-compatible APIs.
| RyJones wrote:
| Intro video: https://www.youtube.com/watch?v=N_Qh5Q8AAAo
| pphysch wrote:
| 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].
|
| [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
| chmod775 wrote:
| OOP with an inheritance tree is nice until you have a
| houseboat.
| worldsayshi wrote:
| 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.
|
| Hearing about ECS gives me hope.
| flohofwoe wrote:
| 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).
| worldsayshi wrote:
| Hmm, I thought the ECS parts of Unity is part of the Unity
| DOTS system, which still seems in an early stage, at least
| in regards to ecosystem?
| flohofwoe wrote:
| 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".
| criddell wrote:
| 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.
| [deleted]
| esens wrote:
| 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.
| worldsayshi wrote:
| Interesting! Is there any game engine or open source engine
| or library that would support those kinds of code styles?
| TaylorAlexander wrote:
| 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.
| worldsayshi wrote:
| 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.
| mkishi wrote:
| 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.
| EamonnMR wrote:
| Godot is sort of its own thing, not a strict "object hierarchy
| everything" so much as "favor composition; everything is a node
| in the scene tree."
| pphysch wrote:
| 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?
|
| https://godotengine.org/article/why-isnt-godot-ecs-based-
| gam... (see "Optimization" section and below)
| flohofwoe wrote:
| 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.
| pphysch wrote:
| > 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.
| mkishi wrote:
| 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.
| aidanhs wrote:
| 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!
|
| [0] https://twitter.com/ID_AA_Carmack/status/1406427706980454406
|
| [1] https://isetta.io/interviews/AmandineCoget-interview/#the-
| mo...
|
| [2]
| https://twitter.com/kingcurrythundr/status/10837887204599726...
|
| [3] https://screenrant.com/anthem-frostbite-engine-development/
| _hao wrote:
| 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.
| 41209 wrote:
| 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.
|
| Best pray the black box does what you want.
| _hao wrote:
| > 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.
| SXX wrote:
| > 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.
|
| Are you also not using Linux and other open source software
| that Amazon contributed to?
|
| This is real open source project now without CLA attached.
| Any company can fork it and do something nice with it.
| Thaxll wrote:
| "so that our usage doesn't drift too far from mainline"
|
| Famous last words.
| AlbertoGP wrote:
| The presentation video says it is "multiplatform", but then in
| the download page:
|
| > _O3DE requires Windows 10 64-bit (versions 1809, 10.0.17763 or
| later)_
| fdb wrote:
| I believe the engine is multi-platform but the editor is
| Windows-only at the moment.
___________________________________________________________________
(page generated 2021-07-06 23:00 UTC)