Weitere Adventure-Engine entdeckt: "Monkeyscript"

[Lebostein]

Moin, moin

bin gerade durch Zufall auf eine Seite gestoßen, auf der jemand seine Scriptengine mit Namen "Monkeyscript" vorstellt:

http://www.hd-rec.de/Monkeyscript/

Eine erste Version ist noch nicht veröffentlicht, aber eine deutsche Dokumentation kann schon gelesen werden: "The documentation is quite outdated and a lot of things have changed, but it gives you an overview what it is about."

Hab mich jetzt noch nicht weiter damit beschäftigt, also keine Ahnung ob das eine interessante Sache ist...

[Lebostein]

Hab grade mal dem Entwickler Thilo eine Mail geschrieben. Er schreibt folgendes zurück:

Also wie gesagt, die Engine ist fertig. Sie unterstützt alle Auflösungen und Farbtiefen. Bilder werden on-the-fly der Farbtiefe angepasst. Auch die FPS lassen sich konfigurieren. Auflösung sollte aber passen, d.h. man legt sich bei einem konkreten Adventure schon fest. Mein Projekt ist in 640x480. Höhere Auflösungen haben irgendwie kein "Adventue" Feeling mehr, weil alles zu fein ist.

Sie besteht grundsätzlich aus folgenden Komponenten:
- Texteditor mit Syntax highlighting für die Skripte/Objekte/locations
- Compiler, der die Skripte in Pseudo Binär Code umwandelt (ähnlich wie Java) und natürlich auf Fehler überprüft.
- Location Editor, mit dem man die Lauf-Pfade grafisch editieren kann, geht aber auch "per Hand"
- Runtime Environment, was die Skripte letztendlich ausführt, wobei es eine Debug und eine Release Version gibt.

Bei der Debug version läuft alles innerhalb eines Fensters, man kann den Ablauf anhalten, den Objekt Cache beobachten etc.
Die Release Version läuft Full Screen und zeigt natürlich nichts mehr an.

Musik wird über Audio Dateien realisiert. Man kann z.B. wav oder mp3 loopen als Backgorund Geräuschklisse oder Musik. One-Shot Sounds gehen natürlich auch.

Das ganze läuft unter AmigaOS3.x/AOS4 und MOS. Unter Windows z.B. mit Hilfe von WinUAE. Eine Windows Version der Runtime ist geplant. Das geht relativ einfach, weil die "Intelligenz" in den Scripten liegt und die Runtime einfach nur macht, was sie gesagt bekommt. Die Runtime ist deshalb sehr klein.

Damit die Skripte übersichtlich bleiben, kann man von einem Skript aus ein anderes Aufrufen. Ich programmiere also nur einmal, wie die Figur mit den Achseln zuckt und rufe das wie eine Funktion auf. Dadruch ist die Engine sehr flexibel, ich kann also alles machen was sich irgendwie Programmieren lässt, und bin nicht an feste Abläufe gebunden. Möchte ich z.B. einen Side-kick für meinen Haupt Charakter haben, dann kann ich den einfach programmieren. Die Engine muss das nicht vorher wissen. Genauso kann ich den Charakter wecheln oder seine Ansicht (also auch mal ein Raum von oben gesehen etc.).

Die Anleitung auf meiner HP ist leider ziemlich out-dated.

Die Engine ist weitestgehend fertig. Nur das Adventure dazu noch nicht. Das ist halt jede Menge arbeit. Von dem Adventrue existieren ca. 10 Räume, 6 Musikstücke und die Story.

Und das Bildchen hat er noch mitgeschickt:

[Norman [nicht eingeloggt]]

Das hört sich ja schonmal sehr lobenswert an.

Wird zwar im Endeffekt schwierig werden, die alteingesessenen Engine-Veteranen wie AGS etc vom Thron zu stoßen, aber dafür hat er sie wahrscheinlich auch nicht geschrieben

Der Screenshot sieht auch sehr schick aus. Wenn er das selbst gemalt hat, neben den offensichtlichen Programmierfähigkeiten also auch noch ein grafische Talent hat, ist er ja fast autark, was die Adventureentwicklung angeht.

