Game Engines on Steam: The Definitive Breakdown
gamedeveloper.com
gamedeveloper.com
A notable XNA game not included in the list is Braid.
>Finally, we only looked at games launched since 2010.
Braid was released on Steam in mid-2009.
(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 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.
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.
I can guarantee this is not an issue in Unity where a object that has been removed from the scene is null.
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?".
There probably is such a method, but you'd have to invoke it on the object, not on some other unrelated object.
I'm making a complex Godot game.
'is_instance_valid' does what you are describing.
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!
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"
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.
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...
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.
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.
https://www.gamedatacrunch.com/steam/list/all/reviews_total/...
You can buy Gaia, use HDRP and have a beautiful forest in about 3 minutes.
Seems to be opensourced engine based on Amazon's Lumberyard engine, which itself was based on Crytek's engine (!!).
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
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.
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.
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.
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.
Plenty of stuff to report on.
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.
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.
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.
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.
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.
I may be wrong, it's been a while since I looked at engines.
Like how EA has Frostbite that's only used for in-house titles
Thank you for the correction!