Architekturbesprechung: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
Zeile 3: | Zeile 3: | ||
Das Treffen sollte damit beginnen, dass die Studenten kurz ihre Spielidee und die Grundlegenden Mechaniken vorstellen. Nach einer kurzen einführung in ihr Komponentendiagramm und einer kurzen Zusammenfassung zu den einzelnen komponenten, präsentieren die Studenten anhand ihrer Architektur die vorgefertigte Szenarien. Im Anschluss gibt es Fragen und eventuell weitere Szenarien, die direkter mit der Architektur/der Spielmechanik verknüpft sind. | Das Treffen sollte damit beginnen, dass die Studenten kurz ihre Spielidee und die Grundlegenden Mechaniken vorstellen. Nach einer kurzen einführung in ihr Komponentendiagramm und einer kurzen Zusammenfassung zu den einzelnen komponenten, präsentieren die Studenten anhand ihrer Architektur die vorgefertigte Szenarien. Im Anschluss gibt es Fragen und eventuell weitere Szenarien, die direkter mit der Architektur/der Spielmechanik verknüpft sind. | ||
===Vorgefertigte Szenarien=== | ===Vorgefertigte Szenarien=== | ||
Für alle Szenarien die hier vorgestellt werden können sie annehmen, dass die ''Quelle'' des Szenarios die Auftraggeber (oder Dozenten sind), und der ''Auslöser'' des Szenarios der Spieler ist. Die Einleitenden Texte klären die ''Umgebung'', gefolgt von einer ''Beschreibung'' des Szenarios. Die ''Antwort'' sollte in allen Fällen sein, dass das Gefragte vorhanden und in der Architektur sinnvoll gelöst ist. | |||
Für alle Szenarien die hier vorgestellt werden können sie annehmen, dass die ''Quelle'' des Szenarios die Auftraggeber (oder Dozenten sind), und der ''Auslöser'' des Szenarios der Spieler ist. Die Einleitenden Texte klären die ''Umgebung'', gefolgt von einer ''Beschreibung'' des Szenarios. Die ''Antwort'' sollte in allen Fällen sein, dass das Gefragte vorhanden und in der Architektur sinnvoll gelöst ist. | |||
====== Ich befinde mich nicht im Spiel, starte die ausführbare Datei, und befinde mich danach im Hauptmenü. ====== | |||
*Es existiert ein ''Einstieg'' in das Diagramm (in welcher Komponente ist <code>Game1.cs</code>). | *Es existiert ein ''Einstieg'' in das Diagramm (in welcher Komponente ist <code>Game1.cs</code>). | ||
*Es gibt einen Ort, an dem die einzelnen ''Benutzeroberflächenelemente'' definiert sind. | *Es gibt einen Ort, an dem die einzelnen ''Benutzeroberflächenelemente'' definiert sind. | ||
*Was wird sonst noch alles getan um das Menü zu laden? | *Was wird sonst noch alles getan um das Menü zu laden? | ||
====== Ich befinde mich im Hauptmenü und drücke auf ''Achievements'', und sehe danach die bisher im Spiel erreichten Achievements. ====== | |||
*Die Achievements werden ''persistiert''. | *Die Achievements werden ''persistiert''. | ||
*Der Filesystemzugriff ist gekapselt (wie geschieht Laden u. Speichern). | *Der Filesystemzugriff ist gekapselt (wie geschieht Laden u. Speichern). | ||
====== Ich drücke im Hauptmenü auf ''Spiel Starten'', und befinde mich danach im Spiel. ====== | |||
*Es wird eine ''Karte'' erzeugt. | *Es wird eine ''Karte'' erzeugt. | ||
*Es werden ''Spielobjekte'' erzeugt. | *Es werden ''Spielobjekte'' erzeugt. | ||
====== Ich bin bereits im Spiel und selektiere eine Einheit. ====== | |||
*Die Position des Mauszeigers wird auf die Karte umgerechnet. | *Die Position des Mauszeigers wird auf die Karte umgerechnet. | ||
*Die selektierte Einheit wird anhand der Karten- oder Weltposition ermittelt. | *Die selektierte Einheit wird anhand der Karten- oder Weltposition ermittelt. | ||
*Die Selektion wird visuell verarbeitet d.h. das Aussehen der Figur und der Hud ändern sich. | *Die Selektion wird visuell verarbeitet d.h. das Aussehen der Figur und der Hud ändern sich. | ||
====== Ich bin bereits im Spiel und habe eine Einheit selektiert. Ich wähle einen Punkt auf der Karte und schicke die Einheit mit einem Mausklick da hin. ====== | |||
*Es wird der Pfad zum Ziel berechnet. | *Es wird der Pfad zum Ziel berechnet. | ||
*Es gibt Datenstrukturen die für das Pathfinding verwendet werden. | *Es gibt Datenstrukturen die für das Pathfinding verwendet werden. | ||
*Wenn einige Frames verstrichen sind und sich auch andere Einheiten bewegt haben: Wie reagiert die sich bewegende Einheit auf diese Änderungen? | *Wenn einige Frames verstrichen sind und sich auch andere Einheiten bewegt haben: Wie reagiert die sich bewegende Einheit auf diese Änderungen? | ||
*Es gibt Kollisionen zwischen den Einheiten. Welche Instanzen sind daran beteiligt? | *Es gibt Kollisionen zwischen den Einheiten. Welche Instanzen sind daran beteiligt? | ||
*Es gibt Datenstrukturen die zur Berechnung der Kollisionen verwendet werden. | *Es gibt Datenstrukturen die zur Berechnung der Kollisionen verwendet werden. | ||
====== Ich bin bereits im Spiel und habe eine Einheit selektiert. Ich wähle ein anderes Spielobjekt aus und starte eine Interaktion zwischen der selektierten Einheit und dem anderen Spielobjekt (z.B. Ressource sammeln, Einheit angreifen, Bauauftrag geben, etc.). ====== | |||
*Der Zustand des agierenden Spielobjekts ändert sich. | *Der Zustand des agierenden Spielobjekts ändert sich. | ||
*Es gibt es einen “normalen” Zustand des agierenden Spielobjekts (z.B. wenn es keine Befehle hat). | *Es gibt es einen “normalen” Zustand des agierenden Spielobjekts (z.B. wenn es keine Befehle hat). | ||
Zeile 26: | Zeile 39: | ||
**Ändert z.B. die agierende Einheit direkt Werte bei der reagierenden? Können dann beide gleichzeitig “sterben”? | **Ändert z.B. die agierende Einheit direkt Werte bei der reagierenden? Können dann beide gleichzeitig “sterben”? | ||
**Ändert die agierende Einheit Werte in der Welt? Wie ist da der Datenfluss? Muss die Einheit Dinge wie “Global Ressources” direkt kennen? (Law of Demeter, SoC, Tell dont ask) | **Ändert die agierende Einheit Werte in der Welt? Wie ist da der Datenfluss? Muss die Einheit Dinge wie “Global Ressources” direkt kennen? (Law of Demeter, SoC, Tell dont ask) | ||
====== Ich bin der zweite Spieler… (alles von oben) ====== | |||
*Die Beschreibungen funktionieren für den zweiten Spieler (z.B. im Netzwerkspiel für den Client). | *Die Beschreibungen funktionieren für den zweiten Spieler (z.B. im Netzwerkspiel für den Client). | ||
*Die Eingaben so abstrahiert, dass sich Spieler und KI (oder Netzwerkspieler) ein gemeinsames Interface teilen. | *Die Eingaben so abstrahiert, dass sich Spieler und KI (oder Netzwerkspieler) ein gemeinsames Interface teilen. | ||
*Der aktuelle Spielzustand wird vollständig persistiert. | |||
====== Ich bin bereits im Spiel (o. im Pausenmenü) und speichere das Spiel ab. ====== | |||
*Der aktuelle Spielzustand wird vollständig persistiert. | |||
====== Ich bin bereits im Spiel und öffne die Optionen. Ich ändere… ====== | |||
*Die Änderung der Auflösung wird durch das Spiel propagiert (wird dabei alles neu geladen?). | *Die Änderung der Auflösung wird durch das Spiel propagiert (wird dabei alles neu geladen?). | ||
===Weitere Szenarien=== | ===Weitere Szenarien=== | ||
Die Dozenten (und gerne auch Tutoren) überlegen sich weitere Szenarien anhand des geplanten Spiels. | Die Dozenten (und gerne auch Tutoren) überlegen sich weitere Szenarien anhand des geplanten Spiels. |
Version vom 24. November 2020, 11:56 Uhr
Die Studenten stellen die Architektur die sie sich für ihr Spiel ausgedacht haben vor, und bekommen Verbesserungsvorschläge zu ihrer Architektur, und hinweise auf eventuelle Architekturfehler.
Besprechung anhand von Szenarien
Das Treffen sollte damit beginnen, dass die Studenten kurz ihre Spielidee und die Grundlegenden Mechaniken vorstellen. Nach einer kurzen einführung in ihr Komponentendiagramm und einer kurzen Zusammenfassung zu den einzelnen komponenten, präsentieren die Studenten anhand ihrer Architektur die vorgefertigte Szenarien. Im Anschluss gibt es Fragen und eventuell weitere Szenarien, die direkter mit der Architektur/der Spielmechanik verknüpft sind.
Vorgefertigte Szenarien
Für alle Szenarien die hier vorgestellt werden können sie annehmen, dass die Quelle des Szenarios die Auftraggeber (oder Dozenten sind), und der Auslöser des Szenarios der Spieler ist. Die Einleitenden Texte klären die Umgebung, gefolgt von einer Beschreibung des Szenarios. Die Antwort sollte in allen Fällen sein, dass das Gefragte vorhanden und in der Architektur sinnvoll gelöst ist.
Ich befinde mich nicht im Spiel, starte die ausführbare Datei, und befinde mich danach im Hauptmenü.
- Es existiert ein Einstieg in das Diagramm (in welcher Komponente ist
Game1.cs
). - Es gibt einen Ort, an dem die einzelnen Benutzeroberflächenelemente definiert sind.
- Was wird sonst noch alles getan um das Menü zu laden?
Ich befinde mich im Hauptmenü und drücke auf Achievements, und sehe danach die bisher im Spiel erreichten Achievements.
- Die Achievements werden persistiert.
- Der Filesystemzugriff ist gekapselt (wie geschieht Laden u. Speichern).
Ich drücke im Hauptmenü auf Spiel Starten, und befinde mich danach im Spiel.
- Es wird eine Karte erzeugt.
- Es werden Spielobjekte erzeugt.
Ich bin bereits im Spiel und selektiere eine Einheit.
- Die Position des Mauszeigers wird auf die Karte umgerechnet.
- Die selektierte Einheit wird anhand der Karten- oder Weltposition ermittelt.
- Die Selektion wird visuell verarbeitet d.h. das Aussehen der Figur und der Hud ändern sich.
Ich bin bereits im Spiel und habe eine Einheit selektiert. Ich wähle einen Punkt auf der Karte und schicke die Einheit mit einem Mausklick da hin.
- Es wird der Pfad zum Ziel berechnet.
- Es gibt Datenstrukturen die für das Pathfinding verwendet werden.
- Wenn einige Frames verstrichen sind und sich auch andere Einheiten bewegt haben: Wie reagiert die sich bewegende Einheit auf diese Änderungen?
- Es gibt Kollisionen zwischen den Einheiten. Welche Instanzen sind daran beteiligt?
- Es gibt Datenstrukturen die zur Berechnung der Kollisionen verwendet werden.
Ich bin bereits im Spiel und habe eine Einheit selektiert. Ich wähle ein anderes Spielobjekt aus und starte eine Interaktion zwischen der selektierten Einheit und dem anderen Spielobjekt (z.B. Ressource sammeln, Einheit angreifen, Bauauftrag geben, etc.).
- Der Zustand des agierenden Spielobjekts ändert sich.
- Es gibt es einen “normalen” Zustand des agierenden Spielobjekts (z.B. wenn es keine Befehle hat).
- Es werden Animationen in Abhängigkeit vom Zustand abgespielt.
- Es werden Soundeffekte in Abhängigkeit vom Zustand abgespielt. Dabei wird die Kameraposition berücksichtigt.
- Die Effekte der Interaktion (Kampf, Ressourcen sammeln…) werden in der Spielwelt propagiert.
- Ändert z.B. die agierende Einheit direkt Werte bei der reagierenden? Können dann beide gleichzeitig “sterben”?
- Ändert die agierende Einheit Werte in der Welt? Wie ist da der Datenfluss? Muss die Einheit Dinge wie “Global Ressources” direkt kennen? (Law of Demeter, SoC, Tell dont ask)
Ich bin der zweite Spieler… (alles von oben)
- Die Beschreibungen funktionieren für den zweiten Spieler (z.B. im Netzwerkspiel für den Client).
- Die Eingaben so abstrahiert, dass sich Spieler und KI (oder Netzwerkspieler) ein gemeinsames Interface teilen.
Ich bin bereits im Spiel (o. im Pausenmenü) und speichere das Spiel ab.
- Der aktuelle Spielzustand wird vollständig persistiert.
Ich bin bereits im Spiel und öffne die Optionen. Ich ändere…
- Die Änderung der Auflösung wird durch das Spiel propagiert (wird dabei alles neu geladen?).
Weitere Szenarien
Die Dozenten (und gerne auch Tutoren) überlegen sich weitere Szenarien anhand des geplanten Spiels.