1 #LyX 1.3 created this file. For more info see http://www.lyx.org/
15 \use_numerical_citations 0
16 \paperorientation portrait
19 \paragraph_separation indent
21 \quotes_language english
25 \paperpagestyle default
30 \begin_inset Quotes eld
33 Die letzten Tage von Aymargeddon
34 \begin_inset Quotes erd
40 Aymargeddon Development Team
48 Warnung: Die Information in diesem Dokument ist zu nicht unerheblichen Teilen
55 Das Spiel besteht aus folgenden Komponenten:
58 Eine Relationale Datenbank
61 Ein Dämonprozess im Server
64 Serverseitige Scripten zur Benutzerinteraktion
73 Ein Programm, dass die Integrität der Datenbank überprüft
76 Eine Bibliothek für gemeinsame Funktionalität
79 Die Aufgaben dieser Komponenten stellen sich wie folgt dar:
85 In dieser Datenbank wird der Zustand aller Spielwelten gespeichert.
86 Außerdem alle Spielerdaten, alle Spieleraktionen und alle Nachrichten an
88 Sie sorgt mittels ihrer Transaktionen dafür, dass auch bei konkurierendem
89 Zugriff die Datenintegrität immer erhalten bleibt.
92 Wir verwenden MySQL zur Implementierung und PhpMyAdmin zur Administrierung
96 Felder, die in vielen Tabellen vorkommen und immer wieder das selbe bedeuten:
99 GAME Das ist die Id des Spiels.
100 Dadurch können alle Spiele in der selben Datenbank verwaltet werden.
101 Es kann maximal max(unsigned smallint) Spiele gleichzeitig geben.
104 LOCATION Feldkoordinaten auf dem Hexraster-Torus.
105 Ein String der Form <x>_<y>.
106 Die maximale Größe der Welt ist max(unsigned smallint) für die Y-Koordinate
107 und max(unsingend smallint)*2 für die X-Koordinate.
112 Die Spieler-Ids bezeichnen den Spieler
117 Sie gilt spielübergreifend.
118 Die maximale Anzahl Spieler ist auf max(signed smallint) beschränkt.
124 Einheiten, die sich bewegen, bleiben im Feld stehen, werden aber auf nicht
126 Am Ende des Befehls werden sie in das neue Feld gesetzt.
127 Sie werden nur wieder aktiv, nachdem alle denkbaren Kämpfe ausgeführt wurden.
130 Kämpfe werden als Quasi-Befehl wieder in die Befehlsqueu geschrieben.
131 Erst nach Ablauf dieses Quasi-Befehls wird ausgewertet, welche Einheiten
132 auf welcher Seite am Kampf teilnehmen.
135 Einheiten, die sich zurückziehen, werden ganz normal bewegt.
141 Das ist die zentrale Karte.
142 Für jedes Feld in jedem Spiel gibt es genau einen Eintrag.
145 HOME Eigentümer der Heimatstadt.
146 Das Feld ist -1, wenn es eine Heimatstadt ist, aber noch niemand spielt.
149 OCCUPANT Besitzer des Feldes
152 TERRAIN kann sein eins aus: WATER, CITY, MOUNTAIN, ISLE, PLAIN
155 PLAGUE ist das Feld verseucht? Kann eine aus einer Liste von Seuchen sein
158 ATTACKER Hier steht der leitende Erdling eines Angriffs drinnen so lange
161 Man kann hier also auch ablesen, ob das Feld umkämpft ist.
164 LAST_PRODUCE Zu dieser Zeit wurde zu letzt ein Krieger (bei Städten) bzw.
165 ein Priester (bei Tempeln) produziert.
166 Der Dämon entscheidet anhand dieser Daten, wann neue Einheiten produziert
170 FLUXLINE Hier stehen die Richtungen, in die sich Avatare momentan kostenlos
172 Die benachbarten Richtungen kosten 1 MP, alle anderen 2MP.
173 Dieses Feld wird bei einer Änderung der IdS für die gesamte Karte neu berechnet.
176 TEMPLE Steht auf 'Y', wenn dort ein Tempel gebaut wurde, auf 'N' sonst.
182 In dieser Tabelle werden alle beweglichen Objekte abgespeichert.
183 Das sind also zunächst: Krieger, Helden, Priester, Avatare und Archen.
184 Dabei gibt es nur einen Eintrag für gleichartige Einheiten im selben Feld
188 Manche Felder werden nur für manche Objekttypen benutzt.
189 Hier wird also ein bisschen Speicherplatz geopfert um die Struktur möglichst
193 ID Eine eindeutige ID.
196 TYPE Ist einer aus WARRIOR, HERO, PRIEST, AVATAR, ARK
199 OWNER Der Spieler, der die Einheit steuert
202 ADORING Der Gott, den der Priester anbetet
208 AVAILABLE Wird auf 0 gesetzt, wenn die Einheit beschäftigt ist (sich also
213 STATUS Eines aus HELP, BLOCK, PEACE.
220 In diese Tabelle tragen die Scripten die Aktionen der Spieler ein und der
221 Dämon führt diese dann aus.
222 Zusätzlich kommen hier auch noch die Quasi-Befehle des Dämons selber rein.
223 Das ist alles, wo er sich für später dran errinnern will.
224 Zur Zeit wird dieser Mechanismus nur für Kämpfe benötigt.
227 TIME Die Zeit zu der das Kommando eingetragen wurde
230 ACK Hier wird vermerkt, dass der Dämon das Kommando zur Kenntnis genommen
231 hat, aber noch nicht ausgeführt.
232 Das ist nötig weil bei vielen Kommandos schon am Anfang Nachrichten generiert
233 werden müssen, lange bevor sie ausgeführt werden.
235 erhalten die Eigentümer eines Feldes, in das man sich bewegt, eine Nachricht,
236 schon wenn man sich auf den Weg macht.
239 DONE Hier werden abgearbeitete Befehle vermerkt
242 Alle drei Felder sind Timestamps und müssen immer GMT enthalten!
248 In diese Tabelle trägt der Dämon Nachrichten an die Spieler ein und die
249 Scripten zeigen diese dann an.
250 Nachrichten an Alle Spieler müssen für jeden Spieler einzeln eingetragen
252 Wenn man es anders machen wollte, müsste man wiederum für jeden Spieler
253 vermerken, welche Nachrichten er nicht mehr sehen will, was fast auf das
258 TIME Der Zeitpunkt, an dem die Nachricht generiert wurde
262 0 bedeutet, dass es eine automatisch generierte Nachricht des Dämon ist.
268 TYPE Message, Error, Warning, ...
271 MSG Die eigentliche Meldung.
273 ein Tag, dass erst noch lokalisiert werden muss (Siehe Tabelle LOCALIZE)
276 ARG1...4 Die Argumente für die Lokalisierung.
282 Hier stehen allgemein Infos das Spiel betreffend.
283 Pro Spiel gibt es nur einen Eintrag.
286 SIZE Die Größe des Spiels.
287 Höhe und halbe Breite des Spielfeldes.
288 Maximale Anzahl Erdlinge.
291 FORTUNE Der Glücksfaktor
294 LAST_TEMPLE Die LOCATION des letzten fertig gestellten Tempels.
297 TEMPLE_SIZE Größe des nächsten Tempels.
303 Hier wird spielunabhängig gespeichert, was es alles über einen Spieler zu
305 Pro Spieler ein Eintrag.
311 Hier wird beschrieben welche Freunde und Feinde man hat.
312 Pro Spieler-Spieler-Relation in jedem Spiel höchstens ein Eintrag.
314 \begin_inset Quotes eld
318 \begin_inset Quotes erd
322 \begin_inset Quotes eld
326 \begin_inset Quotes erd
330 \begin_inset Quotes eld
334 \begin_inset Quotes erd
338 Wenn kein Eintrag vorhanden ist, wird neutraler Status angenommen.
342 Man beachte dass Spieler A, Spieler B als Freund ansehen kann, wärend umgekehrt
343 Spieler B Spieler A als Feind betrachtet!
349 Hier werden Daten für die Götter gespeichert.
350 Pro Gott und Spiel ein Eintrag.
353 DEATH_AVATAR Die Anzahl der für diesen Gott in diesem Spiel gestorbenen
361 ARRIVAL Hier entstehen neue Avatare.
362 Dieser Ort wird nach jedem Tempelbau diesen Gottes neu berechnet.
368 Mit Hilfe dieser Tabelle kann die Darstellung in verschiedenen Sprachen
372 TAG Der Eintrag mit dem man wiederkennt, um welche Message es sich handelt
375 LANG Die Sprache des Eintrags.
377 \begin_inset Quotes eld
381 \begin_inset Quotes erd
385 \begin_inset Quotes eld
389 \begin_inset Quotes erd
395 TEXT Der Text der Nachricht in den einzelnen Sprachen.
397 \begin_inset Quotes eld
401 \begin_inset Quotes erd
404 das n.te Argument eingefügt.
406 \begin_inset Quotes eld
410 \begin_inset Quotes erd
413 gibt ein Prozentzeichen aus.
420 Hier wird die Rolle eines Spielers in einem Spiel beschrieben.
421 Pro Mitspieler in jedem Spiel ein Eintrag.
427 Dieses Programm liest Spieleraktionen aus der Datenbank, berechnet die sich
428 daraus ergebenden Ereignisse und schreibt Nachrichten an die Spieler zurück
432 Wir verwenden Perl 5.8 zur Implementierung des Servers.
438 Sie lesen den Zustand der Welt und die Nachrichten aus der Datenbank, halten
439 Session-Informationen vor und bereiten dies alles in HTML zur Darstellung
440 mittels eines üblichen Web-Browsers auf.
441 Schließlich schreiben sie die Aktionen des Benutzers in die Datenbank und
442 verändern den Aktivitätsstatus von beweglichen Einheiten.
445 Wir verwenden EmbPerl auf Apache zur Implementation.
446 Siehe: http://perl.apache.org/embperl/.
447 EmbPerl scheint genauso einfach und schnell zu sein wie PHP und hat für
448 uns den zusätzlichen Vorteil, dass wir gemeinsame Bibliotheken mit den
449 anderen Komponenten des Servers benutzen können.
455 Folgende Seitenlayouts werden benötigt.
456 Auf allen Seiten findet man ein Hauptmenu.
457 Auf Login und Home gibt es auch noch ein Aymaegeddon-Banner
460 Login Hier gibt es neben News einen kurzen Einleitungstext sowie eine Möglichkei
461 t sich zu registrieren und mal in einem Fakespiel zu schnuppern.
464 Home Liste aller Spiele, pro Spiel: Liste aller Nachrichten, aller Ereignisse,
468 Karte Aktuelles Feld, Beschreibung, Befehle
471 Spieler Beschreibung des Spielers
474 Rolle Beschreibung der Rolle
477 Feldnamen/-koordinaten sind überall immer zur Karte mit dem Feld als aktuellem
479 Rollennamen sind zu der entsprechenden Rollenseite verlinkt.
485 Zentrale Komponente der Darstellung ist eine Karte des Hex-Torus.
486 Dazu werden 3 Tabellenzellen pro Feld verwendet, nämlich so:
488 \added_space_bottom 0.3cm
492 Diese Karte ist scrollbar.
493 Ein Feld ist immer als aktuelles Feld umrandet.
499 Wasserfelder blau, Landfelder, Archen und Inseln in Erdfarben.
500 Dabei gibt es 5 Farbtöne für eigene, befreundete, neutrale, feindliche
501 sowie unbesiedelte Felder.
502 Tempel und Avatare werden in 5 verschiedenen Götterfarben (eher grell)
503 dargestellt, wieder je eine für eigene, befreundete, feindliche sowie neutrale
506 \begin_inset Quotes eld
510 \begin_inset Quotes erd
513 Farbe kann auf andere Erdlinge/Götter verändert werden.
520 Folgende Icons werden benötigt.
529 Eigentum auf Wasser (Schiff)
550 Avatare (oben bis zu vier)
553 Archen (unten, nur eine)
565 Dieses Programm wird einmal zu Beginn eines neuen Spiels aufgerufen um eine
566 neue Welt in der Datenbank zu generieren.
567 Der Generator verteilt die verschiedenen Geländetypen: Wasser, Manapol,
568 Insel, Berg, Stadt, Heimatstadt, Land.
569 Er erhält die Anzahl der Erdlinge als Parameter und ermittelt alle anderen
574 Die Game-ID kann automatisch als die erste Freie in der DB ermittelt werden.
575 Dieses Programm sollte als erstes entwickelt werden, damit man eine sinnvolle
576 Testumgebung für die anderen Teile des Systems hat.
579 Wir verwenden Perl 5.8 zur Implementation.
606 Dort werden alle Funktionalitäten versammelt, die nicht nur von Aymargeddon,
607 sondern auch von anderen Browser-MMOGs verwendet werden können.
608 Das sind im einzelnen:
611 Nachrichtenverwaltung
626 Verschiedene Standardkarten (hier erstmal nur Hextorus)
644 FROGS basiert dabei auf der Annahme, dass bestimmte Felder in bestimmten
645 Tabellen vorhanden sein müssen.
646 Außerdem werden die konkreten Funktionalitäten über Hooks in das Framework
649 für jeden Befehl ein Name festgelegt mit drei Hooks:
652 test Diese Funktion tested, ob der Befehl überhaupt ausführbar ist.
655 ack Diese Funktion wird ausgeführt, wenn der Befehl zum ersten mal vom Dämon
656 zur Kenntnis genommen wird.
659 do Diese Funktion führt schließlich den Befehl aus.
660 Dazu sind am Anfang noch weitere tests nötig.
663 Ziel für Frogs ist, dass man relativ einfach neue Browserspiele bauen kann.
664 Es wird auch ein Satz von Standardseiten in EmbPerl mitgeliefert mit denen
665 Funktionen wie Einloggen, Spielverwaltung, Bestenlisten etc.
666 schon vorhanden sind.
669 Hier noch eine Liste von FROGS-Modulen und was sie tun sollen:
672 Map.pm Dies ist eine Basisklasse für alle denkbaren Topologien.
673 Jedes Modul einer abgeleiteten Klasse sollte auch eine Klasse Location
674 zur Verfügung stellen.
675 Außerdem müssen abgeleitete Klassen einige Funktionen mitbringen, damit
676 die in Map vorhandenen Funktionen funktionieren.
679 HexTorus.pm Dies ist die von Aymargeddon verwendete Topologie.
680 Kann aber auch von anderen Spielen verwendet werden.
681 Abgeleitet von Map.pm.
682 Stellt auch die Klasse Location zur Verfügung.
685 Checker.pm Hier werden die verallgemeinerbaren Funktionen des Checkers zur
689 Scheduler.pm Hier wird die Befehlsqueu durchgegangen und die oben definierten
690 Funktionen werden aufgerufen.
693 Localize.pm Hier wird die Lokalisierung ausgeführt.
696 DataBase.pm Hier werden Basisdatenbankfunktionalitäten zur Verfügung gestellt
700 weitere Module noch unklar
703 Auch FROGS wird in Perl 5.8 bzw.
704 EmbPerl implementiert.
710 Dieses Programm überprüft, ob die Daten in der Datenbank noch konsistent
712 Dabei werden die Checks zu algorithmisch ähnlichen Gruppen zusammengefasst
713 und durch allgemein Funktionen ausgeführt.
714 Bisher sind folgende Funktionen identifiziert worden:
717 Jeder Eintrag in Tabelle X muß auch in Tabelle Y existieren.
721 N Einträge in der selben Tabelle müssen eine logische Beziehung erfüllen
724 Diese allgemeinen konfigurierbaren Check-Funktionen sollten auch Teil von
728 Der Checker überprüft im einzelnen (Zahlen beziehen sich auf obige Funktionslist
732 Jede Spielnummer muß in der Tabelle GAME zu finden sein (1).
735 sämtliche Spieler-IDs müssen in ROLE zum selben Spiel passen (1).
738 sämtliche Spieler-IDs müssen in PLAYER vorhanden sein (1).
741 Location muß immer in MAP vorhanden sein.
744 Location muß immer die kanonische Form haben (2).
747 HOME nur gesetzt in MAP, wenn TERRAIN = CITY (desgl.
748 für GOD_HOME und MOUNTAIN) (2).
751 Keine Zwei Erdlinge im selben Feld, außer es ist Kampf.
754 Alle Einheiten in COMMANDS müssen inaktiv sein.
757 Nur Priester ADORING in MOBILE (2).
760 AVAIABLE immer kleiner oder gleich COUNT in MOBILE (2)
763 Während eines Kampfes nur aktive Erdlinge eines Spielers im selben Feld.
766 Keine blockenden Avatare von zwei feindlichen Spielern im selben Feld ohne
770 Jedes Tag in MESSAGE sollte in LOCALIZE vorhanden sein.
771 Mindestens in einer Sprache.
772 Warnung, wenn nicht in jeder Sprache.
775 Die Anzahl der Argumente in MESSAGES sollte mit den nicht doppelten %-Zeichen
776 in LOCALIZE übereinstimmen (für jede Sprache).
780 CREATE <= EXEC <= ACK <= DONE in COMMAND
783 Dieses Programm sollte möglichst früh entwickelt werden, da es vor allem
784 im Entwicklungsprozess benötigt wird.
787 Wir verwenden Perl 5.8 zur Implementation.
793 Hier werden alle Funktionalitäten versammelt, die von mindestens zwei der
794 Komponenten (Scripten, Generator, Dämon, Check) verwendet werden.
798 Dabei bleiben in dieser Bibliothek nur Sachen, die nicht noch allgemeiner
799 sind und somit in den FROGS-Teil gehören.
800 Momentan ist noch unklar, ob da überhaupt was übrig bleibt.
803 Wir verwenden Perl 5.8 zur Implementation.
813 (c) 2003 Aymargeddon Development Team
818 Permission is granted to copy, distribute and/or modify this document under
819 the terms of the GNU Free Documentation License, Version 1.1 or any later
820 version published by the Free Software Foundation; with no Invariant Sections,
821 with no Front-Cover Texts, and with no Back-Cover Texts.
822 A copy of the license is available at http://www.aymargeddon.de.