SCI (was: SCUMM system)

[Christoph Reichenbach <creichen@rhein-main.netsurf.de>]

Hi,

> >> But the Sierra adventure engine is available, some people
> >> started to rewrite it after reverse engeniering the thing. 
> > Yes, I already took a look at it, but I didnīt found enough useful
> > information.
> I hadn't had a deeper look at it, but maybe the object management
> could be interessting (using objects together, taking/dropping
> objects, etc.)

I don't know about AGI, but SCI (the system Sierra introduced in KQ4 and used up
to LSL7) takes a very low-level approach which make it similar to Java in some
ways: SCI is based on objects and classes in (almost) the usual OOP sense (with
object-relative variables and methods), and it uses the SCI assembly language
(about 2 * 120 opcodes, for byte-sized and word-sized arguments) for
practically all of the game logic. Interfacing to the interpreter is done with
a set of kernel functions; they're used to display graphics, play music, update
the screen, do string manipulation, read and write data, load other scripts,
provide input events and do lots of other stuff.

SCI has the big disadvantage of having lots of arbitrary limits; most of them-
like the class table limit- are only an issue for Sierra's SCI interpreters;
but SCI bytecode is inherently 16 bit, using a 16 bit address space, so memory
runs out pretty quickly (some of the later, more complex games like Quest for
Glory 2 had to implement a sophisticated overlay system- using the SCI language
(it /is/ quite flexible)- to work around this constraint).


IMHO, the best approach for adventure game development- maybe even for other
games- would be to re-implement the basic principle behind SCI using modern
tools, e.g. by embedding Python or Perl. All complex games need some
sort of scripting nowadays- it tends to speed up development e.g. by making
debugging easier- so why not use one of the ready and proven interpreters for
this?

llap,
 Christoph