I'm a Dragon Rider, if you will. I have bought the pro license and have used the toolkit to make some demos/experiments. I'm excited by how quickly I can produce a game that works on multiple targets. It's been great as a recreational coder. I have aspirations of figuring out the right game loop and eventually selling it. It's a lot of fun and fits my desired approach. Thanks to everyone working on it!
Show HN: DragonRuby Game Toolkit
101–110 of 146 posts
Re: Show HN: DragonRuby Game Toolkit
#10220 years ago, I shipped a Ruby/SDL powered quiz game to a network of Windows NT4-powered games cabinets in pubs. They had 64MB RAM and the jerky animation due to garbage collection pauses ATE ME ALIVE for about 6 months.
What's changed in Ruby since then to make smooth animation possible?
Re: Show HN: DragonRuby Game Toolkit
#103> This is not the same Ruby you'd use for building web apps with Rails (far from it). > DragonRuby is powered by highly optimized C code written by Ryan C. Gordon. This feels like a liability for the long term. The community is now depending on Ryan to maintain this custom Ruby implementation, if I'm reading correctly.
Given their limited shelf-life, I’d have thought this would be less of an issue for games than for other software? Many games rely on Lua, for example, which is maintained by a team of just 3 people, and it seems only one of them writes most of the code. https://github.com/lua/lua/graphs/contributors
True for a single game, but developers don't like to learn an entirely new system every time they make a new product. With Unreal and Unity, you might have to learn a few new things when new major versions come out, but your old knowledge is still very much applicable. And if any 1 developer quits working on those engines, it's going to keep trucking along.
But the worry here is that if the main developer of DragonRuby quits, it's dead in the water. Sure, you can use the old version and it'll probably still work, but there won't be any improvements, whereas other engines are constantly improving.
Re: Show HN: DragonRuby Game Toolkit
#10420 years ago, I shipped a Ruby/SDL powered quiz game to a network of Windows NT4-powered games cabinets in pubs. They had 64MB RAM and the jerky animation due to garbage collection pauses ATE ME ALIVE for about 6 months. What's changed in Ruby since then to make smooth animation possible?
Further down on the page:
> Optimized for size and speed. This is not the same Ruby you'd use for building web apps with Rails (far from it).
> DragonRuby is powered by highly optimized C code written by Ryan C. Gordon. He is one of the core maintainers of libSDL
Re: Show HN: DragonRuby Game Toolkit
#105If I understand correctly (from a quick browse of the docs) this is Ruby _without_ anything remotely like Rails. That makes it interesting. I did a Rails job once. I kept thinking that I liked the language as a kind of modern OO language in the spirit of Python (and also Lua a bit) but I really disliked the ecosystem around Rails. For instance, the project I worked on had to maintain two separate versions of Ruby bec…
A friend of mine sat me down and showed me how to work with rails. We ended up programming the entire weekend and worked our way through a few cases of beer in the same time. Working in rails was incredible and the productivity was unlike anything I have ever seen.
Re: Show HN: DragonRuby Game Toolkit
#10620 years ago, I shipped a Ruby/SDL powered quiz game to a network of Windows NT4-powered games cabinets in pubs. They had 64MB RAM and the jerky animation due to garbage collection pauses ATE ME ALIVE for about 6 months. What's changed in Ruby since then to make smooth animation possible?
Seems like this game engine is built on top of RubyMotion which compiles to byte code - no (slow) Ruby VM. This probably also allows them to bundle the game for many platforms.
For hobbyists Gosu (https://www.libgosu.org/ruby.html) should be good enough, but is not very convenient to bundle and distribute.
Re: Show HN: DragonRuby Game Toolkit
#107If I understand correctly (from a quick browse of the docs) this is Ruby _without_ anything remotely like Rails. That makes it interesting. I did a Rails job once. I kept thinking that I liked the language as a kind of modern OO language in the spirit of Python (and also Lua a bit) but I really disliked the ecosystem around Rails. For instance, the project I worked on had to maintain two separate versions of Ruby bec…
Another major use of Ruby that people seem to forget about is Chef. I really enjoy Chef (chef.io).
Re: Show HN: DragonRuby Game Toolkit
#108Earlier quoted context omitted.
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.
Re: Show HN: DragonRuby Game Toolkit
#109If I understand correctly (from a quick browse of the docs) this is Ruby _without_ anything remotely like Rails. That makes it interesting. I did a Rails job once. I kept thinking that I liked the language as a kind of modern OO language in the spirit of Python (and also Lua a bit) but I really disliked the ecosystem around Rails. For instance, the project I worked on had to maintain two separate versions of Ruby bec…
I've done Ruby for 16 years at this point, and avoided Rails for most of it, including for most of my webapp work.
I really wish people didn't associate Ruby so much with Rails.
Re: Show HN: DragonRuby Game Toolkit
#110Earlier quoted context omitted.
Given their limited shelf-life, I’d have thought this would be less of an issue for games than for other software? Many games rely on Lua, for example, which is maintained by a team of just 3 people, and it seems only one of them writes most of the code. https://github.com/lua/lua/graphs/contributors
True for a single game, but developers don't like to learn an entirely new system every time they make a new product. With Unreal and Unity, you might have to learn a few new things when new major versions come out, but your old knowledge is still very much applicable. And if any 1 developer quits working on those engines, it's going to keep trucking along. But the worry here is that if the main developer of DragonRu…
This particular objection doesn't worry me, because all the really effective 'engines' I know about, that provide an environment to be built upon by others, are originated by and run by a single visionary person.
From my perspective, this is an asset rather than a bug, provided the person is committed to his project. It's a guiding force that stops it being a vague laundry list of feature requests.