Überleungen zu Point&Click Engine in Konsole

[Cloppy]

Hallo,
zur Zeit sind Semesterferien. Da ich nicht ganz ohne Informatikübungen bleiben möchte, habe ich mir in den letzten Tagen selbst eine gestellt, nachdem ich die alten LucasArts Klassiker wieder rausgekramt habe:
Zu verstehen, wie eine klassische Point&Click Adventure Engine funktioniert und möglichst (wenn vllt auch nur rudimentär) eine eigene programmieren.

Deswegen ziehe ich euch (die hier sicher noch ein ganzes Stück erfahrener sind) zu Rate und bitte euch, mir bei einigen Überlegungen zu helfen. Als ich nämlich so darüber nachgesinnt habe, kam ich schon zu den ersten Problemen.

Was umfasst eine Engine überhaupt? Prinzipiell müsste es ja Code sein, der Daten einliest, diese interpretiert, bearbeitet, etc und die Daten wieder aktualisiert. Es müsste quasi so allgemeiner Code sein, dass ich ihn in jeden Point&Click Spiel verwenden könnte (sofern es den gleichen Stil haben sollte) ohne groß was dran zu verändern. Das eigentliche Spiel müsste dementsprechend aus Dateien bestehen in denen die Dialoge, die Gegenstände, die Aufgaben, die Personen, die Grafiken, etc enthalten sind, die dann von der Engine interpretiert werden. Lieg ich damit richtig, oder ist das schon wieder viel zu allgemein?

[rapso]

es gibt keine allgemeine definition von engine, verallgemeinert steht das wort fuer 'grosse bibliothek'.

meine definition ist
x-engine definiert eine engine die fuers x zustaendig ist. dabei kann x:
-3d : engine die etwas im 3d raum verwaltet, das kann ganz ohne rendern, sound etc. passieren
-render: engine die irgendwas darstellt
-sound
-network
-adventure engine
-...

falls die sache nicht gross ist, nennt man das eher lib, ich hab bisher z.b. keine "input"-engine gesehen ;), es gibt auch viele netzwerk libs (statt engine) und audio libs.

Dein ansatz von einer engine ist sehr gut, es waere eine pure datadriven engine. aber das ist nicht zwingend noetig, denn es gibt viele engines die ohne programmieren nicht auskommen, sie kapseln lediglich etwas komplexeres mit einfachem interface und oft haben sie auch loesungen und optimierungen fuer probleme die sonst jeder nochmal selbst loesen muesste, was nicht unmoeglich, aber sehr zeitaufwendig sein kann (FreeType, was sich selbst als lib bezeichnet, waere ein sehr gutes beispiel).

Dein ansatz bietet sich aber sehr gut fuer ein Adventure an.
an sich besteht ein adventure aus einer state machine und einzelnen screens.
die einzelnen screens haben
-links zu weiteren screens.
-state kaskaden die filtern was gesagt wird und getan werden kann beim click

links koennen auch gefiltert sein

primitives beispiel:

//index.script

<switch param="clickobject">
  <case equal="gnome">
  <switch param="zauberstab">
    <case equal="0">
      <event type="print" param="du brauchst erst den heiligen zauberstab, sprich mit zauberer susi" />
    </case>
    <case equal="1">
      <event type="print" param="klasse, da hast du ja das nutzlose ding, tritt ein" />
      <event type="door" param="1" />
    </case>
    <case greatherThan="1">
      <switch param="susientschuldigung">
        <case equal="0">
          <event type="print" param="boah, hast wohl susi uebers ohr gehauen. geh und entschuldige dich" />
        </case>
        <case equal="1">
          <event type="print" param="jetzt wo sie nicht mehr weint darfst du durch, Arsch" />
          <event type="door" param="1" />
        </case>
    </case>
  </switch>
  </case>
  <case equal="schlosstuer">
    <switch param="door">
      <case equal="0">
        <event type="info" param="tuer ist verschlossen" />
      </case>
      <case equal="1">
        <event type="link" param="screenschloss.script" />
      </case>
      <case equal="2">
        <event type="info" param="du wurdest aus dem schloss verbannt" />
      </case>
    </switch>
  </case>
</switch>

die simpelste statemachine kann dabei std::mapstd::string,std::string sein

als scripts kann man xml nutzen, einen eigenen parser oder eine simple scriptsprache.

komplexere scriptsprachen koennen dabei oefter ein nachteil sein, da soeine statement-filter-graph sehr zweckdienlich ist und nicht wirklich erlaubt programmierfehler zu machen, lediglich logic oder syntax. endlosschleifen weil man einen state setzt und gleich abfragt (gamefreez wegen nem script) kann man ausschliessen. events kann man schoen loggen und zum debuggen nutzen und auch um eine weniger versionsabhaengige lade/speicher routine zu haben (schreibt z.b. jemand noch einen neune event in ein script, arbeitet man das ab und geht weiter die eventqueue aus dem save, wenn dann neben dem "zauberstab" ein "sauberschuh" im inventar ist, wird das spiel eventuell weiterladen koennen.

naja, genug von meinem spam

[hustbaer]

als scripts kann man xml nutzen, einen eigenen parser oder eine simple scriptsprache.

Eine simple Scriptsprache wäre z.B. Lua. Eine andere wäre Tcl. Also wenn man sich nicht selbst was schreiben möchte.

[rapso]

hustbaer schrieb:

als scripts kann man xml nutzen, einen eigenen parser oder eine simple scriptsprache.

Eine simple Scriptsprache wäre z.B. Lua. Eine andere wäre Tcl. Also wenn man sich nicht selbst was schreiben möchte.

fuer den anwendungszweck sind die schon recht komplex.

ich hab aus faulheit mal ini dateien mit lua geparst, als die leute das rausfanden haben sie allerlei lustige formel eingebaut und globale variablen gehabt die dann andere ini dateien zerschossen hatten...

ich will niemandem lua ausreden, aber man sollte sich auf einiges einstellen

[hustbaer]

Naja Lua-Scripts als "Datenfiles" zu verwenden schlage ich ja auch nicht vor. Ein Script ist ein Script. Wer nicht möchte dass ein Script irgendwelche krummen Dinge machen kann muss eben darauf verzichten, oder Arbeit investieren um sicherzustellen dass es nicht geht. Bei einem Adventure-Game denke ich aber es sollte egal sein. Wenn der Spiel-Author was krummes machen möchte, dann soll er halt
Die schlimmsten Sachen (File-Funktionen etc.) kann man bei Lua ja einfach weglassen soweit ich weiss.

Und was Tcl angeht... Tcl ist nur wirklich ziemlich harmlos und einfach, nicht?