Problems Worth and Not Worth Solving

I've added the ability to mark a cutscene as a repeatable transition, and I've tought the borg to avoid these when pathing within a map, as well as to use them when navigating to a destination map. Marking a cutscene as such still happens manually, and will probably stay that way.

 

There's a lot of little fiddly things in this game that don't show up often enough to justify writing code to handle them. For example, there's a few places in the Ship Graveyard where you can hop from stone to stone to reach a destination. This just about the only place in the game where they use this mechanic, so I just included a few manual movement commands to get through those parts. Climbing the vines in the Worus Tower counts as a cutscene, but it only triggers if you walk into the square from the proper direction, *or* if you walk in from the side and then bump the right direction. This happens in more places, but it'll be a big pain to teach the borg that distinction, so I'm leaving that as well. If it happens to walk into a cutscene from the wrong direction, I'll tell it to walk next to the cutscene and add a manual movement command to approach properly.

Other stuff I'm willing to support with new code. FF5 has squares that quickly push you in a specific direction (such as the waterfalls in Worus and, I suspect, sand in the Quicksand Desert). These aren't cutscenes or transitions; they just happen. I haven't implemented any notion of what direction they push you, but I am giving these squares their own thumbnail in the atlas and treating them as obstacles until I find a place where I need to use them. Then we'll decide if anything more involved needs to be written.

There's also an odd quirk with NPCs when entering areas that show a title; NPCs don't seem to get marked as stationary until after that title window gets closed, so if the cartographer walks into a mostly explored map and the only unvisited squares are under stationary NPCs, it'll choose a path to that square, assuming at the time that the NPC could be pushed out of the way. I'll probably teach the Cartographer and Navigator to press A or B to close the title window before choosing their next path.
 

Doors

Push-open doors are becoming more of a problem than I had anticipated. The borg's movement state doesn't seem to recognize that a move command into a door didn't actually move the player, so we're getting off of our movement path by one square and getting stuck in a lot of places. We already have a check for whether FF5's internal movement flag is set after a movement command, but apparently that's not enough in this case.

My inclination is to add a check for each step to verify that we're on the square we expected to end up on, and to retry the movement if not, retaining the current limit of 200 consecutive failures before panicking. I'm worried that this is going to be a problem with transitions and cutscenes, though. We'll see what happens.

We're pathed and mapped partway through the Ship Graveyard. Karboros wasn't a problem with four monks, as expected.

Edit: Ended up changing how the pre-move cooldown works in the movement state, and our door problems are gone. Pathed through the Siren fight. Sometimes she doesn't even have time to switch form before the fight is over.

Traffic Jams

Results of trial run: Pathing/routing failure.

Details: This is where the borg got stuck:

 

The obvious problem is that our party is trying to walk North, and we've managed to pin an NPC between us and the stairway to the North. However, to really understand everything that's going on here, you're going to need to know more about how FF4 maps and mobile NPCs work.

Every map in FF4 that isn't an overworld map has a byte of layer information for each tile of the map. This layer info helps the game know which tiles you can walk on and when. To help visualize this, here's a picture of the save room in the Antlion's Den:

 

And here's an ASCII representation of the movement layers of that map:

                                 
   ###                           
  #,,,T#                         
 T,,__,_#                        
 #,,##_#                         
 #,##._.#                        
 #,.....T                        
  #.#.#.#                        
  #..S..#                        
  #.#.#.#                        
  #.....#                        
   ##.##                         
     +                           
                                 

• Pound signs (#) are layer 0 - obstacles. These are never passable under any circumstances. The capital Ts are actually layer 0 as well, but I've marked them differently because they contain treasures.
• Periods (.) and commas (,) are layers 1 and 2 respectively. Both can be walked on, but you can't step directly from layer 1 to layer 2 and vise versa. To get between them, you need to step onto layer 3, which is represented here by underscores (_). Layer 3 acts as a connecting layer - you can always step on and off of it.
• Save points (S) are layer 11, but they are essentially always accessible.
• Layers 17 and 19 represent transition squares - if you step onto one of these, you'll end up on a different map. I've chosen to mark these with plus signs (+) and greater than signs (>) respectively. Layer 17 is only accessible from layer 1. Layer 19 can be reached from anything.
• There's one other layer, layer 5, that acts as a bridge layer. You can always step on a bridge layer from layer 1 or 2, but when you leave the bridge you have to step off onto the same layer you entered on. This allows bridges that can be walked over or under, with different rules for where you can walk for each.

So that's how the movement rules work.  Except that that's only how they work for the player, which is where our movement bug comes in.

When the borg chooses a path to a destination and starts moving down it, at every step it checks for NPCs in the way. If someone's in the way, it checks to see if the NPC would get pinned in the players path if we took the next step. If so, it politely waits until the NPC moves out of the way before moving forward. Without this politeness, all too often the borg would get itself into situations like this:

Our destination is the square the NPC is standing on, they have no way to get out of the way, and the borg doesn't know how to solve the situation. The borg eventually gives up and panics.

The problem the borg ran into in this last run is that NPCs don't have the same movement rules as the player does. NPCs are restricted to either layer 1 or layer 2; they can't transition to any layer other than the one they started on, including layer 3. So when you have a map like the top floor of Summonville, whose movement layers look like this:

             ########                  
        #####........#                 
       #.......#####.##                
      T........#   #...#               
    ##..######>#   #...##              
   #...#     #.#######...#             
  #....#     #.......#...#             
  #...#       ######.###..##           
   #.#              T  #....#    
   #_#                 #....#    
   #.T####              ##.#           
   #......#####          #_#           
    #..........#     ####T.#           
    #..........#    #......#           
     ###....>..#   ##......#           
        #......####>#......#           
         ##.####....##.####            
          #_####....##_#               
          #.............#              
           ###.........#               
             #........#                
              ####T###              

...there's a few opportunities scattered about for the borg to pin an NPC in a place that it believes the NPC can escape.

Solution: The borg method that looks for a way for an NPC to escape the player's path, pathToAvoidPlayer(), now starts with all layer 3 tiles on the current map blacklisted. This gets us 99% of the truth for NPC mobility, and should help us avoid any more pinned NPCs.