Comments/Ratings for a Single Item

OK, those look pretty good! :) I'm still working on having all the decks set, but I think this format will work.

(I also have a fixed version of the Bodyguard, though I'll wait to upload it until I'm sure there's nothing else to fix.)

I actually would prefer the ID on the right side, but that's minor.

I moved the ID to the lower right, because it felt like it was competing for attention with the name at the top, and on the right side, thanks to the text being left justified, there is more distance from other text.

While Fira Sans looks good for the name at the top, it didn't look as good for the ID. I'm looking into using something simpler, maybe more suggestive of computers, since the ID will be used by the code. For now, I have set it to Lexend. This is a geometric sans serif that almost looks like a clone of Futura, but it distinguishes all its characters from each other. For example, it puts bars on the capital I instead of letting it look like a lowercase l. Data Control looks like it could be a good option, but I haven't uploaded it yet.

Personally, when it comes to computer-related appearances, I've generally been fond of OCR-style fonts like F2 Tecnocratica.

Personally, when it comes to computer-related appearances, I've generally been fond of OCR-style fonts like F2 Tecnocratica.

I decided against Data Control, because it uses uppercase letters for lowercase letters. Based on your comment, I checked out OCRA, which I already had installed. On the plus side, it looks a lot like Data Control and has lowercase letters distinct from uppercase, but it doesn't include the caret you used in some IDs. F2 Tecnocratica has a Free for Personal Use license, but I prefer to stick to fonts that are either Free or Public Domain, as use on this site might go beyond personal use. So, I'll keep looking.

I checked out OCRA, which I already had installed. On the plus side, it looks a lot like Data Control and has lowercase letters distinct from uppercase, but it doesn't include the caret you used in some IDs.

I updated OCRA with a more complete version that does include the caret. So, I think we can go with OCRA for the ID.

I updated OCRA with a more complete version that does include the caret. So, I think we can go with OCRA for the ID.

Sounds great!

It's hard to find punctuation that doesn't throw off the interpreter, when I have a frequently-used modifier. I had been using a Plus for the Enhanced Pawn, but that turned into a space so I changed it to E. I think the tilde (~), apostrophe ('), and accent (`) are probably available, and I'm sure the period and comma would be; I'm kind of afraid to try to quote ("), though it'd be perfect for Berolina.

But at the very least, I do have the caret for Mecklenbeck.

I do recommend against using punctuation in IDs. Besides some of them being used in URLs, some are used as operators or punctuation in GAME Code. Also, their use will not be as intuitively obvious as letters. For example, I had no idea what the caret meant.

I think the tilde (~), apostrophe ('), and accent (`) are probably available, and I'm sure the period and comma would be; I'm kind of afraid to try to quote ("), though it'd be perfect for Berolina.

The apostrophe is also a single quotation mark, and in that capacity, it should be considered unavailable, along with the double quotation mark. Both are used to demarcate strings in both GAME Code and PHP. The period is used in GAME Code to separate array elements from parent arrays in array element variable names.

I hope the periods in the text portions won't become an issue.

Should I replace the carats with the letter M, do you think?

Should I replace the carats with the letter M, do you think?

Well, the name Mecklenbeck doesn't mean anything at all to me. If you're going to call various Pawns Mecklenbeck Pawns, you should explain what this means. I suppose you're trying to match the cards up with your piece notation. This would limit you to one case. As long as this is what you're trying to do, I recommend using Betza code or acronyms, depending on which is more appropriate for a piece, then disambiguating conflicts with short abbreviations or numbers. For some compounds, you might want to use the letters of the pieces compounded, such as RN and BN for the Chancellor and Archbishop. If a piece appears in a compound, the single letter acronym can be reserved for that piece or for the one most used in compounds, preferably in accordance with Betza code.

If you don't care about matching IDs with piece notation, you could use mixed case IDs to distinguish acronyms from abbreviations, or, since you're not placing values on the cards, you could even just use numbers, as the only use of the ID is as a handle for letting a player handle a card.

I'd been going on the assumption that the ID on the card would be the same as the Gamecode ID, limiting me to capital letters (which would become lower-case for Black), digits, and a handful of punctuation. If that's not actually the case, and lower-case letters can be used as distinct from upper-case, then that opens up many other possibilities.

I'd been going on the assumption that the ID on the card would be the same as the Gamecode ID, limiting me to capital letters (which would become lower-case for Black), digits, and a handful of punctuation. If that's not actually the case, and lower-case letters can be used as distinct from upper-case, then that opens up many other possibilities.

I was rather unclear here (my fault); there was meant to an implied question. Can/should I treat the ID on the card as something different from the GAME code ID?

Oh, and Mecklenbeck is from Mecklenbeck Chess, where Pawns promote early. Mecklenbeck versions of Pawns promote when they reach the opponent's pawn row, rather than the back row.

Can/should I treat the ID on the card as something different from the GAME code ID?

Piece labels and card IDs are in two separate namespaces. So, they don't have to coincide. However, it is sometimes practical to use the same names in two different namespaces. For example, I used to use function and subroutine names that matched piece labels, because this let me more quickly call the right function or subroutine without using a bunch of if-then statements. Since the cards in your game match only pieces, and each piece is going to require a unique notation, it does make sense to let them match up.

Since piece notation should be lowercase for one side and uppercase for the other, this restricts you from using mixed case piece notation. But since your cards do not represent pieces on one side or the other, you could still use mixed case IDs that otherwise match the piece notation but add some clarification on whether neighboring letters mean two different things or mean one thing together. For example, you might use C for the Camel, Cn for the Cannon, and CNZ (Camel+Knight+Zebra) for the Buffalo.

I recommend starting by coming up with a piece notation that makes sense and isn't too cryptic or confusing, then decide whether you want to use it for the IDs on your cards.

Since piece notation should be lowercase for one side and uppercase for the other, this restricts you from using mixed case piece notation. But since your cards do not represent pieces on one side or the other, you could still use mixed case IDs that otherwise match the piece notation but add some clarification on whether neighboring letters mean two different things or mean one thing together. For example, you might use C for the Camel, Cn for the Cannon, and CNZ (Camel+Knight+Zebra) for the Buffalo.

I hadn't considered that any given piece would have only one in the game (at a time), which does open things up a little. I couldn't have a CN and a Cn, but I could do what you describe, which could be helpful.

OK, that gives me a couple of ideas.

Part of what I think I'll do here is include a couple of paragraphs at the top of the GC rules section for this, explaining how to interpret the card ID codes. Things like:

• Variants on a piece have the base piece symbol first, then any modifying adjectives. For example, the standard Pawn is P; the Mongolian Pawn is PM; the Berolina Pawn is PB; the Mongolian Berolina Pawn is PMB.
• Pawns with a caret (^) at the end of their ID are Mecklenbeck Pawns; that is, instead of promoting at the back row, they promote at the opponent's Pawn row. That would make the Mecklenbeck Mongolian Berolina Pawn PMB^.
• Letters appearing in lower-case on the cards can be considered extensions of the preceding capital. For example, [Insert example here.]

That sort of thing.

I've just expanded the Spears expansion, so now there are enough to fill a row on each side for boards up to 12x12.

@Fergus: I want to add one more Pieces expansion before trying to dive into the GAME code.

Edit: Right now, the planned membership for this expansion is Abbess, Barc, Dragon Horse, Dragon King, Grasshopper, Harvester, Hawk, Heroine, Reaper, Roc, Rose, Sissa, Teutonic Knight, Turtle, War Machine, and Withdrawer. It's supposed to be the most familiar pieces that haven't been put in yet (in the main deck, or the three current expansions). I'm very open to suggestions along the lines of "take out X, and replace it with Y."

Addendum: I've also adjusted the dealing rules to improve the likely balance of the dealt-out pieces, as well as better integrate Spears if they're being used.

I think the Usual Equipment categories don't belong here?

Since Winning Conditions is the only thing that still matches up, I left that but deleted Capturing (since there are bound to be locust, rifle, approach, withdrawal, sting, and other types of captures in the game besides displacement and en passant).

But the first requirement for these categories is "can be played with a standard chess set", which isn't true?

But the first requirement for these categories is "can be played with a standard chess set", which isn't true?

I have now changed this. Since most of the Usual-* categories could be useful for other games if not for the Usual Equipment requirement, and since we only really need one category for Usual Equipment, I added a new UsualEquipment category, then I added it to any Item with a Usual-* category that was a 2D game on an 8x8 board but was not in the Small or Large categories. After doing that, I created new versions of the Usual-* categories with the Diff- prefix instead of Usual-, changed them all in the database, and updated some scripts that modify categories. I think I need to modify queryinc.php next.

I have now changed this. Since most of the Usual-* categories could be useful for other games if not for the Usual Equipment requirement, and since we only really need one category for Usual Equipment, I added a new UsualEquipment category, then I added it to any Item with a Usual-* category that was a 2D game on an 8x8 board but was not in the Small or Large categories. After doing that, I created new versions of the Usual-* categories with the Diff- prefix instead of Usual-, changed them all in the database, and updated some scripts that modify categories. I think I need to modify queryinc.php next.

Now I'm a little confused. Does this mean that I should leave "Winning Conditions" in place? Re-reading the instructions on the Edit Index Information page tells me that Ben's correct, and I've misinterpreted it until now.

That aside, is there anything left keeping this from being published?

I tried to publish this, but got

Modify Item
SQLSTATE[01000]: Warning: 1265 Data truncated for column 'Categories' at row 1

presumably something to do with the category changes?

The author, Bob Greenwade, has updated this page.

I've now unchecked all of the boxes under "Usual Equipment." That might help.