Putting the purely technical aspects aside for a moment.

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

Godot, unity, and unreal do all that too. I’m not seeing the advantage other than it’s ruby. Seems like a niche product.

> Seems like a niche product.

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.

I can only speak for Unity until versions till maybe 2019 - and I never developed a full commercial title with it - just a few game jam games - so maybe I'm not the best authority on that... But I think it's quite far away in many of those features

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.....

Am in the midst of shipping a medium sized game in Unity and I can confirm your takes are correct/relevant today. Unity is incredibly frustrating to me, and I would really aggressively challenge the notion that Unity is aimed at any sort of "Developer Productivity". More than anything it's a dumpster of features to allow Developers, Artist and totally nontechnical/non IC contributors to all contribute okay-enough. But the features that go into making Artists productive are at times orthogonal to those that make Devs productive. It's all a big tradeoff.

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.

Playing from editor is the testing on desktop. You can make a parallel builds in Unity with the new build tools. Hot swapping code breaks down quickly as complexity increases (it’s also supported by default in Unity). With nested prefabs changes can be made while scenes are running and preserved. You can debug an unity game remotely with Rider or Visual Studio, you can add new code, change execution order, memory, etc. I guess Ya got Unity best on build speed though; although, I bet a lot of what you saw as build time was asset conversion. In my experience with unity I rarely leave the editor/rider combo and I only make builds when testing new libraries (because of IL2CPP) and for performance analysis. It is much, much faster to iterate through the editor than hot swap could ever hope to achieve; I can test every resolution, notch configuration, etc without leaving the editor. I have built professional games with custom engines, unreal 3, unity, and torque and Unity is by far the most enjoyable to make games in.

> Are there enough Ruby devs to sustain this?

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.

Unity is just fine. 1000s of shipping successful games. The latest hit game made in Unity is Valheim.

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.

By that measure, pure hardware-banging from C is just fine too. Heck, thousands of commercial games written in 6502 assembler have been released over the years. Doesn't mean it was an ideal developer experience.

The market for a game engine is not players. Most games could be written with almost anything.

Wait, you're suggesting Ruby is better than Unity? This has to be a joke.

Nope. Not a joke. We’re faster too: https://youtu.be/UuY7CWdvyWM

Your logic isn’t equivalent: in your Ruby example you precalulate the speed for each axis and only add the value to x and y each frame. In the Unity example you do the inefficient “Speed * new Vector3(1,1,0) * Time.DeltaTime” every frame. If you moved that calculation to the start and then add in fixed update they would be equivalent logic”. That is probably the difference you notice.

Sorry, but if an engine developer says that Unity is just a bad engine and your engine is faster, you are just harming yourself and your work, since this is silly.

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.

Looks like the Ruby code in https://gist.github.com/amirrajan/e26fc9de3c20e7c395f6809a99... does a fixed update, so maybe FixedUpdate with Unity would be a better comparison?

Agree. The comparison only works if you don't dig, or not ask questions.

Press F to doubt.

On some tiny synthetic benchmark maybe.

Come back when your engine can handle something even 1% as complex, as say, Dyson Sphere Program.

I suspect that DragonRuby is faster as a 2D game engine and doesn't make sense for a complex 3D game.

I don't believe that either. Unity works just fine for Cuphead, which is a pretty graphically intense game. Plenty of other graphical complicated 2d games too.

I think you're moving the goalposts. Of course Unity can work "just fine" for things like Cuphead. However, DragonRuby is an mRuby wrapper around SDL by the guy who wrote SDL vs. a 3D engine that was reworked into a 2D engine?

Surely Unity has more overhead and DragonRuby can make more optimizations.

GP made a blanket "We're faster" claim. I'm the one moving the goalposts?

Ehh, I could put together a thing that could display several million dots at 60 fps in unity in a few minutes.

(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.

Can you associate a PhysicsBody2D with each one of these?

AFAIK there's GPU analogs for everything physicsBody2d's can do, but not directly.

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

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).

So this YT video of 3:47 is going to prove that Ruby is faster and better than Unity? This is like comparing BASIC and C, but making sure BASIC is on a quad-core, and C on a 386 to make the point work.

Unitiy's main strengths are it's asset store and ability to export to consoles/phones, also most people like C#. It also had strong momentum of tutorials and community but that is diminishing now as most are so outdated now and for older versions that they are no longer relevant. Unreal is getting easier everyday and they are getting more assets and more community together so it's eating them from the high end while Godot is eating them from the low end. Since DragonRuby is good at exporting to consoles and most Ruby users like Ruby so it's arguable that they could be better in a lot of ways.

