More poignant examples would be `dirent.h` and `system`. Getting access to the file system on a console, or the ability to start up a process out of band is not allowed.
I’m not sure how to respond frankly. You claimed my statements were ignorant. So in response, I provided a source that I agree with wholeheartedly. And a HN comment thread that provides even more criticisms.
I mean, I can add to what’s already been stated. But I’m not sure it’ll really help further the conversation. Especially when it’s being dismissed as “not nearly as bad”. So... yea.
In the event that Godot becomes insolvent, the engine loses the ability to export to console. You must have a business entity to get access to those parts of the SDK. Losing the ability to go to console is a massive hit to the viability of the engine.
From an apples to apples standpoint. What you're seeing in the video is DragonRuby Entities vs Unity GameObjects (with full functionality).
They look like particles yes, but the intent was to show the creation of fully featured constructs (not a demonstration of "fire and forget" particles).
Unity’s implementation of C# is subpar to say the least. Watch the YouTube video, it demonstrates DragonRuby’s speed vs Unity. We can render twice as many sprites and are 1/8th the size.
We also expose C Extensions to the end user if they what blinding fast performance for critical paths.
There’s four of us in the partnership (Ryan just handles the core xplat stuff). And we are leveraging a lot of OSS foundational components SDL, mRuby, LLVM.
So far so good. We’ve been in business for nearly a decade now (with the game engine going onto year 3).
> Unity, Unreal, React Native game engine, or one of the other (thousand) game engines out there?
Well our ability to deploy to console eliminates most engines as competitors/options. Unreal is a fantastic engine for 3D games. Unity is... well... not that great to be honest.
I totally understand the need for Android support back then (and to your point should have happened sooner).
With regards to relevancy, RubyMotion is built on top of LLVM. With regards to Ruby the language itself, it's been around for decades and won't be going anywhere (granted the same can be said for JavaScript).
I'm waiting to see how web assembly will shake things up.
Best of luck to you man (I genuinely mean that). And if you ever decide to come back to RM, I'll be here to help :-)