[max_power]

Schade nur, dass die Knöpfe Betriebssystemstandards zu sein scheinen, das würde im endgültigen Spiel der Atmosphäre sehr schaden.

[Thilo]

Auch die Knöpfe sind natürlich geskinned. Der Screenshot ist schon
etwas älter.
Die Bedienerleiste kann auch ausgeblendet werden. So ist auch
ein Spiel in Fullscreen möglich, oder auch gemischt.
Ich kenne Adventure Engines unter Windows nicht. Es soll auch keine Konurrenz sein. Ich programmiere hauptsächlich für AmigaOS, und dort gibt es keine Engine die allen meinen Ansprüchen genügt. Bei meiner eigenen Engine habe ich immerhin noch die Möglichkeit, fehlende Funktionalität hinzuzufügen, auch wenn das kaum nötig sein wird da alles in den Skripten passiert.

Später kommt vielleicht noch support für ISO Ansichten dazu, dann kann man damit auch RPG machen. Durch das relativ low-level Scripting ist das ganze sehr flexibel und es sind kaum Grenzen gesetzt. So wird es auch einige Game-In-Games geben, z.B.
einen Space Invader Verschnitt in einem Automaten in der Piraten Bar.

[Thilo]

Achso, wegen dem Screenshot:
Die Grafiken sind natürlich selbstgemalt von zwei Leuten, einer davon bin ich. Am besten ist die Musik, aber die kann man auf
dem Screenshot leider nicht hören
So gesehen bin ich schon autark, was Adventure Entwicklung angeht. Einziges Problem ist die liebe Zeit.

Vielleicht findet sich ja hier jemand der die Runtime auf Windows portieren kann ? Das Hauptprogram sind ca. 4000 Zeilen, das ist eigentlich ein Witz, wenn man weiss wie es geht.
Funktionen wie Zoomen, Sound und Bilder laden etc. gibts ja vermutlich in DirextX schon, die musste ich alle selbst schreiben.
Evtl. würde sich auch SDL anbieten.

[neon]

Eine Linux-Version würde mich mehr interessieren. Da hätte ich endlich mal eine echte Verwendung für meine Linux-Kiste.

[Lebostein]

Das wär doch mal was. Eine Adventure-Engine die unter AmigaOS, Linux und Windows läuft...

[Thilo]

Dann wäre ja eine SDL Portierung am besten.
SDL gibts meines Wissens nach für sehr viel Plattformen, und die Performance von SDL würde ausreichen.

[max_power]

Ehrlich gesagt frage ich mich sowieso immer, wenn eine neue Engine entwickelt wird, warum sie nicht gleich mehrere Plattformen unterstützt. Gut, bei manchen Projekten hapert es an der Zeit (wobei ich mich dann frage, warum sie nicht etwas fertiges nehmen) und bei dir gibt es ja den Unterschied, dass du für Amiga entwickelst.
Eine Vorstellung, die mir schon lange im Kopf rumschwebt ist, eine Engine zusammen mit dem ScummVM-Team zu entwickeln, bzw. einen Editor zu basteln, der ScummVM-lesbare Skripte erstellt. Damit wäre perfekte Plattformunabhängigkeit gewährleistet. Aber vielleicht ist ScummVM ja doch zu sehr auf Scumm zugeschnitten, bzw. haben deren Entwickler kein so großes Interesse an Fanadventures, aber wer weiß das schon…

[Thilo]

Es ist halt oft der Reiz, was wirklich eigenes zu machen.
Das Programmieren ist ein Teil des Spasses, den ich beim Erstellen eines Adventures habe.
Und wie gesagt, für den Amiga gibts keine Engine, die meine Anforderungen erfüllt. Unter Windows gibts das vielleicht.

Gleich mehrere Plattformen unterstützen scheitert meistens daran, das der Author sich nur mit einer Platform auskennt. Theoretisch ist das kein Problem, ich habe aber keine Ahnung wie man unter Windows sowas programmiert.

[john_doe]

Das ist es halt.

