Skip to content

Lerntagebuch

Jump to bottom
Carsten Gips edited this page Mar 27, 2022 · 4 revisions

Inhalte

  • Beschreibung der Aufgabe
  • Modellierung
  • Umsetzung
  • Post Mortem

Format

Markdown, als Wiki im Studi-Team-Repo (dadurch sind die Einträge untereinander verlinkbar)

Alte Vorlage / Beispiel

Vorlage

---
title:  'Lerntagebuch zur Bearbeitung von Blatt XYZ'
author:
- VORNAME NAME (EMAIL)
- VORNAME NAME (EMAIL)
- VORNAME NAME (EMAIL)
...

<!--
Führen Sie zu jedem Aufgabenblatt und zum Projekt (Stationen 3-9) ein
Lerntagebuch in Ihrem Team. Kopieren Sie dazu diese Vorlage und füllen
Sie den Kopf entsprechend aus.

Im Lerntagebuch sollen Sie Ihr Vorgehen bei der Bearbeitung des jeweiligen
Aufgabenblattes vom ersten Schritt bis zur Abgabe der Lösung dokumentieren,
d.h. wie sind Sie die gestellte Aufgabe angegangen (und warum), was war
Ihr Plan und auf welche Probleme sind Sie bei der Umsetzung gestoßen und
wie haben Sie diese Probleme gelöst. Beachten Sie die vorgegebene Struktur.
Für jede Abgabe sollte ungefähr eine DIN-A4-Seite Text erstellt werden,
d.h. ca. 400 Wörter umfassen. Wer das Lerntagebuch nur ungenügend führt
oder es gar nicht mit abgibt, bekommt für die betreffende Abgabe 0 Punkte.

Checken Sie das Lerntagebuch mit in Ihr Projekt/Git-Repo ein.

