"Unique piece" check box?

[Stiglr]

Would it be possible to be able to have a check box in a piece's Properties (or a selectable attribute) that makes the piece unique, e.g., not cloneable, but only removable by "returning" the piece to a palette or some other holding area other than the board?

Haven't really thought through the design ramifications, but have suffered the indignity of goofing up a preset scenario and placed multiple instances of a counter or two...

[uckelman]

Thus spake Stiglr via messages:
> Would it be possible to be able to have a check box in a piece's
> Properties (or a selectable attribute) that makes the piece unique,
> e.g., not cloneable, but only removable by "returning" the piece to a
> palette or some other holding area other than the board?

There's already a way to do this: Don't include Clone or Delete and put
a piece in an At Start Stack.

--
J.

[Stiglr]

Forgive me if I don't understand that logic, but what if the piece isn't in play, ever, at the start of a game? What if it's a reinforcement, and you don't wish to populate a large Order of Battle as set-up?

Just seems to me a simple check box would be simpler. Also, not having a Delete function can have other unsavory effects: such as making an error during a Pre-Defined setup or during module creation and having a few pesky counters sitting around in perpetuity....

[Stiglr]

Put another way.... consider designing features based on how "most users think" rather than "how the code comes together" or "can be made to work". Functionality is often only as good as it is accessible.

[Rindis]

I agree with Stiglr that this would be nice (though defining a limit instead of 'one only' would be nice). F&E, for instance, generally lets you build any number of things, and there's dozens of choices. But there's a very few things that you can only build one or two of.

Using anything other than the piece pallet for the vast bulk of cases would be nonsensical. Then asking users to use some sort of at start stack for the the couple of exceptions just isn't going to work. Thankfully, in this case, the item inventory can help the users keep track of what's in use, so it's not a big deal. But it'd still be nice to have.

A thought is that it would be nice to be able to embed a 'deck' into the piece pallet. You set it up like a simple deck, but in the pallet instead of a map. This "deck" then acts like a normal piece pallet until it runs out of pieces. (I'd prefer some sort of faded image of the piece there at that point, but it should be left to the module designer to figure out.) I know that isn't simple, as it is a pretty massive change to how certain things work, and brings up some uncomfortable consequences, but from the end-user's perspective, it'd be the best solution to certain problems.

[Stiglr]

I suppose a "piece number limit" field would provide more flexibility for a designer.... but leaves open the specter of mistaken multiple pieces. Seems to me, if you're building a module for any printed game, pieces are either meant to be unique (unit counters) or are only limited by the # of examples provided in the counter mix (strength point markers, info chits, etc.).

@joel: About the advice, "Don't add a Clone feature to the piece or prototype". Once in a palette, one can drag any number of examples of a piece to the mapboard, with or without a clone feature built into it. Same potential for multiple examples would exist.

[Rindis]

I suppose a "piece number limit" field would provide more flexibility for a designer.... but leaves open the specter of mistaken multiple pieces. Seems to me, if you're building a module for any printed game, pieces are either meant to be unique (unit counters) or are only limited by the # of examples provided in the counter mix (strength point markers, info chits, etc.).

What mistake are you anticipating? The module designer sets up the piece, selects the 'restricted number' trait, and tells it how many there can be.

F&E is once again, somewhat different. As one example, the Federation can have three CVLs, so there's only three in the counter mix. But if one is destroyed, they can build a replacement ('fourth') CVL. Which is why the deck-like functionality occurred to me.

@joel: About the advice, "Don't add a Clone feature to the piece or prototype". Once in a palette, one can drag any number of examples of a piece to the mapboard, with or without a clone feature built into it. Same potential for multiple examples would exist.

As long as you can manage the 'at start stack' part of that advice, that's easy to manage: You can hide a palette, so that the end user never sees it, and cannot add extra pieces from it.

[Stiglr]

I think my point is, all of these other solutions are much more "complex" and involved than having a simple check box on the dialog for a piece that can be (un)checked at will. No need for stacks, decks, hidden objects or any of that rot. A simple box to check for all unique pieces, and the potential for unlimited examples for the others (presumably, informational markers, step loss chits, etc.)

The "mistake" I was referring to (and one I've made myself, to my chagrin, a time or two) is to inadvertently drag multiple examples of a unique piece onto the map when, for example, setting up a Saved Scenario file. If you're doing scenario setup by dragging units from scrollable lists among units that look similar (and if they're in a scrollable list, there's a good chance that they're organizationally related and thus do look alike), it's fairly easy to do. You forget to select a different unit while going down a list of 10, and drag two copies of "unit 6" into a stack. You never notice until you begin play and see, "hey, there's two of that unit in play!" Of course, by then, you've saved your scenario, published your module.... and it's time for errata....

Seems to me the instances where there will be unique pieces will far, far outstrip those cases where there is a limit <1 but >unlimited, to observe.