Quellen für ein Open-Source-Adventure

[G33k]

Hallo, kennt jemand von euch mögliche Quellen, auf denen ich ein Open-Source-Adventure aufbauen könnte?

Ich würde gern ein kleines Proof-of-Concept-Spiel mit dem freien Scumm-Compiler ScummC implementieren, der bislang erst einen recht ereignislosen Stub als Beispiel hat:



Ich fürchte aber, der Compiler ist noch nicht reif genug, um ein Team zur Produktion eines neuen Spiels zu motivieren. Und gute eigene Ideen hab ich auch nicht. Daher würde ich lieber zuerst etwas existierendes portieren, natürlich mit Zustimmung des Authors.

Ich suche darum eine der folgenden Quellen:

• Ein existierendes, GPL-kompatibles Open-Source-Adventure
• Ein existierendes, GPL-kompatibles Interaktive-Fiction-Werk in einem anderen Genre, aus dem man Puzzles oder Dialoge portieren könnte
• Ein existierendes Indie-Adventure, dessen Author die Spiellogik freigeben würde
• Oder ein unfertiges, totes Projekt, dessen Author die halbfertigen Skripte lieber freigeben würde, anstatt sie in seiner Schublade verschimmeln zu lassen

Hat jemand von euch eine Idee?

Bislang habe ich noch kein einziges Stück Open-Source-Software gesehen, das irgendwie eine Story hätte. Postet also ruhig auch abwegige Einfälle. Zumindest in der letzten Kategorie sollte es doch etwas geben...?

Ich bin in erster Linie an der Spiellogik interessiert, um ScummC auszutesten. Grafiken, sofern vorhanden, könnten ruhig proprietär bleiben und durch Dummy-Grafiken ersetzt werden.

Hoffe auf ein extensives Brainstorming!
G33K

[KhrisMUC]

Also es muss ScummC sein? Du willst in erster Linie speziell ScummC testen und erst in zweiter Linie ein Adventure machen?
Sonst hätte ich Dir schlicht eine andere Engine empfohlen (natürlich AGS ).

[G33k]

Also es muss ScummC sein? Du willst in erster Linie speziell ScummC testen und erst in zweiter Linie ein Adventure machen?

Genau. Ich hab ScummC schon angetestet, und es läuft eigentlich alles. Aber ich bin sicher, dass bei einem Spiel mit mehr als einem Inventory Item noch der eine oder andere Bug auftritt.

In zweiter Linie will ich aber auch ein Open-Source-Adventure-Projekt finden bzw. starten. Ich kann vollkommen verstehen, wenn die meisten Leute ihren Code nicht freigeben wollen. Das ist auch in Ordnung, die Kollaboration funktioniert ja auch so, auf persönlicher Basis. Aber in vielen anderen Spiele-Genres gibt es trotzdem ein paar freie Projekte: FPS, RPG, RTS, Simulationen, Arcade... Und bei den Adventures kein einziges? Woran liegt das denn?

Die Communities und die Indie-Szene sind doch sehr lebendig, es wird viel produziert und zusammengearbeitet, die Leute sind kreativ und nicht nur auf kommerzielle Ware aus...

Ist der Grund, dass die FOSS-Bewegung eher aus der Programmierecke kommt? Die meisten freien Spiele-Projekte werden auch von Programmierern gestartet und sehen erst mal grottig aus, bis dann Grafiker, Animatoren, Musiker und Authoren später auf den Zug aufspringen, wenn er an Fahrt gewonnen hat. Ein Projekt, wo das fantastisch funktioniert hat, ist z.B. Wesnoth. Die Intro-Screens zur Hauptkampagne stellen inzwischen alles in den Schatten, was ich bisher gesehen habe.

In der Adventure-Szene gibt's ja auch Programmierer, aber die programmieren eher neue Engines, die dann nie benutzt werden. Von solchen Projekten hab ich leider relativ viele gefunden. An ScummC hat mich dann auch gefesselt, dass sie immerhin einen funktionalen Game-Stub geschrieben haben, mit animierten Charakteren, Interaktion und Dialog, auch wenn es noch keine echte Handlung gibt. Der Stub funktioniert gut, und ich denke, inzwischen hat das Projekt darum mehr verdient.

[KhrisMUC]

Es liegt wahrscheinlich an der Komplexität von Adventure-Engines.

Erstens nutzen viele Adventure-Entwickler vorhandene Engines; nur sehr wenige machen sich die Mühe, eine solche komplett selbst zu schreiben.

Zweitens nimmt einem eine vorhandene Engine so viel Arbeit ab, dass sich eine Veröffentlichung der Source normalerweise höchstens als "HowTo für Newbies" eignet.

