Tagebuch: GalaxyCommand


#1

Ihr habt euch schon immer mal gewünscht eure Finger an einem Smartphone zu verbrennen? Ihr seit es Leid, dass sich euer Smartphone am Ladekabel immer nur auflädt statt sich zur Abwechslung mal zu entladen?

Dann hab ich hier genau das richtige für euch: TMII’s Multithreading Monster: GalaxyCommand

Spiel: Weit im Anfangsstadium. Im Moment gibt es nur den im Video zu sehenden Editor.
Später sollen Stationen, Planeten, Handel und rundenbasierte Raumkämpfe ihren Weg in das Spiel finden.

Multithreading: 8 Kerne und eine GPU, angetrieben von Context Based Threading (CBT). Das CBT Projekt hatte ich vor längerer Zeit hier vorgestellt und dieses Projekt ist das erste auf dem CBT Framework basierende größere Programm.
Unten links kann man die Kern-Threads und ihre Zeiten betrachten.
Das Renderig findet auf einem dedizierten Thread statt welcher ohne Aufnahme bei ca. 60fps arbeitete.
Es ist beachtlich wie vor CBT die Matrizenberechnungen noch eines der Hauptprobleme waren nun auf die Kerne aufgeteilt praktisch nicht mehr ins Gewicht fallen.

Rendering: OpenGL ES 3.1
Die Rendering Performance ist mit 50-60 fps im Vergleich relativ langsam, jedoch auch kaum optimiert. Instanced Rendering und eine intelligentere GPU Pipeline stehen eher weiter hinten auf der Liste.
Auf dem Rendering Thread findet nur die Kommunikation mit der GPU statt. Die Daten werden auf den restlichen Kernen aufbereitet.

Künstliche Intelligenz: Hier wird eine künstliche Schwarmintelligenz eingesetzt, zur Kontrolle und Navigation aller an Bord befindlicher Crewmitglieder.
Auch diese Bibliothek ist eine Eigenentwicklung.
Sie skaliert sehr gut mit steigender Agenten Anzahl, was ihr in Zukunft sehr gut mit komplexeren Raumschiffen/Umgebungen zu sehen bekommen werdet.


#2

Ui, noch ein Tagebuch. :wink:

Zum Spiel:

Das ist super! Mal abwarten. :+1:


#3

Auf das Thema hatte ich schon gewartet :slight_smile:. Dachte mir, dass das kommen wird ^^.

Das Projekt klingt auf jeden Fall sehr spannend und ich finds interessant, dass du da auch eigengeschriebenen Libs für verwendest. An die Vorstellung von CBT erinnere ich mich auch noch, hatte den Thread witzigerweise vor noch gar nicht all zu langer Zeit mal wieder offen gehabt (war unten in Vorgeschlagene Themen gelistet^^).

Machst du hier wirklich alles selber oder setzt du auf sowas wie libgdx?


#4

:smile:

Alles selber geschrieben. Von der Logik bis zur Darstellung und sogar selber gezeichnet. :sweat_smile:
(Außer die Musik und Effekte.)

Feedback zum Zeichenstil sind ausdrücklich erwünscht! Gerade die Bordsysteme sind per Hand gezeichnet, eingescannt und bearbeitet worden. Eigentlich eine Behelfslösung aber mittlerweile habe ich mich daran gewöhnt. :sweat_smile:

Würde aber niemandem dazu raten das gleiche zu tun. Alleine OpenGL ist bereits verdammt schwierig, und wenn man es gut machen will sprengt das alle Ausmaße - ich sage nur Concurrency auf der GPU.
LibGDX und Unity sind definitiv der bessere Weg.
Unity empfand ich aber zu barebones. Für viele Funktionalitäten muss man zusätzlichen zahlen.


#5

Glaube ich dir aufs Wort. Hatte mal damit rum experimentiert (opengl + android) und schnell eingesehen, dass ich das nicht will ^^.

Aber es ist sicherlich interessant, sowas mal von Grund auf selber entwickelt zu haben. Kommt halt immer drauf an wie geduldig man ist. Aber ich glaub schon, dass man einen riesen Spaß damit haben kann. Und ich denk, da kannste sicherlich einiges interessantes zu berichten.

Und da dachtest du dir es ist weniger Aufwand alles selber zu machen :stuck_out_tongue: ? Aber ich glaube du hast noch ein altes Lizenz-model im Kopf. Beim neuen ist das anders:

Alle Engine-Funktionen zur Erstellung und Optimierung von High-End-Spielen und interaktiven Erfahrungen. Uneingeschränkte Freiheit zur Bereitstellung auf allen unterstützten Plattformen


#6

Klar, aber es gibt keinerlei Vorlagen, auch in Unity muss man alles von Scratch programmieren, oder Vorlagen anderer kaufen. Ein Lizenzmodell hätte mir hier besser gefallen, dann kaufe ich nicht die Katze im Sack.
Meine Libs sind außerdem alle bereits in Java geschrieben und nicht auf die Unity Umgebung augerichtet. Zudem kenne ich mich mit Unity nicht aus, weshalb natürlich die Frage im Raum steht: Ist es schneller auf Unity zu wechseln, sich C# nochmal zur Gemüte zu führen als es selber zu machen? (wahrscheinlich schon)


#7

Ja und nein. Klar bekommst du keine assets geschenkt — doch schon, aber das mein ich nicht. Was dir Unity liefert ist halt das komplette Paket drumrum. Einen Editor den du super einfach erweitern kannst und eine komplette Engine. Physik & Co verwende ich einfach und schreibe mir das nicht neu.

Nun ja - kommt drauf an wie du dich mit Unity auskennst. Leider sind alle Tutorials im Netz die ich im Netz gefunden hab kacke. Auch das Video-tutorial auf Udemy wo der Tutor eigentlich von Unity3D unterstützt wird find ich mist. Warum: Die Dinger sind drauf aus, dass du schnell den nächsten Space Invador schreibst. Aber sinnvolle Architektur bekommste da nicht mit. Meine Einarbeitungsphase war Feature Runner - und das Projekt ging bis jetzt 5 Monate (Fast ein halbes Jahr).

Du solltest dir halt klar sein, was deine Ziele sind. Wegen einem Spiel sich in Unity einzuarbeiten ist imho schwachsinn. Wenn es dir “nur um das” Spiel geht und du dann wieder mal was mit libs machst, dann noch eine lib und vllt wieder ein Spiel oder ein anderes Programm was aufwendige Threads benötigt, dann hast du glaub mehr Spaß und Freude daran so weiter zu machen wie du gestartet hast. Bei dir geht es da ja auch schon um mehr als das Spiel. Ich kann mir gut vorstellen, dass du das Spiel nutzen kannst um deine libs weiter zu verbessern.

Ich nutze Unity weil es mir wirklich nur REIN um die Spiele geht. Ich sehe das als netten ausgleich zu meiner täglichen Arbeit wo ich nur mit Java und reiner Software Entwicklung zu tun hab. Ich will nur Code schreiben der relevant für das Spiel ist und nichts anderes. Deswegen sind für mich die 5 Monate auch keine Abschreckung - da ich mir vorstellen kann bis ich alt und grau bin nebenbei kleinere Handyspiele zu entwickeln. Einfach weils Spaß macht. Sollte dich sowas reizen, dann würde ich dir definitiv empfehlen dir irgendwann mal Unity anzuschauen :wink:


#8

Gestern habe ich mich in philosophische OOP Fragen verloren, bei der Umsetzung eines einfachen List.add(o) :smiley:
In meinem Framework müssen benutzerdefinierte Objekte mehreren Listen hinzufügt werden. Welche das genau sind hängt stark davon ab wie das Objekt programmiert worden ist. Viele dieser Listen sind auch in Gruppen zusammengefasst, aber ein Objekt kann auch nur in einem Teil der Listen auftauchen wollen oder in mehreren gleichzeitig.

Jetzt ist nur die Frage wo ich die Logik hinpacke um genau das zu steuern.
o.addTo(ListGroup1, ListGroup2) Eigentlich weiß der Programmierer des Objektes am besten was mit jenem geschehen soll. Auf der anderen Seite müsste das Objekt dann aber die genauen Listen und Gruppen Implementation kennen.
ListGroup.add(o) Listengruppen haben keine Informationen über die spezifische Implementation des Objektes und die Logik in den Speicher zu packen erscheint mir falsch. Jedoch könnten über Visitor-Patterns und Interfaces durchaus eine Lösung gebastelt werden.
{List.add(o)} Oder an die Stelle in der das Objekt erzeugt wird, wird es auch den Listen zugewiesen.
Das könnte für teilweise starke Code Duplizierung sorgen, an jeder Stelle an der so ein Objekt erstellt wird mit ~5-6 List.add(). Dafür kennt sich Objekt und Listen aber nicht. Und der Programmierer müsste an dieser Stelle ein tieferes Verständnis über die Bedürfnisse des Objektes haben, was man über die Doku regeln kann.
Dynamische Zuweisung Zum letzten gäbe es noch die dynamische möglichst automatische Zuweisung, da es zur Laufzeit durchaus indirekte Zusammenhängigkeitsinformationen gibt. Da gibt es aber mehrere Probleme und eins davon ist "instanceof "


#9

Wenn man dafür Regeln definieren kann, dann würde ich das glaub über einen Service lösen. Klingt nämlich nach einer Sache die ansonsten sehr schnell sehr schief gehen kann, wenn eine Liste vergessen oder falsch gewählt wurde.


#10

Japp, nur Regeln machen heißt auch die Möglichkeiten einschränken. Bin ich ganz schlecht drin. Die Baustelle hab ich mehrmals aufgerissen, im Moment erstelle ich manuell Service-Klassen für ein oder mehrere spezifische Klassen-Container-Beziehungen. Der Übergang von funktionellem Design zu OO ist halt leider nicht so einfach, vorallem nicht in Java. Gerade hier fehlt mir die Möglichkeit dass Generics zur Laufzeit nicht mehr existieren.