Given their limited shelf-life, I’d have thought this would be less of an issue for games than for other software? Many games rely on Lua, for example, which is maintained by a team of just 3 people, and it seems only one of them writes most of the code.

https://github.com/lua/lua/graphs/contributors

True for a single game, but developers don't like to learn an entirely new system every time they make a new product. With Unreal and Unity, you might have to learn a few new things when new major versions come out, but your old knowledge is still very much applicable. And if any 1 developer quits working on those engines, it's going to keep trucking along.

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.

This particular objection doesn't worry me, because all the really effective 'engines' I know about, that provide an environment to be built upon by others, are originated by and run by a single visionary person.

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.

In general I don't think I'd be comfortable using any type of engine or framework which is solely developed by one person.

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.

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.

With regards to insolvency. It’s answered in the FAQ: http://docs.dragonruby.org/#--frequently-asked-questions,-co...

I'm not a game dev, but I just want to say thanks for working on this. I empathize and also don't quite understand how the "let's shit on ruby" sentiment spreads even to this, and I was pleasantly surprised to see Among Us is built on dragonruby!

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.

FWIW I think the issue is more that it's closed source than that it's using ruby.

Where did you hear that Among Us was built on DragonRuby? All I can find is that it was written in C# and Unity.

I saw it on the itch website and thought it was for ruby projects, so perhaps I'm mistaken.

itch.io isn't exclusive to ruby games, it hosts games made in any engine. above commenter is correct, Among Us was made in Unity https://innersloth.itch.io/among-us hit more info to see the engine details

> crazy

> camp on the beaches of Jamaica

This sounds great.

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.

Godot doesn't directly offer console support anyway

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.

Details about the runtime are here if you’re interested: http://docs.dragonruby.org/#----what-is-dragonruby?

I’m guessing it’s native extensions rather than a custom ruby implementation.

It seems to be a custom implementation based on mruby and LLVM.

See “What is DragonRuby?” at http://docs.dragonruby.org/.

Huh, ok. When they mean Scadia do they mean Stadia.