Der lange Arm
20. August 2013 von Yhoko
Ich gebe zu, ich mag es kompliziert. Das heisst, ich mag es nicht an sich, weil es kompliziert ist, sondern weil es nach einem gewissen Aufwand die Dinge einfacher macht. Ihr habt keine Ahnung, worauf ich hinaus will...
Ich rede von Interaktionen. Hier zeig sich einmal mehr, wie sich Erfahrung in der Programmierung auswirkt. Als Neuling tendiert man zu einfachen Systemen, die schnell umgesetzt sind und wenig Planung erfordern. Nehmen wir das konkrete Beispiel "Rollenspiel", ein Genre, welches von Interaktionen nur so sprüht. Unser Neuling fängt mit einer Grafik-Engine an und kommt irgendwann an den grossen Punkt namens "Inventar", was vornehmlich aus Gegenständen besteht. Waffen, Rüstungen, aber auch Werkzeuge wie Hämmer, Meissel, Schaufeln und Zangen. Schnell kommt einem der Gedanke, diese Werkzeuge einzusetzen, etwa um einem toten Bären das Fell abzuziehen oder seine Zähne rauszureissen. Dies ist die heutige Ausgangssituation.
Unser Anfänger macht das kurz und schmerzlos, indem er für jeden Gegenstand ein passendes Werkzeug erstellt und jedem Werkzeug eine Aktion zuweist. Für die Zähne gibts also eine Zange und für das Fell ein Häutungsmesser (bei einer Kuh kann stattdessen auch gut Leder herauskommen), wobei diese Werkzeuge sonst im ganzen Spiel keine Verwendung finden. Und wenn doch, kann man genau dort eine Ausnahme skripten, à la "Du benötigst hier eine Zange, um das rauszuziehen", welche einfach nur abfragt, ob der Spieler eine Zange dabei hat. Vielleicht kommt er irgendwann auch noch auf die Idee, man könnte ja die Augen und das Herz auch noch sammeln - statt neuer Werkzeuge gibt es dafür dann Lehrmeister, welche einem die entsprechende Fähigkeit geben - per Klick auf den toten Bären werden diese Sachen dann einfach offengelegt (vielleicht sogar mit einer kleinen Skriptzeile dazwischen, die abfragt, ob man ein Messer dabei hat).
Dieses kleine Beispiel funktioniert wunderbar, solange es klein bleibt. Jedes Werkzeug ist massgeschneidert für seine Aufgabe und alles weitere löst man eben anders. Programmieren kann so einfach sein :-)
Der Haken der Sache liegt im Verständnis des Spielers. Geht es beispielsweise darum, toten Insekten die Flügel abzutrennen, zweifle ich bereits an der Notwendigkeit einer speziellen Flügelschere. Vor allem, wenn es zusätzlich eine Stoffschere, Lederschere, Fellschere und den allseits beliebten Dolch gibt. Oder wozu braucht man eine spezielle Zange, wenn man die Zähne auch einfach rausschlagen oder -brechen kann? Diese Gedankengänge münden in einem System, bei dem ein Werkzeug mehrere Anwendungen findet. Man muss dabei nur berücksichtigen, dass mit einer speziellen Flügelschere die Chance höher ist, die Dinger sauber abzutrennen.
Auch hier gibt es wieder mehrere Wege, das umzusetzen. Eine einfache "Gewaltlösung" besteht darin, jede mögliche Aktion aufzulisten, also sowas wie Dolch->Flügel abschneiden, Dolch->Krallen rauspulen, Dolch->Haut abtrennen, usw. und dann dasselbe für Zange->Zähne rausziehen, Zange->Krallen abklemmen, usw. Mit einer derartigen Liste kann man genau steuern, welche Aktionen welches Werkzeug ausführen kann. Der Krux dabei ist: Man muss das auch vollständig tun, denn sonst wundern sich die Spieler, warum man mit einem Werkzeug etwas bestimmtes nicht tun kann (z.B. mit dem Götterhammer keine Nägel einschlagen, wo es doch eigentlich auch ein Hammer wäre).
Um diesem Aufwand zu entgehen habe ich mich bei Endyr für eine kompliziertere Lösung entschieden. Bisher gab es immer eine direkte Verknüpfung von Werkzeug zu Beute, nun wird aber eine dritte Ebene dazwischengeschaltet: Die Aktion.
In meinem System hat ein Messer z.B. die Aktionen "schneiden", "abziehen", "stechen" und "herauspulen" und die Spielobjekte eine Liste von Aktionen, die man auf sie anwenden kann. Ein toter Bär kennt also mindestens "abziehen" (für das Fell), "herauspulen" (Zähne, Krallen, Augen) und "schneiden" (Zunge, Herz). Wie im letzten Screenshot gezeigt wird der Bär nur dann blau umrahmt, wenn mindestens eine dieser Aktionen mit dem Werkzeug übereinstimmt. Sind es mehrere, erhält der Spieler ein Auswahlmenü, was er z.B. mit der Zange nun machen möchte (Zähne oder Krallen rausziehen?).
Klingt mein System nun intuitiver als das des Anfängers weiter oben? Für mich schon, vor allem aber nimmt es mir die meiste Arbeit ab. Ich muss mir die Gegenstände nur ansehen und überlegen, was man damit tun kann - und wenn ich einem Säbel die Aktion "schneiden" zuweise, kann er ganz automatisch auch ein Messer ersetzen. Einen kleinen Haken hat das Ganze aber natürlich: Man muss sich viel mehr Gedanken darüber machen, welche Aktionen man denn nun definiert. Gerade schneiden ist nicht gleich schneiden - auch eine Papierkante kann schneiden, aber davon kann man sich keine Brotscheibe abschneiden. Statt ein generelles "Schneiden" verwende ich daher genauer definierte Begriffe.
Fazit: mit einem einfachen System kommt man recht weit, aber irgendwann ist der Punkt der Überforderung erreicht, und spätestens dann wünscht man sich einen komplexeren Unterbau. So spät lässt sich das aber nicht mehr ohne Weiteres auswechseln, darum implementiere ich von Anfang an das beschriebene System. Wie so vieles wird sich das (hoffentlich) langfristig lohnen.
Ich rede von Interaktionen. Hier zeig sich einmal mehr, wie sich Erfahrung in der Programmierung auswirkt. Als Neuling tendiert man zu einfachen Systemen, die schnell umgesetzt sind und wenig Planung erfordern. Nehmen wir das konkrete Beispiel "Rollenspiel", ein Genre, welches von Interaktionen nur so sprüht. Unser Neuling fängt mit einer Grafik-Engine an und kommt irgendwann an den grossen Punkt namens "Inventar", was vornehmlich aus Gegenständen besteht. Waffen, Rüstungen, aber auch Werkzeuge wie Hämmer, Meissel, Schaufeln und Zangen. Schnell kommt einem der Gedanke, diese Werkzeuge einzusetzen, etwa um einem toten Bären das Fell abzuziehen oder seine Zähne rauszureissen. Dies ist die heutige Ausgangssituation.
Unser Anfänger macht das kurz und schmerzlos, indem er für jeden Gegenstand ein passendes Werkzeug erstellt und jedem Werkzeug eine Aktion zuweist. Für die Zähne gibts also eine Zange und für das Fell ein Häutungsmesser (bei einer Kuh kann stattdessen auch gut Leder herauskommen), wobei diese Werkzeuge sonst im ganzen Spiel keine Verwendung finden. Und wenn doch, kann man genau dort eine Ausnahme skripten, à la "Du benötigst hier eine Zange, um das rauszuziehen", welche einfach nur abfragt, ob der Spieler eine Zange dabei hat. Vielleicht kommt er irgendwann auch noch auf die Idee, man könnte ja die Augen und das Herz auch noch sammeln - statt neuer Werkzeuge gibt es dafür dann Lehrmeister, welche einem die entsprechende Fähigkeit geben - per Klick auf den toten Bären werden diese Sachen dann einfach offengelegt (vielleicht sogar mit einer kleinen Skriptzeile dazwischen, die abfragt, ob man ein Messer dabei hat).
Dieses kleine Beispiel funktioniert wunderbar, solange es klein bleibt. Jedes Werkzeug ist massgeschneidert für seine Aufgabe und alles weitere löst man eben anders. Programmieren kann so einfach sein :-)
Der Haken der Sache liegt im Verständnis des Spielers. Geht es beispielsweise darum, toten Insekten die Flügel abzutrennen, zweifle ich bereits an der Notwendigkeit einer speziellen Flügelschere. Vor allem, wenn es zusätzlich eine Stoffschere, Lederschere, Fellschere und den allseits beliebten Dolch gibt. Oder wozu braucht man eine spezielle Zange, wenn man die Zähne auch einfach rausschlagen oder -brechen kann? Diese Gedankengänge münden in einem System, bei dem ein Werkzeug mehrere Anwendungen findet. Man muss dabei nur berücksichtigen, dass mit einer speziellen Flügelschere die Chance höher ist, die Dinger sauber abzutrennen.
Auch hier gibt es wieder mehrere Wege, das umzusetzen. Eine einfache "Gewaltlösung" besteht darin, jede mögliche Aktion aufzulisten, also sowas wie Dolch->Flügel abschneiden, Dolch->Krallen rauspulen, Dolch->Haut abtrennen, usw. und dann dasselbe für Zange->Zähne rausziehen, Zange->Krallen abklemmen, usw. Mit einer derartigen Liste kann man genau steuern, welche Aktionen welches Werkzeug ausführen kann. Der Krux dabei ist: Man muss das auch vollständig tun, denn sonst wundern sich die Spieler, warum man mit einem Werkzeug etwas bestimmtes nicht tun kann (z.B. mit dem Götterhammer keine Nägel einschlagen, wo es doch eigentlich auch ein Hammer wäre).
Um diesem Aufwand zu entgehen habe ich mich bei Endyr für eine kompliziertere Lösung entschieden. Bisher gab es immer eine direkte Verknüpfung von Werkzeug zu Beute, nun wird aber eine dritte Ebene dazwischengeschaltet: Die Aktion.
In meinem System hat ein Messer z.B. die Aktionen "schneiden", "abziehen", "stechen" und "herauspulen" und die Spielobjekte eine Liste von Aktionen, die man auf sie anwenden kann. Ein toter Bär kennt also mindestens "abziehen" (für das Fell), "herauspulen" (Zähne, Krallen, Augen) und "schneiden" (Zunge, Herz). Wie im letzten Screenshot gezeigt wird der Bär nur dann blau umrahmt, wenn mindestens eine dieser Aktionen mit dem Werkzeug übereinstimmt. Sind es mehrere, erhält der Spieler ein Auswahlmenü, was er z.B. mit der Zange nun machen möchte (Zähne oder Krallen rausziehen?).
Klingt mein System nun intuitiver als das des Anfängers weiter oben? Für mich schon, vor allem aber nimmt es mir die meiste Arbeit ab. Ich muss mir die Gegenstände nur ansehen und überlegen, was man damit tun kann - und wenn ich einem Säbel die Aktion "schneiden" zuweise, kann er ganz automatisch auch ein Messer ersetzen. Einen kleinen Haken hat das Ganze aber natürlich: Man muss sich viel mehr Gedanken darüber machen, welche Aktionen man denn nun definiert. Gerade schneiden ist nicht gleich schneiden - auch eine Papierkante kann schneiden, aber davon kann man sich keine Brotscheibe abschneiden. Statt ein generelles "Schneiden" verwende ich daher genauer definierte Begriffe.
Fazit: mit einem einfachen System kommt man recht weit, aber irgendwann ist der Punkt der Überforderung erreicht, und spätestens dann wünscht man sich einen komplexeren Unterbau. So spät lässt sich das aber nicht mehr ohne Weiteres auswechseln, darum implementiere ich von Anfang an das beschriebene System. Wie so vieles wird sich das (hoffentlich) langfristig lohnen.
Kommentar schreiben