Browserbasierte Adventures zum Selbstbauen?

[MooMurray]

Naja, dass es nicht so viele Leute gibt, die sich mit Flash auskennen, dürfte wohl auch daran liegen, dass die Sache nicht ganz billig ist.

[beyond the void]

Hmm. Also mit einem Auftrag hatte sich mein Flash mehrfach selbst bezahlt. Soo teuer ist das auch nicht. Und ein richtiges Argument wäre das auch nicht, viele Programmiersprachen und Grafikprogramme kosten viel Geld. Aber ich will nicht streiten, nicht dass du das denkst.


ÜBRIGENS (zurück zum Thema) find ich die Idee ganz hervorragend. Ich bin ein notorischer Customizer, ich mag das immer sehr gern wenn ich was basteln darf in Spielen (ging schon los auf dem C64, Mr. Robot oder Racing Construction Kit, so Sachen..). Ich kann mir vorstellen dass das "fett umgesetzt" auch sehr erfolgreich werden würde. Naja, aber erstmal umsetzen... Wenn du das irgendwie konkreter verfolgst würd ich gern mitmachen.

[hantu]

Hallo allerseits, mal wieder ein kleines Update zum aktuellen Stand der Dinge:

Ich habe mich entschieden, dass reines Links-Rechts-Laufen wohl doch zu langweilig ist, deswegen kann man jetzt festlegen, wie der Charakter kreuz und quer durch den Raum laufen soll, hier mal ein Screenshot aus der Oberfläche, wo man das festlegen kann.


Und noch eine kleine Vorschau, wie die Spieloberfläche auf der Website aussehen wird ( in der Endversion natürlich ohne die ganzen Debug Informationen ;)



Bin wie immer gespannt auf Kommentare!

[MooMurray]

Ich nehme mal an, dass Kreise in den Graphen zum Gehen nicht möglich sind. Wäre es dann nicht besser, grundsätzlich eine gerade Linie durch den Raum zu legen und von der nur Sackgassen abzuzweigen. "Gerade" soll in diesem Fall nicht heißen, dass sie geometrisch gerade ist, sondern dass sie dem Raum angepasst ist. Also sozusagen der kürzeste Weg, den man normalerweise gehen würde, wenn man eben einfach nur den Raum durchqueren will. Wenn man das nämlich jetzt versucht, würde die Figur ja unmotiviert zickzack laufen. Da wäre die Technik mit abzweigenden Sackgassen meines Erachtens "natürlicher". Wenn natürlich Kreise in Graphen möglich sind, kann man auch einfach eine Gerade vor der Tür hinzufügen und gut ist.

[hantu]

Man kann beliebige Kreise bauen Dass die Figur dann sinnvoll und realistisch durch den Raum läuft, liegt dann in der Hand desjenigen der die Bewegung baut, in dem Screenshot sind die Wege leider etwas unglücklich gewählt, da muss ich dir recht geben.

[hantu]

Hallo alle zusammen, ich war die letzten Wochen ganz fleißig und möchte hier mal wieder nen kleinen Zwischenstand präsentieren. Freue mich wie immer über Kritik, Kommentare und Vorschläge!

Ich würde auch gerne kleine Testversion ins Netz stellen, nur leider kommt mein Grafiker grade nicht aus dem Knick und so muss ich die DOTT Grafiken zum Testen verwenden, die ich ja leider aus rechtlichen Gründen eigentlich gar nicht benutzen darf...

Mal ne Übersicht über die Features, die ich jetzt schon einigermaßen fertig gebaut habe:

Die Oberfläche mit der man sein Spiel baut:

Auf dem Storyboard sieht man die einzelnen Szenen und wie sie geographisch zusammenhängen, außerdem werden mittlerweile kleine Vorschaubilder generiert:


Auf der Bearbeitungsseite einer Szene können Bilder, Gegenstände und Charaktere in der Szene per Drag and Drop platziert und verschoben werden:


Wie im vorherigen Post schon gezeigt kann man die Pfade angeben, auf denen sich der Held in der Szene bewegt, manche Punkte sind gesondert ausgezeichnet, weil sie die Stellen markieren wo der Held erscheint, wenn er diese Szene von einer anderen Szene aus betritt:


Dialoge:

Mittlerweile kann man im Spiel auch mit NPCs sprechen:


Hier die Übersicht der Bearbeitungsoberfläche für die Dialoge:


Skalierung:

Außerdem kann man den Protagonisten mittlerweile auch skalieren, um ihn "in den Hintergrund" laufen zu lassen:




Bitte schreien, falls euch etwas auffällt, das total unbedienbar, sinnlos oder unpassend erscheint, ich hoffe mein Grafiker fängt bald an unser kleines Testadventure zu bauen, dann werde ich sicher mal ne Betaversion ins Netz stellen.

Ach ja, weiss jemand ob man die Grafiken irgendeines (Fan)Adventures unter einer freien Lizenz (zb creative commons) verwenden darf? Das hält mich momentan am meisten auf, dass ich keine Hintergrundgrafiken und vollständig animierten Charaktere habe, mit denen ich etwas Kleines zum Testen bauen kann.

[Schabby]

Das ist ja mega geil! Super Idee, werde ich sofort ausprobieren! Respekt! Das könnte der Adventure-Szene einen Boost verleihen, weil man jetzt aus dem Büro zocken kann.

EDIT: Um eine Deiner Fragen zu beantworten: http://www.unet.univie.ac.at/~a0200586/ ... /steelsky/ (Beneath a Steel Sky) ist vielleicht so ein Adventure das Du portieren könntest.

[hantu]

Danke für die Blumen, aber das Lob wegen des JavaScripts gebürt wohl eher den Entwicklern von http://www.prototypejs.org/ und http://script.aculo.us/, da muss man selbst nicht mehr viel machen.

Beneath the Steel Sky scheint leider unter einer proprietären Lizenz zu stehen, da kann man wohl nichts verwenden....

[neon]

Beneath a Steel Sky ist Freeware. Wird auf der ScummVM-Seite zum Download angeboten. Ob Du die Grafiken verwenden darfst, steht natürlich auf einem anderen Blatt. Ich würde mal bei Revolution Software nachfragen. Die sind da in der Regel nicht so.
http://www.revolution.co.uk/

Was Dein Projekt angeht, Respekt. Das macht richtig gute Fortschritte. Lässt sich die Größe der Objekte verändern? Hoagie sieht neben Bernard so klein aus.

EDIT: Dumme Frage, steht ja unter 'Skalierung'...

[hantu]

Hallo an alle,

hatte leider noch keine Zeit wegen der Grafiken von Beneath a Steel Sky zu fragen, aber trotzdem danke für den Tipp! Ich hoffe immer noch, dass einer der Grafiker aus meinem Bekanntenkreis und meiner Verwandschaft mal die Zeit findet mir bei nem kurzen Testadventure zu helfen...

Ich habe weiter an meinem Projekt gearbeitet und möchte die neuen Features hier mal wieder zur Diskussion stellen:

Aktionen

Ich hoffe man kann auf dem Screenshot was erkennen Man kann jetzt Aktionen festlegen, die klassischen Adventure Events eben wie Öffne Tür, Nimm Buch usw. Das funktioniert bisher mit Gegenständen, Charakteren und Ausgängen. Auch das Verlassen und Betreten einer Szene kann als Aktion abgefragt werden.



Ergebnisse

Der eigentliche Sinn von Aktionen ist ja, dass etwas passiert im Spiel, die Ergebnisse einer Aktion können auch schon festgelegt werden, sowie eine Vorbedingung, wann diese ausgeführt werden sollen.



Momentan kann man folgende Sachen passieren lassen:

• Der Protagonist bewegt sich zum betroffenen Gegenstand/Charakter/Ausgang

• Der Protagonist sagt etwas

• Ein Charakter sagt etwas

• Ein Gegenstand kommt ins Inventar

• Der Spieler bekommt einen Token

• Der Spieler verliert einen Token

Token und Bedingungen

Über Token und Bedingungen kann man den Zustand und die Logik eines Spiels festlegen, das System war die Idee von nem Freund von mir und mich interessiert brennend, was ihr davon haltet, ob das verständlich und praktikabel ist.

