Richtlinien und Tips zur Raetselprogrammierung:
1. Bevor man überhaupt anfängt mit Programmieren MUSS ein Konzept erstellt
werden. Ein Konzept sollte einen ungefähren Lageplan, mögliche Loesungs-
wege, Ideen, EP-Vorstellungen usw. enthalten. Das Konzept ist mit einem
der Raetselgoetter und einem passenden DL zu bereden. Konzepte zu Rätseln
sollten (aus gegebenen Anlass) unter /w/.../priv aufbewahrt werden, dort
darf nur der Besitzer lesen. (Da dort auch die Rätsel- und Domainlords
nicht lesen können, muss man ihnen das Konzept per Mail schicken.)
Erst, wenn das Konzept von Raetselgott und DL befürwortet wurde,
sollte man anfangen! Die Raetselgoetter sind übrigens in
/room/rathaus/filed (zgehzu gouv) mit 'liste auth' zu erfragen.
Eine Mail an die Raetselgoetter (inkl. die Admins) kann man mit
'schreibe raetsel' abschicken.
2. VOR dem Programmieren sollte man unbedingt den zu erwartenden Aufwand
abschätzen! Ist das Projekt in einer absehbaren Zeit zu bewältigen?
Für mehr als 500kB Code sollte man sich dringend einen Helfer suchen,
denn sonst kann aus der schönsten Idee schnell eine traurige Sammlung
trostloser Räume und Objekte werden.
3. Lest Euch in der Enzy unter 'Richtlinien/Konzepte' mal alles durch, was
beim Programmieren so zu beachten ist.
4. Ein modernes Rätsel DARF kein Lab der Form 'Du kennst Dich nicht mehr
aus.' haben! Nein, Nein, Nein. Jeder Raum muss detailliert beschrieben
sein und es darf keine unlogischen Raumausgaenge geben. (Wenn es gut be-
gründet wird, darf auch mal ein krumm verpointerter Ausgang dabei sein.)
5. Von Rätsel die zu einem Großteil aus Rennerei bestehen, sollte auch
abgesehen werden, d.h. wenn die Hauptzeit eines Rätsels dabei drauf
geht von Ort zu Ort zu rennen, ist es sicherlich nicht das schönste
Rätsel.
6. Ein Rätsel sollte mehrere Loesungswege besitzen. Für jeden Weg muss es
Hinweise in irgendeiner Form geben. 'Metzelloesungen' gehen auch ohne.
7. Rätsel müssen nicht gefährlich sein, aber sie sollten es sein.
Schließlich soll ein Spieler beim Lösen ja auch Herzklopfen bekommen,
oder?
8. Ein Rätsel muss nicht das schwierigste oder das gefährlichste sein. Das
ist gar nicht nötig:). Aber es darf gerne das schönste sein!
9. Rätsel, die zum Teil oder insgesamt nur in einer Gruppe gelöst werden
können, erhöhen das Spielvergnuegen ungemein - sie sind natürlich auch
schwieriger zu gestalten ;-) Lasst Euch mal was einfallen!
10. Es muss ein detailliertes Lösungsfile geben, mit allen Lösungen. Es ist
allerdings unter Verschluss zu halten (siehe 1).
11. Rechnet damit, dass die Spieler die verrücktesten Sachen machen. Sie
werden jeden Trick versuchen, z.B. wenn man einem NPC etwas geben soll,
muss man das unbedingt mit accept_object() abarbeiten. Ich-Befehle oder
Illusionen sind mittlerweile sehr beliebt.
12. Die Syntax von add_actions sollte flexibel sein und ggf. irgendwo angge-
deutet werden. Der Befehl 'parse_com' bietet dazu viele Möglichkeiten.
Auch von me() und here() sollte man des öfteren Gebrauch machen.
Bitte keine 'festen' Stringvergleiche einbauen, sondern mit strstr()
oder explode() nach einzelnen Kernwoertern suchen.
13. Viele V_Items machen zwar viel Arbeit, doch sie erzeugen erst die echte
Atmosphäre eines Raumes.
14. Viele gleiche Räume, die sich nur anhand der Ausgänge unterscheiden,
sollten nicht sein! Jeder Raum sollte seine eigene Beschreibung haben.
15. Verkaufbare Gegenstände dürfen nicht beliebig oft erzeugt werden,
nur einmal pro Reset.
16. Wenn möglich, sollte man oft inherit oder replace_programm benutzen,
um den Code effizienter zu machen. Man spart damit nicht nur Speicher,
sondern auch mögliche Veränderungen müssen nicht in jedem File einzeln
durchgeführt werden.
17. Dokumentiert auch mal zwischendurch den Code und versucht wenigstens,
einigermaßen übersichtlich zu programmieren - es wird die Zeit kommen,
wo ein anderer den Code bearbeiten muss und dann nur Chaos vorfindet.
18. Wenn man sein Quest schon in einem anderen deutschsprachigen MUD einge-
bunden hat, dann sollte man sich für UNItopia schon was eigenes und
neues ausdenken. Das Konzept kann ja ähnlich sein, doch der Feinschliff
sollte dann UNItopia-spezifisch sein.
19. Einige Gilden haben recht mächtige Eigenschaften, die man zwar nicht
alle in seiner Programmierung beachten kann, doch man sollte sich ab
und zu nach Gefahrenquellen umhören (z.B. die Illusion der Druiden,
das Heino- bwz. Liebeslied der Barden oder das Erschrecken der
Vampyre).
20. Rechnet damit, dass mehrere Spieler gleichzeitig auf Euer Rätsel los-
stürmen werden. Das kann oft zu Problemen führen: offene Türen,
entdeckte Geheimgänge, getötete Wächter-NPCs, nicht mehr vorhandene
Rätsel-Objekte, etc. Man sollte sich dringend Wege überlegen, wie
man so was regelt. Möglichkeiten sind z.B. ein NPC, der für einen
bestimmten Zeitraum den Spieler speichert, der ihm gerade hilft oder
ein Filter im Eingangsraum des Rätsels, der nur jemanden durchlässt,
wenn sich sonst niemand in den übrigen Questraeumen aufhält.
21. Überlegt gut, wie Ihr die Erneuerung der einzelnen Räume und Objekte
des Rätsels gestaltet. Oft ist es angebracht, mehrere Räume synchron
zu resetten. Das erreicht man z.B., wenn man von einem Raum-reset()
aus in den gewünschten anderen Räumen eine eigene _reset()-Funktion
aufruft (Tip: einen Raum, der noch nicht geladen ist, braucht man auch
nicht resetten, also erst mit find_object() prüfen!).
22. Wichtige Rätsel-Objekte sollten nicht ewig in einem Raum rumliegen, wo
sie nichts zu suchen haben, d.h. ihr reset() sollte das Objekt zerstören,
wenn es nicht in einem Spieler oder kein Spieler sich in seiner Umgebung
befindet. Ein später an diesen Ort kommender Spieler hat es sonst zu
leicht, wenn er solch ein Objekt einfach so findet.
23. Immer wieder helfen Engel und befreundete Spieler einem mutigen Aben-
teurer bei einem Rätsel. Wenn man das verhindern will, sollte man in
wichtige Objekte eine Owner-Variable einbauen, die mit dem Namen des
Spielers gesetzt wird, der das Objekt zuerst findet oder an sich nimmt.
Bei jeder Aktion mit diesem Objekt kann man dann this_player() mit
Owner vergleichen und ggf. eine Fehlermeldung ausgeben.
24. Man sollte dran denken, dass ein unsichtbarer Spieler von einem ag-
gressiven Monster nicht automatisch angegriffen wird. Auch beim Starten
einer Rolle etc. sollte der Aspekt der Unsichtbarkeit beachtet werden.
25. Ein Rätsel sollte gut in die darum bestehende Landschaft integriert
werden. Außer der Ankündigung am Newsbrett 'Spieler/Evolution' sollte
es auch unbedingt irgendwo einen Hinweis auf das Rätsel geben,
besonders wenn es etwas abseits der normalen Wege und Städte liegt.
Dabei muss es sich nicht unbedingt um ein langweiliges Flugblatt
handeln, dass am Stassenrand liegt ;-). Stimmt das einfach mit dem
zuständigen DL ab.
26. Ist ein Rätsel sehr lang, dann ist es angebracht, eine Unterteilung
in mehrere Abschnitte einzubauen. Für jeden Abschnitt bekommt man
dann einen Skill. Wenn der Spieler mittendrin einsteigen will, fragt
man einfach seinen erreichten Skill ab. Wichtig dabei ist, dass einem
solchem 'Spaeteinsteiger' ggf. wichtige Objekte fehlen, die er sonst
in den ersten Abschnitten ergattert hätte. Mit Hilfe des Raumtyps
'kein_startraum' oder 'startraum' kann man auch einen alternativen
Startraum definieren, von dem der Spieler nach dem nächsten Einloggen
das Rätsel erneut beginnen kann.
27. Genauso gilt das Problem bei Spielern, die sich mitten im Rätsel aus-
loggen. Zum einen warten nun vielleicht irgendwelche NPCs auf diesen
nicht mehr vorhandenen Spieler und sollten das irgendwann mal merken
und andere Spieler sollten baldmöglichst wieder ein voll funktions-
fähiges Rätsel vorfinden! Möglichkeiten gibt es hierzu z.B. mit
einem Masterobjekt, dass einen Spieler während des ganzen Rätsels
überwacht und/oder mit der Funktion notify_quit() oder notify_dead().
28. Es sollte für abbrechwillige Spieler möglichst einen Weg zurück in
die freie Welt geben, d.h. Einbahnstraßen sollten vermieden werden!
29. Rechnet nicht damit, dass Eure Arbeit beendet ist, sobald die Rätsel-
Admins das Rätsel eröffnet haben! Jetzt kommen die ganzen Fehler
und Ideen der Spieler - und das werden noch mal eine ganze Menge sein!
30. Viel Spaß!