ZFX + Developia

Endlich vollständige Beleuchtung (mit Schatten) in den Reflexionen. Ja, das Aliasing und die Normals sind grausig.

Noch weniger als eine Woche bis zur Abgabe der Arbeit, deshalb vorerst keine weiteren Ausführungen.


Zurück ans Schreiben ...

Sieht super aus!

Vielleicht kannst du das noch etwas blurren, wie sie es hier gemacht haben: http://www.gamedev.net/topic/624752-glo ... flections/ ?

Beeindruckend. Blur finde ich absolut nötig; sobald der drin ist, könntest du so Sachen machen wie Mip Maps mehr blurren als die voll detaillierten Oberflächen, bei flacher Betrachtung klarere Reflexionen als bei frontaler Draufsicht, usw usf … vorausgesetzt, du kannst Raytracing nach der Abgabe überhaupt noch sehen und würgst nicht bei bloßer Erwähnung des Worts schon ein Fellknäuel hoch.

Sieht hervorragend aus; anscheinend konntest du die Geschwindigkeit ziemlich gut optimieren. ;)

Andre hat geschrieben:Vielleicht kannst du das noch etwas blurren

Krishty hat geschrieben:Blur finde ich absolut nötig

CodingCat hat geschrieben:Noch weniger als eine Woche bis zur Abgabe der Arbeit

Wenn ich von meiner BA-Erfahrung auf andere schließen darf, bedeutet das Alarmstufe Rot, lange Nächte und ganz sicherlich keinen Blur für euch in der nächsten Woche. :) (Wenigstens scheine ich damit nicht der einzige zu sein, der solche Arbeiten in letzter Sekunde abliefert.)

@Cironian: Erinnert mich extrem an dieses spezielle Lieblingsspiel das ich da immer noch habe :-) Schön, dass es noch andere gibt, die solche Spiele mögen. Bitte unbedingt fertig machen!

Melde mich mal wieder mit einem Zwischenupdate meines Musikvisualisierers. Mit Hilfe von Modifiern können jetzt nahezu alle Parameter der Visualisierung in Abhängigkeit beliebiger Frequenzen geändert werden, außerdem habe ich ein rudimentäres Labeling System eingebaut.

Und weil manchmal weniger auch etwas mehr ist, hier das neuste Video. Eine Hommage an Minecraft:
[youtube]D3nKnNCWCkY[/youtube]

Also, als erstes: ich wollte gerade anfangen zu schreiben, da fällt mein Kerzenständer von meinem Wahnsinns-Subwoofer... also die Musik is schon mal gut :)

Und ich verfolge immer die Demos von dir, und ich finde die immer klass.
Mal abgesehen davon ob das jetzt schwierig zu implementieren ist oder ganz einfach. Ich mag Musik und mag gecodete Animationen. Also ich finde dein Projekt schön. Ist aber eben nur meine Meinung, weißt ja... kann mit keine Projekt in irgendeiner art überzeugen.

Wenn ich aber trotzdem mal eine Idee einwerfen könnte:
Hab das ja auch mal getestet... habs aber leider nicht so recht zum laufen bekommen bzw. es passierte nichts.
Ich würde mich echt freuen, wenn man eine schöne Nutzerfläche drumrum basteln könnte. Also hübsches GUI und idiotengerechtes Handling. Und wenn man nicht nur WAV-Files als Audio-Input verwenden könnte, sonder auch zB mp3 und ogg, wäre das noch um einiges toller. Aber ich denke mal, das würde einigen Aufwand machen.
Mit dem GUI und so, da könnte ich sogar etwas helfen. Arbeite beruflich mit Qt... also könnte da mit was Kleinem etwas beisteuern.

Ansonsten finde ich das toll.

Gruß

[Edit]
Ich sehe du benutzt die SDL. Also scheint es ja doch ein GUI oder so zugeben. Sorry!
Aber nun die schlechte Nachricht:
Es funktioniert wieder/immernoch nicht. Bin hier auf Arbeit, und habe nur ne billig-Grafikkarte. Aber ich poste mal die _errror.txt

