spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »David Scherfgen«

Ich habe mir das gerade mal angeschaut.
Macht wirklich einen sehr professionellen Eindruck. Mein erster Gedanke war "Das ist Unity für 2D". Du hast ja scheinbar quasi alle Konzepte übernommen. Allerdings erwähnst du Unity in keinem einzigen Wort in der Projektbeschreibung hier - finde ich ein bisschen bedenklich! Man könnte denken, dass du all diese Konzepte selbst erdacht hast, was aber gar nicht so ist.

Dass das Projekt von Unity inspiriert ist, müsste ich irgendwo mal erwähnt haben, doch Das Projekt heißt ja nicht umsonst "Duality", eine Anspielung auf "Unity", den "Zwei"dimensionalen Charakter der Engine. Deswegen zu sagen, alle wesentlichen Konzepte seien bloß gedankenlos übernommen worden, wäre allerdings falsch, auch wenn sich beide Systeme auf den ersten Blick ähneln mögen. Es ist auch nicht das Ziel, die "Unity Engine für 2D Spiele" zu entwickeln. Unity gibt es schließlich schon - man braucht nicht noch eins davon. Duality soll schon seinen eigenen Weg gehen.


Nichtsdestotrotz: Rein zufällig ist die Ähnlichkeit zwischen beiden Systemen sicher nicht. Da magst du schon Recht haben.

Zitat

Nichtsdestotrotz, gute Arbeit!
Sehe ich es richtig, dass es noch keine Collider gibt?

Es gibt in Duality keine Collider, nope. Ich vermute aber, du suchst die RigidBody Komponenten Wenn du reine Kollisionsabfrage ohne Physik willst, kannst du einen RigidBody erstellen und dessen Shapes in den Sensormodus umschalten. Sensorische Shapes kollidieren nicht im physikalischen Sinn, ermöglichen aber die Abfrage der Kollision. Am besten dann auch noch "IgnoreGravity" anschalten, sonst fällt der RigidBody ins bodenlose
Zur Kollisionsabfrage einfach ein eigene Komponente erstellen und ICmpCollisionListener implementieren. Die CollisionEventArgs kannst du dann auch in RIgidBodyCollisionEventArgs casten, falls du genauere Infos brauchst. Natürlich nur, wenn die Kollision auch von RigidBodies reported wurde, was momentan jedoch immer der Fall ist. Kollisionen werden übrigens auch bei nicht-Sensoren reported.

Es gibt mal wieder eine neue Binary Version von Duality. Ihr findet sie > hier <. Die wohl größte Neuerung dabei ist die flächendeckend einsetzbare Undo / Redo Funktionalität: Egal ob im Scene Editor Objekte verschoben wurden, Properties verändert, Prefabs instanziiert oder RigidBody Shapes angepasst - mit Strg+Z kann jeder Schritt einzeln rückgängig gemacht werden, mit Strg+Y können rückgängig gemachte Schritte wiederholt werden.

Das Wechseln der Szene leert die Undo History allerdings und Dateisystem Aktionen wie das Löschen, verschieben oder Umbenennen von Ressourcen sind erst einmal bewusst vom UndoRedo ausgespart worden. Ebenfalls ist es im Sandbox Modus nicht verfügbar, aber dort macht es vermutlich ohnehin nicht besonders viel Sinn

Weil etwas so grundlegendes wie globales Undo / Redo in der nachträglichen Implementierung keine Kleinigkeit ist, kann es sein, dass derzeit noch Inkonsistenzen oder Fehler auftreten, die mir in meinen Tests bisher entgangen sind. Sollte unerwartetes Verhalten auftreten, wäre ein kurzer Bug Report super

Changelog:

• UndoRedo in erster Iteration (s.O.)
• Die Skalierung eines Objekts (Transform.Scale) ist jetzt ein float und kein Vector3 mehr. Damit sind nur noch gleichmäßige Skalierungen möglich - in der gesamten Entwicklungszeit des Projekts hatte ich jedoch nie einen Fall, an dem man ungleichmäßige Skalierung wirklich gebraucht hätte.
• Textdarstellung von Fonts mit deaktiviertem Filtering verbessert. Wirkt deutlich schärfer als zuvor.
• Alternative Kamerabewegung (Space + Maus) rotiert (Rechtsklick) jetzt etwas schneller
• Fehler behoben, der dafür sorgte dass eine externe Aktualisierung von Ressourcen nicht bemerkt wurde. Teilweise wurden bearbeitete Bilder nicht innerhalb der Engine aktualisiert.
• Previewdarstellungen aktualisieren sich jetzt auch beim Neuladen externer Ressourcen verlässlicher
• Weitere kleinere Bugfixes

Arbeite seit geraumer Zeit primär an der Dokumentation des Projekts - ein Teilbereich, der leider viel zu oft in Vergessenheit gerät. Dementsprechend gibt es einigen Nachholbedarf. Den Anfang machen einige kleinere Aufräumaktionen am Wiki, gefolgt von einem ersten Tutorial:

Zitat

Du hast bereits selbst erwähnt, dass bei weitem nicht alles beschrieben wird. Du könntest dir u. a. dafür Textboxen mit einer hervorhebenden Hintergrundfarbe (gelb, grün oder blau), welche dann "fortgeschrittene Hinweise" oder Stellen zum Weiterlesen liefern, wenn man sich dieses Themengebiet weiter anschauen möchte. Als Beispiel könnte ein Artikel über Java, in dem man über Vergleiche und Strings liest der Hinweis stehen, dass man Strings nach Möglichkeit immer mit der Methode equals vergleichen sollte. Später könntest du vergleichbare Boxen auch für Übungsaufgaben in Tutorials verwenden.

Mhm ja, das klingt eigentlich gar nicht so schlecht. Ich muss mal schauen inwieweit das mit Google Code Wikis komfortabel machbar ist, aber hier und da mal weiterführende Themen einstreuen oder Übungsaufgaben stellen ist für ein Tutorial sicher nicht verkehrt. Weiterführende Themen könnte man natürlich statt mit Textboxen auch einfach über Links im Text einfügen. Allerdings müsste es diese Themen dafür auch erstmal geben Da liegt noch einiges an Schreibarbeit vor mir.

Zitat

Du verwendest kein einziges Bild. Mit Bildern könnte es dem Benutzer einfacher fallen, bestimmte Dinge wiederzufinden oder sich diese zu merken. Es müssen nicht übermäßig viele oder große Bilder sein, aber sie würden für eine gewisse Auflockerung des Texts sorgen.

Eigentlich ist da alles voll mit Bildern? Sind ne ganze Menge. Ich hab das jetzt auf drei Rechnern mit Firefox, Chrome und IE getestet, gab bisher nirgendwo Probleme. Mit welchem Browser bist du unterwegs?


Sonst noch jemand ohne Bilder?