Have any data to back up these claims? Unity keeps growing, just went IPO last year, and is releasing high quality tutorials regularly.

I'm not the one you asked, but using google trends as an indicator, both unity and unreal lose mindshare: https://trends.google.de/trends/explore?date=today%205-y&geo...

I daresay the Godot Engine has more to do with that, than Ruby as a game engine.

Unity deploys to console. You just need to be licensed to build to different console platforms. And saying Unity is not that great is an ignorant statement. What about it isn’t great? And how is DragonRuby better?

This does a good job of summarizing what's wrong: https://news.ycombinator.com/item?id=23271973

Been using Unity for a long time and that is a hyperbolic comment. It’s not nearly as bad as that person makes it out to be.

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.

> Lets say I am not a Ruby dev, what would compel me to learn this over Unity, Unreal, React Native game engine, or one of the other (thousand) game engines out there?

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.

I had this discussion with a AAA game studio recently. They have a hit game will millions of players and it's been a hit for many years. It uses a custom engine. They've been releasing new games. Those new games are in both Unity and Unreal.

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.

The target for this is not AAA studios, but indie developers.

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.

and yet 10s of thousands of people make games in a new hours in Unity. Go see all the game jam games.

So no, Unity is not "too complex" and it's very suitable for hobby use.

To me it was "too complex" when I looked at it. That it isn't for others is great for them, but it doesn't make it any more suitable for me.

That I also don't have to use a language I consider absolutely awful is another major bonus.

The needs of AAA game studios and solo/small-team indie devs are very, very different.

> and now think JS is eating the world

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.

Agree. I don't know if the Ruby interpreter is what I'd look to for performance in a game.

The irony is that Ruby was actually designed for this kind of thing. And in fact, RPG Maker XP’s Ruby Game Scripting System, a commercial usage of Ruby as an embedded scripting language for game dev, was released at least a few months prior to the first Ruby on Rails release if memory serves correct.

Do you have a source for the claim that ruby was designed for game development? I'm not saying it's wrong, I just have never heard that before.

Not necessarily game dev, but rather as an embeddable scripting language. There’s also mruby which is even more portable and designed to be more embeddable. My understanding is that in Japan, Ruby is often used as an embedded scripting language the way people might use Lua.

(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.)

I can vouch for Ruby's practicality as an embedded scripting language. The first time I used it was in a game engine (which, IIRC, also predated Rails) with a C++ core. Writing the high-level game logic in Ruby was pleasant, and hooking into C++ functions that did the heavy lifting kept it performant.

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.

Hm... I'm more concerned about running user-land scripts and shaders than sprites. If I wanted raw pixel-blits per second I could just use SDL.

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?

There’s quite a few samples of people doing crazy things with Cuda. Not sure if you can access this demonstration: https://discord.com/channels/608064116111966245/674410581326...

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

Unity rendering sprites has nothing to do with C#. A big portion of their engine and rendering stack are implemented in C/C++.

Unity does also support C extensions... But due to cross platform mess it is not so popular (i guess).

> 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.

Huh, number of sprites per frame has little to do with the speed of C# in Unity. If anything it shows that Unity's default sprite renderer is inefficient.

You have any data to back up that claim? Unity C# is very fast; especially, if compiled to IL2CPP. Your video doesn’t prove anything. Make a lot of moving transform hierarchies and see how they compare. Unity sucks at this, but I bet it will still outperform In your tests.

It doesn’t use the standard Ruby interpreter (MRI), but a custom implementation that includes a compiler. I don’t know if it’s AOT compilation or JIT.

This is mRuby, not Ruby. Different things. Think in mRuby as Lua and MRI Ruby as Python

Unity is a giant download and very complicated. Something like DragonRuby, Renpy, Python Arcade, or LOVE2D are far smaller and suitable for many small games. Even Godot is significantly smaller and offers many of the features of Unity.

EVE Online is written in Python

This post tells me the heavy lifting is done in C++ including 3D rendering, network communication and input handling:

https://forums.eveonline.com/t/how-is-the-eve-online-client-...

The quote is

> 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.

Yep, C++ where performance matters.

Surprising they'd go C++ for networking. Python's had top-notch async for nearly 20 years.

EVE has a history of incredibly bad performance issues, in part due to their extensive use of python for networking, simulation, etc. They seem to struggle with it on an ongoing basis, so it makes sense that in some cases they would move logic from python to C++. Their networking stack was at least at one point heavily Python.

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.

> Some engagements in EVE will literally involve thousands of players in the same system all interacting with each other in big groups

That's a tough workload. I guess it would appear in MMOs, bidding markets, wonder where else.