Ray, a Ruby game library | Hacker News Reader

Ray, a Ruby game library

mon-ouie.github.com

98 pointsmberube18 comments

This looks nice. I'm always excited to see higher level languages being used for scripting games. Lua is awesome at what it does but I've never really liked the syntax and lack of real objects. Building objects on top of Lua tables has always felt like such a hack to me personally.

The one thing that always concerns me with Ruby engines, however, is distributing the un-obfuscated ruby files with a game. In a single player game, with no online leader-boards or other concerns of cheating it's fine. But in a game where someone might be tempted to cheat this just makes it too easy. I know obfuscating / compiling code isn't very strong security against cheating but it's a huge step up from distributing source files ready to be edited.

Engines like Love2D (maybe other Lua based engines too, I haven't tried) allow you to compile your lua scripts and distribute the compiled versions.

With Ruby I guess the options would be to make a Java game engine with JRuby then you're just distributing JVM bytecode. Or maybe building a native engine in c (like this one) but including Rubinius to run compiled Ruby code. Rubinius has a blog post suggesting that this should be possible (http://rubini.us/2011/03/17/running-ruby-with-no-ruby/)

I'd love to see a game engine on Ruby with code obfuscation built in.

Just in case you (or someone else) would like to know, Ray has been tested with both JRuby and Rubinius.

If you use Ruby 1.9, I'm pretty sure there's a way to distribute it as YARV bytecode.

EDIT: I guess not http://redmine.ruby-lang.org/issues/971 Anybody know why this was closed?

Ko1's response implies that they don't yet feel ready to commit to a set bytecode for YARV and don't want to support this feature until it will have some measure of portability.

What I don't see there is collisions. Without a fast collision tool, it's hard to do whole classes of games anything like efficiently. It's a little disappointing that, having written a renderer adapter with native code, there isn't collisions as well.

There's a method to check for collisions between rectangles (which can be called on sprites too).

Which isn't super useful for 3D, though...

Regardless, think seriously about putting collision/physics on the front page, because I certainly use it as an evaluation criteria.

Plus, I'm a little disappointed by rectangles-only collisions. Space partitioning? SAT based collisions aren't bad either, even if they can't deal with fast rotation well. And it's a bummer to have to re-write all that for every engine.

Surprising that there's no physics engine integration like Chipmunk or Box2D.

This looks pretty easy to use, and powerful too (3D?!). I'm going to try this out right now.

What's the speed like? Looks like its built on top of some opengl C code, so I imagine its alright.

Yes, the heavy work is done in C. So it should be fast enough for many games.

Is it possible to detect absolute position of a polygon? It looks like polygon.pos gives position relative to where it was created (and therefore polygon.pos.{x, y, height} are sort of broken).

Would be incredible if a PyGame type community can be built, for the Rubyists out there, around this tool. Kudos to this initiative!

Even better would be a Love2D-like platform.

Has anyone compared this to Rubygame (http://rubygame.org/)?

I haven't compared the two projects, but the rubygame project is currently in a state of "indefinite hibernation":

http://rubygame.org/blog/2011/07/12/the-new-rubygame-org/#mo...

So it is good to have an alternative available.

Better to compare this to Gosu (http://www.libgosu.org/) which Ray seems to have taken a lot of ideas from.

Good to see more people working to combine Ruby and game development.

Would be great if worked with Ruboto on Android.

Reply on news.ycombinator.com