Chapter 6: Too much spinning
I think the navigation Moose is designing is too complex. I am going to take more screenshots and outline for him exactly how to figure out the layout of the dungeon so that he can navigate. First I'll take a look at his code. Actually, I just had Moose describe it to me and he confessed to its complexity. I have entered the maze and taken screenshots that show what it looks like with walls, open space, and doors from many points of view, then engaged with Moose like this:
They are named based on Left, Forward, Right and Wall, Open, Door. A file called "WWO" means "Left side of current cell is Wall, Forward of current cell is Wall, Right side of current cell is Open". When you see D, it means Door, and its place in the filename indicates where the door is.
Sometimes there are 2 examples, in which case the filename ends with (2)
When in the maze you CAN show Status of the party, in which case party information occupies a lower portion of the screen. Filenames ending in "status" have the status portion visible.
If you try to walk into a wall you will see the message shown in the file called 'Blocked'
Note that you don't need to K)ick a door. You can just walk forward through it.
Use these screenshots to make determining cell options very simple. When you arrive at a cell, calculate the LFR. If you walked into that cell, you can determine what is behind you (typically D or O), based on what was in the cell you are walking out of.
Use the information I have provided to make the simplest representation possible of the map and navigation options.
Moose did all that, but we talked back and forth about how he was representing a cell. It was more complex than it needed to be, and I steered him to a simpler representation.
| Old JSON | New JSON |
|---|---|
|
|
We launched another maze run, and navigation was much better. No spinning around assessing where there were walls, doors, and passageways.
A screenshot of "Open, Open, Wall"
But first, I find that Moose is adding code to keep all previous runs backward-compatible with the code. As the JSON schema for the map evolves, Moose has a path to migrate the old maps. I told Moose that at this stage we need to accept "breaking changes" and accept that we'll need to be starting from scratch frequently - because I don't want to accululate a cruft of migration code that is only used during development. So removing ALL backward compatible code is the next workitem.