---
# System prepended metadata

title: Projekt 2d Strategie Spiel

---

# Projekt 2d Strategie Spiel

## Design

### Sprint 1 (2-3 Monate):

0. Project / workflow setup
    - Navigaion between repos and projects
    - Basic folder structure

1. User Interface 
    - Start Menu
    - Settings
    - Controlls
    - Load Screen
2. CI
    - linting
    - formater / check
    - (tests)
3. Game planing (Markdown)
    - Game idea with simple pictures
    - UI Layout
4. Tilemap


6. Buildungs
    - placing buildings (get x,y position)
    - create json file
    - json - save game
    - Definition of done -> game can be saved and loaded 



### Grundlegendes Konzept:
* Echtzeit-Strategie
* 2D-Grafik (Sprites, UI, Karte)
* Aufbaumechanik und Entwicklung
* Arbeiter Einheiten System
* Function before Form
* Gebäude stehen auf mindestens einem Tile, aber nicht weniger

### Ungeklärt
#### Essentiell
- Spielname
- Definierende Eigenschaft des Spiels (Mechanik/Grafik/Sound/Story/Welt/...)
- Wie unterscheidet sich unser Spiel von existierenden?
- Sprite Perspektive:
    - von oben
    - schräg von oben
    - abstrakte symbole
- Grundlegende Steuerung
    - Camerabewegung
    - Gebäudeplatzierung (Drehung?)
    - (Einheitenbewegung?)
- Exakte liste grundlegender Gebäude und Resourcen (ohne die das Spiel nicht funktioniert)
- Ziel des Spiels
- Pixel auflösung von Sprites / Vektorgraphik
    - Pixel pro tile
- Eigene Graphik vs. Asset Store vs. Mischung
- Implementationsdesign
    - UML Diagramme für Grundlegenden Funktionalitäten
        - Navigation
        - Selektion
        - UI
        - 
    - Art der Verwendung von Nodes zum Splitten von Behaviours für:
        - Parallel laufende Behaviours
        - State Machines
    - Plugins?

#### Optional
- Coding richtlinien (zum besser koordinierten Zusammenarbeiten)
    - Reihenfolge und Gruppierung von variablen in GDScript
    - Signals vs. Callbacks
        - Wann sollten Signals verwendet werden, wann Callbacks, wann keines von beidem
    - Dokumentierung von Funktionen, Variablen, Signals, etc.
        - Immer während der implementation vs. Später wenn benötigt
        - Was muss immer dokumentiert sein
            - Funktionen
            - Variablen
            - etc.
        - Was sollte auserhalt der Scriptdatei Dokumentiert werden (und wie: e.g. Markdown)
    - Wie sollten Aufgaben generell getrennt werden
        - Gleichzeitige bearbeiten der selben Datei zur Not erlauben?
        - Verwendung von UML zur abstimmung
            - Wie sollen Signals und Duck-Typing modelliert werden?

#### Spätere Überlegungen
- Gibt es Vorteile/Nachteile für nicht an Tiles gebundene Gebäudepositionen?

## Roadmap (TODO: Muss überarbeitet werden, Reihenfolge ist suboptimal, Planungsphasen fehlen):
1. Tilesystem in GODOT
2. Learn GDScript
3. Überlegung wie werden Classen (Gebäude, Einheiten) aufgebaut, wie hängen sie zusammen wie wird vererbt --> Klassendiagramm
    1. Requirement: Möglichst viel Abstrahieren
4. Koordinaten handling, Tile-Koordinaten vs Weltkoordinaten --> schnelle/effiziente Transformation
5. Speichern des Spielstands/Aktuelle Konfiguration
6. (Godot TCP JSON Protocol, Verbindung aufbauen, Server-Client Kommunikation)
7. Basic User Interactions
    1. Kamera Navigation (Maus am Rand der Karte)
    2. Zoomen, Übersichtlichkeit (Mausrad)
8. Gebäude Baumechanismus
    1. Einfaches Baumenu
        1. Klick auf Menü, Klick auf Karte
            1. Durchsichtiges Gebäude an der Mausposition
            2. Erstmal kein Bau Preview
            3. Erstmal keine Baustelle
            4. Für Gameobjekte eigenes Menü das zugehörige Informationen anzeigt
    2. Ohne Bauanimation und ohne Kosten
    3. Verschiedene Gebäude mit Informationsmenu
9. Ressourcenmanagement (Gebäude/Einheitenkosten)
10. Kampfsystem


### Mögliche Erweiterungen:
- Baubegrenzung (radial)
- Evtl. Territorium Mechanik
- Isometrische Tiles 
- Mini Map
- Entweder Online Multiplayer
    - TCP Verbindung mit Struct der alle Attribute der Gameobjects enthält
- AI für lokales Spiel
- Baustelle mit Transport von Baumaterialien von z.B. Lager oder Haupthaus
- Handel, Ressourcen müssen zum Spieler transportiert werden 
- Konzept Forschung vs Handel
    - Indirekte Forschung
    - Nur eine Richtung



## Skelett Implementierung für Human/AI Agents

```python
class Agent:
    app: App
    def laufen(self):
        # aoösijdg
    def drehen(self):
        # asöokfgj
    def get_list_of_units(self) -> list:
        assert x > 5
        if x > 5:
            return list
        else:
            return None
        # return sladsgjöoads
    def behaviour(self):
        pass


class HumanAgent(Agent):
    def behaviour(self):
        # wait for user input events, and handle them somehow
        if event:
            self.laufen();

class AIAgent(Agent):
    def behaviour(self):
        # do something intelligent
        self.laufen();
        if len(self.get_list_of_units()) > 100:
            angrif()
        if angegriffen: defend()



class App:
    agents: list[Agent] = [HumanAgent(), AIAgent()]
```


## Next Steps
### UI:
- [ ] TBD 
### Objects:
- [ ] create building class 
    - [ ] make it work with signal
    - [ ] make it placable via ui
### Entities:
- [ ] implement behaviour trees (Beehave Plugin) for AI-character movement
- [ ] more units
![](https://hackmd.io/_uploads/rkZCZS6V2.png)
### Map:
- [ ] create/import more tiles 
    - [ ] add navigation layer 
- [ ] make tilesets work with autotileing
- [ ] (auto map generation)