6:33:32.772 Warning| Fehler in Hauptschleife
6:33:32.772 Info| Fehler ist in Hauptschleife angelangt, Abbruch.
6:33:32.771 Warning| Fehler in Scene.Update Soundbild
6:33:32.771 Warning| Access Violation
6:33:32.771 Info| Fehler in AnimationManager.Update
6:33:32.771 Info| Fehler in Szene GameClock: Access Violation
6:33:32.727 Warning| DataMemory: unable to Update, specs.length=25, needs to be 46
6:33:32.727 Info| Start Audio Capture
6:33:31.698 Info| Starting Gameengine
6:33:31.698 Info| Init Soundbild done
6:33:31.698 Info| new Node: screenLabels
6:33:31.698 Info| CreatedEmptyNode videoScale
6:33:31.698 Info| new Node: videoScale
6:33:31.698 Info| CreateEmptyNode videoScale
6:33:31.698 Info| CreateCamera scene3DCam
6:33:31.698 Info| new Node: scene3DCam
6:33:31.698 Info| CreateCamera scene3DCam
6:33:31.698 Info| CreatedFBO fboVideoNode
6:33:31.698 Info| new Node: fboVideoNode_root_0
6:33:31.698 Info| New FBO, textureCount: 1

Hoffe hilft Dir etwas :)

hi Joggel,

erstmal vielen Dank für dein Feedback. Eine Gui gibt es durchaus, wenn auch die Adjektive schön und benutzerfreundlich wohl eher nicht zutreffen. Sie ist am linken Rand versteckt und wird eingeblendet, sobald der Mauszeiger sich diesem annähert.
Wenn sich die Visualisierung nicht bewegt, musst du unter Windows bzw. im Soundtreiber die Standard-Aufnahmequelle ändern. Mit "Stereo-Mix" oder im neuen Windows heißt es glaube ich "was Sie hören", wird alles was du hörst visualisiert - egal ob Webradio oder MP3s.

zu deinem Fehler schicke ich dir noch eine Nachricht hier über das Forum. Der Thread heißt ja Showroom und nicht Fehleroperationszimmer ;)

Die Musik gefällt mir ebenso gut, soundcloud sei Dank, kann man ja heutzutage sehr einfach mit tollen Musikern in Kontakt treten.

zu deinem Fehler schicke ich dir noch eine Nachricht hier über das Forum. Der Thread heißt ja Showroom und nicht Fehleroperationszimmer ;)

stimmt. hatten wir ja schon das letzte mal. Ich vergas...

Ich wollt es auch gerade ausprobieren, leider funktioniert es bei mir auch nicht (Windows 7 64bit, NVIDIA GeForce GTX 560 Ti).

Nun auch nochmal ein 2ter Bericht von mir, ein positiver :)
Zu Hause an meinem Rechner funktioniert es jetzt! Dolles Spielzeug :)

Version: 0.71p

Wollte gerade Video mitschneiden, geht aber nicht.
Ist nichtmal aktiv der Button "Record Video". Was habe ich zu tun?

hey, das ist ja klasse. Schön, dass es klappt!

Der Video-Rendern Button ist solange inaktiv, bis eine gültige Wave Datei (Mono, keine Tag-Informationen) eingetippt wurde. Habe für's Video Rendern auch ein bebildertes Tutorial geschrieben: http://www.weltfalt.de/soundbild/tutorial
Gucke dir vor dem Rendern die "labels..." an, wenn eines vor dem Songstart eingeblendet wird, musst du beim Video Rendern die Wavedatei entsprechend verzögern (in VirtualDub: "Audio"->"Interleaving..."->"Delay Audiotrack by xxxx ms"). Der Punkt ist im Tutorial noch nicht drin.

Aha... okay, danke!
Ja stimmt. Auf der seite waren ja auch Beschreibungen dazu...

CodingCat hat geschrieben:Endlich vollständige Beleuchtung (mit Schatten) in den Reflexionen. Ja, das Aliasing und die Normals sind grausig.

Noch weniger als eine Woche bis zur Abgabe der Arbeit, deshalb vorerst keine weiteren Ausführungen.



Zurück ans Schreiben ...

So, Bachelorarbeit ist, wie bereits andernorts erwähnt, abgegeben, ich darf wieder programmieren. ;)

Halbzeit der Verbesserungen und Optimierungen, doppelte Framerate: (Reflexionen stark übertrieben)
Hoffen wir dass die zweite Halbzeit genauso gut läuft. An dieser Stelle endlich eine kurze Zusammenfassung des aktuellen Vorgehens. Ich arbeite mittlerweile auf einem regulären Strahlengitter, das die gesamte Szene enthält. In diesem Strahlengitter sind pro Zelle alle Strahlen eingetragen, welche diese Zelle durchlaufen. Das Ray Tracing ist damit prinzipiell ein einfacher linearer Renderdurchlauf der gesamten Szene, wie bei normaler Rasterisierung, nur dass ich nicht zweidimensional rasterisiere, sondern in das Strahlengitter voxelisiere. Für jedes generierte Voxelfragment schaue ich dann im Strahlengitter einfach alle Strahlen nach, welche die jeweilige Gitterzelle durchlaufen.

