ma
/
thesis
1
1
Fork 0
Code Issues 1 Pull Requests Releases 8 Wiki Activity

wörk

master
Clemens Klug 2018-05-02 16:32:49 +02:00
parent fe533ba321
commit 24b1cc2efb
2 changed files with 36 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
ThesTeX/content/3-solution.tex
View File

@ -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} \image{\textwidth}{../../PresTeX/images/kibana2}{Game trace in Kibana}{img:kibana2}
\section{Architecture} \section{Architectural Design}
\subsection{Overview} \subsection{Overview}
Based on the learnings above, a custom stack seems like a feasible alternative: 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. The analysis framework.
\image{\textwidth}{solution.pdf}{Architecture approach}{img:solution} \image{\textwidth}{solution.pdf}{Architecture approach}{img:solution}
The following sections describe each of those components.
\subsection{Analysis Framework} \subsection{Analysis Framework}
The analysis framework takes game logs, processes their entries, collects results, and renders them to an output. 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. \autoref{img:flow} shows the data flows through the framework.
Every processed log file has its own analysis chain. 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} \image{\textwidth}{map-reduce.pdf}{Data flows}{img:flow}
\subsubsection{Analyzer} \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. This can be useful to filter verbose logs before computationally expensive operations.
\subsubsection{Result} \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} \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.
\subsection{Interfaces}
The interfaces are rather straightforward: Postprocessing is a hard requirement for rendering the results, as at least a transformation into the desired format is absolutley necessary.
Users select game logs for processing, choose which analyzing methods shall be applied, and finally set a rendering target. 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} \subsection{old}
@ -129,4 +152,4 @@ Game independance:
\item API for integration \item API for integration
\item allow load distribution \item allow load distribution
\end{itemize} \end{itemize}
\image{\textwidth}{architecture.pdf}{archoitecure overview}{img:arch} \end{comment}

2
ThesTeX/content/4-implementation.tex
View File

@ -2,6 +2,8 @@
\section{konfigurierbarkeit (log import)} \section{konfigurierbarkeit (log import)}
\section{...} \section{...}
\image{\textwidth}{architecture.pdf}{archoitecure overview}{img:arch}
\section{1. vortrag} \section{1. vortrag}
\section{Outlook: Implementation} \section{Outlook: Implementation}