spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Schorsch«

Verstanden und akzeptiert. Es handelte sich um ein Skript welches einem Objekt hinzugefügt wurde welches per Drag and Drop im Scene View erzeugt wurde. Vor allem da ich die Variable nicht als Property implementiert habe finde ich das Verhalten recht undurchsichtig. Mir ist klar warum es so läuft wie es läuft, aber anders wäre es klarer. Der "Standardwert" wurde ja nicht im Editor sondern zuvor im Code gesetzt. Das sollte meiner Meinung nach auch weiterhin möglich sein. So zumindest meine Meinung. Ist aber eine Designfrage.

Ich stimme zu, dass hier rein aus Sicht eines Nutzers, der mit dem Editor arbeitet, intuitiveres Verhalten denkbar wäre - gerade am Anfang kann man so schonmal in die Falle tappen leider Technisch ist das aber nicht ohne Weiteres möglich, ohne für jedes einzelne Objekt Buch zu führen, welche Werte explizit geändert wurden und welche noch auf ihrem Startwert sitzen und dementsprechend aktualisiert werden können. Property hin oder her, ein Feld kann ja auch durch andere Einwirkungen einen anderen Wert annehmen als den initialen Wert, oder zufällig wieder auf genau diesem landen. Duality verhält sich da nichtdestruktiv und überschreibt sicherheitshalber erstmal nichts - warum sollte es auch nachträglich die Daten von bereits existierenden Objekten anfassen?

Zu genau diesem Zweck gibt es aber Prefabs: Aktualisiert man ein Prefab zu einem späteren Zeitpunkt, werden auch alle Instanzen dieses Prefabs entsprechend angepasst, mit Ausnahme aller explizit anders gesetzen Eigenschaftswerte. Ein Prefab enthält sozusagen alle Standardwerte. Die Prefab-Instanzen können beliebige andere Werte annehmen - nicht überschriebene Werte werden aber auch nachträglich angepasst. So ist es beispielsweise möglich, einen bestimmten Gegnertypen als Prefab zu definieren, ihn hundertmal in verschiedenen Levels zu platzieren, und später dann doch nochmal den Maximalwert für dessen HP abzuändern - ohne alle nochmal anfassen zu müssen. Der eine doppelt so große Gegner in Level 15 mit einer explizit deutlich höheren HP Zahl wird dabei nicht betroffen, da seine HP ja explizit überschrieben wurden.

Ein alternatives Konzept stellt Blueprinting dar, wobei man eine eigene Ressource definiert (Einfach von Duality.Resource ableiten), welche Rahmendaten eines Gegnertyps enthält. Die konkreten Gegner haben in ihrer jeweiligen Komponente dann einfach einen Verweis auf ihr jeweiliges Blueprint, wo die entsprechenden Daten nachgeschlagen werden. Der größte Vorteil gegenüber Prefabs ist eine deutlich leichtgewichtigere Umsetzung einzelner Gegner-Objekte, der größte Nachteil die Unfähigkeit, bestimmte Werte je Gegner anzupassen.

Mit welchem Konzept man besser fährt, ist teils Geschmackssache und teils abhängig vom konkreten Fall. Am Ende braucht man dann eben das richtige Werkzeug für die richtige Aufgabe

Zitat von »Schorsch«

Das mit den Blueprints klingt interessant und das werde ich mir mal genauer ansehen. Das Prinzip mit den Prefabs kenne ich ja aus Unity. Ist halt auf Bequemlichkeit dass ich mir mein Objekt in der Szene zusammen baue und teste und danach ein Prefab erstelle. Aber der Workflow lässt sich ja leicht anpassen. Was dennoch ganz schön wäre. Baue ich ein Objekt in der Szene zusammen und mache daraus ein Prefab, so werden wenn ich das Prefab selsbt anklicke keine Komponenten angezeigt. Zumindest nicht die, die bis zu dem Zeitpunkt der Erstellung schon bestanden haben. Hier wäre es schön wenn man auf dem Prefab alle Komponenten sehen und verändern könnte. Oder mache ich etwas falsch?

Nope, da machst du nix falsch, das Feature ist einfach noch nicht umgesetzt Werde ich mir für die Zukunft vormerken, das klingt tatsächlich recht praktisch - insbesondere gekoppelt mit der Möglichkeit, die Prefabs direkt zu editieren.

Nachdem meine wochenlangen Bemühungen an einer adäquaten Lösung des Cloning Problems nun endlich mit dem Merge in den main branch ein würdiges Ende gefunden haben, ist nun auch wieder Zeit für andere Dinge. Und ich dachte mir, es ist wäre mal wieder angebracht, Duality im Selbsttest auf Herz und Nieren zu prüfen, sprich: Damit ein Spiel zu bauen. Dieses liegt inklusive Code und Content zu 100% auf GitHub und wird nach seinem Abschluss als Sample in NuGet hochgeladen, sodass es sich via Duality Package Management in wenigen Klicks installieren und von Neulingen inspizieren lässt.

