Ruby for scripting my game engine...

[djork]

I am going to be working on utilizing Ruby as a scripting language for my 2D game engine. Basically I've implemented some VERY basic fundamentals in a Cocoa app (loading images, drawing sprites from those images, a basic scene list, keyboard and mouse input). Now the experiment begins. I basically want to see if it's feasible to write all of the game logic in Ruby (it should be fast enough for this task). It will work by passing input to an update function of the Ruby script designated to handle the logic. The script can interact with the application by rendering images to the window. That's about it.

If this works, I'll try to package it up nicely and make it available for y'uns!

[ThemsAllTook]

A few others and I tried to do this a while back, and we actually found Ruby to be much too slow to use it for all the game logic. Maybe you'll have better luck, though. Let us know how it goes!

[djork]

A few others and I tried to do this a while back, and we actually found Ruby to be much too slow to use it for all the game logic. Maybe you'll have better luck, though. Let us know how it goes!

Really? I'm wondering: what was your approach and where do you think the speed issues cropped up? I'm not trying to handle 3D meshes or actually making individual OpenGL calls with Ruby. With a 2D game you're not looking at more than a few hundred sprites on screen at one time.

[Nickolei]

You should expect ruby to be at least 100x slower and use about 3x more memory than gcc c code, but the productivity gains can be significant. Only you can determine if this will work for your app. I mean java stopped being slow, right? Right? Anybody? Bueller?

Also of note, the Queensland University of Technology recently released a beta Ruby.NET (Windows) compiler: http://plas.fit.qut.edu.au/Ruby.NET/ A fully compiled ruby would be hot stuff for game developers.

[OneSadCookie]

Don't let the speed put you off; you can always write the few bits that are too slow in C, whilst keeping the rest in Ruby.

[djork]

Don't worry, I'm fully aware of the speed (roughly that of molasses) of Ruby vs. C, and that's why I'm writing this as a Ruby extension that does all of the hard work (collision detection, physics, rendering) in Objective-C.

I'm cooking up some good stuff here...

[Skorche]

I've been writing something similar named Aerosol that you might be interested in. It has a XCode project and a rakefile to build under Linux. I haven't worked much on this summer, but that should change once I get back to school I think.

Aerosol binary and tutorials. (http://cda.morris.umn.edu/~lemb0029/Aerosol.tgz)
Aerosol source (http://cda.morris.umn.edu/~lemb0029/AerosolSource.tgz)
Example games (http://cda.morris.umn.edu/~lemb0029/ExampleGames.tgz)

Unless you want to make really bleeding edge games, I don't think you need to be concerned about the speed. I haven't really had problems. Worst case is that you would rewrite portions of the logic into a game specific extension, and that doesn't sound like it scares you. Remember profiler.rb, it will be your friend if you do run into speed problems.

In the current game I've been working on, I found that the parallax star code and the autopilot code take up most of the processor time. This is mainly due to creating thousands of vector and floating point objects every frame. Rewriting either into C would be fairly trivial at this point, and it isn't really even needed yet.

[wadesworld]

If you're looking to embed a scripting language, use Lua. It's designed for that.

[OneSadCookie]

If you're looking for PAIN and SUFFERING, go ahead, embed Lua.

If you'd like a high-level object-oriented language that's easy to embed and powerful when embedded, I recommend Ruby.

[unknown]

If you're looking for PAIN and SUFFERING, go ahead, embed Lua.

lol
Lua is no problem at all, take a look at OneSadCookie's example SmileyTag http://onesadcookie.com/Software
Embedding Lua is really really easy, there is also a whole section on embedding from basic to advanced in the lua book as well http://www.lua.org/pil/#P4

I think the PAIN and SUFFERING would come from working out the basics of embedding Ruby actually, because there is very little apart from README.EXT to help with that.

[OneSadCookie]

It's certainly true that embedding Lua is *much* better documented :)

Writing function bindings for lua is annoying, though -- there's no way to know how many parameters your C function was passed from lua, for a start. Then you have to pull all your arguments out of the stack, and if you need something more complicated than numbers, do some nasty messing with the lua stack to pull elements out of the array, for example.

Ruby works much more easily -- your C function takes the right number and count of arguments, and you can give them meaningful names. Dealing with arrays is very straightforward.

[Skorche]

First of all, if you want to learn about the Ruby C API, get the Pickaxe (http://www.amazon.com/gp/product/0974514055/sr=8-1/qid=1156106829/ref=pd_bbs_1/102-3709040-9590520?ie=UTF8). It has an excellent starting reference.

Also, there are people lurking on this very forum who know a fair amount about writing Ruby extensions. I've written several thousand lines of extension code. OSC has written a lot as well. Just ask!

[KittyMac]

there's no way to know how many parameters your C function was passed from lua, for a start.

int n = lua_gettop(ls);

This tells you the number of parameters passed to your function (each C function call in lua gets its own local stack, which contains only the parameters you sent it in the Lua code).


I can't weigh in much on this topic, other than I've embedded Lua in several programs without a glitch (never Ruby). And lua is plenty fast enough to hold all of the games logic, Pirate Isle (http://homepage.mac.com/felinegames/games/pirateisle/index.html) uses it for everything but the rendering engine.

[OneSadCookie]

int n = lua_gettop(ls);

This tells you the number of parameters passed to your function (each C function call in lua gets its own local stack, which contains only the parameters you sent it in the Lua code).

Interesting, I didn't know that. That's the #1 objection down, then :)