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

Zach Baker <[e-mail]> wrote:
: Todd Gillespie wrote:
:> Oh ghod, how I wish it were so.  The smarter groups in the industry do
:> this, for instance id & Unreal takes this approach[...]

: 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.  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.

There is no reason to suppose your hypothetical baseball game would have
firmer design schedules, or would be less receptive to flexibility.

: 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.  It is one of the
best ways we have right now of keeping, say, the game script from mucking
with the memory management of the collision system.  Good design provides
for this seperation already -- implementing a scripting system enhances
that by moving script code out of the same execution context.

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.

"You heard it here first." :)

: Zach Baker <[e-mail]>
: Any game can be improved with the introduction of a rocket launcher.

Life, too.  

I like your homepage, btw.