Add additional properties for how text displays on characters

[jdanish]

Ideally this includes:

• Placement (top, middle, bottom (default), left, right middle)
• Justification
• Color

TO DO

• [ ] Review half-implemented 6fdff46ee027441767d754368233e79a28ae5928? Does this work?

[jdanish]

Note Ben says: "If we're not careful it can really balloon and affect performance. " Agreed, though we also need the option to display things well. Long-term we may need to re-organize, but short term I wonder if it'd help to make a different character type? (e.g., a Text Feature) that would therefore limit how much info is sent to those characters?

[benloh]

Alignment

• top
• middle
• bottom
• left
• center
• right

Justification

• left
• center
• right

TextColor

[benloh]

@jdanish Can you tell me about 6fdff46ee027441767d754368233e79a28ae5928? Does this work?

[jdanish]

Yes @benloh - I hacked that in when we didn't know we'd have more $ and it works just fine for me. Of course I am sure you can do it better and integrate it with this feature more fully, but to my knowledge it works just fine. But I can't yet change location / placement or color.

[daveseah]

I made a cursory look at 6fdff46 to see what was going on, and am writing some technical notes for future design (this is not a code review):

VISUAL AGENT MODELING

• visual representation of agents has the base state (size, sprite), persistent effects (glows), semantic indicators (selection, part of group), triggered effects (burst of sparkles), sequence info (frame, animation sequence name), layers (consisting of all the above)...these all need to be conveyed somehow from the pure simulation agent object to the visual object.
• previously I hadn't considered labeling itself to be part of the need, but the ability to style text everywhere in a manner that's accessible without resorting to a lot of properties might be worthwhile. This affects templating too, so it may be useful to actually support HTML-style text definitions in templates so familiar <style> can be used...I'm assuming that a lot of grad students have some rudimentary understanding of HTML in 2023. We can use a HTML parser to handle the translation.
• simulation objects should be pure so the simulation can be portable. currently this is violated by many of the hacks that have been added to the system, but portability of the sim engine is now more of a long-term system goal.

As an aside: efficiency improves when the visual is encoded as one of the representational facets because each has an appropriate encoding strategy that could reduce data send frequency without compromising robustness. Currently everything is being sent every frame, which is a potential performance issue as packets get larger and larger. I had left it that way figuring we would optimize if the issue came up with performance.

We would definitely want to revisit this if we wanted to support "over the internet" as opposed to "LAN only" operation, and I think this would need to be budgeted as a V2 of the rendering system as opposed to an "improvement".

[jdanish]

This all sounds right. I'd also note that long-term, when we re-org, it'd be nice to rearchitect the features to work more like standalone plugins in the sense that all edits to a feature should be in the feature file, and not other places. That would make it much easier for us to have someone like me edit a feature without touching any other system which I think is ideal.