Frage von xNeco, 4

Eigenes Spiel + zugehöriger KI entwickeln?

Hey Leute,

ein Freund und ich programmieren schon seid einigen Jahren zusammen verschiedenste "kleinere", aber aufwendige Programme. Jetzt wollten wir uns an das chinesische Spiel "GO" rantrauen. Spricht eben das Spiel, dass man Steine setzen kann etc und auch erkannt wird, wenn jemand gewonnen hat. Wir wollten es direkt mit einer KI versuchen, und sind momentan am Überlegen, mit welcher Sprache wir das Ganze am besten realisieren können.

PS: Ich möchte bitte wirklich hilfreiche Kommentare, Tips & Tricks zum programmieren der KI etc.

Antwort
von Palladin007, 4

Die Sprache ist erst einmal egal, solange sie objektorientiert ist. Ist sie das nicht, dann wird's umständlich.

Ich bevorzuge für praktisch alles C# und WPF. Sehr hohe Flexibilität, riesige Community, zig unterstützende Frameworks, hevorragende kostenlose IDE gegen die sowas wie Eclipse als trauriges Häufchen unter geht.

Erst wenn es wirklich um high-performance geht, solltest Du die C++ anschauen und das ist in deinem Fall nicht so.

An sich ist das kein wirklich kompliziertes Spiel, ich würde sagen: Einfach mal anfangen und schauen, was für Probleme auf euch zukommen. Da ihr das privat macht, könnt ihr auch scheitern ohne dass direkt ein Chef die Uhr unter eure Nasen hält.

Eine KI würde ich aber nicht anfangen, bei einer halbwegs guten Software-Architektur kann das leicht ergänzt werden, wenn das Spiel bereits steht.

Was diese Software-Architektur angeht, ist wichtig, dass ihr die Abhängigkeiten zwischen den Bereichen reduziert und zirkuläre Abhängigkeiten um jeden Preis vermeidet. So sehe ich das Speichern/Laden von Spielständen als eigenen Bereich. Die Oberfläche natürlich ebenfalls. Dazwischen agiert die Engine, die den aktuellen Spielverlauf regelt und z.B. auch prüft wann wer gewonnen hat oder einen neues Spiel startet. Als letzten großen Bereich sehe ich ein Input-Interface. Für eine Person vor dem Bildschirm wird dieses Interface relativ simpel implementiert und durch die UI gesteuert. Für eine KI fällt diese Steuerung weg, die Implemntierung ist dann die KI.
Schichten-Architektur und MVC sollten dabei ein Begriff sein. Wenn ihr mit WPF arbeitet, kommt noch MVVM (als Variante von MVC) dazu.
Der Name Dependency Injection und Inversion of Control ist sicher auch keine schlechte Lektüre.

Grob umrissen:
Ein Interface für Speichern, eins für Laden. Die agieren mit "dummen" Daten-Objekten, die den aktuellen Spielstand darstellen und die zwischen Engine und Speichern/Laden hin und her gereicht werden können.
Die Engine bekommt rein aus Prinzip auch ein Interface, wo die Engine genutzt wird, muss die Implementierung dann nicht mehr bekannt sein, es wird nur mit dem Interface gearbeitet.
Das Input-Interface für die Spielzüge kann den aktuellen Spielstand abfragen bzw. bekommt ihn von der Engine geliefert. Außerdem kann es der Engine indirekt mit teilen, welche Spielzüge gemacht werden sollen.
Die UI lässt sich ebenfalls von der Engine über den Spielstand informieren, um das ganze darstellen zu können.
Die Mensch-Spieler-Implementierung des Input-Interfaces existiert alleine. Sie bietet einfach nur das Mitteilen, welcher Spielzug gemacht werden soll, für die UI an und reicht durch.
Die KI-Implementierung scannt permanent den aktuellen Spielstand und berechnet den optimalen nächsten Spielzug. Wie das gehen soll: Hört euren Gedanken beim Spielen zu und beachtet, was ihr macht. Das lässt sich bei Spielen sicher irgendwie als KI übernehmen. Als Skallierung für den Schwierigkeitsgrad würde ich die Anzahl Runden nehmen, die die KI voraus berechnet. Ich denke mal, weiter als 10 Runden alle möglichen Spielzüge voraus berechnen und dazu eine Wahrscheinlichkeitsrechnung aufstellen, tun die wenigsten und sollte daher als Schwer eingestuft werden. :D

Nochmal in kurz:
Die UI hat ein Objekt vom Engine-Interface und bekommt von ihr mitgeteilt, wie die Steine liegen, ob wer gewonnen hat, ob ein Zug geschehen ist, etc.
Die UI hat ein Objekt, dem sie sagen kann, welcher Stein auf welches Feld gelegt werden soll und dieses Objekt tunnelt das an die Engine weiter.
Die KI-Implementierung agiert eigenständig und unabhängig.
Die UI hat auch Objekte von den Speichern/Laden-Interfaces und kann ihnen das Engine-Objekt zum Laden bzw. Speichern übergeben.

Eine Trennung von Model und ViewModel (MVVM) würde ich an der Stelle nicht tun. Die "dummen" Objekte (z.B. Stone) sind so simpel, dafür eigene ViewModels zu erstellen, halte ich für overkill.

Selbst wenn es ein Multiplayer werden soll, dann könnte die Input-Interface-Implementierung geändert werden, sodass sie über das Netzwerk abläuft.
Speichern und Laden würde ich dann allerdings regelmäßig automatisch machen lassen, damit auch beim Verbindungs-Abbruch sicher gestellt ist, dass nichts verloren geht.
Die UI liegt dann beim jeweiligen Spieler als Input-Interface-Implementierung. Den Spielstand kannst Du dort genauso abfragen, wie die KI das tut.

Das als grobe Skizze, wie ich das anpacken würde. Sicher gibt es in dem Konzept Lücken, aber es ist 1 Uhr morgens, da kann man mir das mal verzeihen :D

Kommentar von Palladin007 ,

PS:

Sowas wie irgendein Game-Maker-Studio würde ich nicht nutzen. Was ich in dem Bereich bisher gesehen habe, sah mehr nach einer Klick-Spielerei für Kiddies aus, die sagen wollen "Ich kann ein Spiel programmieren", nicht nach Programmieren.

Bei so einem kleinen Spiel reicht WPF völlig aus, damit hab ich dir die Oberfläche ruck zuck zusammen gebastelt und die ist dann sogar noch dynamisch in der Oberfläche, mit wählbarem Design und funktionsfähig :D Vorausgesetzt, das Spiel dahinter wurde bis dahin umgesetzt.

WPF ist da sehr flexibel und mit den nötigen Kenntnissen vereinfacht es die Arbeit sehr.

Keine passende Antwort gefunden?

Fragen Sie die Community