ScummVM hat seine Anfänge unter Linux gemacht und wurde dann auf Windows usw. portiert, wo es dann aber pro BS mindestens einen gibt, der sich jeweils damit auskennt.
Alleine ist es fast unmöglich, viele Systeme zu unterstützen, da man sich wie Thilo sagt selten mit vielen Plattformen gleich gut auskennt.
Wenn ich da von mir selber ausgehe, ich benutze WinXP (jaja, ich weiß ), daher entwickle ich meine Engine auch primär dafür, behalte aber zumindest Linux im Hinterkopf, da ich mich damit wenigstens oberflächlich so auskenne, daß ich die Runtime portieren könnte.
Für andere Ports muß man dann wieder Leute "rekrutieren", das Problem dabei ist dann halt, wenn die Leute keine Lust mehr haben, und es für diejenige Plattform dann keine neuen Versionen usw. mehr gibt, bis man jemand neues gefunden hat.

Und für ScummVM wollte Serge (von ScummRevisited) eine IDE machen, mit der man zumindest Spiele im Monkey Island 3-Format selber machen kann.
Allerdings macht das außer dem Ehrgeiz, das schaffen zu wollen, nicht wirklich Sinn, da es wesentlich aufwendiger und fehleranfälliger ist, eine bestehende Engine "zu erforschen" und auszunutzen als seine eigene zu machen, ggf. aufsetzend auf Wissen bestehender Engines. Auch kann man dann keine neuen Features einbauen, da man ja auf die Fähigkeiten der bestehenden Engine beschränkt ist.
Das einzige, was man mit Hilfe von ScummVM machen könnte (vielleicht meintest du das so, max_power) ist, die entsprechende Engine mit den Teilen von ScummVM zu bauen, die für die Systemunabhägigkeit zuständig sind.

Aber die Monkeyscript-Engine sieht nicht schlecht aus.

[Thilo]

Also wen es näher interessiert:

Die Runtime macht eigentlich nicht viel mehr als einen Bildschirm in
der gewünschten Auflösung und Farbtiefe öffnen. Dann hat sie einen Interpreter für den Code, den der Compiler erzeugt hat.
Der Code kann dann so Befehle wie "Setze mir Bild "hero.gif" an
x,y für soundsoviele Frames lang" oder "Spiele mir den Sound Gong.wav ab!". Natürlich gibt es dann noch Funktionen zum
ausabfragen oder zum Abfragen der nächst besten Koordinaten
auf dem Laufpfad, das muss man nicht selbst proggen.
Die Animation, wie der Held läuft programmiere ich dann in einem Skipt und habe keine Einschränkungen. Die Skipte können dabei massiv parallel laufen und sind gekapselt.
Z.B. habe ich einen Teich. Dann programmiere ich ein Skript wie ein Frosch am Ufer entlang läuft, ab und zu mal reinspringt und quakt und wieder rauskrabbelt.
Diese Script rufe ich dann 10 mal auf, wenn die Location initialisiert wird, und schon hab ich 10 unabhängige Frösche.

Dabei werden Scripte, Bilder, Sounds, Objekte und Locations immer
mit Datei-Namen referenziert, es gibt keine IDs oder so. Das erhöht
die übersichtlichkeit bei großen Projekten ungemein. Die Files
können dann auch in unterschiedlichen Schubladen liegen. Dazu
gibt es dann einen Cache, der völlig transparent für den User
arbeitet. Man muss sich also nie darum kümmern, ob ein Bilder oder Sound im Speicher ist.

Das komplexeste an der ganzen Sache ist eigentlich der Compiler, der aus dem ASCII Text der Scripte eine Art Pseudo-Maschinen
Code generiert, der dann schnell abgearbeitet werden kann. Der Compiler kann von sehr streng bis verzeihend eingestellt werden,
z.B: was Variablen deklarationen angeht usw. Die Syntax
bewegt sich irgendwo zwischen C und BlitzBasic.

Später mache ich dann evtl. eine Pack&Go Funktion hinein, die alles
zusammen merged. Bis jetzt geht das aber noch nicht.