Wasn't there also something about the winding order?
It did mention that the patent implied winding order had to be a specific way, but that games supplied polygons with either winding order, and so Sierra's engine handled it anyway (it's trivial to automatically change the winding order if it's the wrong way - SCI Companion does this when it saves the polygons, although I guess it doesn't need to).
The restriction that polygons couldn't intersect is interesting. "SCI Quest" uses some overlapping polygons in spots, I wonder if that's why the pathfinding seemed a little wonky (if I recall correctly).
For Cascade Quest's engine, in which I just implemented pathfinding, I use the
clipper library to subtract barred polygons from contained access. That gives me a set of non-intersecting polygons indicating where the ego can go. Then it's just A* over the concave points in those polygons. It mostly works, but I still have some problems with rounding errors, which that paper talks about too.
The restriction on overlapping polygons probably explains why Sierra didn't auto-create barred polygons for props that block Actors from passing through them. The Door class (in some games) has code for creating polygons from its bounding rect, but Views/Props don't. Then places where they need to block the ego, it looks like they "manually" assign them polygons, which probably means they could craft them carefully so that they don't intersect.
