Random thoughts on the model for Twisted Frontier

Segments need to be able to tell whether their 'next' angle is concave or convex, in order to handle triangle division. I figure the triangles would be done via 'phantom segments', the need for which scales linearly with the number of edges, which is something, at least.

To determine whether a techpoint has been reached, iterate over all unreached techpoints, to find the closest segment. From there, it's relatively simple to work out whether the techpoint is inside or outside the boundary. The calculations are much the same as the angle calculations alluded to above. The easiest way to conceptualize checking points is to iterate around each boundary and take the lowest distance. I'm worried because all of these calculations basically scale linearly with the number of segments involved, which scales however it damn well pleases, which isn't reassuring. Anyway, there are some assumptions we can make: the 'blob', in general, is a single boundary, which may contain inverted boundaries within itself. These boundaries will never contain any more boundaries, so the only issue surrounding them is their creation.

Actually, that serves the same function as any hypothetical triangle code, so I may just use that idea instead, since I sort of understand it better.

However, all of this vector algebra stuff is kind of geometry-agnostic. I wonder if there are any efficiencies that can be derived from a more geometrical basis of calculation.

A change in plans

I've decided that the Tech Landscape project needs a game to live in. Its working title, in the venerable tradition, recently established, of making a game name by colliding an adjective and a noun at high speeds, will be Twisted Frontier.

At the moment, this means very little in terms of development. The most significant aspect of this idea is that, once I get the project into a respectable form, the landscape code will live under a "twistedfrontier" directory. I mean, until we think of a name that isn't just silly.