Re: SCUMM system (was something different)

[Ingo Ruhnke <grumbel@gmx.de>]

Philipp Gühring <p.guehring@enemy.org> writes:

>> Jep, just read your article and had a quick look at the sources of
>> Wuerstelstand.
> How do you like the article? Was everything clear?

The article is to much specific to the implementation of Dialog, I
missed generic description of what happens in a human/human dialog
situation, how, things work in the reallity and how to simulate them
in the computer.
And also Dialog uses the german language, no problem for me, but for
other people it could be a bit hard to understand.
 
>> For a SCUMM like engine I would rewrite the stuff,
>> to add some more flexibility and portability. 
> What exactly would you change? Only to fit your specific needs, or
> general improvements? Do you already have ideas how to improve it?
 
The thing is only 1000 lines of code, not to much. Therefore it
would be probably easier to rewrite it than to fix the existing
code. Its also that if you reimplement a thing a second time, the
second implementiation is mostly much better than the first one.

Maybe I would complete reimplement the thing in guile(scheme) to have
much more flexibility than in a compiled language and to have
interoperability with the rest of the game. But as I know not much
about guile, I can give you a lot of details, I first have to learn
how to use it correctly.

> I had the idea too.  The problem is that Dialog needs a "menu"
> engine, which is graphic target dependent.  But I don´t know how
> that should work.  Please tell me, if you find a solution for this.

I would simple seperate the dialog text from its output, something
like this (this quick,dirty and buggy):

<pseudo code>
        struct Dialog {
                char* text[];
                ...
        };

        Dialog dialog;
        dialog = open_dialog("file");       // Output independent

        while(!quit) {
                if (need_choiche(dialog)) { // Output independent
                    int i;
                    i = choose_something(dialog); // Present a gfx menu
                    set_choice(dialog, i); // Output independent
                }
                do_other_games_stuff();
                render_dialog(dialog);    // Display the answers
        }
</pseudo code>

The dialog libary should just give a sentence to render, than the gfx
lib, renders the sentence, if the dialog lib, needs a choice, it
returns a number of sentences, where the gfx libs, generates a menu
from, than the menu returns the index of the choice to the dialog lib.

> I would be very interested to develop a linkable library out of
> Dialog.

I don't want to implement it now, but sometimes later as a part of a
Adventure system, since the adventure system is not yet written or
designed, I wouldn't know how to make the thing flexible enough to
combine it with the adventure system.
The problem is that I don't have much time at the moment and another
project running (Pingus), so it will take some time before I start
with the adventure system.
 
> But on the other hand, Dialog is meant as a piece of code, which has
> to be adopted to every environment, which uses it, because every game
> (kind of game) has different needs. (Trading simulation, Adventure, ...)
 
Yep, if Dialog works like you want it to, then there is not really a
need to reimplement the thing, it wouldn't bring any advantage for the
existing games, just some work.
 
>> 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.)

-- 
                                  http://dark.x.dtu.dk/~grumbel/pingus/ | 
Ingo Ruhnke <grumbel@gmx.de>             http://home.pages.de/~grumbel/ |
------------------------------------------------------------------------+