Forum: Ruby Honest opinion needed...

I've been trying to find a scripting language to integrate into a game
I'm developing in C and my choices are pretty much either Ruby or Lua.

See, game developers tell me Lua is the way to go for performance and
flexibility, but the C embedding API feels so low-level that it's
intimidating.

Ruby, on the other hand, has a much friendlier C embedding API and
doesn't look to need the developer jumping through hoops. However, some
of my friends develop their games on a program called RPGMaker and they
say the newer versions are awful mainly because of Ruby being the new
scripting language and on top of that, Ruby's been criticized for the
processing power.

I looked into Ruby 1.9 to find it adopted a more efficient third-party
interpreter and that code runs 15% faster... or something. Reading about
that restored my hope that I could use Ruby with no reprecussions. On a
hunch, I checked the latest RPGMaker's release date which was Dec 27,
2007.

A lot of concerns plague me about 1.9. I suppose the most important
would be does 1.9 redeem Ruby's processing efficiency? Version 1.9 is
fairly new, so I'm guessing RPGMaker had to be using 1.8 or lower, which
is the old engine.

The bottom line is would there be any negative impact if I were to embed
a Ruby 1.9.1 scripting engine in my game, in contrast to Lua?

Limiting the use of dynamic features of ruby will lead to better
performance since ruby 1.9 uses YARV. But something like
multi-threading or resource-consuming will possibly bother you.

Above all, you should think over that whether a fully-featured
scripting language is really needed. I think building small
domain-specific languages for different aspects in your game will
reduce the complexity of development and will lead to better
performance.

2010/2/7 Schala Zeal <schalaalexiazeal@gmail.com>:

Dynamic features are the reason for scripting in games, no need to care 
about efficiency here. You have C/C++ for your bottlenecks.

Multithreading and GIL will be a little problem, but many other 
scripting languages have the same problem too, yet not difficult to fix.

The real problem is 1.9's encoding may cause unexpected issues 
(obviously many developers are not used to it). I still can't find a 
good way for embed ruby interpreter to load encdb and transdb.

贾枭 wrote:
> Limiting the use of dynamic features of ruby will lead to better
> performance since ruby 1.9 uses YARV. But something like
> multi-threading or resource-consuming will possibly bother you.
> 
> Above all, you should think over that whether a fully-featured
> scripting language is really needed. I think building small
> domain-specific languages for different aspects in your game will
> reduce the complexity of development and will lead to better
> performance.
> 
> 2010/2/7 Schala Zeal <schalaalexiazeal@gmail.com>:

Well I planned to implement the game's elements (classes for NPC, spell, 
item, etc) internally and then implement the actual game and its 
resources (dialogue, NPC/spell/item instances, etc) in scripting.

Schala Zeal wrote:
> The bottom line is would there be any negative impact if I were to embed
> a Ruby 1.9.1 scripting engine in my game, in contrast to Lua?

I'd say it depends a lot on how consistent your framerate needs to be.

For example, if you must maintain solid 60Hz, it can be quite a
challenge:

http://www.scribd.com/doc/15118967/Hitting-60Hz-in-Unreal-Engine


As of Lua 5.1, the Garbage Collector is now incremental instead of
mark-and-sweep.

An article describing the use of Lua in WoW, which mentions lag
related to the older GC approach:

http://fliiby.com/file/272148/4hh27ix1dt.html

"In Lua 5.0 users were experiencing frequent freezes in their user
interface during heavy combat situations due to the atomic garbage
collection. Users wrote a number of addon solutions that performed
garbage collection as pre-defined ”safe” times, such as when entering
a city or exiting combat When incremental GC was introduced the
system seemed to be much smoother and caused less issues for users.
After further testing and observation the garbage collector wasn’t
aggressive enough, since it only took a step when new functions or
tables were created. I created a simple addon solution that called a
step of the garbage collector periodically when the player was not
in combat."


Ruby, at least the MRI/YARV versions of the interpreter, still uses
mark-and-sweep GC.


So you can almost certainly expect the same periodic long frames
(lag) to occur when Ruby garbage collects, as used to happen with
Lua.


Regards,

Bill

Hmm... That would be a good mechanism for Ruby. Unfortunately I don't 
have the knowledge to code and submit that to the Ruby team.

Schala Zeal wrote:
> Hmm... That would be a good mechanism for Ruby. Unfortunately I don't 
> have the knowledge to code and submit that to the Ruby team.

They are already aware of the possibilities, but there are trade-offs.

For example:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/27463
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/27538


Regards,

Bill

On Sunday 07 February 2010 06:15:17 pm Bill Kelly wrote:
> Schala Zeal wrote:
> > The bottom line is would there be any negative impact if I were to embed
> > a Ruby 1.9.1 scripting engine in my game, in contrast to Lua?
> 
> For example, if you must maintain solid 60Hz, it can be quite a
> challenge:
> 
> As of Lua 5.1, the Garbage Collector is now incremental instead of
> mark-and-sweep.

It might be a bit heavyweight, but if your game is written in Java, 
JRuby
would be a good fit. If not, you could consider embedding a Java
interpreter... I'm pretty sure that's not a good idea, though.

Another possibility would be to implement this hack:

> Users wrote a number of addon solutions that performed
> garbage collection as pre-defined ”safe” times, such as when entering
> a city or exiting combat When incremental GC was introduced the
> system seemed to be much smoother and caused less issues for users.

Anytime you know it's safe, you could call GC.start -- I think that's 
what
it's called.

Probably the best optimization -- though the least pleasant -- is to 
keep your
object graph small-ish, so each GC run takes less time.

I love that idea! Thanks!

On 2010-02-07, Schala Zeal <schalaalexiazeal@gmail.com> wrote:
> See, game developers tell me Lua is the way to go for performance and
> flexibility, but the C embedding API feels so low-level that it's
> intimidating.

It is intentionally low-level, but really, it's not bad.

> The bottom line is would there be any negative impact if I were to embed
> a Ruby 1.9.1 scripting engine in my game, in contrast to Lua?

The obvious thing, I think, would be the size and complexity.  Lua's a
really beautiful simple language for the kind of thing it's trying to 
do.
Lua is very well suited to being the scripting engine for a game; it's a
simple language with a small set of features (the entire LANGUAGE is
probably smaller than some regex implementations!) that are easy to get
used to.  Ruby's a lot larger and more powerful... But frankly, a game
scripting engine doesn't NEED to be exceptionally powerful, it just 
needs
well-chosen primitives.

Background:  I have written a couple of WoW addons in Lua, I've also 
done
various scripting for a couple of other games which used Lua.  It really
is a very good fit for the problem space.  I love Ruby, but I wouldn't 
try
to embed it in stuff; I'd write things in it, though.

-s

Well I mean I read chapters 24 to 29 of Programming in Lua 1st Edition 
and I was like "oh my god..."

On Sun, Feb 7, 2010 at 4:29 AM, Schala Zeal 
<schalaalexiazeal@gmail.com>wrote:

> I've been trying to find a scripting language to integrate into a game
> I'm developing in C and my choices are pretty much either Ruby or Lua.
>
> See, game developers tell me Lua is the way to go for performance and
> flexibility, but the C embedding API feels so low-level that it's
> intimidating.
>
> Ruby, on the other hand, has a much friendlier C embedding API and
> doesn't look to need the developer jumping through hoops.


Ruby has a C embedding API?  First I've ever heard of that.

Lua is designed for embedding.  Ruby isn't.  That doesn't mean you can't
embed Ruby, but YMMV...

On Mon, Feb 8, 2010 at 3:33 PM, Tony Arcieri <tony@medioh.com> wrote:

> Lua is designed for embedding.  Ruby isn't.  That doesn't mean you can't
> embed Ruby, but YMMV...
>

As a follow up: Rubinius, an alternative Ruby virtual machine written in
C++, should be much easier to embed than the standard MRI interpreter.

It's not exactly "prime time" material for advanced Ruby applications 
but it
should certainly be enough to handle basic Ruby scripting capabilities 
in
another application.

I don't have specific instructions for doing a C embed of Rubinius but 
if
you hop onto IRC and hit #rubinius on irc.freenode.net I'm sure they'd 
be
willing to help you.

I took a look at Rubinus and it doesn't support Windows, my primary 
audience.

On Mon, Feb 8, 2010 at 6:48 PM, Schala Zeal 
<schalaalexiazeal@gmail.com>wrote:

> I took a look at Rubinus and it doesn't support Windows, my primary
> audience.
>

Honestly if you're looking for a language which embeds easily into C/C++
programs I think Lua is the way to go.