Aktuelle Entwicklung (V0.8.5dev)

    Waehrend A* durchaus Berechtigung hat, koennte fuer Bombzone Dijkstras Algo von Vorteil sein. A* ist fuer "von A nach B" eine praktikable Loesung. Mit Dijkstras Algorithmus kannst Du Speicher sparen (je mehr Felder, desto mehr Varianten, desto mehr Speicher benoetigt A*).
    de.wikipedia.org/wiki/Dijkstra-Algorithmus


    Vielleicht gibt es aber einen besseren Algorithmus
    de.wikipedia.org/wiki/Bellman-Ford-Algorithmus
    zum Beispiel?

    Warum? Stell Dir vor Du hast auf dem Weg von A nach B noch die Moeglichkeit ein paar Items einzusammeln - und vielleicht sorgt das Item fuer einen Umweg von "1-2 Feldern". A* wuerde das dann ignorieren bzw. muesstest Du da eventuell mit "Gewichtungen" tricksen. Mittels dem von mir vorgeschlagenem Algorithmus koenntest Du den Items statt positiver Gewichtung (in Abhaengigkeit von "Brauche Kicker", "Brauche mehr Bomben"-Prioritaeten) auch negative Werte mitgeben - sprich fuer platzierte Bomben Gewichtungen einbringen - so dass eben schon das "Risiko" auf einem solchen Feld zu landen minimiert wird.


    Wenn man das nun bestehende A* erweitert, landet man schnell bei D*.
    de.wikipedia.org/wiki/D*-Algorithmus
    Dieser Algo haette den Vorteil, dynamisch auf Aenderungen reagieren zu koennen. Mit A* wuerdest Du neuberechnen muessen.


    Unabhaengig davon kannst Du aber ja durchaus schon einen Plan haben, warum Du A* benutzen moechtest: In dem Fall einfach mein Gebrabbel ignorieren ;)


    PS: Ich finde es gut, dass Du die Foristen hier auf dem laufenden haeltst. PR-Arbeit ist muehsam, aber irgendwann zahlt sich das schon aus.

    bye
    Ron
    Dijkstras Algo ist auch schon vorhanden, habe ich zusammen mit A* integriert und funktioniert eigentlich schon gut.
    Genau dafür ist er dann auch gedacht, um Extras, Spieler, Bomben oder sowas zu finden.

    Um den Computergegnern "die Sicht" auf das Spielfeld zu berechnen, werde ich eine Dirtyliste führen, bei jeder Veränderung, welches mit einem Feld zu tun hat, fülle ich eine Dirtylist. Dieser werde ich pro Frame von oben nach unten abarbeiten (eine Fixe Anzahl aus dieser Liste) und das Spielfeld entsprechend neu bewerten. Abhängig dieses bewerteten Spielfeldes können die Computerspieler dann versuchen zu reagieren.

    Ob ich Lua, Python oder eine andere externe Scriptsprachen verwende um an der "KI" zu schrauben weiss ich noch nicht. Ggf. werde ich erstmal alle Parameter in einer Configuration sammeln und dann entscheiden.

    Aber das erst, wenn ich alle möglichen Aktionen der Computergegner in Funktionen gepackt habe.

    Zum Testen werde ich in der nächsten Version mal Computergegner einbauen die nur versuchen zu überleben ;)

    Wenn Du es an ein Script weitergibst, dann braucht die KI eigentlich nur folgendes:
    - aufrufbare Methoden zur Steuerung ("links/rechts/hoch/runter", "bombe werfen", "trigger") - sprich das, was du schon aufs Gamepad/Keyboard mappst
    - Hilfsmethoden zur Spielfeldanalyse ("Was ist auf Block X,Y", "Auf welchem X,Y-Block bin ich", "Wie viel Rundenzeit ist noch?")
    - Hilfsmethoden zur Spielfiguranalyse ("Wieviele Bomben habe ich", "welche Powerups habe ich")
    - Hilfsmethoden zur Kontrahentenanalyse (koennte von der KI selbst gefuehrt werden, aber so ein Zugriff auf die "wer killt wen"-Statistik waere wohl anfangs auch hilfreich)
    - Gimmicks: Sprechblasen, Sounds abrufen ("Hey ich mach Euch fertig, baddaa bumm", "come and get some")

    Das ist aehnlich einer API zu sehen. Die Logik, das Spielfeld mit einer "Dirtyliste" zu verarbeiten, kann dann in Lua, Python, BMZScript geschehen. Am Ende Ihrer Ueberlegung kann die KI dem Spiel mitteilen "nach links bitte" (ob das machbar ist, entscheidet dann die Spiellogik) - oder "Lege Bombe" (ob noch Bomben verfuegbar, entscheidet Spiellogik).

    Von der Sache her braucht eine KI nicht einmal eine bereitgestellte Funktion "GetBombsLeftCount()" da sie ueber jede Bombe die sie legt ja Bescheid weiss - und jede eingesammelte ebenfalls.


    Ok, das waeren die aufrufbaren Funktionen - fuer jede spielerrelevante Aktion wuerde die KI dann einen Event uebermittelt bekommen muessen:
    - onBombExplosion(bombType, x, y, sender)
    - onFigureCollectsItem(itemType, x,y, sender)
    - onFigureDies(x,y, deathReason, sender)
    - onFigureKills(killedFigure, bombType, sender)
    - onFigureSwapsPosition(oldX, oldY, x, y, sender)
    ...
    Das sind alles die "beobachtbaren" Dinge - also von Spielern erkennbar, wenn sie alles gleichzeitig auf dem Bildschirm beobachten koennten. Dabei muessen immer gleichzeitig sichtbare Informationen weitergegeben werden (siehe "swapsPosition" und "oldX, oldY, x, y" - ist eine Figur "sofort" woanders, dann wuerde die "oldX, oldY" Information nicht weiterzugeben sein).

    Wenn als Beispiel die KI ein "onFigureDies(x,y, spieler1)" uebermittelt bekaeme, wuesste es:
    - Spieler 1 ist floeten gegangen
    - rufe fuer alle Spielfelder den neuen Zustand ab, damit ich weiss, wo die nun einsammelbaren Items herumliegen (falls nicht "sofort", benoetigt es eine "onItemAddedToTile(x,y, sender)" Funktion)

    Natuerlich ist obiges nicht vollstaendig und weit von perfekt. Ich finde aber, es wuerde ein rudimentaeres KI-Erstellen erlauben. Wichtig dafuer ist aber, dass die Steuerung komplett abstrahiert ist. Da darf also keine "player.Update()" Funktion bestehen, die ueberprueft ob ein Gamepad-"runter" gedrueckt ist oder nicht. Das muss alles ausserhalb der Funktionen geschehen. Denn dann ist es egal, ob ein Spieler oder ein Computer eine Figur steuert. Man koennte es auch so ausdruecken, dass es neben "Tastatur", "Gamepad" noch "KI" gaebe.


    Bitte entschuldige wenn Du dir hier "reingepfuscht" vorkommst. Sag Bescheid und ich halte mich diesbezueglich erstmal zurueck.

    bye
    Ron