That's a really big one... Garthan 16.05.94 K O N Z E P T E --------------- Hier steht alles drin, von dem man als ausgewachsener Gott ausgeht, dass es alle anderen Götter auch wissen, was aber, wie sich allzuoft zeigt, nicht der Fall ist. 0. Inhalt ========= Konzepte 0. Inhalt I. Allgemeine Konzepte 1. Räume 2. Lebewesen 3. Gegenstände II. Grossprojekte III. Sourcen I. Allgemeine Konzepte ====================== 1. Räume ======== Ein Raum ist im allgemeinen ein Ort, an dem sich ein oder mehrere Spieler aufhalten können. a) Beschreibung --------------- Der Raum liefert den Spielern eine Beschreibung seines Aussehens. Diese besteht aus einem Text, der den Raum im allgemeinen beschreibt, der dessen Inhalt kurz wiedergibt, und der einen Hinweis auf Ausgänge gibt und wohin diese führen. Ein Raum sollte unbedingt in das Gefüge der umliegenden Räume passen. Beschreibt ein Raum eine Stadtmauer im Osten, so sollte der Raum im Osten tatsächlich auch zu einer Stadtmauer gehören. Ein schönes Raumgefuege erhält man, wenn man von einem Raum schon die wesentlichen Eigenschaften eines anderen sehen kann. Also beispielsweise von einem Zimmer in einem Haus durch ein Fenster hinaus auf die Straße sehen zu können, und auch *umgekehrt* von der Straße aus das Haus mit Fenstern sehen zu können. Man sollte achtgeben die Beschreibung des Raums nicht zu sehr zu überladen, so dass der Spieler beim Betreten nicht gleich mit Details überschüttet wird, die ihn im ersten Augenblick des Betretens ja gar nicht interessieren, oder die er eh übersehen würde bei ersten Betrachten. Man macht also nur eine grobe, aber schön formulierte Beschreibung des Raums und seine Details, und ergänzt dann die Details. Der Spieler kann dann, nur wenn er Lust hat, diese Details mit seinen Sinnen untersuchen. b) Details ---------- Details sind wichtig, sie ermöglichen genauere Beschreibung auf Wunsch des Spielers. Nahezu jedes Substantiv in der Beschreibung des Raums sollte eine Detailbeschreibung erhalten. Diese Details sollten mit möglichst vielen Sinnen erfasst werden können, soweit dies sinnvoll erscheint. Man sollte es also auf jeden Fall anschauen können. Schriftstücke sollte man lesen können. An jedem Detail sollte man riechen oder hören können. In diese Details kann man auch schön Informationen verstecken, die der Spieler nicht sofort erkennen soll, sondern erst bei genauerer Untersuchnung. Auch Details von Details sollten beschrieben werden. Wie man sieht kann dadurch ein *einzelner* Raum schon *sehr* viel Zeit in Anspruch nehmen. Statt viele leere Räume in kurzer Zeit aus dem Boden zu stampfen, sollte man sich überlegen, ob der gewünschte Effekt nicht auch mit weniger Räumen, die dafür sorgfältig beschrieben sind, erreichbar ist. Diesen wenigen Räumen kann man dann seine gesamte Kreativität widmen, und steht nicht plötzlich vor dem Problem hunderten von Räumen ein individuelles Outfit verpassen zu müssen. In Räumen sollte man auch Details finden, die man mitnehmen kann, die aber auf den ersten Blick nicht zu erkennen sind. ->Gegenstaende c) Ausgänge ----------- Die Ausgänge eines Raumes sollte man im Text kurz ausführen. Man sollte beschreiben ob es sich um eine Tür, eine Tor, ein Loch, ein Durchgang, eine Steige, eine Treppe, eine Leiter handelt, oder ob hier nur einfach eine Straße weiterführt. Diese Beschreibungen fördern das 'Aneinanderhaengen' der Räume, schwächt beispielsweise die Effekte der Segmentierung einer Straße, die in real life ja *nicht* aus einzelnen Räumen besteht. Bei besonderen Ausgängen sollte man eine spezielle Bewegungsmeldung setzen. Man entfernt sich nicht einfach nach oben, sondern man steigt eine Leiter hoch, klettert an einem Seil empor, und so fort. Ausgänge sollten logisch verbunden sein! Undurchschaubare Labyrinthe sind zwar einfach zu programmieren, für den Spieler jedoch absolut nervtötend und langweilig. d) Größe -------- Die natürliche Größe eines Raums hängt im Prinzip nur von seiner Umgebung ab. Ein Raum in einer öden Landschaft kann schon mal mehrere hundert Meter im Quadrat umfassen, während ein Raum als Zimmer in einem Haus nur wenige Quadrameter umfasst. Größere Raumgefuege sollten auch eine makroskopische Struktur haben, so dass es dem Spieler nicht so schwer fällt sich zu orientieren. Nicht nur Kartographen sollten eine Chance haben. e) Konsistenz ------------- Räume sollten sich nahtlos in ihre Umgebung einfügen. Bevor man also einen neuen Raum in ein bestehendes Gefüge einbaut, sollte man die alten Räume samt ihrer Details anschauen, sich überlegen, wie der neue Raum von Stil und Funktionalität aussehen muss, um gut in das alte Gefüge zu passen. Durch das alleinige Anpassen von Ausgängen ist es nicht getan!!! Die alten Räume müssen erweitert werden um Details, die sich auf den neuen Raum beziehen. Soll beispielsweise eine Bäckerei eingebaut werden, sollte man die Straße vor der Bäckerei um eine Hausbeschreibung und um eine Geruch nach frischen Brötchen ergänzen. Auch für diese Aktion sollte man sich genügend Zeit nehmen, genauso wie für das vorherige Beschreiben des neuen Raums selbst. f) Handlungsmöglichkeiten ------------------------- Jeder Raum sollte für den Spieler nicht nur eine Art Behältnis oder Container sein, in die man den Spieler hineinstellt. Er sollte eine Art Spielwiese für den Spieler bieten. Man sollte sich genug Zeit nehmen, anfassbare Eintrichtung zu programmieren, Gegenstände zu erschaffen, die der Spieler beispielsweise benutzen, oder gar stehlen kann. Das sollte man auch tun, wenn diese Kleinigkeiten gar nicht wichtig erscheinen für den eigentlichen Zweck des Raums. Der Spieler sollte auch Aktionen durchführen können, die keinen direkten Sinn machen, sondern nur seine Neugier befriedigen. Ein Bett sollte man machen können, ein Schrank oeffen können. In einen Schank sollte man Gegenstände legen können. Aus einem Wasserhahn sollte man trinken können, und Wasser entnehmen können. Eine Vase sollte man mit Blumen füllen könne, oder Blumen sollte man aus einer Vase nehmen können. All diese beweglichen Details, machen tote Räume lebendig. g) Inventar ----------- Wichtiges Inventar klont man als Objekte in den Raum. Ebenso Menschen und Tiere. Kleine Details sollten 'mitnehmbar' sein. Die Raumbeschreibung sollte sich ändern, wenn so ein bewegliches Detail mitgenommen wurde! Häuser sollten bewohnt aussehen! Die Einwohner sollten nicht fehlen! Die Einwohner sollten gegenseitig von sich wissen! Viele Querverweise machen das Spiel interessanter. (siehe Lebewesen) 2. Lebewesen ============ a) Allgemeines -------------- Wichtige Persönlichkeiten sollten Namen und Titel haben. Sie sollten ansprechbar sein, zumindest auf Grüße reagieren. Sie sollten auch von sich aus interessante Dinge erzählen, jedoch den Raum, in dem sie sich aufhalten nicht mit Text zuschütten. Lebewesen sollten leben! Sie sollten schlafen, essen, trinken, reden und sich unter Umständen auch in ihrem Territorum bewegen. (Bsp: Bewohner eines Hauses) Sie sind keine Möbelstücke, sondern LEBEWESEN! Vögel sollten zwitschern, Katzen miauen können, Menschen sollten reden können. Stumme Monster, die auf nichts reagieren und nur geplättet werden wollen sind langweilig. Nicht die Zahlenwerte sind entscheidend, sondern die Beschreibung, die Athmosphaere. b) Beschreibung --------------- Lebewesen sollten eine Beschreibung haben. Wie bei Räumen kann und sollte sie wieder aufsplitten in allgemeine Beschreibung und Details. Die allgemeine Beschreibung sollte keine Lebensgeschichte des Wesen beinhalten, sondern hauptsächlich sein Auesseres beschreiben. Alles andere kann man das Wesen selbst erzählen lassen! Auch Geruch und Geräusch sollte man setzen, falls sinnvoll. c) Umgebung ----------- Jedes Lebewesen sollte in seine Umgebung passen. Polarbaeren gehoren in die Arktis und Wuestenfuechse nach Dörrland. [ Motorräder gehören auf den Mond geschossen ;-) ] Wenn das gewünschte Lebewesen nicht passt, dann muss man halt ein Zuhause programmieren. Ein Bäcker braucht eine Bäckerei, ein Bauer einen Bauernhof, und so fort. 3. Gegenstände =============== a) Allgemeines -------------- Gegenstände sind im Vergleich zu Lebewesen zwar einfacher zuhandhaben, aber auch hier gelten ähnliche Regeln. b) Beschreibung --------------- Gegenstände sollten *nicht nur* eine Funktion sondern auch eine Form haben. Spieler sollten keine 'formlosen Tools' bekommen. Gegenstände benötigen eine ausführliche Beschreibung, die durch Details ergänzt sein sollte. Ein 'wtool' (Huezeldues Windmachtool) sollte also besser 'Ein verzierter Faecher' heißen... Gegenstände sollten Aussehen, Farbe, Form, Geruch und Geräusche besitzen. Alle Gegenstände sollten Gewicht haben. Gegenstände sollten realistische Preise haben. Gegenstände sollten aus Materialien bestehen. Normale Gegenstände sollten nicht 'autoloading' sein. c) Aktionen ----------- Gegenstände sollten benutzbar sein! Eine Ring sollte man anstecken können, eine Laterne sollte man anzünden können. Einen Koffer sollte man oeffen und schließen können... Lebensmittel sollte man essen können, kleine Gegenstände sollte man mitnehmen können, große, sperrige und schwere nicht. Gegenstände sollten EINFACH benutzbar sein. Möglichst alle gängigen natürlichen Kommandos sollten verfügbar sein. d) Umgebung ----------- Gegenstände müssen in ihrer Umgebung passen. Gegenstände sollte nicht einfach plump in einem Raum liegen! Als Spieler sollte man sich halbwegs erklären können, warum gerade SOWAS DORT herumliegt. Ein pluescheliges Schnuckelkueken gehört beispielsweise nicht neben ein gefährliches Orklager, sondern eher auf einen Bauernhof. Auch hier gilt: Auf Konsistenz mit der Umgebung achten. Ein Raum sollte nur einen Gegenstand beschreiben, wenn er auch wirklich DA ist, und nicht gerade vom nächstbesten Spieler mitgenommen wurde. II. Grossprojekte ================= An größere Projekte sollte man sich nur ranmachen, wenn: - GENÜGEND ZEIT DAFÜR VERFÜGBAR IST. Ideen zu bekommen und neue Gegenden zu planen geht sehr schnell, eine anständige Programmierung dagegen braucht meist SEHR viel länger als man anfangs denkt! DESHALB: Lieber KLEINE Sachen programmieren, in ETAPPEN arbeiten. - GENÜGEND KREATIVER FREIRAUM VORHANDEN IST! Man sollte sich kein Thema oder Gebiet aussuchen, dass schon zur Genüge ausprogrammiert wurde, sondern NEUE Sachen programmieren. - GENÜGEND KREATIVES MATERIAL DA IST! Man sollte nicht aus einer einzigen Idee heraus ein Spiel, Rätsel oder eine Gilde programmieren. Meist fehlt es dann später an Story, und man muss während der Programmierung noch improvisieren. Am besten überlegt man sich, ob die erste Idee wirklich ausbaubar ist, und ob daraus was brauchbares zu programmieren ist. Eine Brainstorming-Liste kann brauchbar sein. Hat man selbst nicht genug 'technisches Knowhow' oder nicht genug 'kreative Schaffenskraft', so kann man sich mit einem anderen Gott zusammenschließen. Allerdings sollte dann die Projektplanung noch viel sorgfältiger erfolgen. Größere Projekte sollte man unbedingt mit seinem Domainlord absprechen unter Umständen auch mit den Admins. Auch hier gilt wieder: Das neue Projekt sollte sich möglichst nahtlos in die alte Umgebung einfügen! Passt ein Projekt nicht in eine Domain, so sollte man das nicht durch abgesprengte Teildomains umgehen, sondern sich die passende Domain suchen, und diese mit 'Leben' anfüllen. Jedes neue Stück Land, macht UNItopia leerer! Deshalb: Altes Land mitbenutzen! Schönere Gegenden erhält man, wenn man für neue Projekte, altes Territorium mitbenutzt. Verschiedene Dinge miteinanderzuverstricken macht die ganze Sache für den Spieler interessanter. Ein Rätsel sollte möglichst nicht komplett 'STAND ALONE' sein, sondern mit seiner Umgebung zumindest minimal wechselwirken. Größere Projekte ankündigen, damit es zu keinen Missverständnissen oder doppelten Projekten kommt. Jedes Teil, aus dem ein größeres Projekt besteht, sollte sorgsam programmiert werden! Beschreibungen nicht vergessen, Details nicht vergessen! Besser KLEINERE Projekte und dafür mehr DETAIL! Besser ALTES durch NEUES verbessern, ergänzen, erweitern, statt nur neue, leere Länder bauen! Auch unwichtige Details schön ausprogrammieren, nicht nur den Haupthandlungspfad ausbauen. III. Sourcen ============ a) Struktur Sourcen sollten lesbar sein. - Formatierung. Die genaue Formatierung ist frei. Man sollte sich eine Stil aneigenen und diesen konsistent durchziehen und beibehalten. Ungern ist die TAB Formatierung gesehen, will sagen: Jedes File sollte mit der Standardeinstellung für Tabs (= 8 Zeichen pro Tab) gut lesbar sein. - Kommentierung Kommentare sollten komplexe Zusammenhänge oder Datenstrukturen erläutern. Standardfunktionsaufrufe oder Standardkonstrukte zu dokumentieren ist nicht sinnvoll, weil dadurch die freie Sicht auf den eigentlichen Code versperrt wird und diese Erklärungen leicht in der Dokumentation nachzulesen sind. Nicht dokumentierte Standardfunktionen sollten gemeldet werden. Ueberdokumentieren ist auch nicht hilfreich. Beschreibende Variablennamen sind sehr hilfreich für den Leser. (Man sehe von tmp1 bis tmp129 ab...) - Dokumentation Komplexe Objekte brauchen zusätzlich eine Dokumentation, in der ihre Funktionsweise erklärt wird und in der ihre Kommandos beschrieben werden. - Public/Private Objekte sollten klarstellen, welche Codeteile sie anderen Objekten zur Verfügung stellen (public lfuns) und gewährleisten dass diese auf dauer geltend bleiben. Andere Funktionsteile sollten von außen her nicht zugänglich sein. (private functions) Möglichst viel Code sollte versteckt sein, also private. Die öffentliche Schnittstelle (public) sollte einfach, funktionell und klar sein und Zugänge zu allen Anwendungsmöglichkeiten bieten. (Zu einem set-Befehl gehört ein query-Befehl...) b) Quellen für eigenen Code. - Speziell für Anfänger scheint es am leichtesten zu sein, sich bestehenden Code zu kopieren und diesen leicht verändert für seine Zwecke einzu- setzen. Diese Methode beinhaltet aber einige Schwachpunkte: x Der Programmierer des ursprünglichen Codes könnte etwas dagegen haben, dass Du sein Programm einfach kopierst oder er möchte einfach nur in- formiert sein, wo sein Programm noch zum Einsatz kommt. x Der Ursprungscode könnte Fehler oder veraltete Konstrukte beeinhalten, die zum aktuellen Zeitpunkt nicht mehr modern sind. x Du lernst die falschen Methoden zur Behandlung von Standardproblemen. - Eine alternative Methode sind die allseits beliebten "Roombuilders", doch auch sie haben den gravierenden Nachteil, unschönen, veralteteten und unverständlichen Code zu produzieren. - Die beste, aber auch langwierigste Methode ist es, das dahinterstehende Konzept zu verstehen, um so weniger kopieren zu müssen. Den Code, den man selbst schreibt ist letzens immer der beste. (Vielleicht nicht der beste von allen, aber der beste für einen selbst.) Am besten schaut man verwendbare Codestrecken von erfahreneren Göttern an, versucht sie (mit Nachfragen...) zu verstehen und baut sie in seinen Code ein. c) Fertiger Code? Jeder Gott wird irgendwann mal mit seinem Konzept fertig sein, sein Projekt programmiert haben, und so fort. Jetzt kommt das natürlichste der Welt: Er muss es möglichst vielen zeigen, um Bestätigung zu erhalten. Dieses Verhalten führt natürlich zu Problemen, da (wie in unserer hektischen Welt ueblich) keiner da ist, der Dir zuhören will, und der Deine neuen Kreationen bewundern will. Trotzdem solltest Du nicht Spieler dazu zwingen, Deine Kreationen zu bewundern. Auch Götter können von zu aufdringlichem Umwerben um Aufmerksamkeit eher genervt als ermuntert sein, Dir zu zuhören. Viel einfacher führst Du Deine neuen Kreationen ein, indem Du sie mit alten bekannten Dingen verflechtest, welche die Spieler schon kennen. Sie werden dann automatisch auch Deine neuen Kreationen erkennen und würdigen! Das ist zwar die lanwierigerer Methode, sie spart aber viel Nerven und führt auf Dauer zum Erfolg.