Genau so ein Spiel wurde vor kurzem für AGS veröffentlicht: thread, download.

[G33k]

Genau so ein Spiel wurde vor kurzem für AGS veröffentlicht: thread, download.

Hey, sowas hab ich die ganze Zeit gesucht! Ist ja wirklich brandneu...

1000 Dank!

[nihil]

Die Spiele, die wir bisher bei den WME-Competitions gemacht haben sind auch Open Source, sind allerdings auch nur 2: http://forum.dead-code.org/index.php?topic=1873.0

[Lebostein]

Ich verfolge ScummC auch so nebenbei, da ich schon seit vielen Jahren auf einen derartigen Editor warte (im Grunde genommen ist es ja keine Engine sondern nur ein Editor für Datenpakete im Scumm-Format, die dann mit der Scumm-Engine abgespielt werden). Leider scheint sich dort nichts mehr zu tun. Wird an ScummC überhaupt noch gearbeitet?

Hat eigentlich mal jemand versucht, mit den alten LA-Programmierern in Kontakt zu treten? Einige Datenblöcke im Scumm-Format sind ja immer noch unbekannt bzw. nur teilweise entschlüsselt...

[G33k]

Die Spiele, die wir bisher bei den WME-Competitions gemacht haben sind auch Open Source, sind allerdings auch nur 2: http://forum.dead-code.org/index.php?topic=1873.0

Nochmals danke. Ich fürchte aber, bei einer 320x200-Auflösung würde deine Mystery-Atmosphäre etwas verloren gehen. Ich werde mich daher erstmal an die pixeligen Teddies von OpenQuest halten.

Leider scheint sich dort nichts mehr zu tun. Wird an ScummC überhaupt noch gearbeitet?

Es wird weiterhin daran gearbeitet. Ein Entwickler hat auf seiner Homepage über die letzten Fortschritte geschrieben, und über einen Versuch, Code aus ScummVM und dem ScummC-Interpreter nach Flash zu porten. Es gibt allerdings wenig Leute in dem Projekt und eher geringe Aktivität. Da die Basics bereits unterstützt werden, und trotzdem niemand den Compiler benutzt, kann ich es den Leuten nicht verdenken.

Hat eigentlich mal jemand versucht, mit den alten LA-Programmierern in Kontakt zu treten? Einige Datenblöcke im Scumm-Format sind ja immer noch unbekannt bzw. nur teilweise entschlüsselt...

Ich glaube eben, dass die Entschlüsselung der letzten Datenblöcke zumindest der Entwicklung eines freien Scumm-Compilers nicht großartig weiterhelfen wird. Die allermeisten Features, die für ein funktionierendes Spiel gebraucht werden, sind ja dank der Arbeit von ScummVM und LucasHacks geknackt. Meine Überlegung ist eher, dass jemand mal versuchsweise ein Spiel mit ScummC schreiben sollte, um die gegebenen Möglichkeiten und Grenzen auszutesten, und so mehr Motivation für eine Weiterentwicklung zu schaffen.

Mit OpenQuest komme ich da ganz gut voran. Ein Teddy hat bereits das Laufen in Scumm gelernt...

[Lebostein]

Ich bin bereit, die Sache mal näher zu testen. Was benötige ich denn, um den Source unter Windows zu kompilieren? Geht das überhaupt? Mittlerweile habe ich mir über TortoiseSVN den aktuellen Stand (Rev. 266) heruntergeladen.... programmiertechnisch bin ich zwar durch andere Programmiersprachen relativ gut ausgebildet (das Lesen und Verstehen von C bzw. C++ Code eingeschlossen) aber mit dem Kompilieren und dem ganzen Makefile-Kram von C kenn ich mich absolut nicht aus....

[max_power]

Kann man ein ScummC Spiel unter ScummVM spielen?

[G33k]

Laut README kompiliert und funktioniert ScummC unter Windows mit Mingw und Cygwin. Ich habe es mal mit Cygwin getestet, und konnte zumindest den ScummC-Compiler kompilieren und benutzen.

So geht's: Auf der Cygwin-Homepage muss man sich setup.exe runterladen ("Install Cygwin now") und starten. Zusätzlich zu den Default-Packages müssen in der Kategorie Devel noch die Packages "bison", "gcc-g++" und "make" ausgewählt werden. Falls sonst kein SVN-Client installiert ist, kann man noch "subversion" dazunehmen. Abhängigkeiten werden automatisch aufgelöst. Nach dem Start von Cygwin kann man mit den folgenden Zeilen erstmal den ScummC-Compiler selbst kompilieren.

