Will it ever support making 3D games?
Show HN: DragonRuby Game Toolkit
81–90 of 146 posts
Re: Show HN: DragonRuby Game Toolkit
#82Will it ever support making 3D games?
I don't think it will be supported at the engine level but the community tinkers with 3d proof of concepts. Both with pure Ruby and with backing maths in C extensions for even better performance.
EDIT: a 3d example > https://canicvs.itch.io/wireframe-sample
Re: Show HN: DragonRuby Game Toolkit
#83Earlier quoted context omitted.
Agree. I don't know if the Ruby interpreter is what I'd look to for performance in a game.
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.
Unity rendering sprites has nothing to do with C#. A big portion of their engine and rendering stack are implemented in C/C++.
Re: Show HN: DragonRuby Game Toolkit
#84Earlier quoted context omitted.
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…
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.
Re: Show HN: DragonRuby Game Toolkit
#85Earlier quoted context omitted.
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.
Re: Show HN: DragonRuby Game Toolkit
#86Earlier quoted context omitted.
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
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.
Re: Show HN: DragonRuby Game Toolkit
#87Lots of typical anti-ruby grumbling in this so I'll just say; this looks awesome and I'm excited to give it a try. I still love programming in Ruby, and there's no reason at all why a game written in Ruby couldn't be performant. Great to see a good use of mRuby too. I've had ideas for games in the past but I know that having to learn an entirely new language, framework, and concept of development will mean that I never finish it. Having an option in my favourite language removes one of those barriers to entry.
Re: Show HN: DragonRuby Game Toolkit
#88This looks like a fantastic dev experience and it's great to see this team building something like this. Indie game dev is near and dear to my heart. Unfortunately, HN tends to be full of haters. On the behalf of the rest of us, thanks for sharing DragonRuby!
> HN tends to be full of haters 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...
HN can definitively be brutally dismissive of things that doesn't match current perceived wisdom of what is the right way of doing things, much beyond the initial few comments.
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.
Re: Show HN: DragonRuby Game Toolkit
#89Earlier quoted context omitted.
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…
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, becau…
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.
Re: Show HN: DragonRuby Game Toolkit
#90Earlier quoted context omitted.
> HN tends to be full of haters 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...
HN can definitively be brutally dismissive of things that doesn't match current perceived wisdom of what is the right way of doing things, much beyond the initial few comments. 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…
I definitely see the clash you're talking about between people focused on build a product and people focused on building infrastructure.
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.