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.
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.
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.
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.
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.
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?
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.
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.
Amir, thanks for following up. Like I said in the article, I've used RubyMotion in production in the past. We were one of the early adopters and launched at least half a dozens apps in it. We payed for all our licenses. I love the product and this was money very well spent. It allowed us to use the same language (Ruby) in a larger portion of the projects. This was particularly important when some of our clients were small startups with an existing Rails app, and it was important for them to keep the same language for the mobile app.
I just think the support for Android should have happened a lot sooner. But of course this is easier said than done.
Moving forward to React Native is part of the same approach. It's important for us to use a technology that delivers fast in multiple channels and has a great chance of still being relevant in the next 10 to 20 years. And for me, these are the strongest points on Javascript.
And you're correct, React Native is not truly native, but it does the job pretty well without major impacts on usability. RubyMotion is truly native and very well designed IMHO.
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 :-)
This has been a big regret of mine. I should never have preceived anyone in a 9 to 5 that way. And as mentioned above, there is nothing wrong with a 9 to 5 (dice or no dice). It’s a prefectly valid course of action to pursue the more important things in life.
>his apparent lack of curiosity about exactly how his first and only lucky break took place
I completely agree. It's not like he wrote a 300 page book on the whole ordeal or anything. He didn't spend those 300 pages trying desperately to dissect every single day, tweet, email, news post, and website write up between 11/17/2013 and 04/13/2014. Nor did he try to analyze his other assets/how they correlated back to A Dark Room. Now... if he put that kind of effort into understanding A Dark Room's meteoric rise, then maybe his subsequent endeavors would have succeeded. At least he would have been more deserving of those successes.
You can't criticize people for not having information you have. None of that was in your original post. Also the sarcastic 3rd person tone of most of your responses is off-putting. This comment would have been much better if you just stated how you did try to analyze the success of ADR in great depth.
This is really good advice. Additionally I'd say don't bet the farm. Some times the best you can do is be that rock/stepping stone for your kin to build a legacy with.
MIRTS is actually an incredibly shallow take on RTS. I remember playing an extremely similar game back in 2007 and I also remember thinking that game was extremely similar to design docs that I had seen people blogging about a few years earlier.
MIRTS is something I'd expect from a weekend programming jam. It's a minimal effort and it's not surprising that it did minimally well in the marketplace.
>there's got to be interesting, useful knowledge in there for other game dev and future generations.
There is, but "the few ruined it for the many". Some who got access to that information tried to "growth hack" their way to a successful app. They started name dropping me to Apple as if they knew me. This isn't a very nice thing to do.
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.