[ruby-talk:18945] Re: Ruby as opposed to Python?

Todd Gillespie wrote:
> : Sure, but those two are also creating complete game engines that they
> : license to other publishers and developers.  Those are projects that
> : demand lots of flexibility and have a significant maintenance stage.
> : But if you're making, say, a baseball game, general-purpose scripting
> : like UnrealScript isn't a major priority.
> 
> That would be entirely correct if it weren't for the small problem that
> games remain vaguely designed right up until mastering.  If you know that
> the requirements are going to change once a week, you have a strong
> impetus to add a scripting layer, regardless of your licensing
> intentions.

Details are vague, but not the big picture, not to the degree where you'd
often need something on the order of UnrealScript.  Few games have a major
need for general-purpose scripting, while most have or would benefit from
focused, special-purpose scripting.  Embedding Ruby in an application is
the easy part.  Adding another language domain to the entire program
design is what's difficult.

> For example, the hit series 'Crash Bandicoot' is written in
> LISP on a C graphics engine.  (Note: LISP.  on a 30Mhz MIPS chip. running
> fast.  just thought that was cool.)  I do not recall them selling this
> engine to anyone, but I do recall the flexibility of their games.

Sure, something like GOOL/GOAL is great for behavior, since Lisp is the
very definition of flexibility.  In the right hands, that is; I wouldn't
embed CMU CL in a game where most scripting is going to be done by a few
non-programming assistant producers.  Although entity behavior is the soul
of a platform-adventure game, that's still task-focused scripting rather
than high-level component glue.

> : The most common role for scripting languages in games is to facilitate
> : lightweight programming -- design by scripting.  Only games with a very
> : general architecture tend to use scripting in the more powerful "glue
> : language" sort of way, because of the time it takes to design, implement
> : and maintain an appropriate scripting interface. But hey, if you've got
> : the time, it's a slick way to do things.
> 
> Component architecture is more than what you are crediting it with -- it
> is a solid improvement in the stability of programs.

Actually, my focus here is specifically on the role of fully general
scripting in games, not on broader design topics.  Just trying to keep
things somewhat on-topic!

> I'll put my wizard hat on now and predict the future.  The future will
> have many more component/scripting architectures.  All the smartest teams
> are already doing this; we've seen the pack follow before and they'll
> follow again.  Current resistance is based on a blend of rigidity of
> current tools, poor education (CS is notoriously poor in teaching the
> handling of foreign data), and the severe time constraints that game teams
> work under.

I don't think the near future will see that deeper kind of scripting as
much as just more scripting in more problem domains.  In fact, I think
that even if projects do make scripting central to their architecture,
they'll still have these kinds of domain-specific needs.  I see the most
important role of scripting in games to be integrating logic into data
at the lowest levels, not binding components at a higher level.  I don't
think that's going to change anytime soon, and in fact I see scripting
and project-oriented customization showing up earlier and earlier in the
art pipeline.  With improved asset management tools, assets could be
scripted and specified before they're even created.  As a result, I'd
say that you'll see less time spent in asset integration tools (editors)
as more of their tasks can be done inside general-purpose 3D packages.

However, I think smaller game projects will be increasingly 100% written
in languages like Ruby (using Ruby/SDL or RUDL for example).  This isn't
a new phenomenon, though, considering how many games have been written
in BASIC through the years.  However, I don't forsee this kind of move
to scripting languages for console and similar style games, although
middleware and multi-platform engines will become more widespread.

---
Zach Baker <[e-mail]>
"Dewey, you fool.  Your decimal system has played right into our hands!"