amirrajan

Link to source code: https://gist.github.com/amirrajan/5ec37929e9987a72d98d5adb50...

More poignant examples would be `dirent.h` and `system`. Getting access to the file system on a console, or the ability to start up a process out of band is not allowed.

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

Additional Links:

- Starfield Demo: https://www.youtube.com/watch?v=S-baJwEjUsk&ab_channel=AmirR...

- Starfield Source: https://gist.github.com/amirrajan/508f1a6aaf5352cab579104e61...

- Skybox/Coordinate System: https://www.youtube.com/watch?v=fvlRg3GvcLY&ab_channel=AmirR...

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.

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.

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

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?

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

Can you associate a PhysicsBody2D with each one of these?

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

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

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

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

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

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

I totally understand the need for Android support back then (and to your point should have happened sooner).

With regards to relevancy, RubyMotion is built on top of LLVM. With regards to Ruby the language itself, it's been around for decades and won't be going anywhere (granted the same can be said for JavaScript).

I'm waiting to see how web assembly will shake things up.

Best of luck to you man (I genuinely mean that). And if you ever decide to come back to RM, I'll be here to help :-)

>When are you going to open source?

- Build, project templates, dynamic bindings generation (BridgeSupport) have all been open sourced.

- The repl is targeted to be open sourced in Q1 2019.

- The parser is targeted to be open sourced in Q2 2019.

- The rest is TBD. But I bought the website domain dragonruby.org :-D

Owner/CEO/Steward of RubyMotion here.

1. Laurent did sell RubyMotion off (to basically retire). He sold it to me. The guy that built the mobile adaptation of A Dark Room with RubyMotion (which hit the number one spot on the AppStore _and_ the number two spot on Google Play).

2. Since the acquisition, there have been monthly updates to the platform, and measures to slowly open source RM under a _sustainable_ open source model.

3. I have since released 4 other apps using RubyMotion. Combined they have approximately 3.5 million downloads.

4. RubyMotion is _actually_ native (unlike React Native).

5. RubyMotion is definitely not cool anymore. It's battle-hardened, "just works", fast (faster than Swift in fact), and can leverage all the existing Android and iOS libraries out there (which React not-Native can't do out of the box).

6. Email me and I'll hook you up with an Indie license <3.