Schreiben Sie den Text mit [Markdown](https://pandoc.org/MANUAL.html#pandocs-markdown).

Geben Sie das Lerntagebuch stets mit ab. Achtung: Wenn Sie Abbildungen
einbetten (etwa UML-Diagramme), denken Sie daran, diese auch abzugeben!

Beachten Sie auch die Hinweise im [Orga "Bewertung der Aufgaben"](pm_orga.html#punkte)
sowie [Praktikumsblatt "Lerntagebuch"](pm_praktikum.html#lerntagebuch).
-->


# Aufgabe

<!--
Bitte hier die zu lösende Aufgabe kurz in eigenen Worten beschreiben.
-->

tbd


# Ansatz und Modellierung

<!--
Bitte hier den Lösungsansatz kurz beschreiben:
-   Wie sollte die Aufgabe gelöst werden?
-   Welche Techniken wollten Sie einsetzen?
-   Wie sah Ihre Modellierung aus (UML-Diagramm)?
-   Worauf müssen Sie konkret achten?
-->

tbd


# Umsetzung

<!--
Bitte hier die Umsetzung der Lösung kurz beschreiben:
-   Was haben Sie gemacht,
-   an welchem Datum haben sie es gemacht,
-   wie lange hat es gedauert,
-   was war das Ergebnis?
-->

tbd


# Postmortem

<!--
Bitte blicken Sie auf die Aufgabe, Ihren Lösungsansatz und die Umsetzung
kritisch zurück:
-   Was hat funktioniert, was nicht? Würden Sie noch einmal so vorgehen?
-   Welche Probleme sind bei der Umsetzung Ihres Lösungsansatzes aufgetreten?
-   Wie haben Sie die Probleme letztlich gelöst?
-->

tbd

Beispiel

    ---
    title:  'Lerntagebuch Beispiel'
    author:
    - André Matutat
    ...


    # Aufgabe

    Das Dungeon soll um mindestens zwei Monster erweitert werden. Die Monster sollen
    unterschiedliche Eigenschaften haben und sich zufällig im Dungeon bewegen.

    # Ansatz und Modellierung

    Da mehrere Monster erstellt werden sollen, diese sich jedoch viele Eigenschaften
    teilen, wird eine abstrakte Klasse `Monster` als Basisklasse für Monster erstellt.
    Die `Monster`-Klasse stellt alle grundlegenden Eigenschaften und Funktionen eines
    Monsters bereit.

    Da Monster auch im Dungeon gezeichnet werden müssen, implementiert die Klasse
    `Monster` das Interface `IDrawable`. Die Monster sollen vom `EntityController`
    verwaltet werden, daher implementiert die Klasse auch das Interface `IEntity`.

    Monster haben zusätzlich folgende Grundeigenschaften:

    -   `float Lebenspunkte`: Geben die verbleibenden Lebenspunkte des Monsters an
        -   Hat das Monster 0 Lebenspunkte, wird es mit Hilfe der `deletable`-Methode
            aus dem `EntityController`entfernt.
    -   `float hSpeed`: Die Geschwindigkeit, in der sich das Monster horizontal bewegt
    -   `float vSpeed`: Die Geschwindigkeit, in der sich das Monster vertikal bewegt
    -   `float dmg`: Den Schaden, den das Monster im Kampf macht
    -   `dungeonWorld level`: Genau wie der Held müssen auch Monster das Level kennen,
        um sich darin zu bewegen. Wird im Konstruktor gesetzt.

    Monster haben zusätzlich folgende Grundfunktionen:

    -   `void move()`: Bewegt das Monster in eine zufällige Richtung

        Dafür verwenden wir zwei Zufallszahlen: Die erste Zahl gibt an, ob sich das
        Monster nach rechts oder links bewegt, die zweite Zahl, ob sich das Monster
        nach oben oder unten bewegt. Zusätzlich gibt es die Chance, dass ein Monster
        sich gar nicht bewegt.

        ```java
        int linksOrechts = getRandomZahl(0,1);
        int obenOunten = getRandomZahl(0,1);

        //30% Chance, sich nicht zu bewegen
        if (getRandomZahl(0,100) > 30) {
            //horizontal
            if (linksOrechts == 0) {
                this.x += this.hSpeed;
            } else {
                this.x -= this.hSpeed;
            }

            //vertikal
            if (obenOunten == 0) {
                this.y += this.vSpeed;
            } else {
                this.y -= this.vSpeed;
            }
        }
        ```

    -   `void getHit(float dmg)`: Zieht dem Monster Lebenspunkte ab
    -   `float getDMG()`: Gibt Schaden zurück
    -   `getRandomPosition()`: Wird im Konstruktor aufgerufen, sucht sich eine
        zufällige Position im Dungeon als Spawn-Punkt


    Daraus ergibt sich folgendes UML:

    ![Klassendiagramm der angedachten Lösung](figs/lerntagebuch/tagebuch_uml.png)


    Beschreibung der konkreten Monster:

    1.  Zombie:
        -   Hat 5 Lebenspunkte
        -   Macht 0.5 Schaden
        -   Bewegt sich sowohl vertikal als auch horizontal mit 0.1f
        -   Bewegt sich in eine zufällige Richtung

    2.  Einbeiniger Pirat:
        -   Hat 3 Lebenspunkte
        -   Macht 1 Schaden
        -   Bewegt sich nur horizontal
            -   hSpeed=0.2f;
            -   vSpeed=0f;


    Monster werden beim Laden eines Levels im Dungeon verteilt. Dafür erstellen
    wir die Funktion `spawnMonster` in unserem `MainController`, welche in der
    `onLevelLoad`-Methode aufgerufen wird.

    `spawnMonster` erstellt eine zufällige Anzahl an Monstern (zwischen 5 und 10),
    platziert diese mit Hilfe von `getRandomPointInDungeon` (wie beim Helden) im
    Dungeon und fügt Sie dem `EntityController` hinzu.

    Verlässt der Spieler das Level, werden alle Monster aus dem `EntityController`
    gelöscht. Dafür wird die gesamte Liste des `EntityController` gelöscht und der
    Held neu hinzugefügt.


    # Umsetzung

    28.04.

    -   Erstellen der Monster-Klasse nach Modellierung (1h)
    -   Erstellen der spezifischen Monster nach Modellierung (1h)
    -   Monster im Dungeon spawnen lassen nach Modellierung (1h)
    -   Implementierung einer zusätzlichen Kollisionsabfrage in der `move`-Methode (0.5h)


    # Postmortem

    Da wir uns viel Zeit und Gedanken bei der Modellierung der Lösung gemacht haben,
    konnten wir diese fast wie geplant umsetzen.

    Wir sind auf ein Problem bei unserer Modellierung gestoßen: Unsere Monster bewegen
    sich auch durch Wände. Die Lösung ist, in der `move`-Methode genau wie beim Held eine
    Kollisionsabfrage durchzuführen. Ist das Feld unbetretbar, bewegt sich das Monster
    dadurch in diesem Frame nicht.

    Durch unsere Monster-Basislasse können wir auch in Zukunft schnell und einfach neue
    Monster im erstellen (Geister, welche durch Wände gehen können?!).
Clone this wiki locally