Newer
Older
\documentclass[fontsize=12pt,paper=a4,twoside]{scrartcl}
\usepackage{graphicx}
\usepackage{rotating}
\usepackage{pdflscape}
\usepackage[normalem]{ulem}
\useunder{\uline}{\ul}{}
\input{swp-preamble.tex}
%
% Und jetzt geht das Dokument los....
%
\begin{document}
\newcommand\documentTitle{Architekturbeschreibung}
\swpdocument{Karsten Hölscher}{31. Mai 2020}{1.0}%
{Fabian Kehlenbeck & fkehlenb@tzi.de}%
{Leonard Haddad & s\_xsipo6@tzi.de}%
{Luca Nittscher & lnittsch@tzi.de}%
{Rasmus Burwitz & rburwitz@tzi.de}%
{Samuel Nejati Masouleh & samnej@tzi.de}%
{Aaron Rudkowski & rudkowsk@tzi.de}%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section*{Version und Änderungsgeschichte}
{\em Die aktuelle Versionsnummer des Dokumentes sollte eindeutig und gut zu
identifizieren sein, hier und optimalerweise auf dem Titelblatt.}
\begin{tabular}{ccl}
Version & Datum & Änderungen \\
\hline
0.1 & 10.05.2020 & Dokumentvorlage als initiale Fassung kopiert \\
0.2 & 10.05.2020 & Einflussfaktoren \& Problemkarten \\
0.3 & 14.05.2020 & Entwürfe für Modulsicht und Datenmodell\\
0.4 & 22.05.2020 & Evolution\\
0.5 & 23.05.2020 & Konzeptionelle Sicht fertiggestellt\\
0.6 & 26.05.2020 & Codegerüst halbfertig, Problemkarten / Strategien fertiggestellt\\
0.7 & 28.05.2020 & Datenmodell fertiggestellt\\
0.8 & 29.05.2020 & Modulsicht, Ausführungssicht fertiggestellt\\
0.9 & 29.05.2020 & Codegerüst fertiggestellt, sowie JavaDoc\\
\ldots\\ 0.95 & 30.05.2020 &(Optimierung/Fehlerkorrektur)\\ \ldots\\
\end{tabular}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Einführung}
Im Rahmen von Re-Softwareprojekt 2 im Sommersemester 2020 wurde diese Architekturbeschreibung für die Software Galaxytrucker geschrieben.
Es handelt sich bei der Software um ein rundenbasiertes Spiel im Weltraum- und Science-Fiction-Kontext, in welchem der Spieler sein eigenes Schiff bekommt und hiermit ein zufällig generiertes Sternensystem erkundet. Zwischendurch wird der Spieler auf viele verschiedene Ereignisse in der Spielwelt stoßen.
Das Spiel ist sowohl im Singleplayer als auch im Multiplayer spielbar.\\
Im Einzelspielermodus soll ein Spieler mit einem Raumschiff starten, von Planet zu Planet fliegen, gegen computergesteuerte Raumschiffe kämpfen oder zufällige Ereignisse absolvieren, um sich auszurüsten. Das Ziel des Einzelspielermodus ist, dass man den Endboss besiegt und so das Spiel gewinnt. \\
Des weiteren gibt es noch einen Mehrspielermodus, in welchem beide Spieler mit jeweils einem Schiff auf die Karte kommen. Dort müssen sie sich wie im Einzelspielermodus erstmal ausrüsten. Das Ziel des Spieles ist, wie im Einzelspielermodus, den Endboss zu besiegen. Die beiden Spieler können, wenn sie sich auf dem gleichen Planeten befinden, sich angreifen. Der Gewinner dieses Kampfes bekommt eine Belohnung, der Verlierer bekommt einen Nachteil.
Zusammenfassend kann man sagen, dass die Software folgende Eigenschaften mitbringt:
\begin{itemize}
\item{Rundenbasiertes Weltraumspiel mit Raumschiffen}
\item{Einzelspielermodus mit computergesteuerten Gegnern}
\item{Mehrspielermodus mit computergesteuerten Gegnern und einem zweiten gegnerischen Spieler}
\item{Zufällige Gegner oder Ereignisse an verschiedenen Orten}
\item{Zufällig generierte Karten (Spielfelder)}
\end{itemize}
Die Architekturbeschreibung zeigt den Architekturentwurf, den wir uns für das Spiel GalaxyTrucker überlegt haben. Sie dient dazu, allen Benutzern und Bearbeitern der Software die Funktionsweise und die Struktur nahezubringen. Entwickler und Tester sollen eine Übersicht über die Funktionsweise der Software erhalten, sodass sie auf Basis dieses Dokuments die Software implementieren können, bzw. testen können.
Leser dieser Architekturbeschreibung sind Host der Spiele, interessierte Spieler, die die Software vielleicht um Mods erweitern wollen, Entwickler und alle im Rahmen beteiligten von Re-Softwareprojekt 2.
Dieser Architekturentwurf beschreibt den ersten Entwurf der Software. Er wurde noch nicht durch das Architekturreview freigegeben.
\subsection{Definitionen, Akronyme und Abkürzungen}
\textbf{Begriffe in der Software:}
\begin{center}
\begin{tabular}{|p{3cm}|p{12cm}|}
Planet & Mit Planet ist der Planet inklusive dem umgebenen Raumsektor gemeint. \\ \hline
Raumschiff, Schiff, Ship & Raumschiff, mit welchem Spieler oder Computergesteuerte spielen. \\ \hline
Sektionen des Raumschiffes & Verschiedene Räume in einem Raumschiff. Kann Systeme enthalten, kann Crew enthalten\\ \hline
System & Relevante Systeme, die ein Raumschiff braucht, um zu spielen, z.B. Waffensystem, Sauerstoff, Antrieb \\ \hline
Crew, Besatzung & Lebewesen, die das Schiff steuern, kämpfen oder sterben können. Auf einem Raumschiff können begrenzt viele Crewmitglieder Platz finden. Können verschiedene Spezialfähigkeiten haben, Verschiedene Fähigkeiten können verbessert werden. \\ \hline
Ressourcen & Energie, Geld, Antriebsenergie, Raketen \\ \hline
Endgegner, Endboss & Sehr starker Gegner am ende des Spiels. Kampf gegen diesen entscheidet über Gewinnen oder Verlieren des Spiels \\ \hline
NPC & Computergesteuerter Gegner.\\ \hline
Antrieb & System, mit welchem Spieler*innen sich bewegen können. Wenn zerstört, ist kein Reisen mehr möglich\\ \hline
Schutzschild & Energieschild, welches mithilfe eines Systems ausgerüstet werden kann. Wehrt \\ \hline
\textbf{Technische Begriffe:}
\begin{center}
\begin{tabular}{|p{3cm}|p{12cm}|}
H2 & Eine SQL Java Datenbank, die auch die JDBC API unterstützt. \\ \hline
Einflussfaktoren & Faktoren, die das Endprodukt beeinflussen können. \\ \hline
Java & Objektorientierte, klassenbasierte Programmiersprache. Läuft auf so gut wie allen gängigen Plattformen, die eine Java Virtual Maschine haben.\\ \hline
LibGDX & Kostenloses, Open-source Spielentwickluungsframework, welches in Java geschrieben ist\\ \hline
Server & Kann von einem der Spieler gehostet werden, bietet die Grundlage für das Spiel. Ohne Server $\rightarrow$ kein Spiel \\ \hline
Client & Der Part, den der Spieler bei sich auf dem Gerät installiert. Beinhaltet Grafiken, Spielmechanik etc. \\ \hline
JUnit & Unit Testing Framework für Java. Zum Testen auf Fehler in der Software.\\ \hline
DAO & Objekte, die Daten aus der Datenbank verwalten.(Data Access Object)\\ \hline
SQLite & Eine SQL Datenbank. \\ \hline
Derby & Eine Datenbank.\\ \hline
Modularisierung & Das Projekt wird in Module aufgeteilt, die unabhängig voneinander implementiert werden können. \\ \hline
Monolitisierung & Das Gesamte Projekt wird nicht aufgeteilt, sodass alles funktionieren muss, bis man etwas testen kann. (Keine unterschiedlichen Klassen usw.)\\ \hline
Persistence & Stellt die Verbindung zwischen System und der Datenbank her. Alle Daten aus oder zur Datenbank fließen durch die Persistence.\\ \hline
Controller & In Controller befindet sich die Spiellogik. Außerdem bekommt die View alle Daten über den Controller, die angezeigt werden müssen.\\ \hline
UML & Sprache zum Beschreiben eines Programms in verschiedenen Diagrammen. (Unified Modeling Language)\\ \hline
TiledMaps & ist ein Framework von LibGDX, um Karten ins Spiel zu implementieren. \\ \hline
\begin{itemize}
\item{Architekturbeschreibung von RainerRaiders im Rahmen des Softwareprojekts 2 - 2016}
\item{Architekturbeschreibung von DataColorado im Rahmen des Softwareprojekts 2 - WiSe 2019/2020}
\item{Kickoff Folien (Stand 21.04.2020)}
\end{itemize}
Zunächst zeigen wir in Kapitel 2 die verschiedenen Einflussfaktoren auf die Entwicklung und die Probleme und Strategien zum Lösen der Probleme. In den Kapiteln 3, 4 und 6 werden die Sichten von Hofmeister gezeigt. Bei uns wird die Codesicht nicht behandelt. In Kapitel 3 wird die Konzeptionelle Sicht unserer Software dargestellt, in Kapitel 4 die Modulsicht und in Kapitel 6 die Ausführungssicht. Kapitel 5 stellt das Modell der Datensicht dar, eine nähere Beschreibung der Architektursicht. In Kapitel 7 werden einige Anwendungsfälle dargestellt. Abschließend stellen wir in Kapitel 8 Ideen für zukünftige Weiterentwicklungen unserer Software dar.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Globale Analyse} \label{sec:globale_analyse}
%{\itshape Hier werden Einflussfaktoren aufgezählt und bewertet sowie Strategien
%zum Umgang mit interferierenden Einflussfaktoren entwickelt.}
%\subsection{Einflussfaktoren} \label{sec:einflussfaktoren}
%{\itshape Hier sind Einflussfaktoren gefragt, die sich auf die Architektur
%beziehen. Es sind ausschließlich architekturrelevante Einflussfaktoren, und
%nicht z.\,B.\ solche, die lediglich einen Einfluss auf das Projektmanagement
%haben. Fragt Euch also bei jedem Faktor: Beeinflusst er wirklich die
%Architektur? Macht einen einfachen Test: Wie würde die Architektur aussehen,
%wenn ihr den Einflussfaktor $E$ berücksichtigt? Wie würde sie aussehen, wenn Ihr
%$E$ nicht berücksichtigt? Kommt in beiden Fällen dieselbe Architektur heraus,
%dann kann der Einflussfaktor nicht architekturrelevant sein.
%Es geht hier um Einflussfaktoren, die
%\begin{enumerate}
% \item sich über die Zeit ändern,
% \item viele Komponenten betreffen,
% \item schwer zu erfüllen sind oder
% \item mit denen man wenig Erfahrung hat.
%\end{enumerate}
%Die Flexibilität und Veränderlichkeit müssen ebenfalls charakterisiert werden.
%\begin{enumerate}
% \item Flexibilität: Könnt Ihr den Faktor zum jetzigen Zeitpunkt beeinflussen?
% \item Veränderlichkeit: ändert der Faktor sich später durch äußere Einflüsse?
%\end{enumerate}
%Unter Auswirkungen sollte dann beschrieben werden, \emph{wie} der Faktor
%\emph{was} beeinflusst. Das können sein:
%\begin{itemize}
% \item andere Faktoren
% \item Komponenten
% \item Operationsmodi
% \item Designentscheidungen (Strategien)
%\end{itemize}
%Verwendet eine eindeutige Nummerierung der Faktoren, um sie auf den
%Problemkarten einfach referenzieren zu können.}
\begin{longtable}[c]{|p{5cm}|p{5cm}|p{5cm}|}
\hline
\multicolumn{1}{|c|}{\textbf{Einflussfaktor}} & \multicolumn{1}{c|}{\textbf{Veränderlichkeit/Flexibilität}} & \multicolumn{1}{c|}{\textbf{Auswirkungen}} \\ \hline
\endhead
%ORGANISATION
\multicolumn{3}{|l|}{{\textbf{O1: Organisation}}}
\\ \hline
\multicolumn{3}{|l|}{{O1.1: Teamgröße}}
\\ \hline
Die Gruppe besteht aus 6 Entwicklern. & Keine Flexibilität, aber Veränderlichkeit: Eine oder mehrere Personen könnten die Gruppe verlassen & Die Architektur kann wegen Zeitmangel und fehlenden Fähigkeiten Mängel enthalten.
\\ \hline
\multicolumn{3}{|l|}{{O1.2: Architekturabgabe}}
\\ \hline
Die Architektur soll am 31.05.2020 abgegeben werden. & Keine Flexibilität, oder Veränderlichkeit. & Eventuell gibt es Mängel in der Architektur, die uns erst in der Implementierung auffallen.
\\ \hline
\multicolumn{3}{|l|}{{O1.3: Endabgabe}}
\\ \hline
Das Endprodukt muss am 02.08.2020 abgegeben werden. & Keine Flexibilität, oder Veränderlichkeit. & Eventuell können nicht alle geplanten Funktionen implementiert werden.
\\ \hline
\multicolumn{3}{|l|}{{O1.4: Fähigkeiten}}
\\ \hline
Die Gruppenmitglieder haben unterschiedliche Programmiererfahrungen und Kentnisse. & Keine Flexibilität, aber Veränderlichkeit: Neues Wissen kann sich angeeignet werden. & Die Implementierung kann Mängel enthalten.
\\ \hline
%TECHNIK
\multicolumn{3}{|l|}{{\textbf{T1: Technik}}}
\\ \hline
\multicolumn{3}{|l|}{{T1.1: Sprache}}
\\ \hline
Es soll Java 8 oder höher verwendet werden. & Eine gewisse Flexiblität und Veränderlichkeit in der Java Version, allerdings keine in der Sprache an sich. & Das Projekt muss in Java umgesetzt werden.
\\ \hline
\multicolumn{3}{|l|}{{T1.2: Plattformen}}
\\ \hline
Das Spiel soll unter Linux, MacOS und Windows lauffähig sein & Keine Veränderlichkeit oder Flexiblität & Bei der Implementierung muss darauf geachtet werden, plattformunabhängig vorzugehen.
\\ \hline
\multicolumn{3}{|l|}{{T1.3: Datenbank}}
\\ \hline
Es soll eine leichtgewichtige, relationale Datenbank verwendet werden. & Große Flexibilität und Veränderlichkeit: Da es keine festen Vorgaben gibt, ist die Datenbank relativ frei wählbar. Allerdings muss eine Datenbank verwendet werden. & Wir müssen uns für eine Datenbank entscheiden, und diese bei der Implementierung verwenden.
\multicolumn{3}{|l|}{{T1.4: LibGDX}}
Es soll LibGDX verwendet werden. & Keine Veränderlichkeit oder Flexibilität. & Bei der Implementierung muss LibGDX verwendet werden.
\\ \hline
\multicolumn{3}{|l|}{{T1.5: Client}}
\\ \hline
Das Spiel soll ohne weitere Installationen auf Clientseite spielbar sein. & Keine Flexibilität, oder Veränderlichkeit. & Bei der Implementierung muss darauf geachtet werden, keine Abhängigkeiten von Dingen zu haben, die auf Clientseite weitere Downloads erfordern.
\multicolumn{3}{|l|}{{T1.6: Server}}
\\ \hline
Es soll einen Spielserver geben, der von mindestens zwei Spieler*innen benutzt werden kann. & Keine Flexibilität, oder Veränderlichkeit. & Wir müssen einen Spielserver einrichten, der das Spiel kontrolliert.
%PRODUKT
\multicolumn{3}{|l|}{{\textbf{Produktfaktoren}}}
\\ \hline
%
\multicolumn{3}{|l|}{{\textbf{P1: Sektionen}}}
\\ \hline
\multicolumn{3}{|l|}{{P1.1: Sektionen}}
\\ \hline
Das Raumschiff soll in unterschiedliche Sektionen unterteilt sein. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss vorsehen, dass ein Raumschiff eine Ansammlung an Sektionen ist.
\\ \hline
\multicolumn{3}{|l|}{{P1.2: Systeme}}
\\ \hline
Jede Sektion soll relevante Systeme haben. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss unterschiedlichen Sektionen die relevanten Systeme zuordnen.
\\ \hline
\multicolumn{3}{|l|}{{P1.3: Beschädigungen}}
\\ \hline
Sektionen sollen im Kampf beschädigt werden können. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss vorsehen, dass die Sektionen unabhängig voneinander beschädigt werden können. Ebenfalls muss für jede Sektion gespeichert und angezeigt werden, wie heile/kaputt sie ist.
\\ \hline
\multicolumn{3}{|l|}{{P1.4: Systembeschädigungen}}
\\ \hline
Wenn eine Sektion beschädigt ist, soll dies auch die enthaltenen Systeme beeinflussen. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss vorsehen, dass für jedes System der Status gespeichert wird.
\\ \hline
%
\multicolumn{3}{|l|}{{\textbf{P2: Ressourcen}}}
\\ \hline
\multicolumn{3}{|l|}{{P2.1: Ressourcen}}
\\ \hline
Das Raumschiff soll verschieden Ressourcen haben, wie Geld, Energie, Status Außenhülle. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss für das Raumschiff übergeordnete Ressourcen speichern.
\\ \hline
\multicolumn{3}{|l|}{{P2.2: Ressourcenveränderlichkeit}}
\\ \hline
Ressourcen sollen veränderlich sein. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss vorsehen, dass die Eigenschaften nicht konstant sind, und durch Methoden auf die Werte einfluss genommen werden kann.
\\ \hline
\multicolumn{3}{|l|}{{P2.3: Ressourcenverfügung}}
\\ \hline
Ressourcen sollen pro Spielrunde zur Verfügung stehen. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss vorsehen, dass der Spieler in jeder Runde Zugriff auf die Ressourcen hat und diese beeinflussen kann.
\\ \hline
%
\multicolumn{3}{|l|}{{\textbf{P3: Eigenschaften}}}
\\ \hline
\multicolumn{3}{|l|}{{P3.1: Eigenschaften}}
\\ \hline
Ein Raumschiff soll verschiedene Eigenschaften haben, wie Waffen, Schutzschilde, Hüllenpanzerungen, und Energie. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss für das Raumschiff übergeordnete Eigenschaften vorsehen, die für alle Sektionen gelten.
\\ \hline
\multicolumn{3}{|l|}{{P3.2: Waffen}}
\\ \hline
Es sollen mehrere Waffen pro Raumschiff möglich sein. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss vorsehen, dass für ein Raumschiff mehrere Waffen gespeichert und eingesetzt werden können, die Spieler*in muss also auch die Waffe auswählen, mit der sie schießen möchte.
\\ \hline
\multicolumn{3}{|l|}{{P3.3: Waffenunterschiede}}
\\ \hline
Unterschiedliche Waffen sollen sich mindestens in Ladezeit, Trefferwahrscheinlichkeit und Schadenshöhe unterscheiden. & Keine Flexibilität, oder Veränderlichkeit. & In der Architektur muss vorgesehen sein, dass mindestens diese Werte keine Konstanten sind, und das Spiel muss damit umgehen können, in diesen Attributen unterschiedliche Werte zu haben.
\\ \hline
\multicolumn{3}{|l|}{{P3.4: Verbesserung von Eigenschaften}}
\\ \hline
Eigenschaften sollen durch Geld verbessert werden können. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss vorsehen, dass die Eigenschaften veränderlich sein sollen. Ebenfalls muss es Möglichkeiten geben, bei denen der Spieler Geld durch Verbesserungen austauschen kann.
\\ \hline
%
\multicolumn{3}{|l|}{{\textbf{P4: Besatzung}}}
\\ \hline
\multicolumn{3}{|l|}{{P4.1: Besatzung}}
\\ \hline
Das Raumschiff soll eine Besatzung haben. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss vorsehen, dass für ein Raumschiff gespeichert wird, welche Besatzungsmitglieder an Bord sind.
\\ \hline
\multicolumn{3}{|l|}{{P4.2: Aufenthaltsorte Besatzung}}
\\ \hline
Die Besatzungsmitglieder sollen sich in Sektionen aufhalten können. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss vorsehen, dass gespeichert wird, in welcher Sektion sich welches Mitglied aufhält.
\\ \hline
\multicolumn{3}{|l|}{{P4.3: Besatzung und Systeme}}
\\ \hline
Die Systeme einer Sektion sollen durch die Besatzungsmitglieder beeinflusst werden können, zum Beispiel sollen Systeme/Sektionen durch die Besatzung repariert werden können. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss vorsehen, dass die Besatzung mit den Sektionen interagieren kann, entweder automatisch durch ihren Aufenthalt, oder durch explizite Kommandos des Spielers.
\\ \hline
\multicolumn{3}{|l|}{{P4.4: Tod}}
\\ \hline
Besatzungsmitglieder sollen sterben können. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss vorsehen, dass Besatzungsmitglieder einen Gesundheitsstatus haben, der sinken kann. Ebenfalls sollten Mitgleider entweder gelöscht oder inaktiviert werden, sobald sie sterben.
\\ \hline
\multicolumn{3}{|l|}{{P4.5: Neue Besatzungsmitglieder}}
\\ \hline
Neue Besatzungsmitglieder sollen auf das Schiff aufgenommen werden können. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss vorsehen, dass die Besatzung nicht konstant ist.
\\ \hline
\multicolumn{3}{|l|}{{P4.6: Besatzungsmitglieder Fähigkeiten}}
\\ \hline
Besatzungsmitglieder sollen Fähigkeiten haben. Diese sollen sich auf Systeme auswirken, falls sich das Mitglied in der entsprechenden Sektion befindet. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss für die Besatzungsmitglieder ihre Fähigkeiten speichern, und, in welchen Sektionen sich diese auswirken. Ebenfalls muss automatisch geprüft werden, ob ein Besatzunsmitglied in der Sektion, in der es sich aktuell befindet, eine Auswirkung hat.
\\ \hline
\multicolumn{3}{|l|}{{P4.7: Verbesserung Fähigkeiten}}
\\ \hline
Die Fähigkeiten der Besatzungsmitglieder sollen verbessert werden können. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss vorsehen, dass die gespeicherten Fähigkeiten nicht konstant sind. Es muss eine Möglichkeit geben für den Spieler, Verbesserungen auszuwählen (z.B. zu kaufen).
\\ \hline
%
\multicolumn{3}{|l|}{{\textbf{P5: Spielfeld}}}
\\ \hline
\multicolumn{3}{|l|}{{P5.1: Spielfeld}}
\\ \hline
Es soll ein Spielfeld geben, was eine Karte darstellt. Die Karte verzeichent Stationen/Planeten. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss die möglichen Orte sowie ihre Verbindungen effizient speichern. Es muss ebenfalls immer der relevante Ausschnitt der Karte angezeigt werden.
\\ \hline
\multicolumn{3}{|l|}{{P5.2: Reise}}
\\ \hline
Pro Spielrunde kann eine Station/ein Planet laut den Verbindungen auf der Karte angeflogen werden. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss vorsehen, dass der Spieler Eingaben machen kann, zu welchem Gebiet geflogen werden soll. Ebenfalls müssen diese Eingaben überprüft werden (geht dieser Zug mit den existierenden Verbindungen).
\\ \hline
\multicolumn{3}{|l|}{{P5.3: Ereignisse}}
\\ \hline
Auf jeder Station/auf jedem Planet soll ein Ereignis auftreten können, was positive oder negative Auswirkungen haben kann; zum Beispiel der Angriff eines feindlichen Schiffes. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss vorsehen, dass mögliche Ereignisse für jeden Ort gespeichert und mit einer gewissen Wahrscheinlichkeit ausgelöst werden.
\\ \hline
\multicolumn{3}{|l|}{{P5.4: Mehrere Ereignisse}}
\\ \hline
Es soll mindestens fünf unterschiedliche Arten von Ereignissen geben. & Keine Flexibilität, oder Veränderlichkeit. & Das Spiel muss möglichst unkompliziert unterschiedliche Ereignisse auslösen und durchführen können.
\\ \hline
%
\multicolumn{3}{|l|}{{\textbf{P6: Kämpfe}}}
\\ \hline
\multicolumn{3}{|l|}{{P6.1: Kämpfe}}
\\ \hline
Es sollen Kämpfe zwischen dem Spieler und feindlichen Raumschiffen möglich sind. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss vorsehen, dass es abgesehen von Flugrunden auch Kampfrunden gibt, in denen es andere Aktionen gibt.
\\ \hline
\multicolumn{3}{|l|}{{P6.2: Kampfart}}
\\ \hline
Die Kämpfe sollen in Form von rundenbasierten Entscheidungen gefochten werden. & Keine Flexibilität, oder Veränderlichkeit. & Es muss vorgesehen sein, dass der Spieler und der Gegner sich abwechseln, und der Spieler nicht Aktionen durchführen kann, wenn der Gegner dran ist.
\\ \hline
\multicolumn{3}{|l|}{{P6.3: Kampfhandlungen}}
\\ \hline
Es sollen folgende Kampfhandlungen möglich sein: Abfeuern einer Waffe auf das gegnerische Schiff, Verteilung der Besatzung auf die Sektionen, und Zuweisung von Energie an Sektionen. & Keine Flexibilität, oder Veränderlichkeit. & In den Kampfrunden dürfen nur diese Handlungen zur Verfügung stehen.
\\ \hline
\multicolumn{3}{|l|}{{P6.4: Zeit}}
\\ \hline
Kampfhandlungen brauchen Zeit: Waffen müssen laden und Besatzungsmitglieder sind nicht sofort in der Zielsektion. & Keine Flexibilität, oder Veränderlichkeit. & Während den Kampfrunden muss beachtet werden, dass nicht alle Handlungen immer zur Verfügung stehen.
\\ \hline
%
\multicolumn{3}{|l|}{{\textbf{P7: Spielverlauf}}}
\\ \hline
\multicolumn{3}{|l|}{{P7.1: Spielverlauf}}
\\ \hline
Es soll einen klaren Spielverlauf mit einer Endgegner*in un der Möglichkeit, durch Besiegung dieser zu gewinnen, geben. & Keine Flexibilität, oder Veränderlichkeit. & Es muss eine übergeordnete Entität geben, die diesen Spielverlauf über Planeten hinweg kontrolliert.
\\ \hline
\multicolumn{3}{|l|}{{P7.2: Schwierigkeit}}
\\ \hline
Es sollen unterschiedliche Schwierigkeitsstufen für ein Spiel auswählbar sein. & Keine Flexibilität, oder Veränderlichkeit. & Es muss möglichst unkomplex Veränderungen geben, die das Spiel leichter/schwerer machen.
\\ \hline
%
\multicolumn{3}{|l|}{{\textbf{P8: Server}}}
\\ \hline
\multicolumn{3}{|l|}{{P8.1: Direkter Kampf zweier Spieler}}
Es sollen, wenn möglich, zwei Spieler gegeneinander spielen. Diese beiden sollen auch in direkten Kämpfen gegeneinander antreten können. & Keine Flexibilität, oder Veränderlichkeit. & In der Multiplayer Spielführung müssen die Spieler früher oder später zu Interaktionen gezwungen sein.
Wenn kein zweiter Spieler online ist, soll der Gegner durch den Computer simuliert werden. & Keine Flexibilität, oder Veränderlichkeit. & Die Architektur muss Computergegner vorsehen, die gegen den Spieler spielen können.
\multicolumn{3}{|l|}{{P8.3: Prüfung vom Server}}
Der Server soll die Einhaltung von Regeln und Plausibilität während dem Spiel prüfen. & Keine Flexibilität, oder Veränderlichkeit. & Im Server muss es etwas geben, was alle Züge prüft. Es ist wichtig, dass keine Züge ausgeführt werden, ohne dass diese verifiziert wurden.
\multicolumn{3}{|l|}{{P8.4: Speicherung Spielverlauf}}
Der Server soll den Spielverlauf speichern. & Keine Flexibilität, oder Veränderlichkeit. & Es muss nach jeder Änderung in irgendeiner Form alles so gespeichert werden, dass der Spielverlauf nachvollziehbar ist.
\multicolumn{3}{|l|}{{P8.5: Spielverlauf unterbrechen und fortsetzen}}
Es soll möglich sein, den Spielverlauf zu unterbrechen und zu einem späteren Zeitpunkt fortzuführen. & Keine Flexibilität, oder Veränderlichkeit. & Es muss eine Möglichkeit geben, speichern auszuwählen, sowie, bei Spielbeginn ein existierendes Spiel auszuwählen und fortzusetzen.
\subsection{Probleme und Strategien} \label{sec:strategien}
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
%{\itshape Aus einer Menge von Faktoren ergeben sich Probleme, die nun in Form
%von Problemkarten beschrieben werden. Diese resultieren z.\,B.\ aus
%\begin{itemize}
% \item Grenzen oder Einschränkungen durch Faktoren
% \item der Notwendigkeit, die Auswirkung eines Faktors zu begrenzen
% \item der Schwierigkeit, einen Produktfaktor zu erfüllen, oder
% \item der Notwendigkeit einer allgemeinen Lösung zu globalen Anforderungen.
%\end{itemize}
%Dazu entwickelt Ihr Strategien, um mit den identifizierten Problemen umzugehen.
%Achtet auch hier darauf, dass die Probleme und Strategien wirklich die
%Architektur betreffen und nicht etwa das Projektmanagement. Die Strategien
%stellen im Prinzip die Designentscheidungen dar. Sie sollten also die Erklärung
%für den konkreten Aufbau der verschiedenen Sichten liefern.
%Beschreibt möglichst mehrere Alternativen und gebt an, für welche Ihr Euch
%letztlich aus welchem Grunde entschieden habt. Natürlich müssen die genannten
%Strategien in den folgenden Sichten auch tatsächlich umgesetzt werden!
%Ein sehr häufiger Fehler ist es, dass SWP-Gruppen arbeitsteilig vorgehen: die
%eine Gruppe schreibt das Kapitel zur Analyse von Faktoren und zu den Strategien,
%die andere Gruppe beschreibt die diversen Sichten, ohne dass diese beiden
%Gruppen sich abstimmen. Natürlich besteht aber ein Zusammenhang zwischen den
%Faktoren, Strategien und Sichten. Dieser muss erkennbar sein, indem sich die
%verschiedenen Kapitel eindeutig aufeinander beziehen.}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
Da es Ansprüche an die Schwierigkeit gibt, müssen die Waffen von der Stärke her vergleichbar sein. \\
P1 \\
P2 \\
P3 \\
P4.3 - P4.7 \\
P5.3 \\
P6.2 \\
P6.3 \\
P7.2 \\
P8.1 \\
P8.2 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:1.1}
\textbf{Strategie 1.1: Basiswaffen} Es gibt eine Reihe an Basiswaffen, die sukzessive verbessert werden können. Durch die Verbesserungen können verschiedene Arten Bonusschaden gegen Sektionen des Schiffes oder gegen die Crew des Gegners hinzugefügt werden. Das Balencing erfolgt da durch, dass sich der Spieler für eine Art Bonusschaden pro Waffensystem entscheiden muss und die Option auf alle anderen Arten Bonusschaden durch das Upgrade in einer bestimmten Schadensklasse entfällt. \\
\textbf{Strategie 1.2: Manuelles Balancing (ausgewählt)} Das Balancing wird aktiv durch die Entwickler in der Testphase durchgeführt. ist ein bestimmtes Waffensystem o.Ä. im Spielbetrieb zu stark, wird es abgeschwächt, ist es zu schwach, wird es verbessert. \\
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 2:} LibGDX \\ \hline
Die Gruppenmitglieder haben wenig bis keine Erfahrung mit LibGDX, was eine benötigte Anforderung ist. \\
\\ \hline
\textbf{Einflussfaktoren: } \\
T2.1 \\
T2.2 \\
O1.2 \\
O1.3 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:2.1}
\textbf{Strategie 2.1: Anlernen (ausgewählt)} Die Gruppenmitglieder müssen sich so früh wie möglich mit der Verwendung von LibGDX vertraut machen, damit dies idealerweise auch schon in die Architektur mit einfließen kann. \\
{\phantomsection}
\label{strategie:2.2}
\textbf{Strategie 2.1: Experten} Es gibt einen oder zwei Experten für das Framework, diese übernehmen alle Aufgaben in der Entwicklung, die Kenntnisse des Frameworks voraussetzen.\\
\\ \hline
\end{tabular}
\caption{LibGDX Problemkarte}
\label{tab:ProblemKarte2}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 3: Spielstand} \\ \hline
Der Spielstand soll gespeichert werden, und zu späteren Zeitpunkten wieder aufgerufen. Dazu benötigt der Server eine Datenbank. \\
\\ \hline
\textbf{Einflussfaktoren: } \\
O1.2 \\
T1.3 \\
T1.2 \\
T1.1 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:3.1}
\textbf{Strategie 3.1: H2 (ausgewählt)} Wir verwenden die Datenbank H2. \\
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
{\phantomsection}
\label{strategie:3.2}
\textbf{Strategie 3.2: SQLite} Wir verwenden die Datenbank SQLite. \\
{\phantomsection}
\label{strategie:3.3}
\textbf{Strategie 3.3: Derby } Wir verwenden die Datenbank Derby. \\
\\ \hline
\end{tabular}
\caption{Spielstand Problemkarte}
\label{tab:ProblemKarte3}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 4: Raumschiff Größen} \\ \hline
Raumschiffe sollen verschiedene Größen haben. Es soll mindestens drei Raumschiffe mit individuellem Sektionenlayout geben. \\
\\ \hline
\textbf{Einflussfaktoren: } \\
P1.1 \\
P1.2 \\
P3.1 \\
P3.4 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:4.1}
\textbf{Strategie 4.1: Feste Raumschiffe (ausgewählt)} Wir erstellen feste Raumschiffe, aus denen der Spieler eines auswählt. \\
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
{\phantomsection}
\label{strategie:4.2}
\textbf{Strategie 4.2: Raumschiff Selektor} Wir haben einen Raumschiff Editor, in dem der Spieler sich am Anfang des Spieles ein Raumschiff zusammenbauen kann. \\
\\ \hline
\end{tabular}
\caption{Raumschiffgrößen Problemkarte}
\label{tab:ProblemKarte4}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 5: Multiplayer} \\ \hline
Die Spieler müssen vom Server gegeneinander in Kämpfen antreten gelassen werden. \\
\\ \hline
\textbf{Einflussfaktoren: } \\
T1.6 \\
T1.3 \\
T1.2 \\
P8.1 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:5.1}
\textbf{Strategie 5.1: Bestimmte Anzahl (ausgewählt)} Der Server lässt die Spieler nach einer bestimmten Anzahl Runden gegeneinander antreten. \\
{\phantomsection}
\label{strategie:5.2}
\textbf{Strategie 5.2: Zufällige Anzahl} Der Server lässt die Spieler nach einer zufälligen Anzahl Runden gegeneinander antreten. \\
{\phantomsection}
\label{strategie:5.3}
\textbf{Strategie 5.3: Zwangsläufig} Das Spiel ist so konzipiert, dass die Spieler zwangsläufig gegeneinander antreten müssen (z.B. über Quests: \textit{verteidige den Planeten xy} und \textit{Erobere den Planeten xy}, Einzigartige Ressourcen, die für bestimmte Aufgaben/Upgrades o.Ä. erforderlich sind aber nur einmal im Spiel vorkommen und deshalb irgendwann nur noch von einem Mitspieler erbeutet werden können. \\
\\ \hline
\end{tabular}
\caption{Multiplayer Problemkarte}
\label{tab:ProblemKarte5}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 6: Kompetenz der Entwickler} \\ \hline
Die unterschiedlichen Entwickler haben unterschiedliche (weitreichende) Kentnisse der Technologien. \\
\\ \hline
\textbf{Einflussfaktoren: } \\
O1.1 \\
O1.4 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:6.1}
\textbf{Strategie 25.1: Modularisierung (ausgewählt)} Wir teilen das Projekt in Module auf, sodass die unterschiedlichen Module möglichst abgekapselt voneinander implementiert werden können. \\
\textbf{Strategie 6.2: Monolitisierung} Die Entwicklung erfolgt monolit. Bei unterschiedlicher Kompetenz der Entwickler müssen bestimmte Funktionen von einem anderen Entwickler implementiert werden \\
\label{tab:ProblemKarte6}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 7: Zugüberprüfung} \\ \hline
Jeder Zug wird vom Server auf Korrektheit geprüft, bevor er an den anderen Spieler übermittelt wird. \\
\\ \hline
\textbf{Einflussfaktoren: } \\
T1.6 \\
T1.5 \\
P8.3 \\
P8.4 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:7.1}
\textbf{Strategie 7.1: Client erstellt Spielzüge} Spielzüge werden als Datenobjekte gespeichert. In jedem Spiezugsobjekt wird die Veränderung zum vorherigen Spielzug gespeichert und die Veränderung dieses Objektes wird vom Server auf Korrektheit geprüft. \\
\textbf{Strategie 7.2: Server erstellt Spielzüge} Die Spielzüge werden vom Client an den Server übermittelt und dort auf Korrektheit geprüft, ist der aktuelle Spielzug legitim, werden vom Server alle veränderten Objekte erzeugt und an den Spieler übermittelt. \\
\textbf{Strategie 7.3: Client prüft Züge, Server erstellt Spielzüge (ausgewählt)} Der Client lässt nur zulässige Spielzüge zu, und übermittelt dieses an den Server. Der Server überprüft seinerseits, ob die Veränderungen an den betreffenden Objekten zulässig sind und generiert, sofern das der Fall ist, selbige neu um sie an den Client zu übermitteln. \\
\\ \hline
\end{tabular}
\caption{Zugüberprüfung Problemkarte}
\label{tab:ProblemKarte7}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 8: Java} \\ \hline
Es soll eine Java Applikation sein, es soll mindestens Java 8 sein (oder höher). \\
\\ \hline
\textbf{Einflussfaktoren: } \\
T1.1 \\
T1.6 \\
T1.3 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:8.1}
\textbf{Strategie 8.1:Aktuellstes Java verwenden} Wir verwenden immer die Aktuellste Version von Java, sollte es zu signifikanten Änderungen kommen, wird das Projekt an diese angepasst.\\
\textbf{Strategie 8.2: Verwenden von Java 8.251 (ausgewählt)} Das Projekt wird in der Version 8.251, der zum Projektbeginn aktuellsten Version entwickelt. \\
\\ \hline
\end{tabular}
\caption{Java Problemkarte}
\label{tab:ProblemKarte8}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 9: Reise} \\ \hline
Es sollen Reisen von Stern zu Stern möglich sein. Dafür muss es eine Karte geben, auf der es mehrere Planeten/Sterne/Stationen geben kann, über die man sich bewegen kann. \\
\\ \hline
\textbf{Einflussfaktoren: } \\
T1.6 \\
P5.1 \\
P5.2 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:9.1}
\textbf{Strategie 9.1: Listen} Jede Karte ist eine Liste, in der jeder Eintrag ein/e Planet/Stern/Station ist. Die Verbindungen werden extra gespeichert. \\
{\phantomsection}
\label{strategie:9.2}
\textbf{Strategie 9.2: TiledMaps (ausgewählt)} Wir benutzen TiledMaps von LibGDX. \\
\\ \hline
\end{tabular}
\caption{Reise Problemkarte}
\label{tab:ProblemKarte9}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 10: Waffen} \\ \hline
Es muss eine Auswahl von Waffen mit verschiedenen Schadenshöhen, Cooldown, Trefferwahrscheinlichkeit und weiteren Effekten (wie z.B. Einfrieren, Personenschaden in den Sektionen) geben. \\
\\ \hline
\textbf{Einflussfaktoren: } \\
P3.2 \\
P3.3 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:10.1}
\textbf{Strategie 10.1: Attribute (ausgewählt)} Waffen haben neben dem Attribut \textit{Schaden} weitere Attribute die sie von anderen Waffen unterscheiden. \\
\textbf{Strategie 10.2: Verbesserungen (ausgewählt)} Waffen können mit bestimmten Verbesserungen ausgestattet werden, die ihnen neue Eigenschaften verleihen. \\
\textbf{Strategie 10.3: Raum-Attribute} Die genannten Eigenschaften werden nicht über die Waffenklassen implementiert sondern sind Raum-inherrent. Eine Waffe bekommt also Boni, wenn sie in einem bestimmten Raum installiert ist. \\
\\ \hline
\end{tabular}
\caption{Waffen Problemkarte}
\label{tab:ProblemKarte10}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 11: Cross Platform Support} \\ \hline
Das Spiel soll auf verschiedenen Plattformen laufen. Für die Implementierung muss die Performance beachtet werden. \\
\\ \hline
\textbf{Einflussfaktoren: } \\
T1.2 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:11.1}
\textbf{Strategie 11.1: LibGDX (ausgewählt)} Die Implementierung erfolgt über libGDX, ein Framework, dass plattformübergreifende Entwicklung über automatische Kapeslung von Klassen ermöglicht \\
\textbf{Strategie 11.2: Manuelle Entwicklung} Das Projekt wird parallel für verschiedene Plattformen programmiert. \\
\\ \hline
\end{tabular}
\caption{Cross Platform Problemkarte}
\label{tab:ProblemKarte11}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 12: Sektionen} \\ \hline
Das Schiff / die Schiffe sollen in systemrelevante Sektionen aufgeteilt sein. \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:12.1}
\textbf{Strategie 12.1: Freie Anzahl Systeme pro Schiff} jedes Schiff kann aus einer beliebigen Anzahl an Räumen, die ihrerseits wiederum Systeme enthalten können, bestehen. \\
\textbf{Strategie 12.2: Feste Anzahl Systeme pro Schiff (ausgewählt)} Jedes Schiff hat eine festgelegte Anzahl an Systemen, die sich auf eine bestimmte Anzahl an Räumen aufteilt \\
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 13: Kampfrundeninterne Speicherung} \\ \hline
Es muss möglich sein, innerhalb eines Kampfes das Spiel zu unterbrechen und später unter den selben Bedingungen fortzusetzen. \\
\\ \hline
\textbf{Einflussfaktoren: } \\
P8.4 \\
P8.5 \\
T1.6 \\
T1.3 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:13.1}
\textbf{Strategie 13.1: gesamter Spielstand} Der gesamte Spielstand wird bei jeder Änderung gespeichert. \\
{\phantomsection}
\label{strategie:13.2}
\textbf{Strategie 13.2: Änderungen (ausgewählt)} Es wir der initiale Spielstand und danach nur alle Änderungen gegenüber der letzen Speicherung gespeichert. \\
\\ \hline
\end{tabular}
\caption{Kampfrundeninterne Speicherung Problemkarte}
\label{tab:ProblemKarte13}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
Es muss einen Endgegner geben, der zum Sieg zwingend geschlagen werden muss. Entweder muss sichergestellt werden, dass beim Multiplayer ein Kampf gegen den zweiten Spieler am \textit{Ende} des Spieles steht oder es muss mindestens einen NPC geben. \\
\\ \hline
\textbf{Einflussfaktoren: } \\
P7.1 \\
P8.1 \\
P8.2 \\
T1.6 \\
T1.5 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:14.1}
\textbf{Strategie 14.1: NPC (ausgewählt)} Es gibt einen NPC, der besiegt werden muss, um zu gewinnen. \\
\textbf{Strategie 14.2: Zweiter Spieler} Der zweite Spieler ist der Endgegner, und das Spiel endet nach einem Kampf. \\
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
{\phantomsection}
\label{strategie:14.3}
\textbf{Strategie 14.3: Zeitpunkt} Es gibt einen Zeitpunkt im Spiel, nach dem der nächste Kampf zwischen den beiden Spielern zum "Endgegner" wird. \\
\\ \hline
\end{tabular}
\caption{Endgegner Problemkarte}
\label{tab:ProblemKarte14}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 15: Unterschiedliche Besatzungsmitglieder} \\ \hline
Die Besatzungsmitglieder müssen unterschiedliche Eigenschaften (Attribute) haben, die sich auf das Raumschiff auswirken und im Laufe des Spieles verbessert werden können. \\
\\ \hline
\textbf{Einflussfaktoren: } \\
P4 \\
T1.6 \\
T1.5 \\
P6.3 \\
P6.4 \\
P8.2 \\
P8.4 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:15.1}
\textbf{Strategie 15.1: Feste Crew} Es gibt eine Reihe verschiedener Crew Mitglieder, die für jedes Schiff konstant ist. Diese können nach Belieben auf die Räume und Systeme im Schiff aufgeteilt werden. \\
\textbf{Strategie 15.2: Zufällig generierte Crew} Crewmitglieder werden randomisiert generiert und können dementsprechend komplett zufällige Ausprägungen ihrer Attribute haben \\
\textbf{Strategie 15.3: Freie Crew (ausgewählt)} Es gibt eine Reihe von Crewmitgliedern, diese können jedoch im Laufe des Spieles freigeschaltet und ausgetauscht werden. Es muss mehr verschiedene Crewmitglieder als Systeme auf dem Schiff geben. \\
\\ \hline
\end{tabular}
\caption{Unterschiedliche Besatzungsmitglieder Problemkarte}
\label{tab:ProblemKarte15}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 16: Sektionenattribute} \\ \hline
Sektionen sollen Attribute haben, die auch geupgradet werden können. Sie sollen ebenfalls beschädigt und repariert werden können. \\
P1 \\
P2 \\
P3.4 \\
P4.3 \\
P5.3 \\
P6.3 \\
P8.4 \\
T1.3 \\
T1.5 \\
T1.6 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:16.1}
\textbf{Strategie 16.1: Besetzungsmaximum} Das variable Attribut der Systeme ist die Anzahl der Crewmitglieder, die dieses besetzten können. Bei Beschädigung ist das System nur noch von weniger oder gar keinen Besatzungsmitglied zu besetzten. \\
\textbf{Strategie 16.2: Systeminherrente Attribute (ausgewählt)} Durch Upgraden oder durch Beschädigen eines Systems wird der Effekt des Systems verstärkt: Waffen machen z.B. mehr (bzw. durch Schaden) weniger Damage. \\
\label{tab:ProblemKarte16}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 17: Schwierigkeitsstufen} \\ \hline
Das Spiel soll unterschiedliche Schwierigkeitsstufen haben, aus denen der Spieler am Anfang auswählen kann. \\
\\ \hline
\textbf{Einflussfaktoren: } \\
P7.2 \\
P8.2 \\
P7.1 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:17.1}
\textbf{Strategie 17.1: Attribute (ausgewählt)} Bestimmte Attribute werden am Anfang des Spieles abhängig von der Schwierigkeitsstufe gestellt (z.B. Trefferwahrscheinlichkeit, Schadenshöhe, ...) \\
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
{\phantomsection}
\label{strategie:17.2}
\textbf{Strategie 17.2: Unterschiedliche Computergegner} Es gibt unterschiedlich schwierige Computergegner für die unterschiedlichen Schwierigkeitsstufen. \\
{\phantomsection}
\label{strategie:17.3}
\textbf{Strategie 17.3: Karten } Es gibt Unterschiede in den Karten (z.B. Anzahl der schlechten Ereignisse, mehr/weniger Verbindungen zwischen Karten sodass man mehr reisen muss, ...) \\
\\ \hline
\end{tabular}
\caption{Schwierigkeitsstufen Problemkarte}
\label{tab:ProblemKarte17}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 18: Rundenbasiert} \\ \hline
Da das Spiel rundenbasiert ist, kann es sein, dass ein Spieler (vor allem im Zweispieler) sehr lange braucht, um einen Zug zu machen. \\
\\ \hline
\textbf{Einflussfaktoren: } \\
P6.2 \\
P2.1 \\
P2.3 \\
T1.3 \\
T1.5 \\
T1.6 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:18.1}
\textbf{Strategie 18.1: Zeitbegrenzung (ausgewählt)} Es gibt eine Zeitbegrenzung, sodass der Spielfluss erhalten bleibt. \\
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
{\phantomsection}
\label{strategie:18.2}
\textbf{Strategie 18.2: Keine Zeitbegrenzung} Es gibt keine Zeitbegrenzung. \\
\\ \hline
\end{tabular}
\caption{Rundenbasiert Problemkarte}
\label{tab:ProblemKarte18}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 19: Zerstörung von wichtigen Systemen} \\ \hline
Durch gegnerische Angriffe können wichtige Systeme (z.B. Antrieb) zerstört werden. Wenn die Besatzung tot ist, kann das nicht mehr repariert werden, und das Schiff ist nutzlos. \\
\\ \hline
\textbf{Einflussfaktoren: } \\
P1.3 \\
P1.4 \\
P4.3 \\
P4.4 \\
T1.3 \\
T1.5 \\
T1.6 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:19.1}
\textbf{Strategie 19.1: Testen (ausgewählt)} Es muss getestet werden, ob der Spieler noch Züge machen kann. \\
{\phantomsection}
\label{strategie:19.2}
\textbf{Strategie 19.2: Knopf} Es gibt einen Aufgeben Knopf, den der Spieler jeder Zeit drücken kann, um das Spiel zu beenden. \\
\\ \hline
\end{tabular}
\caption{Zerstörung von wichtigen Systemen Problemkarte}
\label{tab:ProblemKarte19}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{|p{15cm}|}
\hline
\textbf{Problem 20: Schutzschilde und Hüllen } \\ \hline
Schutzschilde und Außenhülle müssen einen Einfluss auf die Treffer haben (es soll also unabhängig von der Sektion auf die gezielt wird erst der Schutz zerstört werden / von dessem Status abgezogen werden). \\
\\ \hline
\textbf{Einflussfaktoren: } \\
P1.3 \\
P1.4 \\
P2.1 \\
P3.1 \\
P2.2 \\
P2.3 \\
P6.3 \\
P3.4 \\
T1.3 \\
T1.5 \\
T1.6 \\
\hline
\textbf{Strategien} \\ \hline
{\phantomsection}
\label{strategie:20.1}
\textbf{Strategie 20.1: Schutzschild schützt alles} Solange ein Schutzschild aktiv und intakt ist, ist es unmöglich dem Schiff, seinen Systemen oder seiner Crew Schaden zuzufügen \\
\textbf{Strategie 20.2: Schutzschild ist umgehbar (ausgewählt)} Das Schutzschild schützt zwar Schiff, Crew und Systeme, es gibt jedoch Waffen, die dieses durchdringen oder umgehen können. \\