4 ms·

I would encourage anyone looking for an open source game engine to first consider Godot, Ogre3D, Panda3D, etc. Rebranded as "Open 3D" and backed by the linux f

• spijdar 5y ago
  I'm no game developer, but I think if nothing else, Cryengine/lumberyard/open 3D would be far superior in terms of visuals than the alternatives. I'd assume the code as a whole is clunkier and more bloated, but also more "battle hardened" than most FOSS projects too. Godot's 3D support seems promising, but at a very different level than the "big" engines. Not sure I'd want to pick it up for a serious project just yet. The other options like Ogre seem ... kind of bad, if their industry track record is to go by. Ogre in particular seems to have had a brief golden era, where a few commercial games used it, but in every case I know of, sequels to those games abandoned Ogre for unity or unreal. Even the open source games/frameworks I know of that used it like OpenMW abandoned it. If I was really trying to make a commercial indie game with a FOSS engine, this seems like a good candidate, even considering the questionable Amazon ties... to me, it strikes me as more "open source Cryengine" in the first place anyway, in the same way OpenSolaris indirectly open sourced a lot of older UNIX utilities in addition to Sun's novel code. (Of course if I was only making a hobby project I'd probably stick to Godot, but I'm imagining the perspective of a small team seriously trying to make a commercial game)
  • slimsag 5y ago
    I don't disagree visuals may be better (where better is likely "more configurable" or "more performant" in specific cases), but in many ways your art team and shader team matters FAR more than the underlying engine these days. If you are a small indie team, you'd do well to pick and engine that has a strong community, momentum, and perhaps most importantly - one that you're willing and able to dive into the internals of to fix/debug things when they go wrong.
  • Mikeb85 5y ago
    > Godot's 3D support seems promising, but at a very different level than the "big" engines While this is true, "big" games require a small legion of 3D artists. Very few indies will ever come close to maxing out Godot's 3D abilities. If you "need" a big engine you also need a multi-million dollar budget.
    • lewispollard 5y ago
      Yeah, plus engines with "AAA" graphics like Unreal always look the same unless you have that legion of technical artists to build up the lighting model and set up high quality maps and stuff. The defaults look good, but in a particular way that makes it stand out as a default Unreal engine project.
      • peterashford 5y ago
        With respect, that's not true. I did a two week project with one really talented artist and a lot of off the shelf assets and we made something pretty cool and distinctive in Unreal.
        • lewispollard 5y ago
          > one really talented artist Ok, a legion of mediocre technical artists, or one really talented one :) Edit: though I'd be curious to see if I'd recognise it as an Unreal title without pre-knowledge, of course :)
• jabl 5y ago
  > Ultimately this came from the same Amazon that had this clause in employment contracts of people NOT working in game-related parts of Amazon: > > "I grant to Amazon a royalty free, worldwide, fully paid-up, perpetual, transferrable license to any and all of my intellectual property rights associated with the Personal Game and my Personal Game development." That seems ... sucky, but what does that have to do with O3DE? AFAICT, the Apache 2.0 license doesn't force such employment contracts upon users. > From the same Amazon Game Studios that has failed to release several titles with YEARS of development in them including: Breakaway, Crucible, Lord of the Rings MMO, Intensity, Nova, etc. Are these failures due to using a particular game engine? > The same Amazon Game Studios whose "New World" MMO had health and gold client-side, allowed inserting arbitrary HTML+JS code into the game chat that would run on other's computers, could kick players from the game, etc. Are these failures due to the game engine? I get it, you hate Amazon. Fine. So what? > I don't doubt that this is open source by definition. I don't doubt that the Linux Foundation has allowed this project to live under its umbrella. But the way this came about is a far cry from being in the spirit of open source in my opinion, and rebranding it as "Open 3D" seems just a brilliant marketing trick. > In the best case scenario, Amazon's intentions are to convince the FOSS community to develop their engine to subsidize costs long-term while maintaining ownership of the project broadly, and having full control/ownership of the new "Open3D Foundation" that they can use readily for marketing[0] similar how they do to the Rust foundation[1] to hire talent. My guess is that they figured it doesn't make economic sense to develop and maintain their own engine vs using an off the shelf existing one like Unreal or Unity. So instead of just writing it off they open sourced it. In the best case it'll become a successful open source project like the Linux kernel or Blender, where the industry as a whole can save money by collaborating on a common open source engine. In the worst case it'll be a 'throw it over the wall' open source dump that will never acquire a development community and will thus eventually fade away. Time will tell.
  • slimsag 5y ago
    The employment contract point I made calls into question whether or not Amazon understands indie gamedevs, and by extension whether O3DE (as both software and a community) is developed for indie gamedevs. The game failures I highlighted call into question whether or not Amazon Game Studios produces high quality software, and by extension whether or not O3DE is likely to be high quality. Just look at the contributors to O3DE and search for "AMZN", nearly every contributor is an Amazon employee[0]. Your argument seems to be that as long as the code is open source, the rest doesn't matter. It does. My intent isn't to shit on people's work, but rather to call out that to me this feels far from some "open" initiative like Blender, GIMP, the Linux Kernel, etc. It feels more like how Android is "open source". [0] https://github.com/o3de/o3de/graphs/contributors https://github.com/o3de/o3de/graphs/contributors