In dieser reinen Form ist das Verfahren jedoch nicht umsetzbar, weil jeder Strahl locker 100 Gitterzellen durchläuft, die niemals alle Links auf den jeweiligen Strahl speichern können. Also nutze ich einen weiteren linearen Renderdurchlauf der Szene, um eine grobe Voxelapproximation der Szene aufzubauen (das geht flott, ca. 2 ms). Mit dieser Voxelapproximation kann ich dann das Strahlengitter auf jene Gitterzellen begrenzen, welche tatsächlich von Geometrie bewohnt sind. Damit landet man bei ca. 20 Links pro Strahl, immer noch ne Menge Speicher.

Der nächste Schritt ist ein Multi-Pass-Verfahren, das das Strahlengitter nur teilweise aufbaut (die Voxelapproximation wird von allen Strahlen schichtweise abgetragen, ähnlich wie bei Depth Peeling). Pro Schicht von Geometrie wird ein extra Tracing-Pass durchgeführt, ein großer Teil der Strahlen trifft bereits in der ersten Schicht. Damit profitiert man wie in klassischen Ray-Tracing-Verfahren mit echter (aber meist statischer) Raumaufteilung von der Szenenverdeckung. Ich habe das ganze mit einer einfachen Heuristik auf 3 Passes reduzieren können, wobei jeder Strahl im Schnitt maximal 3 Dreiecke trifft und vor allem pro Pass nur maximal 3 Links emittiert. Der Speicherbedarf wird so tragbar. Dies ist meine aktuelle Implementierung.

Als nächstes werde ich versuchen, die einfache Voxelapproximation durch eine genauere, aber dennoch kompakte Approximation der Geometrie zu ersetzen.

Der ein oder andere fragt sich jetzt vielleicht noch: Warum das Ganze? Es gibt in der Tat bereits wesentlich schnellere Ray-Tracing-Implementierungen auf der GPU, die von Geometrie-Bäumen oder auch Geometrie-Gittern Gebrauch machen. Diese erfordern jedoch meines Wissens nach alle wahlfreien Zugriff auf die gesamte Szenengeometrie und lassen sich somit nur schwerlich in aktuelle Real-time Rendering Pipelines integrieren. Obendrein geht damit der Bedarf eines wahlfreien Zugriffs auf Materialien und insbesondere Texturen einher. Das Verfahren, das ich hier konstruiere, ist direkt in eine ganz normale Deferred Shading Rendering Pipeline integriert, ohne globale Puffer für die Szenengeometrie und unter Verwendung eines ganz normale Objekt- bzw. Batch-basierten Objekt- und Materialsystems.

Nachtrag: Das, was vorhin im ersten Bild zu sehen war, waren gar keine Race-Artefakte, sondern das klassische Mailboxing-Problem. Wieder ein Bug weniger. :)

Ich habe davon zwar nur wenig begriffen, aber das sieht wirklich gut aus! Interessehalber: wie erstellst Du die Voxel-Repräsentation? Rasterisierst Du selber, oder sammelst Du Fragment-Listen und sortierst sie in einem Compute Shader ein?

Ich nutze die Standard-Grafik-Pipeline für konservative 2D-Rasterisierung, diskretisiere die Tiefen konservativ im Pixel Shader und erstelle die Repräsentation direkt im Pixel Shader.

Die neue Approximation der Geometrie hat bis jetzt leider nur eine mäßige Verbesserung gebracht. Die Idee war, in jeden Voxel eine Separationsebene einzusetzen, die grob entlang der enthaltenen Oberfläche ausgerichtet ist und mit ihrem Offset möglichst viel freies Voxelvolumen von tatsächlich belegtem Volumen trennt. Das brachte etwa 70 Tests weniger pro Strahl, der Durchschnitt liegt nun bei 245. Ob das optimal ist, muss ich noch in Erfahrung bringen.

Weiterhin habe ich eine ganze Palette von Bugs gefixt. Ich habe zwar noch immer einige winzige Artefakte, die wohl aus irgendeiner Ungenauigkeit bei irgendeiner Diskretisierung resultieren (ich habe so viele Diskretisierungen, dass ich da locker Tage suchen kann), aber immerhin kann ich jetzt auch Close-Ups rendern, ohne dass sich das Bild in Chaos auflöst.

