Tagebuch: GalaxyCommand

Ufff das ist komplizierter zu erklären, denn es gibt einen Faktor der die ganze Erklärung nochmals gänzlich durcheinander bringt. Ich bin natürlich weder Mozart noch hab ich ein Orchester. :smiley:

Das Komponieren selbst ist schon schwer genug aber man benötigt noch eine gute Composer Software und natürlich einen Synthesizer um die Musik überhaupt abzuspielen. Und die sind teuer. Ein Freund oder Bekannter mit einem kleinen Tonstudio ist von Vorteil.

Hier kommt der Faktor AIVA ins Spiel. Auch wenn es einem das Marketingmaterial auf YouTube zumuten will, AIVA ist kein Hans Zimmer. Sondern eine künstliche Intelligenz die Musikstücke komponieren kann von denen die meisten einem Katzengejammer am nächsten kommen. Aber wenn man nur genügend vielen Affen eine Schreibmaschine gibt kommt manchmal tatsächlich eine gute Anfangsmelodie heraus. Einem Anfänger wie mir gibt das einen unglaublichen Headstart an dem man basteln kann, sowie einen Einblick über den strukturellen Aufbau, von Anfang bis Ende, den Übergängen und den einzelnen Instrumenten.

AIVA kann die Musik auch direkt “Rendern”, also in hörbare Musik überführen - das ist in der Musikwelt weit weg von Selbstverständlich. Man kann die Instrumente und deren Spielart verändern und einzelne misslungene Abschnitte komplett neu generieren lassen. Ich habe relativ schnell die Tonleiter, was eine Oktave ist und den Unterschied zwischen Tremolo, Vibrato, Legato, Spiccato und weiteren kennen gelernt.

https://beta.aiva.ai/

Danach wird es aber komplizierter. Um die Musik gezielter zu komponieren, schiefe Töne zu entfernen, die Übergänge sanfter zu gestalten und das Stück allgemein auszuschmücken wird natürlich weiterhin entsprechende Composer Software und Synthesizer benötigt. Freeware gibt es dafür praktisch nicht.

Ich verwende Steinberg Nuendo. Teuer, aber zu meinem Glück ist mein früherer Mitbewohner Musikproduzent mit einem kleinen Studio. Nuendo kann natürlich auch überzeugende Musik erzeugen.

Hab die Tage mal ein bisschen die Grafik neu gezeichnet (modularisiert), inklusive dem Schadenmodell. Und die API der HiveAI hat gute Fortschritte gemacht, ist jetzt auch ein bisschen intelligenter.

Hier ein kleines Video zum aktuellen Stand. Leider stimmt etwas mit der Video Aufnahme Funktion nicht, weshalb leider gezwungenermaßen große schwarze Ränder zu sehen sind. Ich würde mich über den ein oder anderen Kommentar/Anregung freuen.

Ziemlich cool: Es gab einen Fehler im Renderthread und Umgang mit OpenGL, der dafür sorgte das ALLE Threads ungewöhnlich lange und unregelmäßig pausiert wurden, das hat das gesamte System geräteübergreifend betroffen. Jetzt läuft das Spiel selbst im Debugmodus geschmeidig wie Seide, das ist unglaublich! So sehr hatte ich mich daran gewöhnt.

Der eigentliche Grund des Fehlers ist nicht bekannt und trat auf allen Samsung Galaxy S5-S8 Modellen auf. Hat aber irgendetwas damit zu tun, in welcher Reihenfolge Arrays auf CPU Seite initialisiert und dann an die GPU übertragen werden.

// good
int[] array = new int[10];
int[] array2 = new int[10];
gpu.send(array);
gpu.send(array2);

// bad
int[] array = new int[10];
gpu.send(array);
int[] array2 = new int[10];
gpu.send(array2);
1 Like

Ich habe die letzte Woche - und damit weit mehr als mir lieb ist oder ich öffentlich zugeben würde - damit verbracht mich vor Excel zu setzen und meinen Kalman Filter zu tunen, um Messwerte besser vor Ausreißern zu stabilisieren.

Und so sieht das in der Praxis aus:


In Blau sind die Messwerte+Rauschen / In Orange der gefilterte Wert, und ich finde er ist ziemlich gut. Die gemittelte Abweichung beträgt 0,07.

Die Problematik ist ziemlich einfach: Man misst etwas in Echtzeit, aber die Messung ist ungenau (+Rauschen), der reale Wert ist unbekannt. Für den Durchschnitt müsste man alle Werte vorher kennen. Das führt zum nächsten Problem: Was ist eine Veränderung des Realwertes und was darf weg?

Und jetzt zu dem was ich gemacht habe:
Für Beide Fälle gibt es bereits sehr gut dokumentierte und erprobte Lösungen: Der lineare und der nicht-lineare(/erweiterte) Kalman Filter.
Aber für den erweiterten Kalman Filter benötigt man eine mathematische Darstellung des Systems - macht das mal für Frames per Second :smiley: -, außerdem ist er sau kompliziert aufzusetzen und richtig zu kalibrieren. Für Java wird es da mit guten Bibliotheken auch knapp, weil Mathematiker nur Python oder Matlab können und ich kann kein Mathe :smiley:

Deshalb habe ich mir einfach gedacht ich nehme zwei lineare/einfache Kalman Filter, einen mit niedriger und einen mit hoher Genauigkeit (relativ zueinander), und beobachte wie ihre Werte auf Veränderungen des Realwertes vs Rauschen reagieren.
Z.B. hat jeder Filter einen angenommen Realwert und eine angenommene Toleranz in der sich der reale Realwert nach deren Vermutung befinden könnte. Wenn die Bereiche der zwei Filter nicht mehr überlappen, kann angenommen werden, dass der ungenaue Filter - der sich schneller neuen Werten anpasst - wahrscheinlich eine Veränderung des Realwerts erfasst hat. Und dann wird der genaue und träge Filter daraufhin korrigiert.

Das ganze hab ich dann den stabilen nicht-linearen Kalman-Filter genannt. Und er ist nicht fertig, aber ich hab schon viel zu viel Zeit darin investiert. :roll_eyes:

Ich hab eine interessante Entdeckung gemacht was die Multithreading Performance immens schädigt.

Unten sieht man 3 Bilder, der gleichen Szene, aber mit unterschiedlich vielen Kernen aktiviert und ihrer Ausführungszeit. Wenn man die Gesamt-Ausführungszeit zusammenrechnet kommt man auf folgendes:

  • 1 Kern(e): 246ms [246ms]
  • 3 Kern(e): 85ms [28ms]
  • 7 Kern(e): 353ms [50ms]
    [Schnitt]

Zwar sind 7+1 Kerne parallel immer noch schneller als 1+1 Kerne, aber langsamer als 3+1 Kerne. Weniger ist mehr!

Meine versuchte Begründung: Auf Android-Geräten kommen häufig ARM CPUs in der big.LITTLE oder einer ähnlichen Architektur zum Einsatz. Die Kerne der CPUs unterteilen sich dabei in unterschiedliche Leistungsklasse - das ist wie wenn die hälfte eines Desktop i7 aus einem mobile i7 “U” bestehen würde, um Strom zu sparen wenn der Rechner gerade nicht ausgelastet ist.
Ich schätze dass die Kommunikation zwischen den unterschiedlichen Clustern der CPU einen immensen Overhead hat.

Wenn man jetzt bedenkt dass beim aktuellen Snapdragon 855 oder der Exynos 9 CPU (Samsung Galaxy S10) die 8 Kerne in 3 Leistungsklassen unterteilt werden, muss man ganz genau abschätzen ob Multithreading der Performance nicht sogar schadet. :anguished::fearful:



Zwar schrieb ich die erste Antwort in diesem Faden, aber zugegebenermaßen muss ich gestehen, länger nicht mehr in diesen Faden geschaut zu haben, und jetzt sehr angenehm überrascht zu sein, welche Fortschritte du gemacht hast, TMII! :slight_smile:
Ich werde diesen Faden auf jeden Fall weiter beobachten! :smiley:

Kennt ihr das, wenn man im Nachhinein ein Feature einbauen möchte, für die das bestehende System absolut nicht ausgelegt ist?
Ich überlege seit Tagen, wie ich ein möglichst kompatibles Beleuchtungssystem in mein Spiel bekomme.

