Game Engines on Steam: The Definitive Breakdown(gamedeveloper.com)
gamedeveloper.com
Game Engines on Steam: The Definitive Breakdown
https://www.gamedeveloper.com/business/game-engines-on-steam-the-definitive-breakdown
68 comments
Is Unity used in less blockbusters (or AAA titles)?
Yes. Unreal is the most popular non-proprietary engine for AAA by far.
Isn't Unreal source-available proprietary, as opposed to non-proprietary?
I may be wrong, it's been a while since I looked at engines.
I may be wrong, it's been a while since I looked at engines.
Non-proprietary in this context is generally understood to mean "not an in-house engine"
Like how EA has Frostbite that's only used for in-house titles
Like how EA has Frostbite that's only used for in-house titles
Ah, that makes sense.
Thank you for the correction!
Thank you for the correction!
Correct.
Source-available proprietary.
https://www.unrealengine.com/en-US/ue4-on-github
https://www.unrealengine.com/en-US/ue4-on-github
I'm surprised Godot doesn't even appear
Godot is severely undercounted because of its export format -- many Godot games are just a single EXE! There are actually a few hundred Godot games we could detect (the ones exported in a particular format), but not in the particular criteria for this report.
https://www.gamedatacrunch.com/steam/list/all/reviews_total/...
https://www.gamedatacrunch.com/steam/list/all/reviews_total/...
I'm not—has anything notable shipped with it yet? it's a cool engine and I'm sure there's a nonzero number of Godot games on Steam but it's not surprising it doesn't show up in metrics like these yet
Next week the answer to your question is probably "yes" https://twitter.com/NathanGDQuest/status/1430992735192985605
Juan made it very clear in a follow up tweet that Sega would have had to have made significant changes to the engine in order to ship a game on it.
I spent three months working in Godot a few years ago and it was clear even then that there were significant bugs in major systems. If you want to ship on Godot you had better be prepared to roll up your sleeves and dive right down deep into the engine.
This is one of the few bugs I logged before finally giving up on the engine.
https://github.com/godotengine/godot/issues/32383#issuecomme...
The object pooling system reuses references so that your script can't tell when a reference to an object it is holding, changes. They doubled down on the bug by making the behavior in Debug different to a Release build. It's marked closed, but users still report it happening.
I spent three months working in Godot a few years ago and it was clear even then that there were significant bugs in major systems. If you want to ship on Godot you had better be prepared to roll up your sleeves and dive right down deep into the engine.
This is one of the few bugs I logged before finally giving up on the engine.
https://github.com/godotengine/godot/issues/32383#issuecomme...
The object pooling system reuses references so that your script can't tell when a reference to an object it is holding, changes. They doubled down on the bug by making the behavior in Debug different to a Release build. It's marked closed, but users still report it happening.
Aside from whether this should be fixed, that's a classical problem not unique to godot: https://en.wikipedia.org/wiki/ABA_problem
The real problem is that you are not properly managing the lifetime of your objects so you have dangling references. Obviously Godot could provide better tooling to help you identify and troubleshoot it, but dangling references like that will cause breakage in basically any runtime environment that makes it possible to have them.
IDs of that sort can be reused in many environments. For example, if you use Unity, .NET GCHandle IDs can be reused in the exact same way.
The real problem is that you are not properly managing the lifetime of your objects so you have dangling references. Obviously Godot could provide better tooling to help you identify and troubleshoot it, but dangling references like that will cause breakage in basically any runtime environment that makes it possible to have them.
IDs of that sort can be reused in many environments. For example, if you use Unity, .NET GCHandle IDs can be reused in the exact same way.
Sure, there are easy workarounds, but the issues are unexpected and secret (and now only in release). In any other scripting language I've worked on you can do some test on a reference to see if its null or doesn't exist. In Godot you have to listen for the object reference leaving the scene.
I can guarantee this is not an issue in Unity where a object that has been removed from the scene is null.
I can guarantee this is not an issue in Unity where a object that has been removed from the scene is null.
As it happens, Unity has its own version of this problem, where it pretends that a non-null dangling reference is a null-reference:
https://jacx.net/2015/11/20/dont-use-equals-null-on-unity-ob...
That is not the same at all. The equivalent would be that your reference is pointing to some other object in the scene.
> In any other scripting language I've worked on you can do some test on a reference to see if its null or doesn't exist.
Except - and this is called out in the github thread - the reference is not null and does exist. The check is working correctly.
The problem lies in the fact that what you want to check for is "is the object I originally pointed to still around?", but instead of doing that, you're checking "is the thing I'm pointing to currently a valid object?".
Except - and this is called out in the github thread - the reference is not null and does exist. The check is working correctly.
The problem lies in the fact that what you want to check for is "is the object I originally pointed to still around?", but instead of doing that, you're checking "is the thing I'm pointing to currently a valid object?".
Yes, but read further, there is no method to test whether the object I pointed to still exists. You have to listen for a signal that the object is leaving the scene and manually clear your reference.
> there is no method to test whether the object I pointed to still exists
There probably is such a method, but you'd have to invoke it on the object, not on some other unrelated object.
There probably is such a method, but you'd have to invoke it on the object, not on some other unrelated object.
https://docs.godotengine.org/en/stable/classes/class_%40gdsc...
I'm making a complex Godot game.
'is_instance_valid' does what you are describing.
I'm making a complex Godot game.
'is_instance_valid' does what you are describing.
Only in Debug builds. If you rely on it in a release build you will crash.
https://github.com/godotengine/godot-proposals/issues/1589 https://github.com/godotengine/godot/issues/41179
Reduz doesn't want the fix in release builds because the will be slower!
https://github.com/godotengine/godot-proposals/issues/1589 https://github.com/godotengine/godot/issues/41179
Reduz doesn't want the fix in release builds because the will be slower!
I don't understand. That's not what that PR says. That PR is about using == null. It offers no substantial information about is_instance_valid.
Apologies, you might need to do some digging and research on your own.
On Oct 2 @RandomShaper said "is_instance_valid() was made thread-safe, but it's still not something you can trust. An object allocated at the same address as a freed one will report a false positive. That's, of course, considering that what you want to check is that your variable is still pointing to the object you assigned, and not to just some object, which I think is the case.
@reduz respoinded with "Ah that may be still the case of 3.2, but in 4.0 this function is 100% trustworthy"
On Oct 2 @RandomShaper said "is_instance_valid() was made thread-safe, but it's still not something you can trust. An object allocated at the same address as a freed one will report a false positive. That's, of course, considering that what you want to check is that your variable is still pointing to the object you assigned, and not to just some object, which I think is the case.
@reduz respoinded with "Ah that may be still the case of 3.2, but in 4.0 this function is 100% trustworthy"
My experience back in 2018 was similar. I wanted to do some fairly simple 2D things and it was quite a lot of hassle. I’m sure the issues I hit are fixed now, but at the time it was frustrating.
With that said, I’m still happy to have contributed a little bit of code to gdnative. Nothing exciting, just some quality of life stuff I wanted at the time (a few variadic template wrapper functions around the C api to avoid having to manually construct godot list objects of parameters). Last I checked it was still in use, although moved to a different file.
With that said, I’m still happy to have contributed a little bit of code to gdnative. Nothing exciting, just some quality of life stuff I wanted at the time (a few variadic template wrapper functions around the C api to avoid having to manually construct godot list objects of parameters). Last I checked it was still in use, although moved to a different file.
One of the funniest moments I've experienced with Godot while developing the FitOwl [1] was the behaviour of a flag that governs sleeping state of RigidBodies. That flag was meant to exclude the body from physics-related computations to save some CPU-cycles and it just didn't work.
When I reported the issue to the bugtracker, I was asked by devs literally "I still don't understand the issue you're experiencing. Aside from saving resources, why is it important that Rigidbodys are asleep?"... I was (and still is) speechless from that attitude, because, c`mon guys, the sole reason for that flag is to save some resources! But they didn't really cared about that, just reworded the docs a little and happily closed the issue.
Moreover, I got an email from one of the Devs stating that I'm violating their Code of Conduct for the phrase "I'm struggling to not interpret your comment as a joke.".
That was the last time I tried to take part in Godot improvement...
[1] https://news.ycombinator.com/item?id=28402743
When I reported the issue to the bugtracker, I was asked by devs literally "I still don't understand the issue you're experiencing. Aside from saving resources, why is it important that Rigidbodys are asleep?"... I was (and still is) speechless from that attitude, because, c`mon guys, the sole reason for that flag is to save some resources! But they didn't really cared about that, just reworded the docs a little and happily closed the issue.
Moreover, I got an email from one of the Devs stating that I'm violating their Code of Conduct for the phrase "I'm struggling to not interpret your comment as a joke.".
That was the last time I tried to take part in Godot improvement...
[1] https://news.ycombinator.com/item?id=28402743
A lot of ports, especially from Japan, only do menus and graphics in new/general-purpose engines and use a native library with their old codebases for logic.
I can imagine that this was done here, Godot isn't really ready for a game like this IMO - it would have taken a huge amount of work.
I can imagine that this was done here, Godot isn't really ready for a game like this IMO - it would have taken a huge amount of work.
yooooo that's rad! great news for Godot!
https://store.steampowered.com/app/975150/Resolutiion/ felt quite good to me. It's not an AAA title, it's not graphically complex, doesn't have thousands of actors on screen. But the engine does the task very well.
that's awesome, it's going to be great to see Godot getting more and more market share as it matures in the coming years.
List of godot games on steam: https://steamcommunity.com/app/404790/discussions/0/41244879...
Yes my favorite game right now: Cruelty Squad
https://store.steampowered.com/app/1388770/Cruelty_Squad/
I looked at the trailer on steam and now my eyes bleed. I guess it is a lot of fun though?
A YouTube comment described it best:
"Someone spent a ton of time to make sure this game is designed and plays great, and then spent just as much time making it look like it doesn't."
I agree that the game looks like vomit, but it's really fun to play and it has a lot of personality (partly because of the visual design). It's worth playing, imo.
Cruelty Squad's artstyle feels like someone getting every answer wrong on their art test on purpose. Then sticking with it and making it feel sort of cohesive in the end anyway.
It certainly grew on me more and more as I played it.
Not to mention that the actual gameplay is incredibly fun. With varied gear options, replayable missions with new gear and lots of secrets to find.
Not to mention that the actual gameplay is incredibly fun. With varied gear options, replayable missions with new gear and lots of secrets to find.
Well there's definitely a mistake there - Borderlands 2 is an Unreal engine game, not XNA.
A notable XNA game not included in the list is Braid.
A notable XNA game not included in the list is Braid.
Braid was covered by the criteria.
>Finally, we only looked at games launched since 2010.
Braid was released on Steam in mid-2009.
>Finally, we only looked at games launched since 2010.
Braid was released on Steam in mid-2009.
[deleted]
Braid was not made with XNA. It used a custom game engine. I think it was just on XBLIG?
All XBLIG titles are XNA, Braid was a regular XBox Live Arcade game (XBLIG being 'Indie Games', self-published)
Also XNA isn't an engine.
Depends on your definition of "engine". XNA was a set of APIs and tools for game development. Game engines are also a set of APIs and tools for game development, although usually a bit more integrated than XNA. But before Unity and Unreal Engine became the "default engines" the term was used much more losely, often only for the runtime parts, not the authoring tools.
[deleted]
We welcome your contributions
https://github.com/SteamDatabase/FileDetectionRuleSets
(it might be a false positive; or just as likely there is some utility app or launcher tucked in with it that was written in XNA, in which case it's a match for both engines -- that has happened for a lot of titles)
(it might be a false positive; or just as likely there is some utility app or launcher tucked in with it that was written in XNA, in which case it's a match for both engines -- that has happened for a lot of titles)
I'm really hoping Jonathan Blow sees this and responds to it :)
He’s too busy making a new programming language for his next game
Interesting that Unity moved into the #1 spot. Does anybody have any hypotheses on the basis for that? Lower learning curve? Better developer support?
I've worked on both. I worked at Irrational with Unreal on about 3-4 games until we shipped Bioshock 2 and recently released Void Bastards on Unity.
Unreal is heavily oriented towards 1st or 3rd person walking around a level. Unity begins with a blank slate for really any kind of game.
The visual scripting in Unreal is a turn off, and nobody want to work in c++. Working in C# for Unity is a real pleasure.
Unreal is heavily oriented towards 1st or 3rd person walking around a level. Unity begins with a blank slate for really any kind of game.
The visual scripting in Unreal is a turn off, and nobody want to work in c++. Working in C# for Unity is a real pleasure.
Not discounting your experience, but Bioshock 2 was based on UE2.5... from the early to mid 2000's ... and that was a long time ago, not sure how you can realistically expect that to compete with recent Unity. Unrealscript is gone and ... replaced with a new visual scripting engine (which I agree has some problems, being impossible to diff being one of them). UE4/5 also ship with a bunch of templates, including completely blank, flying, wheeled vehicled, advanced wheel vehicles etc.
Yeah sure, I've been trying to stay up to date by building small prototypes in new releases. It really is amazing how fast you can get a multiplayer shooter up and going!
But come on, blueprints really do suck. Even with all the cool debugging and watching the flow and all that stuff. The tech is amazing, but I just don't want to code like that.
But come on, blueprints really do suck. Even with all the cool debugging and watching the flow and all that stuff. The tech is amazing, but I just don't want to code like that.
Because they aren't meant for you (assuming you're an engineer). They're meant for level scripting, simple prototyping, stringing together systems written in lower level (C++) code, and beginners.
They absolutely don't suck when used in the intended way. I'm not a fan of writing code in visual languages either (worse information density, slower to write the code, harder to debug) but if all you're doing is wiring up some triggers in a level? Hell yeah, it's great. Need to fire a bunch of events over time, maybe do some super simple code-drive animation? Timelines and latent actions are way easier than the textual equivalents. And extending it is dead simple which makes it easy to write something in C++ to be used from Blueprint.
It's also worth noting that Unreal's C++ has many of the niceties of C#. I won't say it's as easy to use (it isn't) or that Unreal gets rid of some of the eccentricities of the language or build system (it doesn't, and Unreal's build system - while nice - is incredibly under documented), but Unreal does provide garbage collection (and even reflection) which takes a big part of the burden of C++ away.
They absolutely don't suck when used in the intended way. I'm not a fan of writing code in visual languages either (worse information density, slower to write the code, harder to debug) but if all you're doing is wiring up some triggers in a level? Hell yeah, it's great. Need to fire a bunch of events over time, maybe do some super simple code-drive animation? Timelines and latent actions are way easier than the textual equivalents. And extending it is dead simple which makes it easy to write something in C++ to be used from Blueprint.
It's also worth noting that Unreal's C++ has many of the niceties of C#. I won't say it's as easy to use (it isn't) or that Unreal gets rid of some of the eccentricities of the language or build system (it doesn't, and Unreal's build system - while nice - is incredibly under documented), but Unreal does provide garbage collection (and even reflection) which takes a big part of the burden of C++ away.
I'm a level designer and artist that now codes because Unity makes it easy. :)
Fair enough. If you're working on smaller projects I totally understand where you're coming from. Unreal's workflows are very much built with an eye towards large teams/AAA where there's a very hard division between engineering/design/art, and having a simpler language (blueprint) that doesn't require much training and that engineering teams can use to expose just what's necessary is a benefit rather than a detriment.
Unfortunately Unreal doesn't really have a middle ground - something between the complexity of C++ and the simplicity of Blueprint. There's been rumblings of a new text-based scripting language (Verse - https://twitter.com/saji8k/status/1339709691564179464) but it hasn't been officially commented on by Epic outside of a single presentation where it was shown in relation to Fortnite.
Unfortunately Unreal doesn't really have a middle ground - something between the complexity of C++ and the simplicity of Blueprint. There's been rumblings of a new text-based scripting language (Verse - https://twitter.com/saji8k/status/1339709691564179464) but it hasn't been officially commented on by Epic outside of a single presentation where it was shown in relation to Fortnite.
Exactly, blueprints might be OK for opening a trigger when you open a door, but there are huge chunks or game logic that needs to be written by game designers.
Magic Armour gives you +15 health and Orcs spawn in the Forest after the Spider Queen is defeated.
You don't want to have to go to the programmers when the behavior of magic amour changes or when Orcs have some other prerequisite.
Can't wait to hear more about this Verse.
Magic Armour gives you +15 health and Orcs spawn in the Forest after the Spider Queen is defeated.
You don't want to have to go to the programmers when the behavior of magic amour changes or when Orcs have some other prerequisite.
Can't wait to hear more about this Verse.
>"and nobody want to work in c++ ..."
I have no idea about game industry as I am not there but I use C++ for business backend servers and have no problems or desire to replace it for this particular task. Modern C++ is a pleasure to work with unless one's ego can not tolerate / accept the fact that you do not need to be Alexandrescu to be productive.
I have no idea about game industry as I am not there but I use C++ for business backend servers and have no problems or desire to replace it for this particular task. Modern C++ is a pleasure to work with unless one's ego can not tolerate / accept the fact that you do not need to be Alexandrescu to be productive.
The problem with modern C++ is that everyone has to be into it.
Plenty of shops are more than happy to keep coding like the world has frozen since C++98.
Even if you look at Microsoft and Google sample code, or Android codebase, it is a bit debatable how much modern it actually is, and yet they are on ISO.
Plenty of shops are more than happy to keep coding like the world has frozen since C++98.
Even if you look at Microsoft and Google sample code, or Android codebase, it is a bit debatable how much modern it actually is, and yet they are on ISO.
>"The problem with modern C++..."
Every language has its own share of problems
>"Plenty of shops are more than happy to keep coding like the world has frozen since C++98"
And if they're comfy then good for them.
Every language has its own share of problems
>"Plenty of shops are more than happy to keep coding like the world has frozen since C++98"
And if they're comfy then good for them.
And quite good for anyone doing security audits, due to the coding practices adopted by them.
Plenty of stuff to report on.
Plenty of stuff to report on.
Yes to both.
There was a time when Unity had momentum because it was free* and the documentation was (comparatively) better than Unreal for the average user.
The learning curve for unity is arguably better for 3D and inarguably better for 2D than Unreal.
*The seat cost for unity has been low (albeit changing over time), but you could release and ship a video game without paying for anything
There was a time when Unity had momentum because it was free* and the documentation was (comparatively) better than Unreal for the average user.
The learning curve for unity is arguably better for 3D and inarguably better for 2D than Unreal.
*The seat cost for unity has been low (albeit changing over time), but you could release and ship a video game without paying for anything
I played with a dozen different game engines before settling on Unity, mainly because the quantity and quality of the tutorials/guides and community around it. I have to search less to find my answers compared to other engines.
Unity is a more generic game engine, Unreal is more specialized.
C# is an easier language for most. C++ (particularly UE's flavor) is more difficult.
Unity is much easier for a single person or small team. Unreal is designed in mind for teams with dedicated designers, artists, audio, engineering, animators, etc.
For a long time, Unity fought to be anything more than just 3D Flash. It wasn't taken seriously. And for good reason. About a decade ago I worked on what was at the time considered to be one of the largest Unity codebases in existence. It was rough. Unity's come a long way since then.
C# is an easier language for most. C++ (particularly UE's flavor) is more difficult.
Unity is much easier for a single person or small team. Unreal is designed in mind for teams with dedicated designers, artists, audio, engineering, animators, etc.
For a long time, Unity fought to be anything more than just 3D Flash. It wasn't taken seriously. And for good reason. About a decade ago I worked on what was at the time considered to be one of the largest Unity codebases in existence. It was rough. Unity's come a long way since then.
Unity is cheaper if you plan to actually make money. Unity charges by seats, Unreal takes royalties.
One potential reason is that the 2d support in Unreal is not very good.
Although it isn’t available on Steam (and so excluded from the data) Escape From Tarkov is built using Unity and it looks and functions incredibly.
I've been working on a side project using Unity. With HDRP you can make things look very nice, at this point I'm only limited by my own time.
You can buy Gaia, use HDRP and have a beautiful forest in about 3 minutes.
You can buy Gaia, use HDRP and have a beautiful forest in about 3 minutes.
I only recently found out about:
https://o3de.org/
https://github.com/o3de/o3de
Seems to be opensourced engine based on Amazon's Lumberyard engine, which itself was based on Crytek's engine (!!).
https://o3de.org/
https://github.com/o3de/o3de
Seems to be opensourced engine based on Amazon's Lumberyard engine, which itself was based on Crytek's engine (!!).