Das sieht echt gut aus! Meinen Glückwunsch!

Danke! Ich habe gerade eben die oben beschriebene Ebenenapproximation von einer auf zwei Ebenen erweitert, damit kann ich jetzt immerhin über 100 Tests sparen. Leider wirkt sich das nicht so drastisch auf die Performance aus wie ich es gerne hätte. Die Bottlenecks hüpfen in diesem Projekt oft einfach von einer Stelle zur nächsten. Dennoch lässt sich die Verbesserung sichtbar machen. Die Farbkodierung der Anzahl getesteter Zellen pro Reflexionsstrahl (Rot = 30, Grün = 10, Blau = 4) zeigt eine deutliche Verbesserung:



Die größte Herausforderung war, zugleich einen Minimal- und einen Maximalwert in einem einzigen uint atomar zu aktualisieren. Die Lösung ist wieder eine InterlockedCompareExchange()-Schleife. Nicht schön, aber erstaunlicherweise nur 4 ms langsamer als zuvor das einseitige InterlockedMax().

Ich glaub deine Performance krankt einfach daran, das eine moderne Graka einen Shader n-mal parallel ausfuehrt. Wenn du jetzt n-1 Faelle davon optimierst, warten diese trotzdem noch auch den letzten Fall und es gibt keinen Performancegewinn.

Naja, ganz so einfach ist das nicht. Klar spielt Ausführungskohärenz eine Rolle, aber zum Einen habe ich auch hier bereits massiv optimiert und zum Anderen optimiere ich fast immer alle Fälle. Das Tracing kommt mit sehr wenig Branching aus und die Daten werden vollkommen parallel abgearbeitet, keine unterschiedlich langen Shader-Ausführungszeiten mehr. Es ist ja auch nicht so, dass es gar nicht vorangeht, ich bin immerhin schon von 1 s auf 100 ms runter.

Im Moment habe ich leider immer noch unglaublich viele Shader-Ausführungen, entspricht etwa 200 Fullscreen-Passes (ganz genau, so parallel: eine Ausführung pro Hit Test. Man könnte also sogar sagen: Nein, die Parallelität der Shaders ist überhaupt nicht das Problem). Eventuell ist es hilfreich, hier einige zu Batches zusammenzufassen. Wo der aktuelle Bottleneck liegt, muss ich allerdings erst noch herausfinden.

Du hast ja oben so Bilder, das einmal nur 4 Zellen und einmal 10 Zellen getestet werden. Wie machst parallelisiert du das denn?

Jedes Dreieck wird voxelisiert (parallel, Rasterisierung via Standard-Grafik-Pipeline). In einem zweiten Pass wird für jeden Voxel die Anzahl der eingetragen Strahlen bestimmt und für jeden Strahl wieder ein Pixel-Shader-Thread gestartet (parallel, 1 Pixel-Shader-Thread pro Strahl und Dreieck).

Die Inkohärenz von 4-10 Zellen pro Strahl findet sich nur im vorangehenden Eintragen der Strahlen in die Voxel wieder. Die Performance dieses Passes ist allerdings nicht wirklich ein Problem (insgesamt höchstens 10 ms), weil das Eintragen an sich sehr billig ist. Außerdem geschieht auch das Eintragen in mehreren Schritten mit jeweils begrenzter Zellenzahl pro Strahl.

Das finale Video zu meinem Studentenprojekt "Developing a Pinball Game":

[youtube]FrEYZDtyaD4[/youtube]

Das sieht nach solider Technik aus, jetzt noch ein Grafiker ... ;) Nein, darum ging es in diesem Projekt ja nicht. Die Materialien fallen besonders positiv ins Auge, mal kein Plastik überall. Vermutlich entsprechende passendere BRDFs? Ansonsten schöne Soft Shadows, schönes AO, schöne Reflexionen.

Vielen Dank :)
Jap, da ist Cook-Torrance am Werk und kein (Blinn-)Phong.
Den einen "Grafiker", den wir hatten, hat noch nie irgendwas gezeichnet oder modelliert und hat sich am Anfang des Semesters in 3ds Max eingelesen. Ein paar Objekte (die Bälle, das "Stargate") hab ich auch gemacht, um ihn ein wenig zu entlasten.
Aber ich finde auch wenn wir keine hochwertigen Modelle hatten, so haben wir wenigstens auf eine einigermaßen passende Zusammensetzung bzw. Gesamtbild geachtet, das war dem Betreuer wichtiger als HQ-Modelle.

