If you were to look at a random polygon-using Sierra game's decompilation, you'd see something like this.
(method (init)
(gRoom addObstacle:
((Polygon new:)
type: 2
init: 150 108 114 115 ...... 187 80 191 102
yourself:)
)
)
(super init:)
...
)That's quite unlike what a Companion game would have.
; from (include 200.shp)
(local
[P_Default200 29] = [1 PBarredAccess 13 150 108 114 115 ...... 187 80 191 102]
)
(method (init)
(AddPolygonsToRoom @P_Default200)
(super init:)
...
)Especially when you consider that the resulting bytecode is nothing alike, and the raw polygon data remains in the heap throughout the room's lifetime as locals. And you get a limit on how many points you can have under a single name.
In that light, I've been sitting on an idea that I implemented this morning, inspired by Phil's
foreach keyword and my own "make it iterate through a Collection" hack.
I made a getpoly keyword.Giving each individual polygon a distinct name because reasons, you can now remove the
include line, add a
(use Polygon), and do this:
(method (init)
(gRoom addObstacle: (getpoly {Beach}) (getPoly {Path}) ...)
(super init:)
...
)When compiled, each
getpoly will expand into a
((Polygon new:) type: X init: ... yourself:) statement matching the .shp file. Convert all rooms and you can throw away those helper functions entirely.
This feature is available
now on
Github.
Edit:
(getpoly {}) is now acceptable and will grab the "Default" poly. The internal thing that the polygon editor uses doesn't expose that with a name, hence the empty text box in the editor. This also allows the
New Room dialog to generate something with minimal fuss.
