(Paraphrasing Rincewind the Wizzard)

Greetings!

Baggers is continuing his amazing work on the new backend and Dwarf has started exciting work on the Kickstarter "Help design a" rewards! So this week I'm going to be rambling on about stuff. Stay awhile, and listen. I mean, if you've got some time...

Everything in this update is still work in progress, UI, etc will evolve, so will the features themselves.

Let's talk about the floors.

This past couple of weeks, I've been working on building mechanics, and more specifically, how they should work with floors. We're technically obliterating the floor concept as it existed in the Early-Alpha. That doesn't mean we're removing verticality, of course, it just means that we're trying to embrace it fully by allowing GMs to stack blocks onto each other, not worrying about what is a "floor" and what isn't.

This new solution doesn't come without its share of challenges, however, as there are certain things associated with the previous system that I'd like to maintain. There was also clarity in the last implementation, and everyone could refer to the floor by number, which quickly translated across. Also, this adds a bunch of complexity. Not only in systems written, but a lot when it comes to the (UX)User Experience. What are the" points of interest" on the vertical space?

How do we communicate that with other players? Where should we cut to make this area visible without hiding relevant information?

I'm trying to move backward through my thought process on these experiments, to talk a little bit about why I went down specific routes.

Navigation

Moving around vertically is the first issue to solve. As we now require somewhat free movement on the vertical axis a couple of things has been added. [SHIFT] will be repurposed to move vertically, while a lot of the building tools will be associated with [CTRL] (delete, copy, sample). (The new input system will allow for easier remapping of these, mapping them to separate buttons should also work). I Added double-click to move to a location, working across all 3 axes. There is also a new marker indicator bar that has a slider to move the camera plane up and down. So far this does feel pretty good and answers our question about basic navigation in vertical space. It will require more actual game testing to settle on though.

"Floors" and Indicators

Looking at the above example, it sort of feels like floors are very much still there. But in reality, the markers clicked on to the right are clusters of creatures. That was mainly done to test the system as creatures are not a great way to calculate where markers should be placed. Although players and Game Masters would be seeing the same markers at the same locations, they also reveal quite a lot about the tower to our players. One could have the ones shrouded in fog, hide, but that would be another piece of data for the Game Master to keep track of. A different approach is to analyze the space with clusters of walkable spaces and try to guess what "a floor" should be. Or maybe more appropriately make it easy for the GM to create bookmarks/markers, both permanent and temporary, which could allow for a bit more control. The answer likely lives with multiple of these options. 

All of this also makes me want to ask the question of, should players even be able to move between floors which the GM doesn't deem a point of interest. This is a question for another time, however. 

Before moving onto the next topic, this solution maintains the nice juicy feeling of moving between floors, but it doesn't fully solve the problem of clarity between Game Masters and players, which is something we'll have to dig into soon.

Visibility, Colliders, and Building

One of the greatest features of the new system, and quite frankly why we needed to get rid of floors, to begin with. Building.  Now you're able to stack blocks on top of each other, not worrying if it lines up with our preset "floor" height.  We could have kept the floor system, and enabled each floor level height to be defined by the Game Masters. That would make sense if you have a single structure, but if you're at the ground floor of a tavern, you don't necessarily want to flatten the rest of the city. As a result, we've centered the visibility around the Camera target. It is currently set to be a square, which can be moved up and down by using the sliders to the right (might change). Zooming out also reveal all hidden tiles (might also change). This along with our cutout shader we can get pretty good visibility within structures which multiple floors. 

I started talking about this great building feature, and then suddenly shifted to visibility. The reason for that is I wanted to talk a little bit about some challenges associated with implementing building with this new system. 

(I might on occasion accidentally use the phrase "floor", but what I really mean is a vertical marker, which indicates a vertical point of interest.)

(If you know what raycasting in games is, I'd skim through this next part) I mean, stacking tiles on top of tiles is great! nothing wrong with that, but what happens if you want to furnish a room way down in your tower, or replace a wall inside. The way the Early Alpha building system works is that we just RayCast down the camera, and interact with the first surface we hit or the plane of the currently selected floor. Raycasting is like pointing a laser at something and seeing where the red dot appears, and from that, we can ask for all sorts of information, including the tile/model hit. It should work perfectly still, but the way we hide tiles is actually more of an optical illusion. The laser still believes they're all there. The red dot would still appear on the outside of the wall, unable to see inside. One solution is to remove the optical illusion, and just actually remove the tiles, temporarily. But there are certain benefits to leaving them in place. One is performance. Disabling\Enabling them (or removing them as per my analogy) is costly, but the main reason is. How would we stop you from building/placing tiles through other tiles? Let's say you forget there is another "floor" above yours. It would be good for us to be able to warn you. This is why we went with another feature of RayCasting. Let's call it XRay mode. Instead of hitting the first thing you see. You can turn on x-ray, and ask it to return ALL the tiles it passes through. Now we get a list of all the Tiles they laser passes through, and we can ignore all results with the illusion applied. 

(if you do know what Raycasting is and happen to be using Unity. Remember that Physics.RaycastAll & RaycastNonAlloc doesn't guarantee being ordered by distance. This took me a while to discover, despite it being clear in the documentation)

With this approach, we should be able to create a visual indicator when something you're building is intersecting with something hidden. How that should be represented visually is still a work in progress. All of this does enable pretty free building, without having to worry about floors, which has been our goal.

Oh, we've also got a separate, moveable, Build plane, which gives you the option to place "floating" things. As hinted at below.

This is still rather clunky, but it's next on the list.

Final thoughts: I think this covers a lot of our requirements. It is currently feeling pretty good! The main thing which hasn't been answered is clarity across players and GameMasters. Making sure there is a consistent language that can be used for communicating where and what. 

Thank you very much for getting this far through the rambles. I apologize for the low resolution on those gifs, I'll fix that for the next update I write.

Till next time, have fun!

TLDR: We got rid of floors in favor of a marker system. This allows free building being able to cut into areas dynamically, and locally. You can now also build things inside of rooms, replace walls, etc. Still, a lot of work to be done.