Soweit sind lediglich ein paar erste Schritte getan. Wer will kann mir beim Entwickeln quasi live zusehen, GitHub hat immer die neueste Version



Waffen / Projektile eingebaut:



Mehrere Spieler, Farbgebung:



Dynamisch zugewiesene Eingabemethoden, derzeit bis zu zwei Gamepads und / oder Maus / Tastatur Kombo:



Automatische Anpassung des Kamerazooms an verfügbare Fläche / DPI des Monitors:



Experimente mit minimalistischem Art Style:

Bastle an einem ersten Gegnertypen.



Tut noch nicht viel, hat aber eine nette Augen-Animation fürs Idlen.

Hab ein wenig am ersten Gegnertyp gebastelt. Eine Mine, die hochgeht, wenn man ihre Stacheln berührt.



Die Stacheln werden einzeln kontrolliert und nur dann ausgefahren, wenn der Weg frei ist. So sprengen sie sich nicht einfach selbst in die Luft, wenn sie zu nah an Hindernissen aufwachen.



Das ist auch in Situationen hilfreich, wenn zwei Minen direkt nebeneinander liegen.



Wenn man sehr vorsichtig fliegt, kann man sie auch ein wenig herumschubsen, ohne sie auszulösen - man darf bloß die Stacheln nicht berühren.

Fortschritt am Example Project

Habe derweil ein wenig an der KI der Minen im Beispielprojekt gebastelt. Sobald man nah genug ranfliegt und sie einen in direkter Linie sehen können, wachen sie auf...



...und folgen dem nächstgelegenen Spieler. Während dem Flug fahren sie ihre Stacheln ein, um sich nicht durch Kollisionen versehentlich selbst auszulösen, oder weil jemand auf sie schießt.



Wenn sie nah an ihr Ziel heran kommen, fahren sie die Stacheln wieder aus und sind damit wieder explosiv.



Nachdem eine gewisse Zeit kein Ziel in Sicht ist, legen sie sich wieder schlafen und verschmelzen optisch mit ihrer Umgebung.



Aus Gameplay-Sicht habe ich mir gedacht, dass die Dinger am besten nahezu unverwundbar sein sollten - so ist man gezwungen, ihnen entweder ganz auszuweichen oder sie aber durch trickreiches manövrieren gegen einen Felsen fliegen zu lassen, während sie gerade ihre Stacheln draußen haben. Muss da nochmal drüber nachdenken und ein wenig herumprobieren.

Binary Update und noch mehr Beispiele

Es gibt eine neue Duality-Version als Binary release, sowohl per frischem Download als auch über den Package Manager als reguläres Update.

Das ganze ist jetzt wieder auf einem Stand mit dem GitHub master branch, was heißt dass nun auch das neue Cloning System, sowie all die kleinen Bugfixes und Tweaks es in die Binary Version geschafft haben. Wer gerade laufende Projekte hat: Bitte mit Vorsicht updaten, eventuell müssen ein paar Dinge in eurem Code abgeändert werden. Neue Nutzer können sich aber bedenkenlos auf die aktuelle Version stürzen

Mit dem Release der neuen Binaries konnte ich nun endlich auch ein paar Sample Packages hochladen, die schon eine Weile verfügbar sind, sich aber auf die neue Version stützen und daher erst jetzt veröffentlicht werden konnten. Sample Packages sind wie alle anderen auch im Package Manager verfügbar, enthalten aber primär nicht unbedingt eigene Plugins, sondern Content zum Ausprobieren. In diesem Fall Beispiele für Steering und DynamicLighting. Hier ein kurzer Blick darauf, was ihr bekommt:

Ambient / Directional Lighting und Herumschieben eines Point Lights:



Steering Behavior und einstellbare Aggressivität von Agenten:



Die Plugins an sich waren bereits seit geraumer Zeit verfügbar, aber da es keinen Beispielcontent gab war es nahezu unmöglich, damit herumzuspielen ohne vorher viele Stunden zu investieren, um erstmal zu verstehen, wie das alles eigentlich funktioniert. Genau hier sollen die beiden Sample Packages abhilfe schaffen: Im Package Manager installieren, Neustarten, Beispielszene öffnen, fertig.

Was mir persönlich wichtig war: Auch wenn beide Plugins von mir stammen, müsste das definitiv nicht so sein: Auch ohne am Source Code von Duality irgendwas zu verändern, kann jeder Nutzer eigene Plugins entwickeln und diese als Packages bei NuGet hochladen und wenig später sind sie für alle anderen Nutzer verfügbar. Das ganze ist also ein offenes System, zu dem jeder konstruktiv beitragen kann - was aktuell aber fehlt sind erstmal Leute, die sich Duality schnappen, um (Plugins hin oder her) coole Sachen zu bauen.

Duality im Overnightcontest der Devmania, anyone?