Newsgroup: it.comp.giochi.avventure.testuali
Titolo: Modello di gioco.

 examine shaft of light
I can't see such a thing
...
Adding FUNCTIONAL graphics you just don't have to provide an "examine"
verb to relate the player with the fictional world, and you (and the
player) can concentrate on the storytelling.
Last but not least, a game like this has a place for actors. I'll never
forget the great acting performed in Zork Nemesis; the slyness of the
characters in the final sequence is what is actually saving your life...
as you realize in that moment what's really going on.
Another possible usage of actors is in reciting the spoken parts. In
example, the fade-in of the "Are you Toret Vargas?" sentence in the above
script may have been underlined by a voice reciting it. That was a very
witty feature in the famous Doujin "Narcisus" (actually, it
couldn't even been defined a "game" as there was not a single choice to
make in that; it was just and exactly a dynamic book). All the sentences
of the only character were recited by an actress. Yet, this limits
internationalization by some degree.
With cheap 3D cards and free and simple 3D engines and modeller programs
being available around, it is now possible also to integrate 3D graphic
in text-based games. I don't have in mind to bring IF and FPS (first
person shooter) to some merge point, but being able to draw 3D scenarios
with some cinematic element instead of static frames may be worth an
experimentation.
A project like that would require the following talents to cooperate:
- 1 Subjectist (specialized in writing general ideas and character
outlines).
- 1-2 Storyliners (specialized in laying down the game storyline,
including every possible development)
- 1-4 writers (writing the definitive text)
- 1-2 programmers
- 1-2 designers (pencil artists)
- 1-4 graphic artists
- 1-2 musician
- 1 sound effect expert
- eventually actors at will.
In small project, it happens that more roles are covered by the same
person; in example, a subjectist may integrate also the roles of
storyliner and writer, or a graphic artist may be also a designer. In
some case, there are also interesting cross competences, as for some
storyliner-programmer-musician I know of.
The point is that game like the one I mentioned are meant to be
teamworks, and that explains why, while the Doujin games keep having a
growing success, and despite the open source community has superior
products as Ren'py at disposal to write them, "amateur doujin" are still
few in number and low in quality. IMHO a minimal team meant to do a good
job should be made of no less than 4 people: one taking care of the
"literature" part, one programmer, one designer with graphics skills and
one musician/sound designer. The minimal product to be considered
"valid" should be a Book Dynamic that can be read in 3-4 hours (for each
possible path except for the dead ends, of course), with no less than 8
background tracks and about 50 drawings. It is not necessary to
associate a different drawing for each location, and in some books
dynamic even the concept of "location" may be dropped...
=========================================================
Q.
14) And what about the tecnology behind the scenes? Could you provide
some examples to the readers?
A.
Well it's all being defined in theese days, so I can't provide any
working sample now. The idea is that to use the Falcon Programming
Language as a base to build a powerful library that can handle theese
games smoothly.
Falcon provides both Object Oriented programming constructs, which can
model the game world quite efficiently and intuitively, and functional
programming constructs, which provide a powerful mean to deal with
sequences, parsing and pure logic processing.
Other than that, Falcon provides in-bound message programming
constructs. Modelling "events", "actions", interception and reactions to
events and so on is much more easy when the underling language
understands and supports this 1-to-N interaction between program
entities. In example, "actions" in Inform are events broadcasted to
every object being "in scope", which can intercept them at many levels
by providing callback hooks as react_before, before, etc. Falcon
provides similar mechanisms, but in a much more generic fashon so that
messages can be used outside the context of a single usage pattern.
What we would like to do is that of providing a powerful and simple
library that automatizes the vast majority of the process of defining
location, actions and so on.
A model I look at with  much respect is that of renpy; renpy provides a
simple scripting language that allow to build "scenes" with simple
commands. They look like this:
init:
    $ s = Character('Sylvie', color="#c8ffc8")
    $ m = Character('Me', color="#c8c8ff")
label start:
    "I'll ask her..."
    m "Um... will you..."
    m "Will you be my artist for a visual novel?"
    "Silence."
    "She is shocked, and then..."
    s "Sure, but what is a \"visual novel?\""
