Show HN: DragonRuby Game Toolkit
dragonruby.org
dragonruby.org
I did a Rails job once. I kept thinking that I liked the language as a kind of modern OO language in the spirit of Python (and also Lua a bit) but I really disliked the ecosystem around Rails. For instance, the project I worked on had to maintain two separate versions of Ruby because different gems worked with different Ruby versions (it's been a while so I don't remember details).
Another thing that bothered me is that everytime I searched online for help to do something slightly more advanced in Ruby my search results were inundated with "hello world" style posts from aspiring Rails devs eager to advertise their passionf or Rails. I could never find the information I wanted, so I had to do everything the hard way.
Overall I had a horrible experience with Rails though I'm sure it's far from that bad for most. Anyway it's refreshing to see a cool use of Ruby without the Rails.
I've been learning React and played around with a Rails API backend and separate React front-end and I forget just how much work Rails takes out
I really wish people didn't associate Ruby so much with Rails.
But yes, it really is a shame that Rails seems more parasitic on Ruby than not and hasn't lead to a larger general purpose Ruby community.
The "hotloading" is really nice and the community on Discord is excellent.
Coincidentally because of that use case I just remembered yesterday that I had a PR open on Ruby2D...
Looks like a great resource.
http://www.rubymotion.com/news/2019/04/19/plans-for-rubymoti...
I remember Ruby Motion was a thing, then it wasn't... then it was again? I started learning web dev with RoR and quickly moved to Python as the ecosystem was so much bigger. I could transfer my Python knowledge into so many different domains. I remember at the time, I really wanted a "Ruby Motion" for Python... still do actually.
I have come full circle and now think JS is eating the world and I am playing in that garden... we'll see where that ends up I suppose. In any case, GOOD LUCK... I hope for the best!
From my experience so far one big point in favor of DragonRuby is that its philosophy focuses on developer productivity, for example
- an iterative immediate feedback style of development using hot reloading
- (in the latest version) direct source code editing and updating via a HTTP Developer interface (think updating your smartphone game at runtime without re-deploying)
- Producing builds for all Desktop platforms in usually less than a minute (mobile and consoles probably take longer considering the surrounding tasks of signing apps, registering in stores etc)
- offering a centralized interface for persistent game state which is automatically dumped for error analysis in case of failure and able to be recorded/replayed/rewinded out of the box during dev
- Abstracting away File Systems/Storage mechanisms out of the box so you don't have to care about where you save on a Switch, PC or iPhone
and probably lots of other stuff I'm not quite aware of atm.
Another big plus point is the lively and encouraging Discord community
It probably is, and that is just fine. As long as enough of us value being able to use Ruby they'll do ok. Not everything needs to aim to become a unicorn.
Sure you can try out your game immediately in the editor, by pressing the play button - but can you edit Source code and it will be immediately applied without restarting and without losing the current game state?
You can edit and adjust scene objects in the inspector during play mode but those changes are usually thrown away after quitting play mode.
I never did serious mobile dev with unity but I same as above... updating and editing your game source persistently at runtime during playing doesn't seem possible, since it's completely compiling everything into an Android package right?
Building for all desktop platforms under a minute - this is 100% not true..... Almost all of the last hours of game jams where I used unity where spent in worry waiting for a long build process not being sure everything works all right afterwards - and that was always for just _one_ platform at a time...... DragonRuby builds your games into fully functional Windows, Mac, Linux, HTML5 and FWIW Raspberry Pi builds in under a minute in total for all those platforms. I don't know of any other Engine (except maybe LÖVE2D which is interpreted in its basic nature and doesn't need building) which can do anything close to that speed
Persistent flexibly modifiable game state? - maybe there's something in the asset store - but out of the box?
Cross-platform File storage is the only thing where I can see that that is probably a well solved problem in Unity....
I cannot speak for the other game engines. But in general it would be nice if you back up your claims.....
Godot is smaller and has way way less learning material (and no Asset Store), but purely from an Editor perspective it's miles ahead from a dX perspective.
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.
Other differentiators are on the site.
I don't choose games based on their engine I choose them based on if they are fun. Same as I don't choose movies based on what camera was used to shoot them or what software was used to render the CGI scenes.
The market for a game engine is not players. Most games could be written with almost anything.
Unity employed Mike Acton a few years ago, who is now lading their transformation to a data oriented backend. They are switching everything out for a pretty well thought out Entity-Component-System (not the old Component stuff you had in unity, but a way of saving your game data in arrays of the same type for performance, instead of as objects with data that should not be together in memory). I have not kept up in the last year, but already a year ago this was showing many promising results, being able to simulate enormous amounts of agents in games: https://www.youtube.com/watch?v=L9_7QYaeNjc
Unreal and Godot have their good sides (Unreal being great for non-coders and/or if you want to an FPS, Godot being able to bind to many languages in the backend and being open source). But none of them is doing the same huge transformations in the backend as unity.
On some tiny synthetic benchmark maybe.
Come back when your engine can handle something even 1% as complex, as say, Dyson Sphere Program.
Surely Unity has more overhead and DragonRuby can make more optimizations.
(a recent example of some dots I moved) https://twitter.com/LeapJosh/status/1378056437105049603
Not saying DragonRuby isn't the bees knees, I've never used it but appreciate alternatives existing.
Despite that, sprites are the wrong facility for drawing that many dots in unity.
Per particle gravity and forces are batteries included. If you want GPU particles that can collide with other particles there's Fluvio, it's free.
Here's 65k https://www.youtube.com/watch?v=jwzfr9ppvj4
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).
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.
A good reason would be that RoR is still a competitive advantage for indie web devs and small startup teams working on non performance-constrained domains.
It's amazing how many successes In see in the IH world using Ruby despite far larger numbers of people building everything in JS or maybe Python.
Dev experience matters and there are some durable advantages the Ruby ecosystem has maintained despite others growing more quickly in popularity. Building DSLs is one.
You can see all the reasons
1. Their custom engine doesn't have all the features of either of those other engines. Their artists in particular are pushing to switch to get those features.
2. Their custom engine doesn't have have amount of tooling those other engines have (likely no blueprints, no shader graph, no state machine editor, no animation editor, etc..., etc..., etc...)
3. Their custom engine doesn't have tens of thousands of potential hires that already have experience with them.
4. Their custom engine doesn't have 1/1000th the amount of docs, tutorials, youtube videos, etc on how to use it so the team that maintains that engine has to provide that knowledge to every new hire
The result of the above is it limits their growth. If they want to start a new team for a new game, if they stuck with their custom engine they'd basically have to take a significant number of people off the existing game and move them to the new game otherwise no one on the new game would have any easy way to know how to use it.
For my part, I don't have enough spare time to learn one of the big engines. They're too complex, and this is a hobby.
DragonRuby on the other hand is simple enough that you can start doing stuff immediately if you know even basic Ruby. That is the appeal to me.
Whether or not it would work for a large team is totally irrelevant for that kind of use, because I have no interest in starting a studio.
It seems a lot of the people criticizing DragonRuby in this thread forgets that game dev spans from hobby development by individuals who might toy with it a few hours a week to multi year projects by major companies, and they have different needs and interests.
E.g. I value having fun over ever completing a publishable game. DragonRuby is fun.
That I could release something with it is a bonus, but to me even that is secondary.
So no, Unity is not "too complex" and it's very suitable for hobby use.
That I also don't have to use a language I consider absolutely awful is another major bonus.
It will via asm.js, except no one will be coding in JS anymore since everything will compile to asm, and you will have asm compiler in your kernel.
(I don’t have an exact source for this, it’s something that seems to come up periodically when talking about Ruby. Matz mentions it briefly when introducing mruby. I also don’t necessarily think it was conceived for this reason, but rather that over time, it fell into the niche and became influenced by it. But I’m not sure about that, either.)
We also expose C Extensions to the end user if they what blinding fast performance for critical paths.
Do you have any concrete numbers on compute (ie. scripts)?
Do you support shaders?
eg. How would you do this in DragonRuby? --> https://github.com/keijiro/StableFluids
Ie. a compute buffer that renders a fluid simulation in real time?
These are other demonstrations of DRGTK’s performance capabilities: - https://twitter.com/Groteskly/status/1373668110482427906 - https://twitter.com/amirrajan/status/1361640855589842951 - https://twitter.com/amirrajan/status/1339575630187425792
> double the amount of sprites
It sounds a bit low? My experience is that with instancing and 2d array textures (2d games usally uses spritesheets) can be much much faster then 2x. I would guess 20x-200x faster than unity.
https://forums.eveonline.com/t/how-is-the-eve-online-client-...
> As far as we know, the EVE client is written in C++ and Python. C++ handles all the low-level stuff like 3D rendering, network communication, input handling and such. (Stackless) Python is used for everything else, which includes the user interface and even the management of graphic resources (you can see this in the debug window by pressing ctrl+alt+shift+m). This technology mix is quite unique, so I’d suggest CCP implemented the EVE GUI in-house, not using a (open source) widget library. I’ve been playing EVE for many years now, and the GUI has evolved a lot since the days I first tried EVE (around 2005). This also strongly suggests that the code was written by CCP.
Some engagements in EVE will literally involve thousands of players in the same system all interacting with each other in big groups, so it becomes extremely important to be able to push a truckload of packets and events and process them with low latencies.
That's a tough workload. I guess it would appear in MMOs, bidding markets, wonder where else.
Would be neat to have something to quickly go wow over.
One question. Is DragonRuby, in essence, a mRuby compiler? Or is it an implementation of an mRuby interpretor that calls on a low-level API for fast game functionality?
The hook is you like to program in Ruby, so here is a game engine where you can use Ruby.
No offense to ruby programmers but, Ruby's not necessarily the ideal language for game programming even when it comes to scripting languages.
And...if you know ruby well enough to make a game, you could learn one of the many other languages better suited to game dev fairly easily.
What makes this worth paying for?
What makes this worth paying for, without considering the technical details (like maybe it's a bit faster for some stuff than Godot or Unity) is just Ruby.
Yes, most programmers are able to learn other languages just fine, but we all have preferences. And people who prefer Ruby usually tend to like Ruby a lot.
Apart from being Ruby, the simplicity is a major selling point for me.
(Yes, I have bought it, though not had time to use it much lately)
Unfortunately, HN tends to be full of haters. On the behalf of the rest of us, thanks for sharing DragonRuby!
I'll stick up for the community: I don't think that's true. This submission has been heavily upvoted, after all. You may be running into the contrarian dynamic: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
But I don't think there's a way around that while maintaining open discussion. At least here the disagreements are mostly civil.
Part of what makes announcements like this tricky on HN, and what I think triggered the comment you replied to, is that while part of HN values "cool hacks" and simplicity greatly, part of HN evaluates everything based on whether it's useful at scale, as a product, right now, and can grow big (there's certainly a big overlap, and I'm oversimplifying), and an announcement relating to a commercial project that aims for the former crowd unsurprisingly strokes some of the latter crowd entirely the wrong way as a weird niche project seemingly massively lacking in the features they think are essential.
I think that with DragonRuby that is particularly unavoidable. What makes some of us find it awesome is an inherently alien way of thinking to a lot of people in a way that look backwards to many.
The infrastructure people often have day jobs at companies working with more traffic, more users and more need for correctness than all but the most wildly successful products ever see.
Conversely the practices that work for successful solo product creators would be disastrous for a tech giant / financial company / enterprise b2b company to use.
A hard yet important lesson in life is to learn to do things in spite of haters hating. For example, I'm writing a programming language, and I can almost guarantee that people will hate it... and that's ok.
What you want is for the correct people to hate it, because it's not there to serve them, and makes no concessions to 'em about it.
> 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/.
Thank you!
What's changed in Ruby since then to make smooth animation possible?
For hobbyists Gosu (https://www.libgosu.org/ruby.html) should be good enough, but is not very convenient to bundle and distribute.
> Optimized for size and speed. This is not the same Ruby you'd use for building web apps with Rails (far from it).
> DragonRuby is powered by highly optimized C code written by Ryan C. Gordon. He is one of the core maintainers of libSDL
The GC has changed a lot in the past 20 years too. Here's a great talk about it: https://www.youtube.com/watch?v=lcQ-hIfiljA
EDIT: a 3d example > https://canicvs.itch.io/wireframe-sample
Ruby has been a language in decline for quite some time.
I think you're a bit off in describing Ruby as a language in decline. Rails startups are being built every single day, Hotwire is threatening yet another Rails renaissance as Ruby moves towards reactive web app technology, mruby is pushing forward into smaller areas, and TruffleRuby is moving forward into exceptionally performant Ruby code.
This is all on top of 3.0, which brings all manner of improvements, most notably type annotations.
I love Python as much as anybody, but I think they are equally respectable and equally popular in their own niches.
Syntax is only a preference, there is much more to Ruby as a language than just the syntactic departures from Python code. It's a different model and encourages a different style of problem solving.
Examples?