Moderne-Datenbanken/Ringstats_Dokumentation.tex

\documentclass[12pt,a4paper,parskip=half]{scrartcl}
\usepackage[utf8]{inputenc}
\usepackage[ngerman]{babel}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage[colorlinks=true, linkcolor=black]{hyperref}

\title{Ringstats Dokumentation}
\author{Justin Rost \\ 7208260
        \and
        Michelle Reichelt \\ 7216628
        \and
        Yasin Ergün \\ 7215184
}

\date{\today}

\begin{document}

\maketitle
\tableofcontents
\newpage


%Viele PC-Spieler suchen stetig nach neuen Tools um ihr Spielerlebnis zu optimieren und ihre Echtzeit Statistiken besser im Blick zu haben. Daher haben wir
% Die Einleitung ist bla.
% Fliessender uebergang ins Fazit

\newpage

\section{Anwendungsszenario}
% Das nehmen wir direkt aus dem Proposal und schreiben es min eine seite lang.
In diesem Kapitel zeigen wir, worum es bei Ringstats eigentlich geht und in welchen Situationen die Anwendung dem Spieler im Spiel weiterhilft.

% Ein Spieler startet einen Bosskampf und kann in einem kleinen Fenster sehen, was für Resistenzen dieser Boss hat und welche Fähigkeiten er am häufigsten benutzt.

% Spielerdaten werden live gespeichert und an den Server gesendet, damit der Spieler direkt sehen kann, welche Truhen und Sammelobjekte in der Nähe sind.

% Die Gebiets-Checkliste zeigt bei einem Gebietswechsel an, welche Aufgaben der Spieler in dem neuen Gebiet hat.


\subsection{Projektidee und Zielsetzung}
Die Idee von Ringstats ist die Bereitstellung einer Schnittstelle zwischen dem aktiven Spiel und einer Datenbank mit hilfreichen Spielinformationen.
Während des Spiels erfasst die Desktop Anwendung in Echtzeit Parameter des Spielers und schickt diese an die Datenbank. Zu diesen Parametern zählen z.B. die aktuelle Position oder Ausrüstung.
Auf Grundlage dieser Live Daten stellt unsere Anwendung dann hilfreiche Informationen über Bosse oder Gegner in der Region des Spielers bereit. Zudem kann auch eine regionenbasierte
Checkliste angezeigt werden, auf der sich weitere benutzerdefinierte Aufgaben befinden. All diese Informationen werden auf In-Game Panels eingeblendet.


\subsection{Kernfunktionen und Anwendungsfälle}
Um den Nutzen von Ringstats zu verstehen, haben wir folgende Kernfunktionen definiert:
Die wichtigste Funktion ist das Erfassen der Spielerdaten in Echtzeit. Während der Spieler spielt, liest die Desktop Anwendung laufend aus,
wo der Spieler gerade steht, wie viel Leben er hat, wie schnell er ist und was er ausgerüstet hat. Diese Daten werden direkt an die Datenbank geschickt,
damit immer der aktuelle Stand vorliegt.
Sobald der Spieler einen Gegner oder Boss anvisiert, blendet die Anwendung ein kleines Panel im Spiel ein.
Darin sieht der Spieler die Resistenzen des Gegners und welche Fähigkeiten dieser am häufigsten benutzt.
So weiß man direkt, worauf man sich einstellen muss.
Zusätzlich gibt es eine Checkliste, die sich nach der Region richtet, in der sich der Spieler gerade befindet.
Diese lässt sich mit einem Hotkey ein und ausblenden. Auf der Liste stehen zum Beispiel Items, Dungeons und Bosse.
Der Spieler kann die Einträge filtern und selbst festlegen, ob sie automatisch abgehakt werden, sobald eine Bedingung erfüllt ist, oder ob er das lieber von Hand macht.
Alle diese Daten landen nicht nur im Spiel, sondern sind gleichzeitig über die Internetseite abrufbar.
Der Spieler meldet sich auf der Seite an und verbindet sich mit der Desktop Anwendung. Dann kann er seine Informationen auch im Browser einsehen.


Damit das Ganze einen Sinn ergibt, hier ein paar typische Situationen aus dem Spiel:
Der Spieler startet einen Bosskampf. In einem kleinen Fenster sieht er sofort, welche Resistenzen der Boss hat und welche Fähigkeiten am häufigsten kommen.\\
Während der Spieler durch ein Gebiet läuft, werden seine Daten an den Server geschickt. Dadurch sieht er direkt, welche Truhen und Sammelobjekte in seiner Nähe sind.\\
Wechselt der Spieler in ein neues Gebiet, zeigt die Checkliste an, welche Aufgaben in diesem Gebiet noch offen sind.

\newpage

\section{Dokumentation der Datenmodellierung}
In diesem Kapitel schauen wir uns an, wie wir die Daten von Ringstats aufbauen und wie das Ganze in den verschiedenen Datenbanken aussieht.

\subsection{Das konzeptionelle ER-Modell}
Die komplexe Struktur der Spielwelt bilden wir mit einem Klassischen ER-Modell ab.
Das Modell veranschaulicht,
wie der Spieler (Player) über seine Ausrüstung (Gear)
mit Waffen (Weapon), Rüstungen (Armor) oder Talismanen (Talisman) etc. verbunden ist.
Fast alle dieser Gegenstände haben einen Typen (Type) und Effekte (Item\_Effect).
Auch ist der Spieler (Player) immer in einer Region (Region), in der Gegenstände (Item) und Gegner (Enemy) aufzufinden sind.

Das Modell dient in den folgenden Kapiteln als Grundlage für die Modellierung und den Vergleich.

\begin{figure}[h]
    \centering
    \includegraphics[width=0.6\textwidth]{assets/er-modell}
    \caption{Konzeptionelles ER-Modell}
    \label{fig:er-modell}
\end{figure}
\newpage


\subsection{Key-Value-Modellierung}
Key-Value Datenbanken sind eine einfache und schnelle Lösung für die Speicherung von unstrukturierten Daten.
Wir verwenden in diesem Kapitel Redis.

\subsubsection*{Schlüsselaufbau}
Keys sind Strings, die eindeutig zum identifizieren von Objekten verwendet werden. Diese starten immer mit dem Namen der Entität, gefolgt von einem Doppelpunkt und der ID des Objekts.
Dabei werden alle Entitäten als Redis-Datentyp Hash Map gespeichert um die Daten effizient zu verwalten.

Anhand dieses Systems bilden wir die Schlüssel wie folgt ab:

% \paragraph{player}
% player:{id} = { id, name, health, stamina, focus\_points, level, experience, region\_id}
% player:{id}:weapon = { item\_id }
% player:{id}:shield = { item\_id }
% player:{id}:armor = { item:1, item:2, ... }
% player:{id}:talisman = { item:1, item:2, ... }

% player:1 = { 1, Jonas, 100, 100, 10, 1, 0, 1 }

% \paragraph{region}
% region:{id} = { id, name}
% region:{id}:items = { item:1, item:2, ... }
% region:{id}:enemies = { enemy:1, enemy:2, ... }

% region:1 = { 1, limgrave }
% region:1:items = [1, 19, 248, 2385]
% region:1:enemies = [1, 245, 1234, 11211]

% \paragraph{item}
% item:{id} = { id, name, gear\_type, gear\_id, region\_id }
% item:82347 = { 82347, coolestalisman, talisman, 1, 1 }

% item\_effect:{id} = { id, description }
% item\_effect:1 = { 1, Du hast mehr Ausdauer }

% talisman:{id} = { id, item\_effect\_id }
% armor:{id} = { id, item\_effect\_id, type\_id, weight, physical\_defense, magical\_defense}
% weapon:{id} = { id, item\_effect\_id, type\_id, weight, damage }
% shield:{id} = { id , item\_effect\_id , type\_id, weight, physical\_defense, magical\_defense, guard, damage }

% type:{id} = { id, name }
% type:1 = { 1, Dolch }

% \paragraph{enemy}
% enemy:{id} ={id, region\_id, name, health, level, damage}
% enemy:{id}:items = { :1, item:2, ... } % dropt diese items

% enemy:1 =  { 1, 1, Tree\_Sentinel, 30000, 20, 70 }
% enemy:1:items = [5, 10]

