---
# System prepended metadata

title: Conclusion

---

# Conclusion

## Finales Ergebnis
Video:  
https://mega.nz/file/8AMkWDYI#cLgQ9DYXtmQ4qg4Xy4EG5q_Z58BHvIs0ImKL0C73p9U
https://streamable.com/fpjtzu

### Steuerung
**Overworld**  
WASD, ↑←↓→ = Laufen  
Enter/Space = Interagieren  
F [im Dialog]: Weiter  

**Kampf**  
A = Attack  
W = Walk  
Q = Ability  
D = Defend  
S = Skip  
Pfeiltasten, Enter = Feld auswählen  
ESC = Aktion abbrechen  
*Oder mit der Maus das Menü betätigen...*  

### Screenshots
![][dialog]
Startdialog / Anfang der Story  

![][fight]
Kampf auf der Waldkarte  

![][city]
Stadt mit verschiedenen Gebäuden:  
- Kaserne, um die aktiven Einheiten auszuwählen und zu verbessern  
- Hospital, um verletzte Einheiten zu heilen  
- Burg, um neue Einheiten zu rekrutieren  

![][ui]
Hospital  

![][second-level]
Letzter Schutz vor der Unterwelt  

![][underworld]
Unterwelt  

![][fight2]
Kampf auf der Unterweltkarte  

### Bekannter Fehler
Manchmal wenn die KI(der Hund) den Kampf startet kommt es dazu, dass er einfach nichts macht. In dem Fall einfach den Flee-Button drücken und den Kampf neu starten.

## Änderungen nach dem Alpha Release
Es hat sich viel geändert, weil unser Alpha Release sehr unfertig war. Wir sind außerdem speziell auf die Ergebnisse des Playtesting eingegangen und haben unter anderem Dialoge für Tutorial und Story hinzugefügt, welche am Anfang nicht geplant waren.  

Der Alpha Release hat gezeigt, dass unsere Spieler nicht genug geführt wurden, wenn es darum ging, das Ziel des Spiels zu ermitteln; Hierbei wurde oft nach dem ersten Kampf gefragt: "Warum muss ich gegen diesen Hund kämpfen?" oder "Warum ist der Greif so schwach?". Die Stärken und Schwächen unserer Einheiten sind am Anfang nicht einfach ersichtlich, deshalb war es uns wichtig, einen Roten Faden in das Spiel einzufügen, der über den Kampf hinaus Sinn macht, verfolgt zu werden. Zudem waren uns Spielaspekte wichtig, die dem Spieler ermöglichen, durch Training und Upgrades seine Einheiten zu verbessern und einen unmöglichen Kampf letztendlich möglich zu machen. (Random-Encounter, EXP, Promotion) Oder es zumindest zu erlauben, dass der Spieler einem unmöglichen Kampf entkommen kann (Flee).  

Wir haben ein Konversationssystem implementiert, was uns ermöglicht, unsere Einheiten vielschichtiger zu verwenden, so können die selben Einheiten, die im Kampf eingesetzt werden nun auch Spiel-Relevante Geschichte in der Overworld rüberbringen. Der Spieler bekommt (hoffentlich) hilfreiche Hinweise darüber, wie die Situation in der Welt ist und was er tun kann, um sie zu verbessern.  

## Erfahrungen durch den Kurs
Durch den Kurs haben wir gelernt, mit Unity umzugehen und die wichtigsten Bestandteile der Spieleprogrammierung kennengelernt. Außerdem haben wir das schreiben in C# und das Erstellen und Umgehen mit grafischen Material gelernt.  
Wir sind davon überzeugt, dass wir einen guten Einblick in die Spieleprogrammierung bekommen haben wir Sie in der Industrie abläuft.  

### a) Wie gut ließen sich ihre anfänglichen Ideen in das finale Spiel umsetzen? Konnten Sie ihren Zeitplan einhalten?
Einige Spielideen wie die Skilltrees für Units, 8 Fraktionen einbauen, fertige individuelle Abilities sind Beispielsweise gar nicht mehr, nicht in der ausführlichen anfangs geplanten Art oder eben nicht vollständig in Spiel vorhanden. Doch viele anderen Ideen haben es ganz ins Spiel geschafft, wie zB. die Overworld mit ihren Funktionen und auch die ausgefeilte Battlemechanik.  
Unser Zeitplan hat sich durch die anfänglichen Schwierigkeiten gleichzeitig an Skripten zu schreiben, die stark von einander abhingen, sehr deutlich dann nach hinten verschoben. Durch das größer werden des Projektes und die steigende Anzahl der verschiedenen Teile konnte später besser gleichzeitig gearbeitet werden.  

Jede Einheit sollte in der Lage sein, abhängig Ihrer Stats und Promotion verschiedene Fähigkeiten im Kampf einzusetzen. Im Moment wäre es für die direkte Verbesserung des Spiels gut, für jede Einheit eine einzigartige Fähigkeit zu implementieren und in die künstliche Intelligenz der Gegner als mögliche Aktion einzubauen. Auf diese Weise, also Verbesserung an der Engine und der Entscheidungsfindung bei einzelnen Aktionen, könnte man rapiden Fortschritt machen, wenn es darum geht, weitere Fraktionen zu implementieren. Der momentane Stand jedoch repräsentiert unsere Spielidee recht gut.  

### b) Wo sind sie stark davon abgewichen?
Den Anfangs geplanten Skill-Tree haben wir komplett aus dem Spiel gelassen. Dieser war auch eher, um das Spiel "Power-Up"-fokussierter zu machen. Stattdessen haben wir eine gleichmäßige Statserhöhung nach Level eingebaut. Hinzugefügt haben wir noch mehr Dialoge und Story, die das Spiel interessanter machen soll. Auch die Freischaltung von besseren Units über stehende Charakter in der Overworld waren keine Anfangsideen.  

### c) Wie haben die Elemente des Kurses (Entwicklungsplan, Prototyp, Playtesting etc.) das Fortkommen im Kurs begünstigt oder behindert?  
Entwicklungsplan - In den frühen Phasen der Entwicklung ist es durch Enginespezifische Notwendigkeiten schwer einzuschätzen, welchen Aufwand eine gegebene Funktionalität tatsächlich erfordert. Jedoch wussten wir bereits im groben, was für ein Spiel wir letztendlich entwickeln wollen und haben viel Referenzmaterial ausgetauscht, um unsere Idee durch Überlappungen anderer Ideen zu umschreiben. Die gebotene Freiheit hat es uns erlaubt, für jeden Komplex eine Minimalanforderung neben der Gewünschten zu ermitteln und daraus letztendlich ableiten zu können, welche Funktionalität in jedem Bereich des Spieles vorhanden sein muss, um jede Minimalanforderung zu implementieren. Sobald wir die Minimalanforderung hatten, konnten wir uns entscheiden, inwieweit wir das System ab dem Punkt komplexer designen oder nicht.  
Prototyp - Das Prototyping hat uns gezwungen, individuelle Systeme miteinander zu kombinieren um eine Idee der Komplexität zu erhalten, die unser System beschreibt, aber die "frühe" Notwendigkeit (schon Monate vor Ende des Kurses) eines solchen Prototypen hat uns spezifisch dazu gezwungen, viele sich bewegende Teile des Codes zusammenzufassen und die Funktionalitäten, die sich ähneln oder überlappen, zusammenzufassen. Hierbei wäre es jedoch gut gewesen, bereits eine Idee darüber zu haben, wie die jeweiligen Aktionen der Einheiten ermittelt werden und welche visuellen Indikatoren wir wählen im Zusammenhang mit der Spielerinteraktion durch den Controller.  
Playtesting - Das Playtesting hat sich positiv aufs Fortkommen ausgewirkt, wobei es nicht viel Arbeit in Anspruch nahm, aber dafür wertvolles Feedback einbrachte.  

### d) Konnten Sie ihre Erwartungen umsetzen? Sind sie stolz auf das Spiel?
Wir konnten unsere Erwartungen größtenteils umsetzen. Hier und da sind ein paar Kleinigkeiten die über den Rand gefallen sind, aber wir sind dennoch stolz und zufrieden über unser Endprodukt.  

### e) Hatten Sie genug Zeit?
Insgesamt hätten wir wohl noch einige Wochen mehr gebraucht, um unseren gewünschten Stand zu erreichen, aber so sind wir in die Bredouille gekommen und mussten einige Ideen vorzeitig ausrangieren.  
Größtes Problem hierbei waren die anderen auch zeitfressende Kurse.  

### f) Was war die größte technische Schwierigkeit?
Die größte technische Schwierigkeit war vor allem das mergen unserer Projektdateien in git.  
Auch die kaputt gehende PC's bei zwei unserer Teammitglieder waren nicht hilfreich.  

### g) Sind sie mit dem Thema des Kurses klar gekommen?
Das Thema PowerUp war kein Problem für uns, da es in dem Genre Strategy/RPG oft eine Art Progression System gibt. Auch die Umsetzung war keine Schwierigkeit.  

### h) Hat Ihnen die Arbeit mit dem Thema Spaß gemacht, oder hätten Sie lieber mehr Freiheit gehabt?
Wir hatten genug Freiheit mit dem Thema, da es ja ziemlich grob gefasst ist und man es auf unterschiedliche Weise einbauen kann.  
Die Arbeit mit dem Thema hat auf jeden Fall Spaß gemacht, nur im zeitlichen Rahmen kann man natürlich nur einen Bruchteil von dem, was man sich wünschen würde implementieren, insbesondere da die Zeit nochmal für jeden Studenten aufgeteilt ist und somit tatsächlich noch weniger ist als "ein ganzes Semester für ein Spiel". Dennoch wird einem bewusst, wie wichtig es ist, für das effektive arbeiten verschiedene Programmierparadigmen zu verwenden. Diese unterstützen einen dabei, mit Systemen zu interagieren, die eine gewisse Komplexität überschreiten.

### i) Was würden Sie bei ihrem nächsten Spiel anders machen?
Bei unserem nächsten Spiel würden wir wahrscheinlich schon im Voraus Ordnerstrukturen festlegen und eine realistischere Planung schreiben, die unsere neu erworbenen Erfahrungen miteinbringt.  

Unity realisiert seine Funktonalität größtenteils durch Prefabs. Besonders bei SpriteAnimationen ist es wichtig, eine geordnete Struktur zu haben; Also wie Animationen ausgelöst werden und ihre Vollendung signalisiert wird.
Einige ShaderEffekte realisieren ihre Effektivität durch eine Emmission Textur, die Kalkulation des Effekts geschieht also durch eine hinterlegte Textur. Ist diese Textur ein Dictionary oder eine Liste von Sprites (spritesheets) kann es bei fehlender Distanz zur Nachbartextur zu bleed Effekten kommen. Daher ist es hilfreich, die Texturen aufzuspalten, falls man solche Effekte nutzen möchte.  

Das Modell, welches die Interaktionen mit dem System beschreiben sollten besser definiert werden, hierbei waren in unserem Fall die Manipulation des Grids, also initialisierung und halten der Daten und darauf folgende Manipulation durch einen generellen BattleManager notwendig. Zudem haben wir uns letztendlich neben dem BattleManager noch für einen Controller entschieden, wobei der Controller die anbindung an die UI über den UIManager ermöglicht und interaktionen mit dem Taktischen Interface durch KeyEvents und UI-Hover und Klick Operationen Initialisiert. Da der Taktische teil solcher Spiele mindestens eine so große Rolle spielt wie der visuelle Part war es uns wichtig jede Interaktion des Spielers durch eine nachvollziehbare Aktion im Spiel beschreibt.  

Gegen Ende ist klar geworden, dass die Ermittlung möglicher Aktionen ein komplexer Teil der Entwicklung ist, hierbei werden die Aktionen versucht recht individuell der Situation abhängig zu machen, jedoch existiert keine exakte Kalkulation darüber welche Aktion tatsächlich die wäre mit den höchsten Erfolgschancen zum gewinnen. Wollten wir nun unterschiedliche Schwierigkeitsgrade implementieren, wäre dies nur möglich durch vergrößern der jeweiligen Gegnerarmee bzw der Auswahl gegnerischer Einheiten (wobei in hinblick der KI es schön wäre, wenn die Entscheidungen die getrofffen werden abhängig der Schwierigkeit mehr oder weniger optimal sind). Nach weiterer Überlegung und recherche in einer Schach-Engine wurde uns bewusst das eine vereinfachung der Ermittlung möglicher Aktionen durch Listenkonstrukte in der Engine von Vorteil wäre um realistisch entscheiden zu können was für Aktionen Einheiten ausführen sollten/könnten.  

### j) Was war der größte Erfolg während des Projekts? War das Projekt ein Erfolg?
Der größte Erfolg war es alle Teile die wir vor der Alpha Version hatten zusammenzufügen und das dabei ein gut spielbares Battle rauskam.  

Die Aufteilung der Funktionalität in seine Bestandteile hat viele Straßen offengelegt, an denen man minimale Verbesserungen vornehmen kann, wodurch letztendlich durch viele kleine Änderungen große Verbesserungen erfolgen können. Das Verwenden der Tilemap als Basis für das Grid ermöglicht die Implementierung eines stilistisch vollkommen anderen Spiels in 2D oder 3D - Sollte man sich also entscheiden, anhand der momentanen Engine ein weiteres Spiel zu implementieren mit einem anderen Stil, wäre dies möglich und könnte wie oben erwähnt durch gezieltes Verfeinern der Teilfunktionalitäten in ein allgemeines System wachsen, mit dem man Turn-based Combat beschreiben könnte.  


### k) Mochten Sie Unity?
Die 2D-Funktionen sind oft etwas klobig und es ist nervig, dass man Szenen praktisch nicht mergen kann. Auch die komplizierte Art auf Objekte in Laufzeit zuzugreifen und die vielen verschiedenen Weißen dies anzustellen waren nicht so schön.  
Unity hat große Probleme, das Layout beizubehalten, wenn Änderungen außerhalb der Szene vorgenommen werden; Generell ist es extrem nützlich, dass man in der Lage ist, seine eigenen Inspektoren und Views im Editor implementieren. Jedoch ist es natürlich nicht schön, dass man nach einem potentiellen Merge öfter mal das Layout resetten muss und deshalb seinen Arbeitsbereich ständig neu erstellen muss, um eine spezifsche Aufgabe zu erfüllen.  
Aber im Allgemeinen ist Unity eine gut durchdachte Software die einem sehr viel Spielraum gibt und damit umgehen zu können ist auf jeden Fall ein Gewinn.  

[dialog]: https://i.imgur.com/IQRmKCM.png
[fight]: https://i.imgur.com/BUn3pam.png
[fight2]: https://i.imgur.com/w7Cm74J.jpg
[city]: https://i.imgur.com/GZ4gbqx.png
[second-level]: https://i.imgur.com/uj7NmxL.png
[underworld]: https://i.imgur.com/Sc4Xakc.png
[ui]: https://i.imgur.com/Rmq7iVH.png