Token kann man sich vorstellen wie Spielkarten, die dem Spieler als Ergebnis bestimmter Aktionen gegeben und weggenommen werden können (ohne dass er etwas davon mitbekommt natürlich).

Dadurch hat man einen bestimmten Zustand im Spiel und kann diesen abfragen, zB kann für alle möglichen Elemente eine Sichtbarkeitsbedingung festgelegt werden (als einfachen boolschen Ausdruck wie: Spieler muss Token A haben und darf nicht Token B haben), damit diese angezeigt werden. Diese Bedingungen werden nach jeder Aktion überprüft und die Szene, in der man sich gerade befindet, notfalls angepasst.

Ein Beispiel:

Man hat 2 Grafiken, eine offene und eine geschlossene Tür und möchte es ins Spiel einbauen, dass man die Tür öffnen und schließen kann. Dazu benutzt man den Token TÜR_OFFEN (wie der heißen soll kann man natürlich selbst bestimmen).

Für die geschlossene Tür legt man fest, dass sie nur sichtbar ist, wenn man den Token TÜR_OFFEN nicht besitzt, für die offene Tür legt man fest, dass sie nur sichtbar ist, wenn man den Token TÜR_OFFEN besitzt (sprich das genaue Gegenteil).

Anfangs würde also die geschlossene Tür angezeigt werden.

Dann legt man die Aktion Öffne Tür an, und gibt als Ergebnis an, dass der Spieler den Token TÜR_OFFEN bekommt. Führt der Spieler diese nun aus, wird die Website automatisch die geschlossene Tür ausblenden und die offene Tür einblenden.

Legt man nun die Aktion Schließe Tür mit der offenen Tür an und nimmt dem Spieler als Ergebnis den Token wieder weg, so wird wieder die geschlossene Tür eingeblendet.

Ich hoffe, dass war einigermaßen verständlich erklärt Bitte schreien falls nicht!

Hier ein Screenshot, wie man die Sichtbarkeit eines Elementes mit Tokens festlegen kann:


Außerdem lassen sich über Tokens auch Vorbedingungen für Aktionen festlegen (sowas wie der Spieler darf nur den Zauberstab nehmen, wenn er vorher mit dem Meister gesprochen hat, zB)

Das System ist sehr einfach und flexibel (und verständlich?), damit sollten sich ohne Programmierkenntnisse schon eine Menge Sachen abbilden lassen. In meinem Day of the Tentacle Testspiel beschwert sich Bernie beispielsweise wenn man den Eingangsraum verlassen will und die Haustüre aber noch nicht geschlossen hat.

Was haltet ihr von diesem System? Ist das verständlich und erscheint es praktikabel, um damit halbwegs komplexe Spiele zu bauen? Ich bin wie immer für jegliches Feedback, Kritik und Meinungen dankbar!

[neon]

Sieht sehr klasse aus, ich schreibe Dir zu dem Thema noch eine PN.

[perfektopheles]

Das mit dem Token und Bedingungen ist an sich ein Automat. Hattet ihr das im Sinn und der Schlichtheit wegen als Token implementiert?
Sollen alle Tokens im Spieler abgelegt werden? Das fände ich nicht so intuitiv.

PS: Zur GUI in Verbindung mit Flash/DHTML gibt es z.B. http://de.wikipedia.org/wiki/OpenLaszlo

[hantu]

Du hast recht, das müsste ein endlicher Automat sein, hatten wir eigentlich nicht explizit im Sinn, aber ich kann mich noch dunkel an meine Theoretische Informatik Vorlesung erinnern, da war das mal Thema

Die Tokens werden nicht im Spieler abgelegt, sondern es gibt eben pro Spiel eine Menge erlangbarer Tokens und in den jeweiligen Spielständen wird gespeichert welche Tokens man von denen bereits hat. So kann man über ein relativ simples System alle möglichen Zustände eines Spiels abspeichern.