\begin{table}[h]
\centering
\begin{tabular}{l l l}
\hline
\textbf{Datentyp} & \textbf{Key-Struktur} & \textbf{Attribute} \\ \hline
\texttt{HMAP} & {item\_effect:\{id\}} & id, name, value \\
\texttt{HMAP} & {item\_type:\{id\}} & id, item\_id, name \\
\\
\texttt{HMAP} & {weapon:\{id\}} & id, item\_effect\_id, item\_type\_id, weight, damage \\
\texttt{HMAP} & {armor:\{id\}} & id, item\_effect\_id, item\_type\_id, weight, defense \\
\texttt{HMAP} & {shield:\{id\}} & id, item\_effect\_id, item\_type\_id, weight, damage, defense \\
\texttt{HMAP} & {talisman:\{id\}} & id, item\_effect\_id \\
\\
\texttt{HMAP} & {item:\{id\}} &  id, name, gear\_type, gear\_id, region\_id \\
\\
\texttt{HMAP} & player:\{id\} & id, name, health, stamina, level, region\_id \\
\texttt{SET} & {player:\{id\}:weapon} & item\_id \\
\texttt{STRING} & {player:\{id\}:shield} & item\_id \\
\texttt{SET} & {player:\{id\}:armor} & item\_id \\
\texttt{SET} & {player:\{id\}:talisman} & item\_id \\
\\
\texttt{HMAP} & {region:\{id\}} & id, name \\
\texttt{SET} & {region:\{id\}:items} & item\_id \\
\texttt{SET} & {region:\{id\}:enemies} & enemy\_id \\
\\
\texttt{HMAP} & enemy:\{id\} & id, name, health, level, damage \\
\texttt{SET} & enemy:\{id\}:items & item\_id \\
\texttt{SET} & enemy:\{id\}:item\_effects & item\_effect\_id \\
\hline
\end{tabular}
\caption{Übersicht der Schlüsselstrukturen in Redis}
\end{table}
\newpage

% \begin{table}[h]
% \centering
% \begin{tabular}{l l l}
% \hline
% \textbf{Datentyp} & \textbf{Key-Struktur} & \textbf{Beschreibung} \\ \hline
% SET & \texttt{player:\{id\}:gear\_list} & Liste der Gear IDs, die einem Spieler zugeordnet sind \\
% \hline
% \end{tabular}
% \caption{Übersicht der Schlüsselstrukturen in Redis}
% \end{table}

\subsection{Dokumentenorientierte Modellierung}
% Wie sieht das in z. B. MongoDB aus? Zeigt hier ein fiktives JSON-Dokument, das einen Gegner oder Spieler mit all seinen verschachtelten Eigenschaften beschreibt.
\newpage

\subsection{Graph-Datenbank-Modellierung}
% Wie sieht das in z. B. Neo4j aus? Beschreibt (oder zeichnet), wie Knoten (Player, Region) und Kanten (has_equipped, is_in) die Beziehungen darstellen.

% Wir müssen erst die datenmodellieren
% Habe bereits ein Projekt, lass das nehmen zum vergleichen nachher
% - Redis
% - MonogoDb
% - MariaDB
\newpage

\section{Vergleich der Datenmodellierung}
\subsection{Vor- und Nachteile des Key-Value-Modells}
% Vorteil: Extrem schnell für euer Live-Streaming (Lese-/Schreibzugriffe). Nachteil: Komplexe Abfragen (z.B. "Zeige mir alle Waffen mit Stärke > 20") sind schwierig.

\subsection{Vor- und Nachteile des dokumentenorientierten Modells}
% Vorteil: Alles zu einem Spieler ist in einem JSON-Dokument gebündelt. Nachteil: Redundanzen, wenn z.B. Spieldaten wie "Waffen-Typen" bei jedem Spieler gespeichert werden.

\subsection{Vor- und Nachteile des Graph-Modells}
% Vorteil: Genial, um Beziehungen abzufragen (z.B. Welcher Spieler trägt welches Item, das von welchem Boss droppt?). Nachteil: Für pures Live-Streaming von Koordinaten eher überdimensioniert.
% Siehe Dokumenatation der Datenmodellierung
\newpage

% \section{Bau der app bis zur Endpräsi}
\newpage

\section{Fazit}
% Mehr coole sachen die wir gelernt haben.
% Warum wir uns fuer dieses Datenbankmodell entschieden haben.

\end{document}