As a reminder for anyone who hasn't seen this yet, I've created a player survey in Google Forms: [b][url=https://docs.google.com/forms/d/e/1FAIpQLSd38NmuWFg7Dprk1Y82LV1oO-dLfkLLaghV5uGV1qqTZCKs8A/viewform?usp=sf_link]Google Survey[/url][/b] This week I am mostly just continuing to work on the "Creator Tool" project. The goal of this is to transform my design tools into something that others could use to create their own content. Still no promises when or even if this will be made available, but I'm making good progress. I am currently working on what I expect to be the hardest part of the tool, the Region Editor. I have the working version of it that I used during development, but there were aspects of that version that I don't like, so I'm doing a full rewrite. [img]{STEAM_CLAN_IMAGE}/42185452/ab2c59ef8622581c6de0539a4b482923db54504a.png[/img] Two of the bigger challenges with redesigning the Region Editor: [h2]Coordinate Systems[/h2] There are many different coordinate systems that object positions may be represented by: world coordinates that Unity's rendering and physics operate on, the game logic's "SuperCoordinates" used for storing absolute position at scale and across universes, local position used for constantly keeping the sectors immediately around the player active and positioned correctly, the coordinates that the player actually sees displayed, "region relative" versions of the SuperCoordinates so I don't have to design and position the entire universe at once, and then the various screen and UI coordinate spaces that emerge from actually being able to visualize all of these in the tool. [h2]Data and Class Design Constraints[/h2] The logic of how the universe "works" evolved over the development process and at this point is both complex and fairly robust. Which means the new Region Editor needs to work while making few if any changes to the existing world logic. At the same time, there are design problems with the original Editor that I want to correct. For example, the original Editor used the same "GameWorld" class as the game itself to organize persistent objects. This made sense at the time, but in hindsight it limited the tool too much, particularly now when if I want to add new features that the GameWorld logic doesn't support. The downside is re-duplication of some logic that I need in the Editor, but don't want to refactor out of the GameWorld for the aforementioned reasons. Until next week! - Kevin