Für die Bedinungen, die auf Tokens basieren kann man beliebig komplexe boolsche Ausdrücke festlegen, zb ( !TÜR_OFFEN && ( HAT_STOCK || HAT_HUT ) ). Sprich: der Spieler darf nicht den Token TÜR_OFFEN besitzen und muss entweder den Token HAT_STOCK oder den Token HAT_HUT haben.

Unser Ziel ist es ja, dass man keinerlei Programmierkenntnisse haben muss, um ein Spiel zu bauen, ich denke aber, das mit den Ausdrücken für Tokens lässt sich noch relativ leicht erklären und erlernen, was komplizierteres soll aber definitiv erstmal nicht eingebaut werden.

OpenLaszlo hab ich mir mal angesehen, das macht auf jeden Fall nen guten Eindruck, ich hatte erst auch überlegt ein anderes kompontentenorientiertes Framework wie wicket einzusetzen, aber mir war dann doch die Einarbeitungszeit zu hoch.

Momentan ist die Oberfläche in JavaScript mit Prototype und Scriptaculous geschrieben und ich bin eigentlich recht zufrieden damit, lässt sich v.a. sehr gut debuggen und es gibt viele Leute, die sich damit auskennen.

[perfektopheles]

Die Tokens werden nicht im Spieler abgelegt, sondern es gibt eben pro Spiel eine Menge erlangbarer Tokens und in den jeweiligen Spielständen wird gespeichert welche Tokens man von denen bereits hat. So kann man über ein relativ simples System alle möglichen Zustände eines Spiels abspeichern.

Alles klar, ich dachte nur wegen "Der Spieler bekommt einen Token, Der Spieler verliert einen Token" wird jedes Token im Spieler-(Objekt) abgelegt.

Für die Bedinungen, die auf Tokens basieren kann man beliebig komplexe boolsche Ausdrücke festlegen, zb ( !TÜR_OFFEN && ( HAT_STOCK || HAT_HUT ) ). Sprich: der Spieler darf nicht den Token TÜR_OFFEN besitzen und muss entweder den Token HAT_STOCK oder den Token HAT_HUT haben.

Unser Ziel ist es ja, dass man keinerlei Programmierkenntnisse haben muss, um ein Spiel zu bauen, ich denke aber, das mit den Ausdrücken für Tokens lässt sich noch relativ leicht erklären und erlernen, was komplizierteres soll aber definitiv erstmal nicht eingebaut werden.

Ich weiß nicht, ob der Zusammenbau von logischen Ausdrücken für jemanden ohne Programmierkenntnisse intuitiv ist, vllt. müssen größere Konstruktionen erstellt werden, so dass man den Überblick verlieren kann.
Ich finde die Zustände bei Automaten anschaulicher, denn da werden Bedingungen implizit durch mögliche Übergänge zw. den Zuständen ermöglicht. Aber, ich denke, die Zustände selbst mit allen möglichen Tokens drin zu erstellen und zu verknüpfen ist zu aufwändig und redundant.
Der zusammengebaute logische Ausdruck lässt sich als Baum darstellen, so wie hier z.B.: http://wiki.geneontology.org/images/1/1 ... editor.gif
Dadurch kannst du die (unübersichtliche) Klammerung vermeiden. Wenn du den Baum dann in bekannter Form darstellst und die Operatoren AND, OR etc. durch intuitive Namen ersetzt ("muss alles zutreffen", ...), dann wäre das viel intuitiver für den User Weitere Tokens kann er dann wie Untereinträge in den Baum einfügen.

[Einzelkämpfer]

Das sieht bislang alles sehr durchdacht aus. Wenn es tatsächlich so funktioniert, wie es die Screenshots vermuten lassen (bei JavaScript bin ich von Haus aus immer skeptisch ), dann könnte das eine interessante Plattform werden.

Was haltet ihr von diesem System? Ist das verständlich und erscheint es praktikabel, um damit halbwegs komplexe Spiele zu bauen?

Ein Adventure, das ohne Programmierkenntnisse über Aktionen und Bedingungen realisiert wird - das klingt nach dem Funktionsprinzip von Visionaire. Dass damit komplexe Spiele kein Problem sind, ist ja bekannt (ist natürlich nicht webbasiert).