Whaling Away At a Keyboard...

One of the biggest benefits to switching over to Aron Granberg's pathfinding is that the documentation is a lot better.  It's still really difficult to find WHERE the documentation is, but once it's there is basically tells you exactly what to do (with one noteable exception that probably added 2 hours to a debugging headache due to a poorly named attribute).

The first half of the week included adding erosion (the ability to have margins around corners, walls, and ledges), and detours (the ability to click patway along a path and only redraw the remaining bit of the path, and to merge a drawn path into an existing path, allowing you to make small adjustments instead of redrawing the entire path).  These changes make the design a lot more intuitive and forgiving to players.

A lot of time was wasted debugging issues with Vectrocity which were eventually chalked up to "a problem with the  library, nothing we can do".  When the player completes a path, the "work in progress" line will often remain visible underneath it, and since some additional smoothing is done on the finalized path this can be very noticeable.  This doesn't affect gameplay but is annoying.  It looks like the switch to Vectrocity 4 when unity 4.6 comes out will address this. 

Your paths will now automatically avoid your own towers now, which is certainly convenient.  The big holdup was a poorly named and documented attribute that was named and treated in a way that it appeared to be a certain type of variable, but was actually a completely different kind.  This was made worse by the fact that it was an int that primarily worked with numbers in a way that it would run into integer overflow issues.

Significant work was put into solving an edge case that comes up on slow machines, where the pathfinding requests that are discarded to to decaying do not drop their associated metadata from the queue, so if a request is dropped, the next one to be processed will use the previous one's metadata.  This was not very apparent in the design of the pathfinding, but the issue was simple to solve once it was discovered.

Due to some inconsistencies with map design and the sizing of the units, they still don't appear very intelligent and will bump into things and cut corners too close.  This probably won't be fixed until we hammer out some more details about the design of the map, but they are noted and being addressed,

Accomplishments

• Merging the path you a drawing with an existing path (2 hours)
• Making it so if you stop editing a path near part of the existing path, it will "autocorrect" to math the remainder of that path. (2 hours)
• Implementing erosion and margins around ledges (1 hour)
• Paths now won't go through your own towers (2.5 hours)
• Making sure the "path metadata" queue and the pathfinding request queue can't fall out of sync (2 hours)
• Bug fixes and optimizations (3 hours)
• Assorted art direction and design work (1.5 hours)

Not-so-much Accomplishments

• Trying to fix the error involving the work in progress  paths not disappearing when a path is completed.  Determined it is an internal Vectrocity error  (1.5 hour)
• Discussing how territory control will work and enumerating all the options (1 hour)
• Discussing map design and unit sizing (.5 hours)
• Tweaking with different map types and trying to find an ideal grid layout, ended up realizing it will involve changing the map design and unit sizing (2 hours) 

Next Steps

• The next priority is to handle units walking along blocked paths, followed by more work on how exactly to handle invalid paths (which is tricky since the team is still conflicted).

Ryan Daugherty