Wie programmiere ich ein Spiel? ------------------------------- 1. Idee Man habe eine Idee. Klingt einfach, ist es aber nicht unbedingt. Nicht jede Idee ist gut umzusetzen in ein Spiel. Ausserdem ist es inzwischen sehr schwer geworden, etwas wirklich neues zu bringen. Man ueberlege sich, ob die Idee wirklich sinnvoll als Spiel innerhalb UNItopias zu realisieren ist. Z.B. ist ein Spiel wie Memory ziemlich witzlos, da jeder seinen Rechner einsetzen kann, um sein Gedaechtnis ein wenig zu unterstuetzen. Spiele, die schnelle Interaktionen verlangen, sind ebenfalls sehr problematisch. Desweiteren ist auch zu beachten, dass in UNItopia die Spieldauer im Vergleich zum RL-Spiel sich sehr leicht verdoppeln bis vervierfachen kann. 2. Vergleich mit vorhandenen Spielen Man versuche herauszufinden, ob die Idee in gleicher oder sehr aehnlicher Form nicht vielleicht schon einmal umgesetzt wurde. Auch dieser Schritt ist nicht ganz einfach, da es inzwischen eine Unmenge an Spielen gibt, und aus dem Namen nicht unbedingt hervorgeht, was sich dahinter verbirgt. Im Rathaus (/room/rathaus/raetsel bzw. zg raetsel) und im Spieleraum (/z/Spiele/Admin/spieleraum bzw. zg spiele) ist eine Liste aller installierten Spiele abrufbar. Detaillierteren Aufschluss gibt das Spielearchiv (/doc/spieleformulare), welches auch ueber den Spieleraum einzusehen ist. Auch die Newsbretter und die Spielelords geben Informationen darueber, welche Spiele bereits programmiert wurden bzw. in Planung sind. Optimalerweise findet sich in /z/Spiele/NEU/ZSF_SPIELE eine aktuelle Auflistung. Die Spielelords sind wohl die beste Anlaufstelle. Sollte jemand nicht wissen, wer das gerade ist, kann man das im Gouverneursbuero (zg go, list auth) nachlesen, oder einfach ans Brett schreiben, die Spielelords beissen nicht und werden sich melden ... Ein Brief an die Adresse 'spiele' hilft auch, da hier an alle Spielelords (und Admins) die Nachricht geschickt wird. 3. Reservierung der Spielidee Vor der Programmierung eines Spiels verstaendige man den Spielelord. Er/sie kann dann noch seinen Kommentar zur Realisierbarkeit der Idee abgeben, gegenfalls sogar ein zu diesem Zeitpunkt noch weniger schmerzliches Veto abgeben. Ausserdem wird er/sie in vielen Faellen insbesondere unerfahrerenen Goettern wertvolle Tips geben koennen. Eine Liste aller Spiele, die sich im Bau befinden, sollte im Idealfall in /z/Spiele/NEU/ZSF_SPIELE enthalten sein. Hat das Spiel seine Zustimmung gefunden und sind die groebsten konzeptuellen Fragen geklaert, dann wird von den Spielelords ein passendes Verzeichnis in /z/Spiele/ und ein vorlaeufiges Gameobjekt angelegt und die Spieleentwicklung kann beginnen. 4. Umgebung fuer das Spiel Es ist sinnvoll, sich jetzt schon Gedanken darueber zu machen, in was fuer eine Umgebung das Spiel gut passen koennte. Wenn darueber von vorne herein Klarheit besteht, kann man dem Spiel schon die geeignete Atmosphaere mit auf den Weg geben. Dies gilt besonders, wenn NSCs (Nicht-Spieler-Charaktere) Bestandteil des Spiels sind. Hat man eine Wahl getroffen, sollte man diese auch mit der Domainleitung abstimmen, was selten problematisch sein duerfte, da ein gutes Spiel sicher gerne aufgenommen wird. 5. Realisierung Wenn man sich nicht von vorne herein im klaren darueber ist, wie man das Spiel in LPC realisieren koennte, ist es sinnvoll, sich von der Machart her aehnliche Spiele anzuschauen (die Spieleformulare helfen bei der Suche nach solchen Spielen). Die Spiele koennen in vier Gruppen eingeteilt werden, die Programmierkonzepte direkt beeinflussen: - Spiele fuer einen Spieler ohne NSC (transportabel / nicht transp.) - Spiele fuer einen Spieler gegen NSC - Spiele fuer mehrere (meist 2) Spieler ohne NSC (transp. o. nicht) - Spiele fuer mehrere Spieler mit NSC(s) Es ist darauf zu achten, dass man an kein allzu altes Spiel geraet, da diese oft nicht mehr den heutigen Anforderungen genuegen. Wer mehr als nur ein paar Fragmente aus existierenden Spielen uebernehmen will, sollte sich mit dem Programmierer der Vorlage abstimmen, der in der Regel nichts dagegen haben wird. 6. Typische Probleme Folgendes ist bei der eigentlichen Programmierung zu beachten: - Das Spiel muss sinnvoll darauf reagieren, wenn ein Spieler den Raum verlaesst. Ausgaben sollten an den Spieler nur gemacht werden, wenn er auch im Raum ist. - Wie reagiert das Spiel, wenn sich ein Spieler ausloggt? Dadurch wird der Objektpointer 0 und es kann recht leicht zu Fehlern kommen. Fuer solche Faelle empfiehlt es sich den Realname zu merken. - Wie reagiert das Spiel, wenn ein Spieler zur Statue wird? - Es muss damit gerechnet werden, dass ein beteiligter NPC oder Spieler waehrend des Spiels sterben kann. - Falls der NPC Aktionen macht die ZPs verbrauchen (reden, bruellen usw.) sollte man drauf achten, das er immer genuegend dafuer zur Verfuegung hat. - Kann man das Spiel waehrend einer Partie nehmen? Ist wohl weniger sinnvoll. - Falls das Spiel mitten in einer Partie verlassen wird, koennen andere Spieler das Spiel benutzen? - Es sollte ein Logfile (mit log_file(), nicht mit write_file()) vom Spiel gefuehrt werden, aus dem der Zeitpunkt des Spielstarts, des Spielendes und das Ergebnis eines Spieles hervorgehen. Dies ist wichtig, da es Anhaltspunkte fuer eine sinnvolle Vergabe von Erfahrungspunkten liefert. Ausserdem koennen Betrugsversuche damit aufdecken werden. - Alle zum Spiel gehoerigen Dateien sollten sinnvoll in der Verzeichnisstruktur untergebracht sein. Ein spaeterer Debugger wird es euch danken, dass er nicht erst sich alles zusammen suchen muss. Und wer lebt schon ewig? - Eine Hilfe muss verfuegbar sein. Wie, haengt natuerlich auch ein wenig vom Spiel ab. Bei einem Brettspiel koennte es auf der Rueckseite stehen, oder einen Beipackzettel haben. Uebliche Kommandos fuer die Hilfe waeren z.B. 'hilfe ' oder 'lies regeln', wobei mir das Lesen der Regeln wesentlich besser gefaellt. Gibt es bei einem Spiel viele Kommandos, ist auch eine Kurzzusammenfassung der Kommandos sinnvoll. Vgl. auch /z/Spiele/TEXT/REGELN.HLP - Die Handhabung sollte so intuitiv wie moeglich sein. Deswegen auch lieber ein paar mehr add_actions und v_items spendieren. Ueber das Betrachten der Vitems sollte man zu denselben Informationen kommen (z.b. add_action liste und betrachte v_item liste). Die Add_actions sollten sehr flexibel gehalten werden. An einigen Stellen empfiehlt sich der Gebrauch von parse_com. Manche Befehle (z.b. legen, ziehen und setzen) kollidieren auch leicht mit anderen Add_actions. Hier sollte auch auf die Vertraeglichkeit geachtet werden. Am besten hier Alternativen anbieten. - Bei den meisten Befehlen, die zur Verfuegung gestellt werden, muss abgeprueft werden, ob der Spieler, der es ausfuehren will, wirklich das Recht hat, sie auszufuehren. Z.B. ist es oft interessant, ob er ueberhaupt mitspielt und ob er an der Reihe ist, und ein Aussenstehender sollte ein Spiel zwischen 2 Spielern nicht abbrechen koennen, indem er es einfach neu startet. - Gibt es etwas zu sortieren, unbedingt sort_array verwenden. Wer sich nicht dran haelt, wird mit einer Programmier-Belehrung nicht unter 5 Minuten bestraft. Alles andere ist einfach zu langsam, wenn erstmal die ersten paar Dutzend Spieler sich vor das Spiel gesetzt haben. - Falls eine Highscore gebraucht wird, am Besten /p/Misc/i/high_score.c als Grundlage verwenden. Damit muss man das Rad nicht neu erfinden und sich auch weniger um die Effizienz kuemmern. 7. Testphase Man teste das Spiel, bis man der Meinung ist, dass es so eingebunden werden koennte. Spieler sollten zum Testen nicht herangezogen werden, andere Goetter nach ihrer Meinung zum Spiel zu fragen, ist dagegen ratsam, solange man sie nicht allzu sehr damit nervt... Der Spielelord hat hier eigentlich noch nicht seinen Wirkungsbereich. Keine Angst, er findet auch danach noch Bugs und andere Dinge, die ihm nicht passen. Und falls nicht - um so besser! 8. Spieleformular Man fuelle ein Spieleformular aus. Ueber die EP-Vergabe braucht man sich hierbei noch keine allzu grossen Gedanken machen. Ein leeres Formular findet sich in /z/Spiele/INFO/FORMULAR.TXT. In FORMULAR.HLP wird ausfuehrlich erklaert, wie im einzelnen auszufuellen ist. 9. Game-Objekt Wer will, kann die Funktionen zur EP-Vergabe schon in sein Spiel einbauen und ein Game-Objekt schreiben, diese Aufgabe kann aber unter Umstaenden auch auf einen Spielelord abgewaelzt werden. Das Gameobjekt liegt dann unter /z/Spiele//apps/spiele_ob.c. Beim Eintragen des Spieles in die Testphase wird schon ein Dummyobjekt angelegt, das noch entsprechend modifiziert werden muss. Siehe hierzu folgendes Beispiel, sowie Schritt 6 beim Raetselprogrammieren. Die Funktionen beim game_object heissen etwas anderes, hier ein vollstaendiges Beispiel als Erklaerung: --- snip --- snap --- knabber --- inherit "/i/object/game_obj"; void create() { replace_program("/i/object/game_obj"); ::create(); set_name("Lancelot"); set_hint("Grabsch dir ein paar Mitspieler und spiel Lancelot!\n"+ "Meister Erad-Nair hatte angeblich solch ein Spiel...\n"); set_skill(500); set_skill_msgs( ({ "Du hast gerade mal so die Regeln von Lancelot durchschaut.", "Du entwickelst neue Tricks im Lancelotspiel.", "Mit fiesen Zuegen aergerst du deine Mitspieler beim Lancelot.", "Du bist ein gefuerchteter Gegner fuer alle Lancelotspieler.", ({ "Du bist ein wahres Meisterlein des Lancelotspiels.", "Du bist ein wahrer Meister des Lancelotspiels.", "Du bist eine wahre Meisterin des Lancelotspiels." }) }) ); set_solved_msg("$Der('ob) ist Meister im Lancelot geworden!"); } --- snip --- snap --- knabber --- Falls die solved_msg geschlechtsabhaengig sein soll: set_solved_msg(lambda(({ 'ob }), ({ #'sprintf, "%s ist %s im Lancelot geworden!", ({ #'Der, 'ob }), ({ #'switch, ({ #'call_other, 'ob,"query_gender" }), "saechlich", "Meisterliches", #'break, "weiblich", "Meisterin", #'break, "maennlich", "Meister", #'break, }) }))); Der Aufruf zum Setzen der Punkte heisst entsprechend: --- snip --- snap --- knabber --- #include ... GAME_ROOM->set_game("game_name", , this_player()); --- snip --- snap --- knabber --- Wichtiger Hinweis: set_game setzt nicht die EPs, sondern wirkt additiv. D.h. zweimal set_game(..., 10, ...) erhoeht um insgesamt 20 und setzt nicht auf 10. Alles weitere ist bei den Raetseln nachzulesen... Kommentar: Es mag sinnvoll erscheinen, das Spiel-Objekt von Programmierer entwerfen zu lassen, besonders wenn man nicht die autoskalierten Skill-Messages aus dem Beispiel oben verwendet. Wer sich aber dabei nicht sicher ist, kann natuerlich auch einen Spielelord damit beauftragen, sollte ihm aber sagen, bei welchen Ep-zahlen welche Skill-Message erscheinen soll. Neugierige koennen natuerlich auch bei schon bestehenden Spielen spicken. 10. Brief an die Spielelords Jetzt kann man den Spielelords einen stolzen Brief schreiben, in dem man erwaehnen sollte, wo das Spiel mitsamt Formular zu finden ist. 11. Endphase Die Spielelords werden versuchen, das Spiel zum Abstuerzen zu bringen. Wenn sie das nicht schaffen, werden sie nach Bedienungsschwaechen suchen. Wenn sie sich auch in diesem Bereich ausgetobt haben, werden sie ueberpruefen, ob sich das Spiel gut in seine Umgebung eingliedert. Wenn dann auch noch eine Einigung ueber die EP-Vergabe erzielt wurde, koennen die Funktionen zur Vergabe falls noch nicht vorhanden vom Programmierer oder Spielelord eingebaut. Klappt alles, kann das Spiel offiziell eingebunden werden. Bei Fragen wendet man sich vertrauensvoll an die Spielelords. Wer das ist, kann man mit zg gouv list auth herausbekommen. Mit Post an die Spielelords richte man sich am besten an 'spiele'. Hier nocheinmal eine Kurzfassung des Spieleschreibens: 1. Idee hab'. 2. Idee an Spielelord melden (Konzept erarbeiten und an Spielelords schicken) 3. nach Kampf mit Spielelord, Beginn der Programmierung (nicht vorher) 4. Game-Objekt und Spiel in /z/Spiele proggen, dabei gleich: 5. Formular erstellen 6. Spiel testen (1. Phase) 7. EP-Vergabe einbauen (in Testphase bekommen nur Goetter und Testies EP) 8. andere Goetter nerven 9. Spiel verbessern 10. Spiel testen 11. Spielelords verstaendigen, damit Spiel von ihnen getestet wird 12. Spiel verbessern 13. Spiel testen (2. Phase) 14. Spielelords nerven, dass sie weitertesten 15. Spiel verbessern 16. Spiel testen 17. Spielelords nerven, dass sie weitertesten 18. Spiel testen lassen (jetzt evtl. auch von Engeln oder Spielern (Nein, keine Spieler teleportieren. Portable Spiele zu den Spielern bringen, bzw. die entsprechenden Raeume anschliessen (vorausgesetzt die Raeume sind von den DL's abgenommen ;-))) 19. Spiel verbessern 20. Spielelords nerven, dass sie das Spiel freigegeben 21. freuen 22. Spiel fuer Spieler oeffnen 23. Spiel warten und verbessern!!!