spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »neon_symp«

Was ist das Ziel von dir? Möchtest du deinen Maker ähnlich wie Construct2, GameSalad, Unity and co populär machen (ok, wer würde das nicht wollen ), oder machst du das einfach so ohne wirkliches Ziel?

• Ich hatte meine Game Engine ZweiDe sowie das Spiel Nullpunkt fertiggestellt und war es leid, immer wieder "denselben" Code zu schreiben und am Ende eines Projekts größtenteils einzustampfen. Insbesondere die notwendige Editor Entwicklung war lästig, weil meist zu stark spezialisiert, um für andere Projekte weiter nützlich zu sein. Mein Ziel war ein Framework für "all meine zukünftigen Hobbyprojekte".
  
• Kurz vor Beginn der Entwicklung hatte ich als Student bei einem lokalen Spieleentwickler gearbeitet und arbeitete dort mit Unity. Ich mochte die Idee dahinter und einige wesentliche Konzepte, störte mich aber an einer ganzen Reihe von Detailentscheidungen. Ein Mix aus "Inspiration" und "Es besser machen wollen".
  
• Ich kann kaum aufzählen, wie viel ich durch die Entwicklung von Duality gelernt habe und nutze es für mich als Plattform, auch weiterhin dazuzulernen.
  
• Teilweise ist es auch zum Selbstläufer geworden, gerade wenn es um die Nutzung durch Community und Indie Entwickler geht. Als mich BatCat / DigitalFurnace darüber informiert hat, dass sie gerne Duality nutzen würden, war das eine großartige Neuigkeit - aber auch eine absolute Feuerprobe. Plötzlich saß ein ganzes Art Team am Editor während zwei Programmierer eifrig Plugins schrieben, an die ich noch keinen Gedanken gerichtet hatte. Es kamen viele Requests, eine Menge Bugs rein und ich war dadurch auch ziemlich aktiv im vergangenen Jahr: SVN-Merge-taugliche Duality Ressourcen, ein komplett neues Cloning System, der Umzug auf GitHub, NuGet Support, Package Management und unzählige Bugfixes und Tweaks entstanden im Grunde alle aus dem Feedback das ich auf diese Weise bekommen hab. Super stressig, aber auch ein riesiger Entwicklungs- und Qualitätsschub! (Und ansonsten trudeln immer mal wieder Requests seitens der Community ein, die mich auf Trab halten.)
  
• Es macht zeitweise einfach auch eine Menge Spaß.
  
• Es ist schön das Gefühl zu haben, etwas sinnvolles zu tun.
  

Zitat

#ADD: Added logging for a lot of (non-personal) system specs by default.
#ADD: The top keyboard number keys can now be used to switch between the available camera view states when the cam view has focus. (BatCat)
#ADD: Added more unit tests for various classes.
#ADD: Log entries now carry the context of their message, derived from the object parameters in their Write call. (AdamsLair & BatCat)
#ADD: Double-Clicking a log entry in the LogView now highlights the messages context object. (AdamsLair & BatCat)
#ADD: Added a small but neat API for handling the applications focused state: DualityApp.IsFocused.
#ADD: Added an interface to plug in custom renderer visibility strategies for custom performance optimizations. (AdamsLair & BatCat)

#CHANGE: As of now, Duality manages the "Source/Media" folder to mirror the "Data" directory in a non-destructive way.
#CHANGE: Duality now preserves folder structures when importing new media directly from within the "Source/Media" directory.
#CHANGE: Refactored graphics initialization.
#CHANGE: No longer asking for confirmation when closing the editor and no changes have been made. (BatCat)
#CHANGE: FileHash performance improvements. (BatCat)
#CHANGE: Editor startup performance improvements. (BatCat)
#CHANGE: Improved performance of managing Scene objects ingame. (BatCat)
#CHANGE: Huge performance improvement for keeping the Scene clean using a ridiculously small change.
#CHANGE: Improved RawList.RemoveAll performance significantly by using a more efficient algorithm.
#CHANGE: Now using Parallel execution on SetPixelData commands to speed up image import via Bitmap objects. (AdamsLair & BatCat)
#CHANGE: DrawOnto and various dependent methods now use a partitioned parallel execution approach rather than Parallel.For, speeding up loading times.
#CHANGE: Improved performance of PathHelper.FilesEqual method by reducing disk read ping-pong.
#CHANGE: Pixmap.Layer now properly disposes temporary Bitmap objects immediately after no longer needing them.
#CHANGE: Refactored and cleaned up Project View / Scene View context menu creation and handling code.
#CHANGE: Moved tree view node classes to separate files.
#CHANGE: Moved common Resource name functionality to static ContentProvider methods.

#FIX: Fixed DrawDevice finalizer performing illegal cross-thread graphics calls.
#FIX: Fixed silent failure when creating a project on a storage medium that doesn't have enough space.
#FIX: Fixed crashbug when failing to determine parameter types while parsing XML code documentation files.
#FIX: Fixed a bug when renaming content refs and their Type is missing due to source code changes. (BatCat)
#FIX: Fixed IContentRefPropertyEditor throwing a NullReferenceException when getter returns null objects. (BatCat)
#FIX: Fixed FullWindow screen resolution changes not using the displays native size.
#FIX: Fixed a rare problem the could occur when a logged object's ToString implementation threw an exception in the wrong moment.
#FIX: Fixed Camera.Pass.CollectDrawcalls event being serialized by accident.
#FIX: Fixed ProjectFolderView object creation menu ignoring the invisible flag.
#FIX: Fixed CreateObjectDialog showing certain Types recursively.
#FIX: Fixed Pixmap throwing unintelligible Exceptions if something goes wrong during Layer image file saving.
#FIX: Fixed unhandled exception when hitting F2 in the Project View before actually selecting anything ever.
#FIX: Fixed several misspellings in comments. (caryanne)

#REMOVE: Removed FlushDisposedObjects extension methods, because they've become trivial.
#REMOVE: Removed legacy code that monitored "Source/Media" for rename operations and attempted to auto-update Resources. This was nonsense. "Source/Media" is designed to be a receiver, not a sender.