**Sorting Stumper--Update.** I finally got the "Water Room" to render correctly. Here it is with the proper rendering order: Floor -> Marika -> Wall

There are about seven layers in this sector. Moving the actor to the correct subsector ("Occupiable Volumes") was already implemented as part of the collision detection system. So that part came together easily. I just had to get the walls and OVs into the correct layers, which proved to be a bit more challenging than I originally thought. (This is usually the case...)

This is only the first correct room, so I'm not convinced yet that I won't find a few more bugs... but this is a good sign. I can move on to the next thing.

The Water Room is a pretty complicated room. It's not one of the most complicated, but it is far from the simpler test cases I've been using. It has 43 visible walls and 4 OV's. These 47 structures are organized in a graph which is the dependency graph. I figured out Mathematica has a neat feature where it will construct a graph from its adjacency matrix. Being able to look at the graph made it much easier to debug everything.

This is the graph. It's how Vallas Engine (well, the renderer and collision detection parts) sees the room.

The nodes labelled 44 - 47 represent the OV's. The rest represent walls. It's a directed graph where the direction indicates which structure is to be rendered in front of the other. The depth of a node will be the layer the structure should be rendered on.

So if you're writing a walls-based isometric renderer (as opposed to the usual tile-based), here is a general algorithm that will handle rendering order.

`1. Create a graph. Add one node for each quadrilateral (representing a wall) or hexagon (representing an OV).`

2. For each node A and for each node B, determine if their polygons overlap

2A. If the polygons overlap, determine whether the corresponding 3D structure of A is in front of B, or behind, or neither.

2B. If A is in front of B, then connect node A to node B.

2C. If B is in front of A, then connect node B to node A.

3. Write the topological sorting of this graph. I used Kahn's algorithm for this. If the graph is cyclic, return "Fail" (This is what I call the "Escher Error", since the endless staircase will trigger this problem)

4. Compute the depth of each node. I used (ref 1) as a guide, but not the code presented. (ref 2) also is a good reference... a bit better if you haven't seen much graph theory and want a deeper explanation of what's going on.

5. Compute the depth of the deepest node. Call it D

6. Create D number of layers.

7. Draw each wall on the layer N, where N is the depth of its corresponding node.

8. Draw each sprite occupying an OV on the layer N.

Note that 2A, 2B, and 2C are not trivial problems. They are problems I've discussed elsewhere in the thread, though. I spent more time debugging the code handling these three steps than any other part of the process.

Now I have a solution I'm happy with. It's one graph that handles everything rendering related. This solution feels more "graceful" than the previous--the two phase process that felt clunky.

This was one of the final "big problems" in the core engine that I knew I'd have to solve, so it's good to get this one out of the way.

While I'm still working on the map editor and a few other design tools, I've slowly started moving onto the game itself. I worked out more details on a storyline that I think will do well for the episodic format I'm planning on. I've made some further adjustments to the overall map, features list, and stats tables. No release date, but I expect to be done before the heat death of the universe.

*References.*(1)

https://stackoverflow.com/questions/2525316/longest-acyclic-path-in-a-directed-unweighted-graph(2)

https://www.geeksforgeeks.org/find-longest-path-directed-acyclic-graph/