[jb3689]

My experience with DragonRuby was really poor. I was dismayed how restrictive it was (e.g. with libraries). Images were particularly painful and I was annoyed that the toolkit couldn't dynamically resize them for me (nor could I pull in ImageMagick). Perhaps it was trying to deal with sprite sheets and having to hardcode pixel offsets. Yes, it uses Ruby syntactically, but it doesn't feel like Ruby to me as far as ecosystem and productivity go. This was a few years ago - maybe this has changed. I probably wouldn't give it another go, but I'd love to see something built in DragonRuby hosted online to see what it can do.

Godot, while not perfect, fit my expectations better. I found myself simply using the prebuilt abstractions I was already building by hand in DragonRuby. Things mostly work. When it came time to cross-compile for hosting on itch.io, I was really delighted by how easy it was to get my games in front of people. That quick feedback loop got me hooked for a while.

[vr46]

Godot is pretty good, I wish I had more time to spend with it. DragonRuby reminds me of RubyMotion, the magical framework to write cross-platform apps that was also hopelessly disappointing and over-hyped. A complete waste of my money.

And then I went to check out the DragonRuby and RubyMotion websites and it turns out that DragonRuby IS RubyMotion.

Kudos to the team for building something clever but I'm not falling for that one again.

[pdc56]

My dream would be mruby or full ruby in Godot. OMG that would be all my xmas's all at once

[Mikeb85]

> My dream would be mruby or full ruby in Godot.

There's a C API for Godot and GDExtension. It should be easy and it has been done before (but not maintained). The problem is that it's just far slower than GDScript or C#.

[KronisLV]

> It should be easy and it has been done before (but not maintained).

Here's one such example of Ruby in Godot: https://github.com/onyxblade/godot-ruby

> The problem is that it's just far slower than GDScript or C#.

I'd say that depending on what you're doing, you can get away with a lot even in slower language runtimes, otherwise we'd be writing all of our game code in C, C++ or Rust (or other languages like that) only.

I actually ported the Godot LOD plugin from GDScript to C# a while back to what the performance would be like between the two supported languages: https://blog.kronis.dev/articles/porting-the-godot-lod-plugi... and found that the performance was comparable (so language runtime performance itself doesn't matter that much)

As long as you don't do too much number crunching every frame, you should be fine, especially if the engine itself does most of the heavy lifting. Of course, when it comes to the performance impact of interop between different languages/components, that might be a different story.

But hey, it's not like challenges like that can't be overcome due to some inherent limitations, even the Unity game engine sees popularity of MoonScript (which runs Lua under the hood), as far as I can tell. And in regards to games in general, the whole S.T.A.L.K.E.R. game series used Lua for scripting, if my memory doesn't fail me.

[Mikeb85]

The problem isn't just Ruby speed, it's that GDScript exists and Ruby doesn't really offer any benefit over it. If there were no scripting language, sure, hook up Ruby. But GDScript is good.

[KronisLV]

> But GDScript is good.

Agreed, GDScript is pretty nice for working with the engine.

> The problem isn't just Ruby speed, it's that GDScript exists and Ruby doesn't really offer any benefit over it. If there were no scripting language, sure, hook up Ruby.

However, I'm inclined to say that familiarity with a language might be reason enough to choose to use it, if there are no other significant dealbreakers! If you like C++, use C++. If you like Rust, use Rust. If you like Python, Lua, or Ruby use those... as long as someone has done the work to make that possible (or you want and can do that yourself).

GDScript is nice and easy to pick up, but someone who has used .NET for close to a decade might benefit from using some C#, or maybe they like the refactoring or other functionality that an IDE like JetBrains Rider might provide, especially with the occasional nice plugin for the engine itself popping up: https://plugins.jetbrains.com/plugin/13882-godot-support (to be honest, I really liked the Rider plugin for Unity as well, which made writing code a more pleasant experience).

Secondly, there's also the question of an ecosystem, which may or may not work depending on how well any runtime integrates with the engine and what the situation for packaging various libraries/dependencies is (since sometimes you need to deal with native code in Ruby and others). But when it works, you can get a library for basically anything you might want to do: a novel game with AI processing? There are libraries for that. Want to hook up your own netcode solution? There's probably a solution for that. Want to do compression, or work with a variety of file formats, or add dynamic scripting, or interact with a web service of some description? Those are solved problems in some languages, with the solution being just a library away.

Of course, most games probably don't need anything that fancy and the engine has bits of nifty functionality in it, like making web requests, for example, but overall being able to benefit from a rich ecosystem is also good, especially when you decide to do something a bit more novel.

At the end of the day, use whatever works for you: for someone that might be GDScript with its nice integration with the engine and easy syntax, for someone else that might be C# with its static type system and rich IDE support, whereas someone else might be a bit more brave and go off the beaten path further!

[brettcodes]

Thanks for sharing your experiences with the engine. I know what you mean by the ecosystem doesn't feel quite like Ruby—you can't pull in gems from RubyGems.org (but there is a dependency tool called Smaug) and it's not as focused on OO as most Ruby is. But after I spent my first few weeks making games with it, I came to realize lack of a huge dependency tree is a benefit. The engine doesn't have strong opinions on how you code your games, but it gives the tools to do so in a more functional mindset than most Ruby code. The API is data-driven, meaning you can work with just hashes or arrays and methods and get really far with your projects. You can abstract away into classes and modules if you need to.

I'm actively working on an interactive showcase of the samples and open source DragonRuby games here: https://dragonridersunite.itch.io/dragon-os

You can browse more games made with DRGTK here: https://itch.io/games/made-with-dragonruby-gtk

There's also the official samples page, which includes commercial games shipped to Android, iOS, and Switch: https://dragonruby.org/toolkit/game/samples

I think any type of 2D game is possible to build with the engine. But it's up to the community (and time) to make great games with it.

+ just wanna say I'm glad you dig Godot! There are so many game engines and libraries out there, and what matters most is finding one that fits your needs and style well. Because ultimately, what's most important, is that the game gets made, regardless of tech.

[weaksauce]

dragon ruby uses mruby which is a much more constrained ruby designed to be embedded into applications and does constrain your gem use some.

[stevenwoo]

What language did you finish your projects with Godot and what language did you have to use on itch.io?