WonderRect

[PurgeandFire]

The RectList concept is cool, as well as the underlying concept of creating more unique shapes like triangles or polygons from rectangles

But IMO I think the modifiers and the way triangles are integrated (by subtracting vertices) is a bit counterintuitive/clunky. I feel like I'd need to go back to the reference documentation each time to make a triangle, and I wouldn't be super confident of getting the order right so I think it'd be a bit frustrating for the user. Not to mention the name, since once something is a triangle, it is no longer a Rect(angle). I think I'm also still having a hard time understanding why modifiers are needed.

If you want to support triangles, I'd personally make a separate class for a Triangle and a Rect--and then they can share some common function API (e.g. ContainsUnit). And maybe a polygon/N-gon class for making a shape out of multiple rects. Maybe it could be a "WonderShape" library. In my head that'd be a bit more intuitive. And maybe leaning a bit more on function-based APIs--less on naming and string-based APIs since those are a little harder to get intellisense assistance on.

 

[Antares]

The name suffixes are one way to modify the rects, the other is with the functions SetActiveEdges and ConvertToTriangle. I found it cumbersome to use those functions, so I added the string suffixes, but you can definitely just use the API functions instead. But I am actually a dingus and completely forgot to add a function list at the top of the library. I will fix that.

It is true that a triangle is no longer a rectangle, but the library is named after the native type and I can't rename that one .

What do you think is the most intuitive way to declare what orientation you want the triangle to have?

Creating different classes is not something I'm a fan of (not a fan of OOP/inheritance in general).

 

[PurgeandFire]

Oh sweet, thanks for adding the docs! That helps. And no worries about the lib name haha, I was just teasing.

As for the triangle concept, the most intuitive way for me personally is to just have a function that lets you create a triangle by providing an (x1, y1), (x2, y2), (x3, y3) set of coordinates. BUT after looking at the sample map I see now that you designed it that way so you can more easily make the shape you want via pre-placed regions. So I think it is great as you have it.

I might've gotten it confused with the edge flags syntax (FFFT), which I think I only sorta understood once I took a look at the sample map (it seems like you use it to determine how far "into" a region a unit is, to control the fog density). I think I understand it better now. For others who try to check out this system, it might be good to list some small examples of what you can do with your system (e.g. detecting when a unit enters a complexly shaped zone, controlling fog depending on how "deep" you are in the region) somewhere in the description just to help clarify why the features like the modifiers are useful. I think I also couldn't see innately what the "interactions" are (maybe that is an ALICE thing?).

But overall, after checking out the sample map I got a better idea of what you could do with it. Cool stuff!