GAKI

04 Project Basics

Yannik Brändle - SoSe26

TH Bingen

Heutige Themen

  • Gamedev Projekt Grundlagen
    • Source Control
    • Task Tracking
    • Typische Tücken
  • Pathfinding Vertiefung
    • Dijkstra
    • A*
    • Grid vs Graph
    • Godot Navagent

Was ist "Source Control" und "Git"?

  • Git ist eine der bekanntesten Source-Control Systeme
  • Man kann sehr gut Schritt für Schritt veränderungen von Source code tracken
  • Gemacht für text basierte Dateiformate
  • "Binary" Dateien können auch getracked werden, aber schwieriger

Source Control Funktionsweise

  • Jede Veränderung (auch Erstellung) einer Datei wird "committed"
  • Dabei wird die Verändung in einem commit gespeichert
  • Diese können dann in der Regel automatisch vereint (merged) werden
  • Man kann sich auch die differenzen anzeigen lassen

Beispiel Git Diff in vscode

Git branches

  • Gut zum Testen
  • Einfacheres Parallel arbeiten (weniger merge konflikte)
  • Man kann einfacher den Stand eines Teammitglieds ansehen/testen

Gute Lernressource: https://learngitbranching.js.org/

Alternativen:

  • Git ist sehr weit verbreitet, vor allem für Sourcecode
  • Bei Spielen gibt es oft viele "Assets", welche idR Binaries sind
  • Bei Datei größen > 50MiB warnt GitHub beim upload
  • > 100MiB große Dateien werden komplett geblockt
  • Bei kleinen Spielen mit Assets <= 30MiB kein Problem normal Git zu nutzen
  • Git LFS für größere Dateien (Achtung: Bei GitHub nicht kostenlos)
  • Sonst auch Gamedev Industriestandard: Perforce statt Git

Task Tracking

  • Oft nimmt man "Kanban Boards"
  • Unterteilt in Backlog, In Progress, (Review) Done
  • Kann man beliebig Anpassen und "Zweckentfremden"

Source: Wikipedia Kanban → https://en.wikipedia.org/wiki/Kanban_board#/media/File:Abstract_Kanban_Board.svg

Echtwelt Beispiel aus einem Gamejam (Trello)

Hilft auch wenn es nicht perfekt befolgt wird!

Typische Tücken Bei Gamedev

  • Gleichzeitiges Arbeiten an Szenen
    • Godot's Szenenformat .tscn steht für "TextScene"
    • Kann dadurch besser durch Version Control Verwaltet werden als die Szenen der meisten Engines
    • Trotzdem führt paralleles Arbeiten an einer Szene oft zu Merge Konflikten
    • → Besser Komponenten in eigene Szenen auslagern und absprechen wer woran arbeitet
    • (Vorteil bei Perforce: "Exclusive Lock" bei Dateien um alleiniges Arbeiten sicherzustellen)
  • Scope Creep
    • Gamedev tendiert sehr schnell und oft zu Scope Creep
    • Immer sehr velockend noch eine "Kleinigkeit" hinzuzufügen
    • Oft gibt es unangenehme Teile an Spielen die man Prokrastiniert
    • → Versuchen die Scope am anfang des Projektes stark einzugrenzen mit der Erwartung, dass Scope Creep ohnehin eintritt
  • Pareto Prinzip
    • Auch bekannt als 80/20 Regel
    • 80% der Zeit wird gebraucht für die letzten 20% des Spiels
    • Durch typische "übersehenen" Teile eines Projekts oft unerwartet
      • Bugfixing
      • Polishing
      • Menu Flow & UX
      • ...

Pathfinding

Dijkstra

Von https://qiao.github.io/PathFinding.js/visual/ 

              Funktion Dijkstra(Graph, Startknoten):
    initialisiere(Graph,Startknoten,abstand[],vorgänger[],Q)
    // Der eigentliche Algorithmus
    solange Q nicht leer:
        u := Knoten in Q mit kleinstem Wert in abstand[]
        // für u ist der kürzeste Weg nun bestimmt
        entferne u aus Q
        für jeden Nachbarn v von u:
            // falls noch nicht berechnet
            falls v in Q:
               // prüfe Abstand vom Startknoten zu v
               distanz_update(u,v,abstand[],vorgänger[])
    return vorgänger[]

Quelle: Wikipedia https://de.wikipedia.org/wiki/Dijkstra-Algorithmus

  • Garantiert kürzester Pfad
  • Probiert zu viel "unnötig"
  • Findet Theoretisch viele Pfade zum Startknoten durch Vorgänger

Idee: Dijkstra mit Schlauem Ausprobieren

A* im Details
    • f(n) = g(n) + h(n) → geschätzte Gesamtkosten
    • g(n) → Kosten vom Startknoten
    • h(n) → Heuristik: geschätzte Kosten zum Ziel
    • Offene Liste → zu bewertende Knoten
    • Geschlossene Liste → bereits bewertete Knoten
    • Heuristik-Regeln:
      • Muss zulässig sein (überschätzt niemals)
      • Oft Manhattan für Gitter, euklidisch für kontinuierlichen Raum

    A* Step-By-Step

    A* Step-By-Step

    A* Step-By-Step

    A* Step-By-Step

    A* Step-By-Step

    A* Step-By-Step

    A* Step-By-Step

    A* Step-By-Step

    Grid vs Graph

    • Nicht alle Pathing Probleme in Gamdev sind "normale" Grids
    • Oft auch Graphen
    • Oder schlimmeres...

    😱

    Quelle: https://www.redblobgames.com/grids/hexagons/

    Spielbeispiel (Alchemist Assembly)

    Lösung: Ein Graph!

    Abstrakteres Beispiel (Froggo Jump)

    Verbindung der Platformen selbst

    Nach Sprungtests

    Pathfinding In Aktion

    Godot NavigationAgent2D

    FIN