Kennt ihr das auch, dass wenn man ein halbes Jahr an so einem Projekt sitzt, was wirklich nicht so viel Szenen-Vielfalt hat, dann kann man das Ganze nicht mehr wirklich sehen?

Das glaube ich gern :-) Das Gesamtbild ist aber wirklich auch beeindruckend geworden. Wie macht ihr die Soft Shadows?

Das sind Exponential Shadow Maps.
Tut mir leid, dass ich dir noch nicht auf deinen Thread geantwortet hab, ich hab das immer vor gehabt, aber nicht die Zeit gefunden.
Heute hab ich Zeit, ich guck mal nach, was wir anders gemacht haben.

Hallo in die Runde.

Auf ZFX selbst habe ich bisher nur wenig gepostet, doch einige dürften mich noch von Developia kennen. Nach einigen Monaten Entwicklungs- und sonstiger Arbeit (Finanzamt besuchen und ähnlicher Kleinkram) habe ich nun auch ein Projekt vorzuweisen: Eine Android-App, die ich auf Googles Play Store anbiete.

Dabei handelt es sich um ein rundenbasiertes Strategiespiel für zwei Personen. Es gibt Ähnlichkeiten zum Spielprinzip von Schach, Mühle, Dame und dergleichen. Beide Spieler sind abwechselnd am Zug, es gibt keine Zufallselemente und keine unbekannten oder versteckten Elemente. Jedem der beiden Spieler sind alle Informationen zur Spielsituation bekannt.

Hier ein nicht mehr ganz aktuelles Bild:


Das Spielprinzip
Jeder Spieler besitzt zu Beginn einige Felder. Die Spielsteine werden Sterne genannt. Diese Sterne haben einen Wert zwischen 1 und 5. Der Spieler kann in seinem Zug den Wert eines seiner Sterne um 1 erhöhen. Steigt der Wert dadurch auf über 5, "explodiert" der Stern. Zurück bleibt ein Stern mit einem um 5 niedrigeren Feldwert. Als Ausgleich dazu werden alle waagrecht und senkrecht benachbarten Felder dem aktuellen Spieler zugesprochen. Leere Felder erhalten einen neuen Stern mit dem Wert 1. Der Wert eigener Nachbar-Felder und ehemals gegnerischer Nachbar-Felder wird um 1 erhöht. Falls der Wert eines solchen Nachbarn dabei ebenfalls auf über 5 steigt, explodiert dieser ebenfalls. Auf diese Weise können Kettenreaktionen große Teile des vom Gegner besetzten Gebiets erobern - teilweise sogar durch "Fünfer-Sterne" des Gegners.

Technisches
Die Implementierung des Spiels war vergleichsweise einfach, da ich das gleiche Spiel schon im MorgenGrauen umgesetzt habe. Außerdem ist die Google-Dokumentation sehr gut.

Interessant und erwähnenswert finde ich allerdings den computergesteuerten Gegenspieler, gegen den man wahlweise antreten kann. Hier habe ich einigen Gehirnschmalz bemühen müssen, bis ich zu einem einigermaßen brauchbaren Ergebnis gekommen bin. Brauchbar bedeutet hierbei, dass die KI sich nicht völlig zufällig verhält, sondern einem gewissen gewinnorientierten Schema folgt.

Zur Auswahl standen zwei beziehungsweise drei Ansätze.

Zunächst habe ich mit einem Tiefen- und MinIMax-Algorithmus herumprobiert. Das Konzept dieser Vorgehensweise ist technisch noch sehr einfach, jedoch bin ich bei dem umgesetzten Spielprinzip darauf angewiesen, tief in den Baum einzusteigen. Mindestens eine Halbzug-Tiefe von 10 setze ich voraus, um bestimmte Konstellationen als gefährlich oder gewinnbringend einzuschätzen.
Der Bewertungsalgorithmus hingegen konnte vergleichsweise einfach sein. Im Prinzip reichte es aus, die Anzahl besetzter Felder und deren Wert zu summieren und gegen die gleiche Berechnung für gegnerische Felder zu setzen. Dies gab eine grobe Richtung an, in die das Spiel sich entwickeln könnte.
Leider stellte sich schnell heraus, dass der Algorithmus bei 10 Halbzügen überaus lange (zu lange) braucht, um eine Reaktion auf den Zug des Spielers auszuspucken. Obwohl ich grundsätzlich Optimierungspotenzial sehe und sah, habe ich mich dann an einem anderen Ansatz probiert.

