diff --git a/ThesTeX/content/3-solution.tex b/ThesTeX/content/3-solution.tex index b042c47..dfaa02f 100644 --- a/ThesTeX/content/3-solution.tex +++ b/ThesTeX/content/3-solution.tex @@ -42,7 +42,7 @@ The default Kibana worchbench does not qualify for this, a custom interface coul \image{\textwidth}{../../PresTeX/images/kibana2}{Game trace in Kibana}{img:kibana2} -\section{Architecture} +\section{Architectural Design} \subsection{Overview} Based on the learnings above, a custom stack seems like a feasible alternative: @@ -61,12 +61,13 @@ The already mentioned interfaces (Web and CLI/API) for both target groups are th The analysis framework. \image{\textwidth}{solution.pdf}{Architecture approach}{img:solution} +The following sections describe each of those components. \subsection{Analysis Framework} The analysis framework takes game logs, processes their entries, collects results, and renders them to an output. \autoref{img:flow} shows the data flows through the framework. Every processed log file has its own analysis chain. -The log entries are fed sequentionally into the analysis chain. +The log entries are fed sequentially into the analysis chain. \image{\textwidth}{map-reduce.pdf}{Data flows}{img:flow} \subsubsection{Analyzer} @@ -85,20 +86,42 @@ A consumed log entry is not passed down the analysis chain anymore. This can be useful to filter verbose logs before computationally expensive operations. \subsubsection{Result} +When all entries of a game log have been processed, the results of each analyzer are collected. +Each result is linked to the analyzer which has produced this artifact to avoid ambiguous data sets. -\subsubsection{Render} - - -\subsection{Interfaces} -The interfaces are rather straightforward: -Users select game logs for processing, choose which analyzing methods shall be applied, and finally set a rendering target. - - +\subsubsection{Postprocessing \& Render} +When all game logs are processed, the whole result set is passed into the Postprocessing step. +This is the first step to compare multiple game logs, i.e. the results of the analyzed game logs, directly. + +Postprocessing is a hard requirement for rendering the results, as at least a transformation into the desired format is absolutley necessary. +Rendering is not restricted to visualizations, artifacts of all kind can be produced. +A whole range from static plots and CSV exports to structured JSON data for interactive map visualizations is possible. + +\subsubsection{Log parser} +Key to the framework described above is a component to import game log data, parse it, and prepare it to a common format for processing. + +\subsection{Web Interface} +The web interface is rather straightforward: +Expert users prepare a set of analysis methods and bundle them with suitable rendering targets to an analysis suit. +Non-expert users select game logs for processing, choose a prepared analysis suit, and receive a rendered result once the analysis process has finished. + +\subsection{CLI/API Interface} +Providing insight access to analysis and render classes, the CLI/API interface offers the most powerful way to explore the log data. +By implementing custom algorithms, expert users can cope with difficult input formats and special requirements. +\subsection{Architecture} +The API is a standalone microservice. +It is independent of both game servers and user interfaces. +Separation from game servers narrows the scope, and allows the usage with any kind of game. +Games without central server can provide a mocked server to supply logged data, while games with server can e.g. expose API endpoints with authentication and user management. +By acting like any normal client, the framework can avoid obstacles like CORS/XSS prevention. +The independence to user interfaces, mainly the web interface, allows scalability through load-balancing with mulitple API workers. +Expert users with special requirements can embed the framework in projects without pulling in large amounts of dependencies. +\begin{comment} \subsection{old} @@ -129,4 +152,4 @@ Game independance: \item API for integration \item allow load distribution \end{itemize} -\image{\textwidth}{architecture.pdf}{archoitecure overview}{img:arch} +\end{comment} \ No newline at end of file diff --git a/ThesTeX/content/4-implementation.tex b/ThesTeX/content/4-implementation.tex index 34fe9ca..8467b9c 100644 --- a/ThesTeX/content/4-implementation.tex +++ b/ThesTeX/content/4-implementation.tex @@ -2,6 +2,8 @@ \section{konfigurierbarkeit (log import)} \section{...} +\image{\textwidth}{architecture.pdf}{archoitecure overview}{img:arch} + \section{1. vortrag} \section{Outlook: Implementation}