Hat das Priorität? Nein.
Ist es notwendig? Nein.
Ist es sinnvoll? Nein.
Aber Spiele mit Beleuchtung sehen einfach stimmig aus.

Oh, Beleuchtung oder besser gesagt Shader-Programmierung ist gleichsam „ein Buch mit sieben Siegeln“ (aber hier überwiegend im Sinne von geheim oder geborgen). Soweit ich weiß, halten dies die Spielehersteller sehr geheim, und jeder „kocht“ mehr oder weniger „ein eigenes Süppchen“. - Also man wird wahrscheinlich nicht einfach so „gute“ Shader im Internet finden - wenn auch solche Sachen wie globale Modelle, Schatten u. v. m. hinzukommen. Die Namen Phon, Blinn, Cook + Torrance sollten ein Begriff sein, aber darüber hinaus wird es rar… Siehe auch: https://en.wikipedia.org/wiki/List_of_common_shading_algorithms .

Um hier mal etwas Staub zu wischen, teile ich mal mein Logo:

Das wurde von mir komplett in PaintDotNet gezeichnet. Die Planeten (und ein Haufen Weiterer) hatte ich eigentlich mal für ein anderes mobile game gezeichnet, aber die zwei hier fand ich sehr gut gelungen.
Die Schriftart ist von irgendeiner Font-Download-Seite.

3 Likes

Schaut echt gut aus und interessant was man mit PaintDOTNet so anstellen kann. Hab das bisher noch nicht wirklich versucht auszureizen.

1 Like

Das folgende finde ich wahnsinnig cool: Gestern hatte ich meinen neuen Magma Planeten im Discord Chat vorgestellt:


Daraufhin kam von @L-ectron-X der fantastische Vorschlag, ich solle die Furchen größer machen. Der sieht für ihn nicht so sehr nach einem Magma Planeten aus bzw. vielleicht ein „etwas älterer“. Eigentlich wollte ich Designtechnisch ursprünglich in eine völlig andere Richtung gehen.
Gesagt getan (nach mehreren Iterationen): :smiley:

Sehr zufrieden mit dem neuen Ergebnis, kam dann von @CyborgBeta der Input, dass man die Furchen am Rand (Silhouette) des Planeten nicht sieht. Meine Idee war, die Atmosphäre zu verrußen, damit die technische Limitation nicht mehr so auffällt. (Nach mehreren Iterationen:) :smiley:

Ich bin sehr zufrieden mit dem Ergebnis! Ohne Feedback wäre das nicht herausgekommen :smiley: Danke euch.

Das mach ich jetzt auf jeden Fall öfter. Halt! Wohin rennt ihr denn alle plötzlich weg?! :smile:

2 Likes

Sehr gutes Endergebnis, wie ich finde. :star_struck::+1:

Ja, Nummer 3 sieht am natürlichsten aus.

Hoffentlich ist das nicht die Erde im nächstem Jahr (nach dem KW). :clown_face:

Mir ist was unglaublich doofes passiert. Ich hab nach Jahren mal wieder auf der GitLab Seite selbst ins Projekt geschaut und dort wurde es zuletzt vor „über einem Jahr“ geändert… ich hatte in IntelliJ immer auf Commit -> Commit & Push geklickt und irgendwann hab ich wohl unbedacht angefangen den anderen Button Push zu verwenden.
Es hatte mich noch gewundert warum alle Branches auf dem gleichen Stand waren. Herrje, fühl ich mich doof gerade.

Mir hatte die „Artefakt“ Halterung in meinem Spiel nicht so recht gefallen (für Upgrades des Schiffes)
artifact
das ist jetzt der neue Prototyp
artifact_2
ich bin eigentlich ganz zufrieden damit. Die Farbe des lila „Artefakts“ ist noch in der Schwebe.

Mein jetziges Problem ist nur, dass das auch den Generator oder den zentralen Schiffskern darstellen könnte.

Es ist viel passiert in den 4 Monaten :smiley: Ein großer Meilenstein wurde nach langer Planung und hohem Einsatz endlich erreicht: Licht und Schatten!


Statt den angedachten 2-4 Wochen Umsetzungszeit, war dann doch etwas intensiverer Zeiteinsatz erforderlich :sweat_smile: Für viele Qualitative Verbesserungen und erweiterte Funktionen an verschiedensten Stellen im Code hat sich der Zeitaufwand aber gelohnt.


Für die Umsetzung hab ich diesmal stärker auf agile Projektplanung (HacknPlan) gesetzt und das hat sich definitiv ausgezahlt. Vor allem um über den langen Zeitraum immer einen Überblick über das Gesamtprojekt zu haben. Aber auch für Detailfragen der Umsetzung.
Sehr hilfreich war dabei auch Tomate_Salat, der mit seinem Tagebuch eine Orientierung gegeben hatte.
Auch wenn ich meinen Planungsstil eher als radikalere Scrum-Interpretation einschätzen würde. :sweat_smile:

Die Tage wird es noch ein paar extra Posts zu Planung und technischer Umsetzung geben.

1 Like

Ja, dass kenne ich nur zu gut. Man plant etwas für 2-4 Wochen und dann dauert es mehrere Monate (hust Feature Runner hust). Aber das Ergebnis kann sich dafür echt sehen lassen. Bei solchen Sachen lerne ich immer mehr zu schätzen, welche Arbeit mir Unity3D da abnimmt ^^.

Hehe, endlich zeigst du Vernunft :stuck_out_tongue:. Gutes Projektmanagement ist halt leider nicht zu unterschätzen. Ich hoffe mal dir geht es da dann aber ähnlich wie mir, weil ich find das mittlerweile echt spannend.
Als ProjektManager hast du deine Vision und als Entwickler setzt du das um und als Tester wirst du von deinen anderen beiden Ichs gehasst. Tolle Welt ist das :stuck_out_tongue:

Ein wohl sehr bekannter Effekt :smiley: Das eine from scratch Implementierung hier lange dauert, war abzusehen. Mehr dazu in einem kommenden Post zum technischen Hintergrund). Einige Algorithmen waren aber schon vorhanden. Haben sich im Nachhinein aber als zu ungenau herausgestellt.

Danke.
Ja, die Unity Community hat entsprechende 3D und 2D Belichtungsbibliotheken bereits. Ich glaube es soll auch eine offizielle 2D Umsetzung in naher Zukunft geben. Aber für mich ist es jetzt zu spät darüber noch zu neiden :smiley:

Ich bin auf die Rot_Grüne Seite der Macht gewechselt.

Interessant wie du das betrachtest. Bei normalen Projektmanagement (Wasserfall) teile ich die Ansicht komplett. Als Projektmanager habe ich mich vorher echt gehasst :smiley: Vor allem ging die Planung an der praktischen Entwicklung völlig vorbei.

Was ich an agilem Development so mag, ist eben dass das Projektmanagement auf Entwicklerebene stattfindet. Die Rolle des Projektmanagers wechselt von administrativ auf moderativ. Und die Planung orientiert sich eher an den praktischen Anforderungen. :slight_smile:

Verstehe ich gerade nicht.

Bei Wasserfall oO? Weil beim Wasserfall hat man imho keine Visionen mehr. Eine Vision ist für mich ein (sehr) vages Konzept.Von demher muss es agil sein. Man hat Ideen, wo es hingehen kann, aber weiß es eben vorher noch nicht. Man lässt sich ja ganz bewusst Spielraum. Entscheidungen trifft man erst für unmittelbar anstehende Aufgaben.

Und genau deswegen find ichs so spannend. Für mich ist der Projektmanager auch mehr in der Rolle des Spielers. Von demher versuche ich bei so Dingen das ganze möglichst nicht von der Entwickler-Seite zu betrachten.
Das tolle daran ist ja dann auch gerade der Punkt, dass man sich selber überraschen kann. Mit so mancher Implementierung baust du etwas ins Spiel ein, was du an anderer Stelle gut wiederverwenden könntest. Die Idee dazu hättest du mit Wasserfall nicht haben können. Zudem entdeckt man Sachen, die man als Spieler einfach gerne hätte. Ich find diesen iterativen Prozess einfach toll :slight_smile:.