• 10x-dev 5y ago
  This is just pointless drama. The fact is the code was open sourced under Apache or MIT and that's a great thing for everyone. You're free to fork the code, remove all the AWS code and build your own community around it without ever caring about Amazon. For what it's worth, as a former Amazonian who wanted to release games, the games clause did prevent me from attempting to create a commercial game, but it didn't stop me from working on games for fun.
  • drran 5y ago
    Why? It looks like an open contract for me, because price is an essential part of the contract. A contract with 0 price for all future labor is just slavery. Slavery is forbidden by law. Thus, you can make a game and then ask for reasonable compensation for your labor, e.g. $1000 per line of code.
    • 10x-dev 5y ago
      Since you're not forced to contribute the changes back to their repo, or even tell anyone that you made any changes, the slavery metaphor makes no sense to me.
• KronisLV 5y ago
  Dropping by to second Godot as a good choice for game development in 2021: https://godotengine.org/ https://godotengine.org/ I'd say that its advantages are: - small download size, easy to get started with - has a pretty shallow learning curve - decent documentation and tutorials: https://docs.godotengine.org/en/stable/ - their GDScript language is pretty reasonable: https://docs.godotengine.org/en/stable/getting_started/scripting/gdscript/gdscript_basics.html - they also support C# (even though less convenient than Unity), the performance of which is better - they also support C++, if need be (though probably a bit less convenient than in Unreal) - really good for 2D games, more convenient than Unity - unlike certain engines (Unity, which deprecated HLAPI and LLAPI), it seems feasible for multiplayer: https://docs.godotengine.org/en/stable/tutorials/networking/index.html - the node based approach to scenes composes really well, not the kind of mess that Unity's prefab system is Its current downsides are: - current stable versions are underwhelming for 3D games (and no functionality like automatic LOD in the engine, it's really nice in Unity) - a lot of the development is focused on the upcoming Godot 4 release, which isn't quite ready for being a stable release yet (e.g. wait for using it for 3D in larger projects) - GDScript is nice to get started with, but the performance can be underwhelming (for certain types of games), it has similar fragmentation to how Unity used to have with C#, Boo and ECMAScript - if you use GDScript, some patterns might be harder than others to implement, e.g. having game global services and singletons (e.g. like IaC) that handle common logic regardless of what scene is loaded - if you use GDScript, the ecosystem (e.g. package management) that's available to you is severely limited, you won't be parsing YAML or formats like that anytime soon, nor will you be talking with SOAP/gRPC APIs if the need ever arises, nor will you be sending stuff to RabbitMQ/Kafka or anything else, which in general purpose languages would be a library import (not a dealbreaker, just something to consider) - the asset store is still new, no realistic chances of being able to earn money from submitting packages there yet: https://godotengine.org/asset-library/asset (it cannot compete with the asset store of Unity) - their node based model can seem cumbersome and inconvenient for some, where each node can only have a single script: contrast that with Unity where you could have separate components for the same game object, e.g. HealthAndManaContainer, GenericEnemyAIController, SpellCastingAIController, PathfindingController, EnemyVoiceController, ... (just a random example i thought of, thinking in terms of nodes instead of having the separation between objects/behaviour takes some getting used to) - there is lots of hype surrounding the engine, but it's still relatively new, expect fewer resources than the likes of Unity have and more outdated ones because of the pace it's moving ahead at - platform support is falling behind the proprietary alternatives in regards to consoles, due to the console publishing landscape being an anti-developer dumpster fire due to the large corporations wanting to protect their IP Depending on what you want to do, those may or may not be relevant concerns. Overall, though, it's a lovely engine and i see a bright future ahead of it. I just wish that other open source engines also got more love, for example, jMonkeyEngine: https://jmonkeyengine.org/ https://jmonkeyengine.org/ Seeing how underfunded that one is made me throw some money in its direction, too (since there aren't any other 3D Java game engines with high level tooling): https://opencollective.com/jmonkeyengine https://opencollective.com/jmonkeyengine Personally, i'm torn. For commercial projects or industry employment prospects, i'd just go with Unity. The other engines are probably good too, especially for smaller indie projects that you develop for your own enjoyment, but other than that i'd maybe revisit Godot in about 5 years, to see how far it has progressed, rather than take the long way round and experience lots of breakages along the way (seeing as how Unity is past that, because they've broken everything that can be broken, from the rendering, to input systems, to networking, to ECS). Of course, if i wanted to actually be happy, i'd also look at Xenko/Stride, which was extremely promising, yet also half baked because it seems like the financial backing behind the project just died down and therefore it ever getting competitive with the larger engines just wasn't meant to be: https://www.stride3d.net/ https://www.stride3d.net/
• pixelpoet 5y ago
  > But the way this came about is a far cry Several, in fact! ;)