Updated to optimise Initialisation phase; initial piece count now uses an Attachment too.
Posting this as a demo so the devs can see an example of how I’ve interpreted the Attachment feature and how some of the tweaks to it are proving useful. Also, to prompt advice if I’m not using the feature optimally.
Requirement:
The game board has three sections. A particular card provides the choice to “order” Infantry units in one of the three sections, or one other type of piece if no Infantry units exist.
I wish to provide ability to choose the section when that card is selected for play, and to automatically order units. Also, if there are no Infantry, then the card is simply to be played. The screenshot shows the card (“Force March”) has been selected for play in the British player’s hand. A widget representing the sections of the board has just been created (Place Marker trait). The involvement of Attachment and related traits is described below.
Initialisation
On creation, the widget counts the British infantry in the playing area, using this Attachment trait:
If the AttachCount for this is zero, the widget exits after playing the card.
Next, the widget sets up an Attachment for each section of the board, sub-dividing the original Attachment. Pieces in a boundary (split) hex will be in each section that shares it. These counts are displayed in the widget.
Example of a “section” Attachment trait (key portion):
Usage
When a section is selected on the widget, a GKC to that section’s attachment will “order” (mark moved) the relevant infantry units and the card is played.
Example GKC:
I have several other different use cases in my current C&C Napoleonics module development project, mainly in a “Combat Assist” feature which requires extensive coordination of pieces. On the whole, I am making most use of 1-1 attachments, where one piece needs to access properties on the other piece. I also have a many-1 and 1-many use case (many being usually 2 at most but the module doesn’t limit this). I have not so far needed to access properties using the Indexing (Attachment Property trait). So far, simply attachmentName_Property and attachmentName_attachmentName_Property have served well enough for the requirements. Yes, accessing the property nested a second level down works. I haven’t had to go deeper than that, but 2 levels have proved useful.
One last observation, the Attachment trait allows integrated functionality to be implemented in a much lower vsav/vlog (and I assume, memory) footprint because you can put complex logic into transient pieces that are created only when needed, yet still have full, easy access to piece data, completely transparent to the piece itself.