Code: Alles auswählen

svn checkout https://dotsec.net/repos/scummc
cd scummc/trunk/
./configure
make

Jawohl, man kann ScummC-Spiele wie alle Scumm-Dateien ganz normal unter ScummVM spielen, das ist ja (zumindest für mich) der Witz an der ganzen Sache. Um die Dateien zu akzeptieren, muss ScummVM aber momentan noch gepatcht und neu kompiliert werden, was unter Windows wohl eher komplizierter ist. Im README ist eine Alternative beschrieben: man kann zusätzliche Parameter übergeben, um das Spiel als DOTT zu maskieren. Dazu muss man Zeile 70 des Makefile unter scummc/trunk/examples/road/Makefile so verändern:

Code: Alles auswählen

$(SLD) -v $^ -o tentacle -key 0x69

Um dann mit dem ScummC-Compiler das Beispiel-Adventure "Road" zu Scumm-Dateien zu kompilieren, genügt es, das Makefile auszuführen:

Code: Alles auswählen

cd examples/road/
make

Es werden dann 3 Dateien erzeugt: "tentacle.sou", "tentacle.001" und "tentacle.000", die mit ScummVM abgespielt werden können. Im Großen und Ganzen ist also alles noch nicht sehr benutzerfreundlich, hehe. Deswegen hatte ich auch erstmal mehr nach freien Quellen gesucht, und nicht nach Adventure-Entwicklern, die Lust haben, sich damit rumzuschlagen.

[Lebostein]

Danke für die kompilierten Dateien @G33k. Das Demo-Spiel macht ja schon einen sehr soliden Eindruck. Wenn das ScummC irgendwann mal für jedermann "bedienbar" ist, hat das sicherlich eine große Zukunft vor sich. Spiele erstellen mit der original Monkey Island-Engine. Wer hat nicht schon davon geträumt...

Also ich würde dich bei deinem Vorhaben unterstützen, wenn ich das ganze irgendwie zum Laufen bekäme und selber die Dateien kompilieren könnte... um zu testen usw.

PS: Da haben wir wohl zur selben Zeit geschrieben. Ich les mir deinen obigen Beitrag gleich mal durch. Danke!

[Lebostein]

Also ich habs jetzt einmal auf meinem Heimrechner und einmal auf Arbeit probiert. In beiden Fällen scheitert das Kompilieren mit jeweils anderen Fehlermeldungen. Auf Arbeit hab ich zum Beispiel so was:

boxedit.d:1: *** multiple target patterns. Stop.

Muss irgendwas mit den relativen Pfaden im Makefile zu tun haben bzw. mit irgendwelchen Leerzeichen oder mit Differenzen zw. Windows und Unix-Pfadschreibweise... laut Internet

Die ersten Zeilen bzw. Zeile 1 in der "boxedit.d" sieht übrigens so aus:

1: boxedit.o: /home/leibelt/scummc/trunk/boxedit.c ./config.h \
2: /home/leibelt/scummc/trunk/scc_fd.h \
3: /home/leibelt/scummc/trunk/scc_util.h \
....

[G33k]

Frohe Botschaft: OpenQuest wurde erfolgreich nach ScummC portiert. Die Scumm-Version des Spiels ist als Download verfügbar, und kann ab sofort von jedermann in ScummVM abgespielt werden. Vielen Dank nochmal an das ganze Forum für die Tips!!!

Hat vielleicht sonst noch jemand Lust, die Quellen von seinem Adventure für eine Portierung freizugeben?



Zusätzlich sind mit dem neuen 0.2.0-Release jetzt auch Win32-Binaries aller ScummC-Tools verfügbar, so dass man sie nicht mehr selbst kompilieren muss.

Einziger Wermutstropfen: das Kompilieren der Spiele basiert weiterhin auf Makefiles, die erstens eine UNIX-Umgebung mit Make brauchen, und zweitens unter Windows wegen irgendwelcher OS-spezifischer Syntax anscheinend nicht richtig funktionieren.

Das bedeutet, das ScummC-Projekt braucht weiterhin dringend versierte Windows-Kommandozeilenbenutzer, um entweder die Makefiles Windows-fähig zu machen, oder alternative Batch-Dateien zu schreiben. Also, Leute... meldet euch!

[neon]

Was bedeutet in dem Fall 'Schreiben von alternativen Batch-Dateien'?

Batch-Dateien zu schreiben ist doch nun wirklich kein Problem, Probleme machen meistens die Kommando-Tools, weil sie keine ordentlichen Kommandozeilenparameter mitbringen.

Kannst du da mal mehr ins Detail gehen?