designentwurf
Dataaccess Layer: Soll ein „Arbeiten am offenen Herzen“ an den Datenobjekten verhindern und so inkonsistente Zustände vorbeugen.
Service Layer: Kümmert sich um „aufwändige“ Prozesse, die viel Logik beinhalten und Referenzen verändern, z.B. wenn ein Item aufgehoben wird.
Interface Layer: Die Schnittstelle nach außen, mit dieser Schnittstelle kommuniziert der Client.
Projektstruktur: • Core wird in einem eigenen Projekt verwaltet. (Klassenbibliothek) • Core.Tests das Testprojekt zum Core Projekt. (In der Abbildung nicht beschrieben) • Server, dort wird der eigentliche Server implementiert.
Das vorliegende Klassendiagramm zeigt die Models. Es ist untergliedert in fünf Bereiche:
• Rooms & Areas (blau) • Users (rot) • MudGames (grau) • Characters (lila) • Inventories (grün)
Die einzelnen Bereiche werden teilweise in Kapitel 3.1 näher betrachtet. Für eine größere Darstellung kann das Klassendiagramm auch auf LucidChart direkt anschauen.
Link für LucidChart:
https://www.lucidchart.com/documents/view/7cae6548-427f-4e1c-88b8-e9a8482832d8/0_0
Dieses Klassendiagramm zeigt die Zusammenhänge zwischen den Services und Managern. Als zentrale Schnittstelle zur Datenbank dient die Klasse „MudDbContext“. Eine nähere Betrachtung der einzelnen Bereiche erfolgt teilweise in Kapitel 3.2. Für eine größere Darstellung kann das Klassendiagramm auch auf LucidChart direkt anschauen.
Link für LucidChart:
https://www.lucidchart.com/documents/view/b780b52c-f8af-4015-a24f-99ab7b65cbbd/0_0
Es wird eine RESTful API implementiert mit den passenden Methoden je nach Fall [GET, POST, PUT, DELETE]. Bei geschützten Schnittstellen wird eine Authentifizierung nach dem Bearer-Schema mittels eines JSON-Web-Token´s gefordert.
Die User-Schnittstelle dient zur Verwaltung der Benutzer auf dem Server. Sie erfordert eine Authentifizierung und kann nur von Benutzern der Rolle „Admin“ konsumiert werden.
/api/users
/api/users/:userid
/api/users/:userid/roles
/api/users/:userid/request
Die Rooms-Schnittstelle dient zur Verwaltung der Räume auf dem Server. Man kann ebenso die ItemInstances steuern.
/api/rooms
/api/rooms/:roomid
/api/rooms/:roomid/iteminstances
/api/rooms/:roomid/iteminstances/:iteminstancesid
Die Areas-Schnittstelle dient zur Verwaltung der Gebiete auf dem Server.
/api/areas
/api/areas/:areaid
Die Races-Schnittstelle dient zur Verwaltung der Rassen auf dem Server.
/api/races
/api/races/:raceid
Die Classes-Schnittstelle dient zur Verwaltung der Klassen auf dem Server.
/api/classes
/api/classes/:classid
Die Items-Schnittstelle dient zur Verwaltung der Items auf dem Server.
/api/items
/api/items/:itemsid
Die Image-Schnittstelle dient zur Verwaltung der Bilder auf dem Server.
/api/images
Die Connections-Schnittstelle dient zur Verwaltung der Verbindungen auf dem Server.
/api/connections
/api/connections/:connectionid
Die Character-Schnittstelle dient zur Verwaltung der Charaktere auf dem Server.
/api/characters
/api/characters/:charcterid
Die Authentication-Schnittstelle dient zur Anmeldung und Registrierung von Benutzern am Server.
/api/auth/login/
/api/auth/register/
/api/auth/reset/
Über die MUD-Schnittstelle lassen sich alle MUDs abfragen, sowie alle notwendigen Informationen zu einem speziellen MUD. Sie erfordert eine Authentifizierung und kann teilweise von allen Benutzern konsumiert werden.
/api/muds/
/api/muds/:mudid/
/api/muds/:mudid/validate
/api/muds/:mudid/request
/api/muds/:mudid/request/:userid
/api/muds/:mudid/requestjoin
/api/muds/:mudid/start
/api/muds/:mudid/stop
/api/muds/:mudid/edit
• Die „Hub“ Interfaces stellen die RPC in Richtung Client zu Server dar. • Die „HubClient“ Interfaces stellen die RPC in Richtung Server zu Client dar.
Es werden 2 Hubs definiert ein „GameHub“ und ein „ChatHub“.
• Der „GameHub“ wird für die Spiele Interaktion genutzt. • Der „Chathub“ wird für die Chatnachrichten genutzt.
Anmerkungen: Die Resultklassen werden noch mit Metadaten gefüllt, was jedoch die Daten sind, ist zum Zeitpunkt der Designerstellung nicht vollständig abschätzbar.
Die Angular-Anwendung wird in Komponenten aufgeteilt, dabei wird zwischen verschiedenen Arten unterschieden: Shell-Components (dienen als „Hülle“ für mehrere Unterkomponenten), Router-Components (zeigen je nach aktiver Route unterschiedliche Unterkomponenten an), Presentational-Components (zustandlose UI-Komponenten zur Darstellung) und „normalen“ Komponenten mit internem Zustand und Funktionalität.
Anmerkung: In den unteren Ebenen wurden der Übersichtlichkeit halber manche Presentational-Components weggelassen.
Weiterreichende Logik, die API-Kommunikation sowie die SignalR-Schnittstelle werden in Service-Klassen ausgelagert, auf die die einzelnen Komponenten mittels Dependency-Injection zugreifen können.
Anmerkungen: Die Response-Typen werden noch definiert, wie diese konkret aussehen ist zum Zeitpunkt der Designerstellung noch nicht vollständig abschätzbar.
Für größere Applikationen bietet es sich in Angular an, die einzelnen Komponenten in Module zusammenzufassen. Diesen Prozess bezeichnet man als Modularisierung.
In unserem Fall wird die gesamte Applikation in 6 Module gegliedert (App, Game, Home, Login und Configuration, Shared). Durch die Aufteilung in Module lassen sich Logik und Komponenten, welche zu einem großen Use-Cases gehören, bündeln und so logisch voneinander trennen.
Bei der Entwicklung des Front-End ist dadurch mehr Übersichtlichkeit gewährleistet. Ebenfalls wird durch die Trennung der Anwendungsbereiche in einzelne Komponenten, die Fehlerbehandlung zum späteren Zeitpunkt erleichtert und die Ladezeiten werden minimiert durch dynamische Nachladen.
Einen Einfluss auf die Funktionalität der Anwendung hat die Modularisierung nicht.
Die Webanwendung wird in 4 Top-Level Ansichten strukturiert: (vgl. 1.3.1)
- Home-Ansicht: Übersicht über bereits gespielte MUDs und verfügbare MUDs
- Login-Ansicht: Start-Ansicht für nicht authentifizierte Benutzer, um sich anzumelden oder zu registrieren
- Konfigurations-Ansicht: Konfigurationsmöglichkeit für MUD-Master, um MUDs zu erstellen und zu verwalten
- Spiel-Ansicht: Ansicht, über die das eigentliche Spielen in einem MUD abgebildet wird
Innerhalb dieser Top-Level Ansichten existieren weitere, speziellere Ansichten, welche an den jeweiligen Anwendungsfall angepasst sind.
Nach einer Eingabe des Benutzers über das Eingabefeld des Spiels wird diese an einen zentralen CommandService weitergeleitet. Dieser überprüft anhand von registrierten Kommandos ob die Eingabe ein Kommando ist und wenn ja, welcher. Wenn die Eingabe bezüglich des Kommandos korrekt ist, wird dieser mit den angegebenen Argumenten ausgeführt.
Bei der Erstellung eines MUDs beginnt der MUD-Master mit der allgemeinen Beschreibung des MUDs. Nach Festlegung eines Namens, einer Beschreibung, der Sichtbarkeit (öffentlich oder privat) und optional eines Bildes, wird das MUD-Game serverseitig erstellt. Hierbei wird diesem dann eine einmalige ID zugewiesen. Nach dem Anlegen des MUDs können allerdings noch keine Spieler die Welt betreten. Der MUD-Master muss hierzu in den kommenden Schritten zuerst weiter Konfigurationen vornehmen. Zunächst wird ein Raumsystem erstellt, die Ressourcen und NPCs entworfen und diese den Räumen dann hinzugefügt. Anschließend können für die Charaktererstellung die Rassen und die Klassen kreiert werden. Dabei kann er auf vorhandene Vorlagen zurückgreifen. Der MUD- Master ist dabei nicht auf die im Diagramm angegebene Reihenfolge beschränkt, sondern kann auch beliebig vor und zurückspringen. Er kann beispielsweise ein NPC erstellen und im Nachgang noch eine Ressource hinzufügen. Ist der MUD-Master zufrieden mit seinem Werk, kann er den MUD abspeichern und erstellen. Nun können die ersten Spieler seinen neu erstellten MUD betreten.
Der Akteur/Spieler stößt beim Klick auf Registrieren den Prozess für das Registrieren an. Dabei wird die Registrierungskomponente angesprochen, welche die Daten an den AuthService weiterleitet. Dieser Service kommuniziert per HTTP-Request mit dem Server. Ist auf diese E-Mail schon ein Benutzer registriert, dann wird der Antrag abgelehnt und diese Information wird über die Schichten zurückgegeben. Ist auf diese E-Mail noch keine Benutzer registriert, wird der Benutzer erstellt, in die Datenbank mitaufgenommen und die Bestätigung wird zurückgegeben. Im gleichen Zug wird der Mail-Server angestoßen eine Verifizierungsmail an die E-Mail-Adresse zu senden.
Bis auf kleine Ausnahmen, die im folgendem genannt werden, läuft der Login-Prozess Clientseitig identisch ab wie der Registrierungsprozess. Bei einer Anmeldung eines bestehenden Benutzers wird die Login-Komponente angesprochen. Der AuthService und Server kommuniziert mithilfe eines HTTP-Request.
Es folgt nun eine genauere Betrachtung des Klassendiagrammes aus Kapitel 1.1.1.
Eine Besonderheit bietet das Enum „LockType“ dieses definiert die verschiedenen Bedingungen, die an dem Wechsel zwischen Räumen gebunden sind. So kann zum Beispiel der Durchgang zwischen Raum X und Raum Y für „Elben“ (Enum CharacterRaceLook) gesperrt werden.
Ein User kann in unserer Anwendung verschiedene Rollen annehmen. Die Rollen werden als Enum verwaltet, welches später bitweise ausgelesen wird. So kann ein User die Rolle „Player“ und „Master“ besitzen.
LiveUpdates in der Klasse „Character“ ist ein Kommentar, dort werden Daten gespeichert, die sich relativ Frequent ändern.
Nicht nur jeder Character soll ein eigenes Inventar besitzen, sondern noch zusätzlich jeder Raum ein Inventar. Damit ist sichergestellt, dass jedes Item zu jeder Zeit in einem Inventar ist.
Die Klasse „LoginServiceOption“ enthält das Secret, das zur Erstellung des Tokens benötigt wird.
Die Klasse „GameService“ kümmert sich um zeitliche Themen, z.B. ein Buff der 20 Sekunden anhält und danach wieder entfernt werden muss.
Die Klasse „LoginService“ enthält das Secret, das zur Erstellung des Tokens benötigt wird. Die Klasse "UserManager" in Verbindung mit der Klasse "UserHelpers" kümmern sich um alle zu Verwaltendenden Eigenschaften eines Users.
Die Klasse "ItemManager" kümmert sich um Anlegen, Aktualisieren und Löschen von Items. Die Klasse "InventoryService" ist für die Item-Instanzen zuständig.
Die Klassen "MudManager" und "GameService" kümmern sich beide um die Verwaltug des Mud-Spiels.
In diesen Klassen können Räume, Umgebungen und Verbindungen Angelegt, Bearbeitet und Entfernt werden.