This sample is taken from renpy quick start guide.
As you can see, this "command oriented" model is mainly aimed to perform
scrolling dialogs with choice points. There are also commands to change
background, foreground images and provide some visual/audio effects.
Other than that, the renpy script can "escape" to python (meaning, start
to program in real python language) for serious processing when things
get hard.
The model I have in mind is something in between Inform 6 (i.e. rages of
guru-oriented code) and the above sample (i.e. do-everything one-liners).
I would use directly Falcon, rather than having a meta-language; Falcon
is powerful and flexible enough to provide simple one-liners for doing
simple things.　The above example, rewritten in Falcon using the library
I am developing would look like:
object sylvie from Character( "Sylvie" )
   color = "#c8ffc8"
end
object me from Character( "me" )
   color = "#c8c8ff"
end
function start()
    game.say("I'll ask her...")
    me.say("Um... will you...",
      "Will you be my artist for a visual novel?")
    game.say( "Silence.",
        "She is shocked, and then...")
    sylvie.say( "Sure, but what is a \"visual novel?\"" )
end
For sure, this is a bit more verbose than the above text, but the
functional model may be exploited to do things very similarly to the
one-liner commands:
function start()
    SayALot(
       "I'll ask her...",
       me, "Um... will you...",
           "Will you be my artist for a visual novel?",
       game, "Silence.",
             "She is shocked, and then...",
       sylvie, "Sure, but what is a \"visual novel?\""
    )
end
That' much more compact, and can be much more handy in long sequences of
uninterrupted texts. The readability with respect to the renpy script
gets just a bit worse, but the flexibility it brings in (and that we
need for a non-simple-visual-novel IF model we have described up to
date) is very probably worth the distress.
There's more. Falcon functional constructs allow to "cache" whole
function calls for later processing. Look also at the following sample:
function start()
   if first_time
      thing_to_say = generateFirst()
   else
      thing_to_say = generateNormal()
   end
   //do initialization stuff
   thing_to_say()
   // do cleanup stuff
end
function generateFirst()
   return [ SayALot,
       "I'll ask her...",
       me, "Um... will you...",
           "Will you be my artist for a visual novel?",
       game, "Silence.",
             "She is shocked, and then...",
       sylvie, "Sure, but what is a \"visual novel?\""
    ]
end
function generateNormal()
   return [ SayALot,
       "We knew where we standed...",
       me, "You already know, eh?",
       game, "Silence.",
       sylvie, "Yes I do."
    ]
end
Thing_to_say in start() is a "callable array" (a processable list),
which is returned by the chosen function and then processed at a later
moment.

Molto interessante, Giancarlo...
Anche io sto studiando da un po' di tempo le visual novel come forma
di narrazione interattiva.
Tienici aggiornati.
Rob


:-)
Scusate per non essermi fatto vivo per un po', pur avendo un bel po' di
materiale sulla linea di partenza.
Quello che mi manca in questo momento per fare qualcosa di serio è un
binding minimo con SDL (una libreria multipiattaforma di gestione di
grafica 2D, font, immagini e cose simili), e anche un binding con un
windowing essenziale (GTK?) non guasterebbe.
Purtroppo, il mio piano di lavoro passa prima per XML, poi per MYSQL,
Interbase e ODBC, e contemporaneamente per Apache. Quindi, io non potrei
mettere le mani sugli strumenti di base che servirebbero per ancora,
diciamo, tre-quattro mesi, come minimo.
Però, c'è da dire che Falcon sta per essere incluso in KDE e che ci sono
ottime probabilità che esca già nella prossima release UBUNTU (hardy).
Quindi, prevedo di avere a disposizione qualche collaboratore abbastanza
presto, e un modulo SDL sarebbe un ottimo banco di prova per un
neo-falconiere.
Ovviamente, se qualcuno vuole farsi avanti anche fra di noi, oppure
conosce qualcuno che potrebbe essere interessato...
Giancarlo.
P.s. nell'intervista c'è molto di più! Non perdetela! :-)

ottime probabilità che esca già nella prossima release UBUNTU (hardy).
Urka. Complimenti... :-)
Saluti da
Vincenzo Scarpa
http://www.vincenzoscarpa.it/inform/manuale
http://www.vincenzoscarpa.it/emulatori/manuale

 neo-falconiere.
E bravo, complementi!!!
Tommaso