Hacker News new | past | comments | ask | show | jobs | submit | amirrajan's comments login

Late reply, but maybe it’ll be useful to other people coming across this post.

1. mRuby is trivial to embed.

2. S7 Scheme is also trivial to embed.

3. LuaJIT will not work on consoles (proprietary CPU architectures), and JIT isn’t supported on iOS or Android. You have to use vanilla Lua.

4. Lua has historically been the default because it was first to provide a nice embed story.

5. Lua as a language leaves a lot to be desired (Ron Gilbert really disliked using it within his games)

6. This gist post goes into details wrt the deficiencies of Lua [1]

7. Here are two GH repos with Roguelike Tutorial. One in Lua [2], the other in mRuby [3]. It’s worth comparing and contrasting.

8. If I want extremely performant code, then I drop down to C. For scripting level/game code. mRuby is plenty fast [4].

[1] https://gist.github.com/amirrajan/2c42315ffef311600ecb2d8dcf...

[2] https://github.com/Lycea/Rogue/tree/master/components

[3] https://github.com/kfischer-okarin/roguelike-tutorial-2021/t...

[4] https://m.youtube.com/watch?v=MFR-dvsllA4


Creator of DragonRuby here. Send me an email and I’ll hook you up with a license to the game engine :-)

at[at]amirrajan[dot]net



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.


Decided to do a flash sale given all the visibility the engine has gotten recently. You can get the Standard License free for the next 24 hours: https://itch.io/s/48411/dragonruby-game-toolkit-hacker-news-...


The FAQ covers this in detail under the "What is DragonRuby?": http://docs.dragonruby.org/#--frequently-asked-questions,-co...


> Python provides a better syntax in almost all areas

Examples?


Things I don't like about Ruby: %w{} et al., symbols, more implicit "magicy" things.


Ryan has a custom compilation of it actually. That editor will go to the grave with him :-P


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.


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


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: