Architekturentscheidungen angepasst

Simon Wilkening 2024-12-02 07:05:02 +01:00
parent 7e85a4d4b0
commit 4377759b46
4 changed files with 114 additions and 16 deletions

@ -1,6 +1,33 @@
Hier werden sonstige Abweichungen von der Designphase veröffentlicht
Hier werden Abweichungen von der Designphase veröffentlicht
<details>
<summary>Allgemeines</summary>
**Abweichungen von vorherigen Phasen**
* Alle graphischen Änderungen gegenüber den vorherigen Phasen sind in den folgenden Menüs zu finden! Diese folgen immer folgendem Muster:
* Alte Skizze
---
* neue Skizzen
**Gebäudebesitzkarte: BuildingProperty**
* Der Ausdruck "Besitzerkarte" über dem Gebäudenamen wird entfernt
* Die Kosten für das Hotel werden nicht seperat angegeben
Sonstiges:
* Das "Spielmenü" wurde in "Einstellungen" umbenannt
* In dem Startmenü wurde der Knopf für die Einstellungen entfernt
* Das "€"-Zeichen wird nicht angezeigt:
* Lösung: statt 2000 € wird 2000 EUR ausgegeben
</details>
---
@ -211,23 +238,15 @@ Hier werden sonstige Abweichungen von der Designphase veröffentlicht
</details>
---
<details>
<summary>Änderungen bei den Architekturentscheidungen</summary>
**Abweichungen von der Analysephase**
* Neu hinzugekommen: notificationAnswer, alterProperty, notificationMessage, TradeReply
* buyPropertyRequest und buyPropertyResponse haben den Namen getauscht
**Gebäudebesitzkarte: BuildingProperty**
* weitere Infos in den [Architekturentscheidungen_V1.4](../uploads/Implementierungsphase/Architekturentscheidungen/Architekturentscheidungen_V1.4.md)
* Der Ausdruck "Besitzerkarte" über dem Gebäudenamen wird entfernt
* Die Kosten für das Hotel werden nicht seperat angegeben
</details>
**Sonstige aktualisierte Skizzen**
Sonstiges:
* Das "Spielmenü" wurde in "Einstellungen" umbenannt
* In dem Startmenü wurde der Knopf für die Einstellungen entfernt
* Das "€"-Zeichen wird nicht angezeigt:
* Lösung: statt 2000 € wird 2000 EUR ausgegeben

@ -0,0 +1,3 @@
Hier finden Sie die angepassten Architekturentscheidungen aus der Implementierungsphase
* [Architekturentscheidungen_V1.4](../uploads/Implementierungsphase/Architekturentscheidungen/Architekturentscheidungen_V1.4.md)

@ -64,6 +64,7 @@ Schmelz Stubentür (20/0140)
- [Use Cases](./Implementierungsphase/Use-Cases)
- [Testhandbuch](./Implementierungsphase/Testhandbuch)
- [Klassendiagramme](./Implementierungsphase/Klassendiagramme)
- [Architekturentscheidugnen](./Implementierungsphase/Architekturentscheidugnen)
# Protokolle

@ -0,0 +1,75 @@
# Architekturentscheidungen
## Aufteilung Client Server
### Server-seitige Aktionen und Berechnungen
1. **Spielstart und Serververbindung**:
- Der Server wird beim Start des Spiels durch einen Spieler initialisiert, was anderen Spielern den Beitritt ermöglicht (UC-game-01).
- Spieler können sich über die Eingabe von Hostnamen und Portnummer zum Server verbinden (UC-game-07).
2. **Spielmechanik**:
- Zentrale Berechnungen wie die Würfelwürfe (UC-gameplay-02), Mietenberechnungen bei Grundstücksbesitz (UC-gameplay-08), und Strafzahlungen (UC-gameplay-20) werden serverseitig ausgeführt und anschließend an die Clients gesendet.
- Spielaktionen wie der Übergang ins Gefängnis (Gulag) oder der Kauf eines Grundstücks werden ebenfalls auf dem Server ausgeführt, da diese den Status der Spielwelt beeinflussen (UC-gameplay-09, UC-gameplay-07).
3. **Spielzüge und Spielerwechsel**:
- Die Verwaltung der Spielerreihenfolge und das automatische Beenden des Zugs bei Inaktivität erfolgen serverseitig (UC-gameplay-17, UC-gameplay-19).
4. **Handelsberechnungen**:
- Alle Berechnungen und Validierungen für Handelsangebote, z.B., Verifizierung der Verfügbarkeit von Grundstücken und Geldern beim Handel, werden serverseitig durchgeführt (UC-trade-07, UC-trade-08).
5. **Zustandsverwaltung der Spielwelt**:
- Änderungen in den Besitzverhältnissen, wie das Markieren von Grundstücken bei Kauf oder Verpfändung, werden zentral durch den Server verarbeitet und an alle Clients synchronisiert (UC-gameplay-10, UC-gameplay-14).
### Client-seitige Aktionen und Darstellungen
1. **UI-Interaktionen und Auswahlmöglichkeiten**:
- Der Client ermöglicht den Spielern, Menüs zu öffnen (z.B., Startmenü, Handelsmenü, Einstellungen) und eigene Aktionen wie den Würfelwurf oder die Auswahl von Handelsoptionen zu initiieren. Diese Aktionen lösen serverseitige Berechnungen aus, bleiben jedoch in der Steuerung und Interaktion clientseitig (UC-game-02, UC-trade-05, UC-menu-01).
2. **Anzeige und Soundeffekte**:
- Die Anzeige von Würfelergebnissen, Karteninformationen und Pop-Ups bei Ereignissen (z.B., Zahlung von Miete oder Startgeld) werden klientenseitig dargestellt. Soundeffekte werden durch clientseitige Trigger abgespielt (UC-sound-01, UC-gameplay-29).
3. **Echtzeit-Anzeigen**:
- Visualisierungen wie der Timeout-Counter und Anzeigen über das Vermögen der Mitspieler werden durch die Clients verwaltet und aktualisiert (UC-gameplay-36, UC-menu-12).
4. **Benachrichtigungen und Popup-Verwaltung**:
- Der Client verwaltet das Ausspielen und Schließen von Pop-ups und Warnhinweisen für den Nutzer, z. B., Timeout-Warnungen und Handelsofferten, die durch serverseitige Signale ausgelöst werden (UC-gameplay-40).
## Messages
### 1\. Verbindungsmanagement
- **Client → Server**: `ConnectRequest` Spieler sendet eine Anfrage, dem Server beizutreten (mit Hostname und Port).
- **Server → Client**: `ConnectionResponse` Antwortet, ob die Verbindung erfolgreich hergestellt wurde.
- **Client → Server**: `playerReady` Setzt den Status eines Spielers in der Lobby auf Bereit oder nicht Bereit.
- **Client → Server**: `DisconnectRequest` Spieler möchte das Spiel verlassen.
- **Server → Client**: `notificationMessage` Benachrichtigt den Client über Ereignisse oder löst Popups aus.
---
### 2\. Spielaktionen und -zustand
- **Client → Server**: `rollDice` Spieler fordert einen Würfelwurf an.
- **Server → Client**: `diceResult` Sendet das Ergebnis des Würfelwurfs an den Spieler.
- **Server → Client**: `eventDrawCard` Informiert über gezogene Ereigniskarten und deren Effekte.
- **Client → Server**: `buyPropertyRequest` Spieler möchte ein Grundstück kaufen.
- **Server → Client**: `buyPropertyResponse` Antwortet, ob der Kauf erfolgreich war.
- **Server → Client**: `JailEvent` Informiert den Spieler über den Eintritt ins oder Austritt aus dem Gulag.
- **Client → Server**: `alterProperty` Spieler möchte ein Grundstück verändern (z. B. bebauen oder verkaufen).
- **Client → Server**: `endTurn` Spieler signalisiert das Ende seines Zugs.
- **Server → Client**: `nextPlayerTurn` Teilt allen Spielern mit, welcher Spieler an der Reihe ist.
---
### 3\. Benachrichtigungen und Statusupdates
- **Server → Client**: `gameStart` Teilt mit, dass das Spiel beginnt und alle Spieler bereit sind.
- **Server → Client**: `gameOver` Informiert über das Spielende, entweder durch Bankrott eines Spielers oder weil ein Spieler gewonnen hat.
- **Server → Client**: `playerStatusUpdate` Sendet allen Spielern Statusänderungen von Mitspielern (z. B. Bankrott, neue Besitztümer).
- **Server → Client**: `timeOutWarning` Warnung an einen inaktiven Spieler, dass sein Zug bald automatisch beendet wird.
- **Server → Client**: `notificationMessage` Informiert den Client über Ereignisse oder Auslöser (z. B. Soundeffekte, Würfeln, Popup-Nachrichten).
- **Server → Client**: `notificationAnswer` - beantwortet Jail-Messages (z.B Bezahlen, Gulag-Karten benutzen)
---
### 4\. Interaktionen und Handelsmanagement
- **Client → Server**: `tradeOffer` Spieler sendet ein Handelsangebot an einen Mitspieler (enthält Details zu Geld, Grundstücken, etc.).
- **Server → Client**: `tradeRequest` Übermittelt das Handelsangebot an den ausgewählten Handelspartner.
- **Client → Server**: `tradeResponse` Antwortet auf ein Handelsangebot mit „Annehmen“, „Ablehnen“ oder „Gegenangebot“.
- **Server → Client**: `TradeReply` Übermittelt die endgültige Antwort an den Spieler, der den Handel initiiert hat.
- **Client → Server**: `viewAssetRequest` Spieler fordert an, die Besitztümer eines Mitspielers anzuzeigen.
- **Server → Client**: `viewAssetResponse` Antwortet mit einer Übersicht der angeforderten Besitztümer eines Mitspielers.