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.
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.
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.
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:
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:
“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-deï¬ned â€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.
On Sunday 07 February 2010 06:15:17 pm Bill K. wrote:
Schala Z. 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-deï¬ned â€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.
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.
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.