Here are some features I tried and couldn't get to work, along with why they won't work (this list may get longer as I develop Dicier more):

'BLANK'-sided dominoes

I wanted to include dominoes that could have 'BLANK' on either or both sides of the underscore, just like the 'ANY' and double-'ANY' wildcards. This would include blank-wildcard combinations in all possible styles. For pipped dominoes, the BLANK side would look like the 0 side. For numeral dominoes, the blank side would be actually blank (no 0 in Arabic numerals or N in Roman numerals). This meant that firstly, you could actually call the blank domino sides "blank", and secondly, you could have actually blank faces when using the Arabic/Roman numerals.

What was the problem? The blank-number dominoes were fine, but the double-blank and blank-wildcard dominoes have codes that are 11 and 9 characters long respectively (BLANK_BLANK and BLANK_ANY/ANY_BLANK), which is too long for Affinity Publisher to export in pdfs (unless I'm missing a setting somewhere).

UPDATE: This is actually fixed now (kind of), as of v1.1! Character variant 14 replaces zero numerals (Arabic: 0, Roman: N) with blank die faces/domino sides. Not quite the same, but close enough.

Card value custom fonts

I had ligatures/codes (in fact, they're still in the font files, just inactive) that'd let you use any font for card values. The ace and face codes worked like this: 'CE', 'CE_', 'ACK', 'ACK_' and so on. Basically these produced zero-width invisible icons. You'd be able to write out e.g. 'QUEEN', set the Q to be whatever decorative font you wanted, and set the 'UEEN' to be in Dicier and it'd basically disappear (but the underlying text would still read 'QUEEN'). The underscore versions of these invisible icons would let you use them in combination with card suits, and I had a similar plan for number-suit combinations.

What was the problem? The zero-width, invisible icons didn't export in pdfs (at least, from Affinity Publisher). From what I can tell, it's because they don't have any visible information, and .pdf only cares about visible things. The codes work fine in the actual .afpub file, and would probably work fine in .html/.epub, but not in the most common format people use to digitally share games!

UPDATE: The ligatures are no longer in the fonts. They'll probably be added to Dicier v...2, though.

Perfect language variants

This one's a bit more technical than the other issues.

Basically, the way Dicier handles translations as of v1.1 is that every code in every language goes into one big list. This works fine if and only if no languages use the same word for different things. If any languages do, then there's a problem: which one takes priority? There's no fair solution to this beyond seeing if either language can use a different word for that icon. The other method I tried was to basically make separate lists for each language using OpenType's script and language controls, so if your app/computer's language was English then you'd use the English codes, if it was French you'd use the French codes, etc. and even if two languages used the same word for different things the words would be on separate lists. The third option, which I really don't want to take, is to have separate fonts for different languages (or groups of non-overlapping languages).

What was the problem? I could only get the OpenType solution to reliably work in apps that seriously deal with OpenType features (e.g. layout apps like Affinity Publisher, not things like MS Word). At the moment I'm trying to keep Dicier as technically accessible as possible, which means making it work on more apps (including cheap, ubiquitous, and free software).