> DragonRuby is powered by highly optimized C code written by Ryan C. Gordon.
This feels like a liability for the long term. The community is now depending on Ryan to maintain this custom Ruby implementation, if I'm reading correctly.
> DragonRuby is powered by highly optimized C code written by Ryan C. Gordon.
This feels like a liability for the long term. The community is now depending on Ryan to maintain this custom Ruby implementation, if I'm reading correctly.
But the worry here is that if the main developer of DragonRuby quits, it's dead in the water. Sure, you can use the old version and it'll probably still work, but there won't be any improvements, whereas other engines are constantly improving.
From my perspective, this is an asset rather than a bug, provided the person is committed to his project. It's a guiding force that stops it being a vague laundry list of feature requests.
Let's say he goes crazy tomorrow and decides to camp on the beaches of Jamaica. No matter what you do, particularly with a closed source engine, you're stuck.
With unity if one programmer decides to quit, we still have a game engine that gets updated.
With Godot if both of the paid maintainers quit and the project collapses, you can just fork it and keep going.
With regards to insolvency. It’s answered in the FAQ: http://docs.dragonruby.org/#--frequently-asked-questions,-co...
I always love to see ruby's focus on developer productivity being spread, and if I decide to take a crack at making a game, I'll be sure to check this out.
> camp on the beaches of Jamaica
This sounds great.
https://docs.godotengine.org/en/3.0/tutorials/platform/conso...
Realistically this means if porting to console is a priority you should go with one of the dominate engines, Unreal or Unity.
See “What is DragonRuby?” at http://docs.dragonruby.org/.