Der zweite Ansatz war eine Breitensuche mit MinIMax-Algorithmus, also prinzipiell ein ähnliches Vorgehen wie bei der Tiefensuche. Hier konnte ich einige Optimierungen schon im ersten Ansatz umsetzen.
Die Idee war, dass viele Halbzüge nach zwei oder drei Halbzügen zu gleichen Situationen führen. Daher entschied ich mich, diese Situationen (die sich aus der Spielfeldbelegung und dem aktiven Spieler ergibt) nur ein einziges Mal zu bewerten beziehungsweise weiter zu verfolgen.
Dadurch war es möglich, im Vergleich zum unoptimierten Tiefenalgorithmus um einen Faktor X schneller zu sein. (X müsste ich schätzen, vielleicht auf 100 bis 1000.)
Ärgerlicherweise stellte sich heraus, dass trotz dieser Optimierung sehr viel (zu viel) Arbeitsspeicher notwendig wurde, sobald die Anzahl der Zugmöglichkeiten ansteigt. Auch hier bestünde weiteres Optimierungspotenzial, jedoch wollte ich noch eine dritte Möglichkeit austesten.

Während die Breiten- und die Tiefensuche ihre Stärke daraus ziehen, dass sie "in die Zukunft schauen", also zukünftige Spielsituationen berechnen können, können ihre Bewertungsfunktionen vergleichsweise simpel sein. Die Alternative dazu ist, nicht die zukünftigen Situationen zu berechnen, sondern in einem wesentlich komplexeren Bewertungsalgorithmus eine Zeitpunktbetrachtung vorzunehmen.
Dazu habe ich die einzelnen eigenen Felder des Spielbretts kategorisiert und entsprechend sortiert.
Diese Kategorien unterscheiden zwischen Feldern, die mit gegnerischen Feldern benachbart sind, und Feldern, die es nicht sind. Unter den Feldern mit Fendkontakt gibt es beispielsweise Eroberer (die stärker sind als die stärksten gegnerischen Nachbarn), unbedingte Eroberer (gleich starke gegnerische Nachbarn mit Maximalwert), potenzielle Eroberer (gleichstark wie der stärkste Gegner, aber nicht mit Maximalstärke) und bedrohte Felder oder Opfer. Manche dieser Kategorien können noch weiter unterteilt werden, zum Beispiel in tatsächlich bedrohte Felder und Felder, die von einem Feld bedroht werden, das seine Bedrohung (durch ein anderes eigenes, bedrohendes Feld) nicht ausspielen kann.

Unter den nicht mit Gegnern in Kontakt stehenden Feldern gibt es solche, die selbst an unbesetzte Felder grenzen (siedlungsfähige-Felder) und solche, die im "Hinterland" sind.
Auf meiner Website habe ich einige Taktiken näher beschrieben, die es sinnvoll erscheinen lassen, Hinterland-Felder weiter zu unterteilen, zum Beispiel in solche, die bedrohte Felder absichern, solche, die aggressive Angriffe ermöglichen und ähnliche.

Erstaunlicherweise funktioniert die auf diese Weise gestaltete KI sehr gut. Sie ist in ihrer aktuellen Implementierung zwar noch recht schwach und macht vorhersehbare Fehler, gewinnt aber regelmäßig noch gegen einen siebenjährigen Testspieler. (Zugegeben, das ist nicht die Zielgruppe, aber wenigstens ist die KI gewinnorientiert.)
Die KI ist sogar so schnell, dass der Bewertungsalgorithmus direkt im GUI-Thread durchgeführt werden kann, anstatt ihn in eigene Threads auszulagern.

Einige weitere Informationen könnt ihr auf meiner Website finden http://android.sistance.de/explode/ und ich freue mich außerdem über Feedback hier im Forum.


Die App ist über den folgenden Link im Play Store verfügbar: https://play.google.com/store/apps/deta ... id.explode

Gruß,
Torik

Schaut hübsch aus.

Du hast "reine" Minimax-Suche ohne Alpha-Beta-Pruning probiert, right? Sollte das der Fall sein, dann schau dir das unbedingt an, Minimax allein ist witzlos. Erfahrungsgemäß kriegt man dieses Kaliber Spiel mit (ggf. iterativer) Alpha-Beta-Suche, Transition Tables und einer halbwegs brauchbaren Heuristik ziemlich schnell unschlagbar.