\chapter{Conclusion}
\section{Final Results}
We were able to deliver on our intended goals and did not deviate far from the initial plans aside from cutting down on a few features that would have taken up too much time to implement. The most significant change would be the usage of pathfinding aerial drones instead of a simple wall of death to implement the chase mechanics, as seen in \autoref{fig:sneaking-and-alert}. This gives rise to a more classical stealth game experience.

\begin{figure}[h]
  \begin{center}
    \includegraphics[width=1.0\textwidth]{../../Screenshots/2019-05-10-105543_1229x630_scrot.png}
  \end{center}
  \caption{Getting seen by enemies will cause an alert during which drones will actively seek you out and chase you down.}
  \label{fig:sneaking-and-alert}
\end{figure}

Unlike initially assumed, we were able to implement a few additional features as well, such as a fully-fledged level editor, a full in-game menu, and background music tracks. The editor in particular, as seen in \autoref{fig:editor-office}, can be used in any browser and does not require any other parts of the game. It reads and writes to a specified format, and should thus be easily adaptable for other games.

\begin{figure}[h]
  \begin{center}
    \includegraphics[width=0.8\textwidth]{../../Screenshots/2019-05-12-16-22-07_b6727c52c6bc.png}
  \end{center}
  \caption{The office level in the separate level editor. See \autoref{fig:game-office} for an in-game screenshot.}
  \label{fig:editor-office}
\end{figure}

\begin{figure}[h]
  \begin{center}
    \includegraphics[width=1.0\textwidth]{../../Screenshots/2019-05-12-162808_1877x988_scrot.png}
  \end{center}
  \caption{An in-game snapshot of the office level}
  \label{fig:game-office}
\end{figure}

The final game delivers on the crucial features for a fully-fledged game, though definitely needs more work in terms of level design, story writing, and polish.

\section{Experience}
Our initial game idea translated pretty well, though with as little actual game data as we could gather, it's hard to say whether it would be possible to expand it to the length of multiple hours. We quickly threw the initial schedule away and started managing work ad-hoc between ourselves as need demanded. After the initial base systems such as animation, tile rendering, and collision detection were in, we then organised tasks and todos using a google sheet, adding and ticking off things over time. We also kept weekly meetings, and the main contributors actively partook in Slack chat to exchange ideas and discuss the project.

We still feel that the paper prototype as it was done did not help us much and our time would have been better spent implementing the base gameplay systems, so that we would have had more time to polish the game and work out gameplay and level design issues. The gameplay session was also way too short and we were not able to privately test the game enough or get in enough people to get a lot of useful feedback that we did not already discover ourselves.

Difficulties in terms of programming mostly lied in getting the collision and enemy AI to work perfectly, which led to many bugs and revisions over the course of the development. Almost all of the credit for the work on that goes to Gengyan Li however.

The biggest hindrance by far was the communication between teammates and the lack of coordinated academic schedules to allow this project to flourish. Team members were often heavily burdened by other tasks such as workshops or time-intensive exercises from other courses.

\section{Personal Impressions}
This project was a very stressful and hugely time-intensive endeavour that would require at least twice the amount of credit points to properly justify the amount of work that went into producing a presentable game up to my standards. While the joint operation between ETH and ZHdK for this course is a welcome idea, it is executed very poorly. The huge discrepancy in credit points means ZHdK students are far less motivated to contribute a lot of time to the project over other subjects. The lack of schedule coordination also meant that ZHdK students were absent for large spans of time due to workshops or other obligations. As students are thrown together into groups rather abruptly without knowing each other at all there is also a very significant challenge in managing and coordinating the team, which further adds on to the already massive amounts of time commitment necessary for this course.

Being restricted to the Windows 10 platform and the Monogame framework also proved rather annoying. A lot of time was wasted trying to figure out how to coerce Monogame into doing what's required and debugging Monogame or Windows 10 related issues, to which there was often very scarce amounts of information to be found online, if any at all. The Windows 10 and development environment setup restrictions further burdened our team and led to the fact that the ZHdK students were not able to test the game at all outside of the weekly meetings. This was extremely troublesome during the level design phase, as there was no direct way for them to get feedback on the playability as they were developing the levels.

If I were to make another game in a group, I would definitely seek out people I've already known for a good while and commit to the project as a 100\% job. Otherwise the amount of stress produced and time wasted that builds up would hamper the progress and quality of the final result far too much. I would also not choose a framework that is locked into the Windows 10 ecosystem, or target the failing Xbox One console. Depending on the project goals, either go for a fully fledged commercial engine like Unity or Unreal, or use a fully home-grown engine based on OpenGL and other platform-portable technologies.

Overall I am not quite happy with the final result, though that is mostly due to extremely high standards on my part. For the vast amounts of hindrances and restrictions that were placed on this project, I would say that we did surprisingly well. The game looks like something that could be finished, if it were expanded upon and the existing content polished further. The theme to us was mostly a side-thought that spawned the initial story, but it did not inspire or impact the game design by much, as the same game could have been implemented under many other themes by swapping out the art design and story.

The course could be significantly improved if the collaboration with ZHdK was either removed entirely, or revamped significantly to match up the amount of credit points awarded and to synchronise the student schedules better as to not collide so frequently. The idea of building up a game from scratch is great, but then the course should be renamed to \textit{Game Development}, rather than \textit{Game Programming}. The latter implies less of a full game development and more of a hands-on teaching of game and engine programming techniques. That, too, could be an interesting and exciting course, but as it stands the title of this course is a misnomer.

The lectures presented in the course felt mostly superfluous and only contained sparsely useful information. The content could be improved radically by focusing more on case studies of existing games and the critical analysis of gameplay, art, and presentation. The current presentations often felt aimless and factually dry. By focusing on an active discussion about existing games and their systems, the points could be delivered in a more tangible manner and could be livened up by connecting the information with games the students might already know, or might want to investigate on their own. Being able to see a system work or fail in action would also be a far more effective way of demonstrating why or how these points are actually important. For this reason, the presentation by the Studio Gobo member was the most insightful and interesting.


%%% Local Variables:
%%% mode: latex
%%% TeX-master: "report"
%%% TeX-engine: luatex
%%% TeX-command-extra-options: "-shell-escape"
%%% End: