[Projekt] Duality

[Zudomon]

Dann mach den Blog doch auch auf deutsch :D

[Fetze]

Hatte ich mal, aber das schränkt den Kreis der potenziellen Leser sowie Nutzer des Frameworks doch erheblich ein. Abgesehen davon ist Englisch ja schon irgendwie zur "Branchensprache" geworden, die Hobbyisten-Community ist international erheblich größer und die meisten Entwickler haben mit Englisch kein Problem. Von daher bleib ich erstmal dabei :)

Und den Thread hier gibts ja auch noch, wenns Fragen gibt oder jemand hier technische Details erklärt haben will mach ich das dann auch auf deutsch ;)

[Fetze]

Lang lang ists her. Tjaja, das Real Life forderte seinen Tribut :D In den letzten Monaten hat sich aber trotz jeglichen Newsmangels einiges getan an Duality und ich dachte mir, es ist mal wieder an der Zeit, ein paar Binaries in die Welt zu schmeißen und herauszufinden, was damit passiert ;)

Im aktuellen Videoblog erkläre ich kurz, was so die größten Neuerungen sind. Im Wesentlichen der neue Sandbox-Mode, der es ermöglicht, das Spiel direkt im Editor zu starten, sowie eine integrierte Physikengine. Außerdem kann man seine Ressourcendateien jetzt als XML speichern statt binär.

Die neue Asteroids-Demo (mit Physik :lol: ) gibts --> hier <--

Feedback willkommen und falls sich jemand findet, der mutig genug ist, Duality für irgendwas sinnvolles zu benutzen: Fragen werden natürlich gerne beantwortet, Support gibts soweit ichs zeitlich schaffe ;)

[Jonathan]

Klingt sehr cool :)

[Andre]

Mir ist ein kleiner Schönheitsfehler aufgefallen, der auftritt wenn man rückwärts fliegt und dabei schießt.
Bin trotzdem erstaunt was damit schon alles möglich ist! Weiter so! :)

[Fetze]

Das übliche Problem langsam fliegender Projektile und additiver Geschwindigkeit, nehme ich an? ;) Ja, das ist schon unschön, da hast du Recht. Könnte das mal clampen bei Gelegenheit.

[Fetze]

Gibt mal wieder was zu testen :)



Dynamische Beleuchtung in Duality, Techdemo gibts hier. Per-Pixel Beleuchtung mit Ambient, Directional, Point und Spot Lights. Einfach mal DualityLauncher.exe starten, ums in Bewegung zu sehen, oder eben den Editor für alle die damit lieber selbst rumspielen wollen. ;)

Interessantes Detail: Um das alles umzusetzen hab ich Duality selbst nicht angefasst - steht zu 100% in Plugin Code. Ist also keine Hexerei seitens des Entwicklers sondern etwas, das auch jeder andere mit Duality hätte basteln können!
Vermutlich werde ich Kram wie Beleuchtungstechniken und Co nicht in den Duality Core aufnehmen; ich gehe davon aus, dass nur ein winziger Bruchteil von Spielen tatsächlich darauf zurückgreifen wird. Denen kann die Techdemo hier aber natürlich als Beispiel und Vorlage dienen, für alle anderen bleibt dafür der Core etwas aufgeräumter.

Wäre cool wenn ein paar von euch mal testen könntet, ob es denn läuft. Ich bin nicht unbedingt ein Grafikprogrammierungs-Guru und mir nicht im Klaren darüber, ob mein Shader- und Grafikcode hier plattformübergreifend verlässlich arbeitet. :D

[Chromanoid]

Läuft bei mir einwandfrei :) das Schiff links unten wird bei mir nicht beleuchtet, Absicht? Auf jeden Fall eine sehr coole Sache. Hast du mal überlegt so eine Art Baukastensystem für Spiellogik einzubauen? In gewisser Weise könnte das ja eine Open Source Alternative zu Game Maker und Co. werden. Wie sieht es eigentlich mit anderen Plattformen aus? Besonders im Smartphone Sektor fände so ein Toolkit sicher eine große Interessentengruppe.

[Fetze]

Das Schiff unten links ist so weit im Hintergrund, dass es nicht mehr von der Punkt- oder Spot-Lichtquelle erreicht wird. Beleuchtet wird es trotzdem, nämlich vom direktionalen Licht. Deswegen dreht es sich auch: Damit man sehen kann wie sich die Schattierung ändert :)

Was das Baukastensystem angeht, da zitiere ich einfach mal aus einem anderen Forum, wo dieselbe Frage aufkam:

Duality ist kein GameMaker. Es ist ein Framework und Toolset, um Entwickler zu unterstützen - nicht, ihnen mit vorgefertigten Regeln vorzuschreiben, wie ihr Spiel auszusehen hat ;)

Da sowohl Core als auch Editor 100% pluginbasiert sind, steht es natürlich jedem frei, selbst ein paar solcher Standardkomponenten zu erstellen und frei verfügbar zu machen. Wer entwickeln will ohne zu coden müsste dann lediglich die Plugins in den entsprechenden Ordner kopieren und könnte loslegen. Es ist also ohne Weiteres möglich, Duality in Richtung GameMaker zu bewegen, aber ich werde mich daran nicht beteiligen.

Was ich natürlich entwickeln und pflegen werde, sind solche Standardkomponenten, die nicht an vorgefertigte Spielregeln geknüpft sind, zB. Partikelsysteme, Tilemaps oder eben die frisch hinzugekommene Physik :)

Frage geklärt? :)

Was die Sache mit den Plattformen angeht: Momentan nur Windows. Duality verwendet zwar OpenTK und wäre damit rein theoretisch portabel, aber ich verfüge als einziger Entwickler des Projekts derzeit nicht über die nötigen Ressourcen, mehr als meine eigene Plattform zu supporten. Von daher gibts zur Portabilitätsfrage auch erstmal ein klares Nein. Ich will erstmal sicherstellen, dass Duality unter Windows sein volles Potenzial ausschöpft, bevor ich auf X Plattformen was halbgares abliefere :)

[Andre]

Kann mich da Chromanoid nur anschließen. Ich finde solche Sachen im 2D-Sektor immer ziemlich interessant :)

[Fetze]

Es gibt mal wieder ne Releaseversion mit ein paar neuen Features. Genaugenommen sogar einer ganzen Menge davon :D Zu den Highlights zählen:

:arrow: Komplett neu geschriebenes PropertyGrid zum Bearbeiten von Objekteigenschaften. Sieht besser aus, ist deutlich schneller, kann komplett mit der Tastatur gesteuert werden und hat vernünftigen Ctrl+C / Ctrl+V Support.
:arrow: Preview-Bilder für allerlei Ressourcentypen (Pixmap, AudioData, Font) für verbesserten Workflow
:arrow: Intelligentes Dragdrop, oder: "Ich zieh das hier mal nach da drüben, der Editor weiß dann schon wies gemeint ist". Einige Dinge lassen sich dadurch deutlich schneller bewerkstelligen.
:arrow: Komplettes Redesign der Editor GUI

Freue mich natürlich wie immer über jeden Tester, Feedback, Fragen und Anregungen sind immer gerngesehen :)

Downloadlinks:
--> Asteroids <--
--> Dynamic Lighting <--

(Wen's interessiert, einige der neuen Features hab ich in meinem letzten Blogeintrag ein wenig genauer beschrieben.)

[Fetze]

So, ich hab gerade ein wenig Zeit über, da kann ich ebensogut noch ein paar Worte zum intelligenten DragDrop verlieren - ich denke nach meinem letzten Post hat wohl kaum jemand wirklich eine Ahnung davon, was es eigentlich tut. :D

Also, worum gehts dabei eigentlich? Das Grundproblem ist eigentlich recht banal: Der Dualitor Workflow basierte von Anfang an zu einem gewissen Teil auf DragDrop, beispielsweise um Verknüpfungen zwischen Ressourcen (Materialien, Texturen, Sounds, etc.) und Komponenten von GameObjects (SpriteRenderer, SoundEmitter, etc.) herzustellen. Ich packe mir im Project View einfach die entsprechende Ressource mit dem Cursor und ziehe sie im Object Inspector auf den jeweiligen Slot der Komponente. Soweit kein Problem.



Ein anderes Anwendungsgebiet von DragDrop ist das Erstellen und instanziieren von Prefabs: Wenn ich als Nutzer ein Prefab aus einem GameObject machen will, greife ich mir das GameObject im Scene View und ziehe es in den Projekt View. GameObjects haben bei den Projektressourcen nichts zu suchen, das weiß der Project View und erstellt deswegen eine Prefab-Ressource, wo das gezogene GameObject dann reingepackt wird.



Will ich aus diesem Prefab jetzt ein GameObject instanziieren, packe ich mir das Prefab im Project View und ziehe es runter in den Scene View oder wahlweise auch den großen Hauptbereich mit der Levelansicht (Camera View). Dort wiederum haben Ressourcen nichts zu suchen, also wird das Prefab kurzerhand ausgepackt und eine Instanz des GameObjects erstellt.



So weit so gut. Auch ohne intelligentes DragDrop war das schonmal ein relativ intuitives Verhalten. Leider funktionierten nicht alle Dinge im Editor so einfach. Nehmen wir an, man wollte (ohne intelligentes DragDrop) ein Sprite-Objekt erstellen, das eine Grafik verwendet, die irgendwo auf der Festplatte herumliegt. Folgendes müsste man dafür tun:

1. DragDrop der Bilddatei in den Project View. Die Grafik wird importiert und eine neue Pixmap-Ressource wird angelegt.
2. Jetzt brauchen wir eine Textur, welche die Grafik verwendet. Rechtsklick auf die Pixmap-Ressource und "Create Texture" im Kontextmenü wählen.
3. Objekte werden aber nicht mit Texturen, sondern mit Materialien gerendert. Also Rechtsklick auf die Texture und "Create Material" im Menü wählen.
4. Jetzt brauchen wir noch das Objekt. Rechtsklick auf eine leere Stelle im Scene view und "Create / GameObject" wählen.
5. Das Objekt benötigt nun Komponenten um ein Sprite darstellen zu können, zunächst einmal eine Position. Rechtsklick auf das neue Objekt und "Create / Components / Transform" wählen.
6. Jetzt noch die Renderer Komponente: "Create / Components / SpriteRenderer".
7. Zu guter letzt müssen wir dem Renderer noch das Material mitgeben. Also die Material-Ressource packen und in den entsprechenden Slot im PropertyGrid ziehen, wenn das Objekt ausgewählt ist.

Wenn sich an dieser Stelle jemand denkt "Wtf, so viel Aufwand für ein einfaches Sprite?!", den kann ich beruhigen: In aller Regel passierte es nicht sehr oft dass man wirklich den kompletten Strang an Aktionen ausführen musste. Oft gab es ja bereits ein passendes Material oder das Objekt existierte schon, etc.
Trotzdem gab es da natürlich Verbesserungsbedarf und hier kommt intelligentes DragDrop ins Spiel. Spulen wir mal zurück auf Anfang und schauen uns an wie die gesamte Aktion jetzt mit intelligentem DragDrop aussieht:

1. Grafik importieren. Im Prinzip noch genauso wie vorher, da hat sich nix geändert. Siehe Punkt 1 oben.
2. Jetzt noch die neue Pixmap Ressource packen und in Scene- oder Cam View absetzen.
3. Tadaa!

Diese simple Aktion veranlasst den Editor dazu, automatisch Textur und Material zu erstellen, konfigurieren und abzuspeichern, ein neues GameObject zu erstellen sowie Transform- und SpriteRenderer Komponente hinzuzufügen. Vollautomatisch und superschnell :D

Aber kommen wir langsam mal zum intelligenten Teil: Was ist da intern eigentlich gerade passiert? Diese Aktion hardcoded festzulegen wäre doch ein übler Schnitzer im flexiblen Plugin-Design von Engine und Editor. Dem Editor selbst sollte es völlig egal sein, was es für Komponenten und Ressourcen gibt und was man damit tun kann, all dieses "Wissen" kommt erst über entsprechende Plugins hinzu. Doch selbst wenn man diese Aktion hardcoded in ein Plugin packt, wirklich schön oder flexibel ist das nicht.

Also auf zur Lösung des Problems:
Eine DragDrop-Aktion enthält grundsätzlich erstmal Daten eines bestimmten Typs. Das mögliche Ziel einer DragDrop-Aktion (also beispielsweise Scene- oder Cam View) interessiert dabei gar nicht, was für Daten das genau sind, sondern nur ob man diese in eine Form bringen kann, die das jeweilige Steuerelement verwalten kann. Die Cam View arbeitet z.B. mit GameObjects, da man diese dort drinnen herum schieben kann.
Grundsätzlich könnte man der Cam View nun also beibringen wie es andere Datentypen (z.B. Pixmaps) in GameObjects konvertiert, aber was ist dann mit der Scene View? Und allen anderen Steuerelementen? Damit man dasselbe Verhalten nicht allen Steuerelementen einzeln beibringen muss, ist es ratsam, dieses zu zentralisieren. Ein erster Ansatz wäre also, dass Cam View, Scene View und Co beim Feststellen einer DragDrop-Aktion die Rohdaten extrahieren, diese an die "Zentrale" weiterleiten und darum bitten, sie in GameObjects zu konvertieren.
Dieses Konzept abstrahierend kam ich auf folgendes: In der Zentrale wird eine Liste von DataConverter-Objekte verwaltet. Jedes dieser Objekte ist in der Lage, einen bestimmten Datentyp in einen anderen Datentyp zu konvertieren. Editor-Plugins können eigene DataConverter definieren und ebenfalls in der Zentrale registrieren.



Ich kann nun der "Zentrale" beliebige Objektdaten rüberschicken und Objekte eines bestimmten Typs zurückverlangen. Was die Zentrale nun tut ist herauszufinden auf welche Weise sich die registrierten DataConverters am effizientesten kombinieren lassen um die Anfrage zu erfüllen. Man kann sich das im Prinzip wie eine Pathfinding-Operation vorstellen.

Was also bei der oben vorgestellten DragDrop-Aktion intern passiert ist folgendes:
1. DragDrop erreicht die Cam View. Selbige verlangt GameObjects als Daten und startet "über die Zentrale" eine Konvertierung mit dem Zieltyp "GameObject"
2. Dort wird das Datenpaket geöffnet und festgestellt: Hm, Mist. Keine GameObjects drin. Fragen wir mal rum, ob sich ein Konverter mit Zieltyp "GameObject" findet
3. GameObjectFromPrefab und GameObjectFromComponents bieten sich an. Die Anfrage wird nacheinander an beide weitergeleitet.
4. GameObjectFromPrefab lässt sie nach einigem Pathfinding zurückgehen da der Konverter feststellt dass ihm die zum Arbeiten nötigen Daten fehlen. Es werden keine Prefabs gefunden und es lassen sich auch keine aus den verfügbaren Daten ableiten.
5. Bleibt noch GameObjectFromComponents. Ich überspringe jetzt aber mal die Pathfinding-Details. Die vollständige Konvertierungskette ist:


(Nicht alle existierenden DataConverter angezeigt)

Es werden also im Rahmen der Aktion automatisch eine Textur aus der Pixmap erstellt, dann ein Material aus der Textur, dann eine SpriteRenderer-Komponente die das Material nutzt und anschließend ein GameObject welches erst alle "required Components" des SpriteRenderers hinzufügt (Transform) und dann den Renderer selbst. Und da sind wir.

Natürlich kann man jetzt sagen "Oh man, so ein Aufwand für so ne Kleinigkeit", aber dieses System hier hat tatsächlich ein paar Vorteile, die anders nur schwer erreichbar wären. Es reagiert zum Beispiel sehr flexibel wenn Nutzer eigene Komponententypen erstellen - einfach einen eigenen Konverter schreiben (Wenige Codezeilen in der Regel) und in der Zentrale registrieren. Und sofort ist der gesamte Editor in der Lage, DragDrop-, Clipboard- und Konvertierungsaktionen mit den Nutzerkomponenten durchzuführen.
Ein anderer Vorteil entsteht durch die Arbeitsaufteilung der DataConverter: Eine Konvertierung wird nicht als atomare Aktion begriffen, sondern als Teamwork. Dementsprechend können auch viele DataConverter an einem gemeinsamen Datensatz arbeiten und sich gegenseitig ergänzen. Es ist beispielsweise ohne weiteres Möglich, im Project View ein paar Sounds und eine Textur zu wählen und den ganzen Packen komplett in die Cam View zu ziehen. Das Resultat ist ein GameObject, das neben der SpriteRenderer-Komponente (aus der Textur) auch eine SoundEmitter-Komponente enthält, welche die beiden Sounds als Sound Sources hinzugefügt bekam. Das ist nur dadurch möglich, dass DataConverter "in Teamarbeit" vorgehen.

Natürlich gibt es auch DataConverter, die das explizit verhindern. Packt man beispielsweise ein Prefab gemeinsam mit einem Sound, wird das Prefab instanziiert und der Sound ignoriert. Prefabs haben vorrang, da hier angenommen wird dass diese grundsätzlich erstmal in ihrer unbearbeiteten Reinform instanziiert werden sollen. Das ist nirgendwo hardgecodet, sondern steht im DataConverter GameObjectFromPrefab - welcher in der Zentrale bei Bedarf ohne Weiteres überschrieben werden kann.

Okay, jetzt hab ich eine ganze Menge Theorie von mir gegeben. Hier zum Abschluss noch ein paar kommentierte Codefragmente:

Das hier ist mal so ein DataConverter von Innen, und zwar TextureFromPixmap.

Code: Alles auswählen

public class TextureFromPixmap : DataConverter
{
    public override bool CanConvertFrom(ConvertOperation convert)
    {
        return 
            convert.AllowedOperations.HasFlag(ConvertOperation.Operation.Convert) && 
            convert.CanPerform<Pixmap>();
    }
    public override bool Convert(ConvertOperation convert)
    {
        bool finishConvertOp = false;

        List<ContentRef<Pixmap>> dropdata = new List<ContentRef<Pixmap>>();
        var matSelectionQuery = convert.Perform<Pixmap>();
        if (matSelectionQuery != null) dropdata.AddRange(matSelectionQuery.Ref());

        // Generate objects
        foreach (ContentRef<Pixmap> pixRef in dropdata)
        {
            if (convert.IsObjectHandled(pixRef.Res)) continue;
            if (!pixRef.IsAvailable) continue;
            Pixmap pix = pixRef.Res;

            // Find Material matching Texture
            ContentRef<Texture> texRef = ContentRef<Texture>.Null;
            if (pixRef.IsDefaultContent)
            {
                var defaultContent = ContentProvider.GetAllDefaultContent();
                texRef = defaultContent.Where(r => r.Is<Texture>() && (r.Res as Texture).BasePixmap == pix).FirstOrDefault().As<Texture>();
            }
            else
            {
                string texPath = pix.FullName + Texture.FileExt;
                texRef = ContentProvider.RequestContent<Texture>(texPath);
                if (!texRef.IsAvailable && convert.AllowedOperations.HasFlag(ConvertOperation.Operation.CreateRes))
                {
                    // Auto-Generate Texture
                    texRef = Texture.CreateFromPixmap(pix);
                }
            }

            if (!texRef.IsAvailable) continue;
            convert.AddResult(texRef.Res);
            finishConvertOp = true;
            convert.MarkObjectHandled(pixRef.Res);
        }

        return finishConvertOp;
    }
}

Und so wird er "in der Zentrale" registriert:

Code: Alles auswählen

CorePluginHelper.RegisterDataConverter<Texture>(new DataConverters.TextureFromPixmap());

(Die Zentrale hat noch einige andere Aufgaben - man kann dort z.B. auch Editor-Metadaten für Core-Klassen hinterlegen, z.B. zu nutzende Icons, etc.)

Hier eine zum Verständnis gekürzte und editierte Version dessen was die Cam View tut, um an ihre Daten zu kommen:

Code: Alles auswählen

private void LocalGLControl_DragDrop(object sender, DragEventArgs e)
{
    DataObject data = e.Data as DataObject;
    ConvertOperation convert = new ConvertOperation(data, ConvertOperation.Operation.All);
    if (convert.CanPerform<GameObject>())
    {
        var dragObjQuery = convert.Perform<GameObject>();
        List<GameObject> dragObj = dragObjQuery.ToList();

        // .. snip ..
    }
}

Mithilfe der ConvertOperation-Klasse sind es im Prinzip nur ein paar Zeilen, um jeden beliebigen Objekttyp anzufordern. Sie kapselt auch die ganzen Zugriffe auf die "Zentrale".

So. Hoffe, das war so halbwegs informativ :)

[Fetze]

Bin gerade leider ziemlich beschäftigt mit Studienkram und langsam stapelt sich eine Menge Zeug auf meiner ToDo-List. Zeit für eine kleine Spielerei war aber trotzdem, deswegen kann ich euch jetzt viel Spaß mit Tetris wünschen :) Ist übrigens nicht ganz der Klassiker, ganz so langweilig war mir dann doch nicht. Einfach mal ausprobieren ;)

Feedback und Highscore-Vergleiche sind willkommen :)



(Danke für die Musikuntermalung an SunandWeather)

[Fetze]

Hab mich in letzter Zeit nochmal ausgiebig mit der Integration der Farseer-Physikengine befasst. Neu sind unter anderem 14 Joint-Typen und eine Physik-Sandbox in der man das ganze mal in Aktion bewundern kann. :)



Das ganze kann hier heruntergeladen werden. Außerdem hab ich in der Zwischenzeit mal eine allgemeine Infoseite zu Duality aufgesetzt. Und ein neues Video zusammengeklatscht.

[youtube]3rAB2GRJfcc[/youtube]

Das angesprochene Downloadpaket zum selbst ausprobieren oder mit dem fertigen Template herumspielen gibts hier. Wer sichs nur angucken und nix selbstmachen will, kann den Duality Editor öffnen, neues Projekt wählen und dann das PlatformerTemplate.zip auswählen, das sich im "Example Content" Ordner befindet.

Wer sich Duality laden will, um damit selbst ein wenig herumzuprobieren, dem würde ich letzteren Download empfehlen - das ist eine zwei Wochen neuere Version, die ein paar mehr Features und viel weniger Bugs hat ;)

Jegliches Feedback ist wie immer willkommen :)