Carcassonne Central

Carc Central Community => General => Topic started by: DIN0 on July 27, 2019, 05:04:34 PM

Title: Carcassonne game notation system for tournament play
Post by: DIN0 on July 27, 2019, 05:04:34 PM
Recently a purchase of the first Carcassonne map (Germany), revisiting of wind rose expansion and a rather bizzare conversation with a fellow Carcassonne player about clasification of game components,  has spurred an idea in my mind. I know that chess, along with many abstracts and other games that are being played at tournament level, have a notation system to keep track of and document the progress of the game. So I wondered if something similar was possible in Carcassonne. It would have to be relatively simple when compared to other games with notation, but at the same time thorough enough so that each game could be replayed accurately.

This proposed notation system is intended for use in  1 vs 1  base game tournament play of Carcassonne:


The consolidated tile reference was an immidiate go to, when deciding on how to refer to individual tiles. Only two small additions are needed. Firstly to differentiate between redundant tile references, that being ccff and cfcf. Both come in two variations: Splitters and Joiners. Thhus they can be referenced as ccff-J vs ccff-S and cfcf-J vs cfcf-S respectively. Secondly, the presence of a pennant can be marked by simple + symbol such as cccf vs cccf+.The fact that in  consolidated tile reference, one of the four tile sides is alphabeticaly designated as a starting point of further description (a striking resemblence to alicyclic hydrocarbons nomenclature btw >:D) is also useful, because this side can serve as a descriptor of tile orientation.

In tournament play there are two players: A (starter) and B (opponent), so notation of player's turn should begin with A:  or  B:

Next we need to determine placement of the tile, its orientation and identity. For this I was inspired by Carcassonne map, to create a simple abstract grid with x and y coordinates in square brackets: [x;y]. This grid is determined by starting tile (crfr), with x-axis running from west to east, and y-axis running from south to north, from player A (starter's) perspective. So position of starting tile would be [0;0], a tile placed to the immidiate north of the starting tile [0;+1], to the west [-1;0], etc.
An example in the first attachment - red dot marks the recently placed tile. That tile was placed at that position by player B (white) B:[-1;+2].
For marking the orientation we can determine four cardinal points North, East, South, West (windrose inspiration) with north always pointing from player A (starter) to player B (opponent).
Orientation of the tile side that is first in consolidated tile reference is marked with a descriptor. For example: The starting tile is in orientation [0;0]N:crfr which means the city segment is facing north. Player A draws the very first tile and it is the cfff tile. He/She places it and completes a 4 point city. That move would be marked as: A:[0;+1]S:cfff. Likewise in attachment 2, the tile placed  would be marked as: A:[+2;+2]E:ffrr. In case of bilaterally or radially simetrical tiles either side can be used to mark orientation, but perhaps North and West should be defaults for the sake of consistency.
Another thing that  needs to be adressed is meeple placement. If it was placed then notation of tile placement and orientation should be followed
 by > symbol and then combination of meeple type and orientation of its fature. Knight, Robber, Monk, Farmer. Knowing the meeple type automatically provides information about the type of feature it occupies. This is done in this way purely to avoid confusion due to Cloisters and Cities having the same first letter. Orientation descriptor goes before meeple type and marks on which tile side the feature segment is. Example: again first tile drawn is cfff and player A places a meeple in the completed city: A:[0,+1]S:cfff>S:Ksometimes combinations of cardinal directions will be needed such as farmers on rrrr tile: NE:F.
Finaly, any scoring of points is marked with =+n with additional +n for every scored feature. Also, every +n must be followed by the player who scored it. To finish the small city example, complete notation would be: A:[0,+1]S:cfff>S:K=+4A
Following the established rules, I was able to make a notation of a certain game from world finals. Here is an  excerpt from the beginning:
[0;0]S:crfr
A:[0;-1]N:cfrr>N:K=+4A
B:[0;+1]N:cfff>NW:K
A:[-1;+1]W:ffrr>NW:F
B:[0;+2]E:ccff-J+
A:[-1;-2]W:crfr>W:K
B:[-1;0]N:frfr>W:R
A:[-2;-2]W:cfcf-J
B:[+1;+2]W:cfcf-S>E:K=+8B
A:[0;-2]W:frfr>N:R
B:[-2;-1]N:ffff>N:M


When making this notation I came along  a need for a minor adjustment.One cannot tell the placment of farmer on ccrr tile because both field segments can have only the exact same descriptions. In this specific case I would suggest instead of using cardinal directions, write following descriptors: cf: for city-field and rf: for road-field. For example: B:[-1;+4]E:ccrr+>cf:F

This topic is getting way too long  so I am goin to end it here. If anyone has any questions regarding this  notation system I am happy to answer. Also I would like to know what the community thinks about it and if anyone has ever tried something similar. I could also provide full notation of the said tournament final.
Title: Re: Carcassonne game notation system for tournament play
Post by: Meepledrone on July 30, 2019, 03:36:46 PM
Hi tp10053,

Great post.

As I was reading it I was making a comparison in my mind with the way JCloisterZone (JCZ) saves games. For those who don't know JCZ, it is a free Java implementation of Carcassonne created by farin and it allows you to play the basic game as well as many expansions. Check it out here: http://jcloisterzone.com/ (http://jcloisterzone.com/)

Supporting more than 2 players is no rocket science. In some countries there are 4-player games in some phases of the tournaments.

Beyond base game tournaments, I wanted to check with you if you were interested to extend your notation to support expansions as well.   

If so, I would like to share with you some ideas about how JCZ approaches some topics that might be of interest:
* Tile encoding including any special features
* Feature identification on a tile for placement
* Meeple / figure /token placement

I was preparing a long post about all this but I preferred to check first if you would be interested.

Cheers!
Title: Re: Carcassonne game notation system for tournament play
Post by: CarcFox on July 31, 2019, 08:28:15 AM
 One could just denote tiles starting from the "north" feature. So a crfr could be written as an rfrc or as a rcrf depending on how it's placed. It seems a bit more elegant imho and it's more coincise. It also doesn't require anybody to remember which feature is where in the official tile reference. Could it work or are there some problems that I'm overlooking?

Also, I would gladly offer my help to extend this notation to other expansions... It shouldn't be too hard to add Inn and Cathredals. Next to the string rapresenting the tile, c+ is a city with a cathedral, r+ is a road with an inn. The same system can be extended to indicate the placement of a big meep (K+, T+, M+, F+). Could it work?

Maybe I'll try to notate some other expansions later.
Title: Re: Carcassonne game notation system for tournament play
Post by: Meepledrone on July 31, 2019, 10:14:23 AM
Hi CarcFox,

Here the issue is what is the "north" feature. Each tile may have up to four version of their description depending on the rotation applied. So the idea would be to pick one and work from there separating coding from rotation when placed.

Regarding the c+ and r+ notation, it is a valid option. I understand that c+ccr+ would represent a tile cccr tile with a cathedral and an inn on its road, right? 
As for meeples, other pieces and tokens, we would need to extend the notation to represent all the cases.


As you also seem to be interested in extending the notation to other expansions, I'm including some info on how JCZ encodes tiles to open the discussion.

Recently a purchase of the first Carcassonne map (Germany), revisiting of wind rose expansion and a rather bizzare conversation with a fellow Carcassonne player about clasification of game components,  has spurred an idea in my mind. I know that chess, along with many abstracts and other games that are being played at tournament level, have a notation system to keep track of and document the progress of the game. So I wondered if something similar was possible in Carcassonne. It would have to be relatively simple when compared to other games with notation, but at the same time thorough enough so that each game could be replayed accurately.

This proposed notation system is intended for use in  1 vs 1  base game tournament play of Carcassonne:


The consolidated tile reference was an immidiate go to, when deciding on how to refer to individual tiles. Only two small additions are needed. Firstly to differentiate between redundant tile references, that being ccff and cfcf. Both come in two variations: Splitters and Joiners. Thhus they can be referenced as ccff-J vs ccff-S and cfcf-J vs cfcf-S respectively. Secondly, the presence of a pennant can be marked by simple + symbol such as cccf vs cccf+.The fact that in  consolidated tile reference, one of the four tile sides is alphabeticaly designated as a starting point of further description (a striking resemblence to alicyclic hydrocarbons nomenclature btw >:D) is also useful, because this side can serve as a descriptor of tile orientation.

The basic coding used JCZ is based on the same letters and symbols (C = city, R = road, F = field, + = pennant) but it uses a different coding for joiners and splitters based on the use of uppercase and lowercase letters to indicate connected sides.

For example ccrr-J would be coded by JCZ as CcRr where Cc represents two city sides connected and Rr represents to road sides connected.

JCZ also uses some type of shorthand with fields so tiles are rotated so field side would be enumerated at the end. Trailing field sides are omitted.

For example ccff-S would be coded by JCZ as CC (no trailing F.) As you can see both city segments are represented by uppercase C as they are not connected.

So revisiting your previous examples with JCZ coding we will have the following mappings:

ccff-J --> Cc
ccff-S --> CC (already mentioned above)
cfcf-J --> CFc
cfcf-S --> CFC
cccf --> Ccc
cccf+ --> Ccc+

Additionally, JCZ codifies monasteries by prepending letter L to the tile coding (remember that trailing field sides are omitted), so:
L represents a ffff tile with a monastery
LR represents a rfff tile with a monastery



Note on JCZ approach to generalizing tile description

So in both cases the basic game is perfectly covered, but what would be necessary to cover any expansions? The approach JCZ takes is to code tiles as follows:

E.X{Y}{.Z}

where:
* E is a 2-character acronym tho represents the base game (BA) or any other expansion (TO = The Tower, R1 = River I,...)
     - The expansion identifier serves as an implicit feature identifier if present in all the tiles of a expansion
     - Examples:
          - Tiles with E = TO (The Tower) present a tower foundation
          - Tiles with E = FE (The Festival) present a festival symbol
          - Tiles with E = PL (The Plague) present a plague doctor symbol
* X is the coding of the tile as commented above. There are multiple letters used depending on the needs, for example:
     - Basic game: C/c = City, R/r = road, F = field, L (prefix) = monastery
     - Abbey & Mayor: A (Preffix) = Tile with abbey (no sides specified afterwards)
     - The Abbot: G (prefix)= Tile with garden
     - River I & II: I = River side (JCZ is not using lowercase i)
     - The Cult: S (preffix) = Tile with shrine
     - The Count: 1..12 = City of Carcassonne tiles are identified by their position number from 1 to 12 (special case)
     - German Monasteries: Name = German monasteries are identified by the monastery name (special case)
* Y is an identifier to qualify the tile with some extra features present in cities or fields, for example:
     - Base game: + = pennant
     - River II / CG#11: + = pig-herd
     - Abbey & Mayor: ++ = double pennant
     - Several expansions: ! = layout variation, normally associated to city peaks touching an opposite vertex of the tile
           - Example: C! = city segment with a pointy hat
     - Several expansions: !+ = combination of ! and +
* .Z is an additional identifier for additional features on tiles, for example:
     - Inns & Cathedrals: .i = inn, .c = cathedral
     - Traders & Builders: .c = cloth, .g = grain, .w = wine
     - The Princess & the Dragon: .p = princess, .v = volcano, .d = dragon, .g = magic portal
     - Bridges, Castles & Bazaars: .b = bazaar, .bi = bazaar + inn
     - Hills & Sheep: .v = vineyard, .h = hill
     - River I & River II: .s = source, .e = end, .v = volcano, .i = inn
     - Flying Machines: .o/.d/.NS.o/.WE.o/.NW.o/.SW.o = road orientation + arrow direction ( o = to the left, d = top left diagonal )
     - Several expansions: .1, .2,... = tags for extra configurations
     - Several expansions: .X = road crossing with a bridge

So, for example, the following case of a base game tile is coded as follows.

ccff-J --> BA.Cc

This coding is not 100% unique for some tiles or there may be variations due to rotations. For example CCcc+ can represent the following tiles, so the expansion prefix is one way to tell them apart:

* AM.CCcc+:

(https://github.com/farin/JCloisterZone/blob/master/src/main/resources/plugins/classic/tiles/AM/CCcc+.jpg?raw=true)

* TO.CCcc+ (or TO.CccC+):

(https://github.com/farin/JCloisterZone/blob/master/src/main/resources/plugins/classic/tiles/TO/CccC+.jpg?raw=true)

But in general terms, the coding system is flexible enough to cover all cases and provides, if necessary, tools to clarify any ambiguities when necessary.



Hope there is enough material here for an initial discussion.

Cheers!


EDIT: Added line for Hills & Sheep
Title: Re: Carcassonne game notation system for tournament play
Post by: CarcFox on July 31, 2019, 01:05:07 PM
I find the system JCloisterZone uses to notate tiles very effective. And props to you for explaining it here   :(y) We now need to notate the placement of special meeples in some expansions and more generally all the “moving the wood” phase.

Traders and Builders seems like also pretty doable using the .w, .g and .g symbols jcloisterzones uses. Putting them in the middle of the string (e.g. cc.wrf, i don’t know if that tile actually exists but I hope you kinda get the idea) would ensure maximum accuracy tho.

Regarding the special figures: T* could indicate the placement of a builder on a road, K* on a city and maybe F* the pig.

Probably the River (I and II) are also quite easy to notate. The Princess and the Dragon seems quite a mess, especially considering the movements of the dragon. But it’s definitely doable.

 The hardest expansion to notate consistently is by far “The Plague” since it would require almost certainly a second and a third  coordinate system to indicate how the plague spreads and which plague tiles are moved to expand that region. And a third one for meeple escaping the plague. Maybe we should standardize all of those “movements” (Flying Machines, Magic Portals, the Dragon to an extent, the Plague, meeple escaping from the plague and meeple escaping from the Cathars...):

Figure.[x;y]->[w;z]

For example: PlagueChip[17;18]->[20;12] or Dragon[5;6]->[5;7]->[6;7] etc.

This was just a quick draft and notations indicating those things eliminating meeples are needed but I feel like it’s a good start.
Title: Re: Carcassonne game notation system for tournament play
Post by: DIN0 on July 31, 2019, 03:55:12 PM
Hello Meepledrone,

thank you for explaining JCZ tile coding, as I was unfamiliar with it. It is interesting indeed and I believe it is a very good way of recording games that include expansions. However I chose to focus on just the base game for its simplicity and the fact that I have recently been trying to collect game data more efficiently to do some statistics of tournament play. My aim was to provide a more detailed, faster and more intuitive system of game notation, one that would be manageable by a person, in real time, with a spreadsheet. Thanks to inclusion of just the base game, I could afford to be exhaustively descriptive without notation getting convoluted, therefore I have created this system with that mindset.

I still have a few questions about JCZ system:

how does it handle tile rotation?
does it use some kind of grid as well?
what about meeple placement?
Title: Re: Carcassonne game notation system for tournament play
Post by: Decar on August 01, 2019, 04:49:20 AM
The easiest thing to see what JCZ does is open a save file. It's an xml document that maintains gamestate at any moment.

Sorry don't have one to hand!
Title: Re: Carcassonne game notation system for tournament play
Post by: CarcFox on August 01, 2019, 05:29:52 AM
So, I opened a simple save file of JCloisterZone and I hope that I can answer tp10053's questions. The whole file is composed by lists in curly brackets, for example:

{"type":"PLACE_TILE","payload":{"tileId":"BA.Rr","rotation":"R270","position":[-2,0]}} ,or
{"type":"DEPLOY_MEEPLE","payload":{"pointer":{"position":[-2,0],"location":"NL.NR.EL.SR.WL.WR"},"meepleId":"0.small.2"}}

As you can see, it does infact handle rotation in a similar manner as tp10053 proposed in the original post, and it does have a coordinate system. You can see the full file at https://pastebin.com/bXPqB11b (it's quite short, I saved the game after a few moves).

To be honest this doesn't seem so usefull to create a system humans can use. I would stick to the original one that was proposed in this thread, perhaps expanding it to include expansions.
Title: Re: Carcassonne game notation system for tournament play
Post by: DIN0 on August 01, 2019, 11:23:04 AM
Thank you, CarcFox, for making this clear for me.
It does seem too complex and time-consuming for human use. As I already mentioned, I created my proposed system to be human-friendly and completely descriptive of the base game, without making it too complex. If I were to create an equally descriptive system that would encompass all the expansions, then perhaps some of the fundamental characteristics of the the original system would not be ideal. Then again maybe its not impossible.

Lets say we do use the original "special" notation system as a basis for a "general" notation (borrowing the naming of the two theories of relativity...).

Several basic questions need to be answered about the approach, so let me brainstorm for a moment:

In my opinion the biggest challange is accurate description of tile configuration without adding way too much complexity - ideally a set of rules that would enable us to describe any theoretical tile configuration (with as little exceptions as possible). Consolidated tile reference only describes the edges of the tiles and their connectivity with other tiles. It doesn't actually tell you anything about inner layou. In "special" notation, this is not a problem since there is only a limited number of configurations.

Secondly, I believe we need to make some sort of distinction between a type of follower - which I see as sort of a class or specialisation, and its deployment, which I see more as an occupation it serves on the board. Special figures can only be deployed as themselves.
Title: Re: Carcassonne game notation system for tournament play
Post by: DIN0 on August 01, 2019, 12:10:30 PM
Also here is the spreadsheet ready to print. You can write notation into it.
Title: Re: Carcassonne game notation system for tournament play
Post by: Meepledrone on August 01, 2019, 12:26:29 PM
Hi guys,

You both posted while I was preparing an reply to the pending questions...

So here you are some more information on JCZ to add more info to the discussion...


Hello Meepledrone,

thank you for explaining JCZ tile coding, as I was unfamiliar with it. It is interesting indeed and I believe it is a very good way of recording games that include expansions. However I chose to focus on just the base game for its simplicity and the fact that I have recently been trying to collect game data more efficiently to do some statistics of tournament play. My aim was to provide a more detailed, faster and more intuitive system of game notation, one that would be manageable by a person, in real time, with a spreadsheet. Thanks to inclusion of just the base game, I could afford to be exhaustively descriptive without notation getting convoluted, therefore I have created this system with that mindset.

Hi tp10053!

My pleasure. I just wanted to share with you what JCZ did just in case you wanted to another view to the same problem you solved. Of course added flexibility means additional verbosity. And your approach is perfectly fine to cover your objective.

I still have a few questions about JCZ system:

how does it handle tile rotation?
does it use some kind of grid as well?
what about meeple placement?


Let me address address your questions using the saved game excerpt from CarcFox's post:

{"type":"PLACE_TILE","payload":{"tileId":"BA.Rr","rotation":"R270","position":[-2,0]}} ,
{"type":"DEPLOY_MEEPLE","payload":{"pointer":{"position":[-2,0],"location":"NL.NR.EL.SR.WL.WR"},"meepleId":"0.small.2"}}


JCZ saved games are stored in JSON format. It is like a veborse chunk of Javascript describing a data structure describing, in this case, the actions of players during the game. The file does not indicate explicitly the player making each move, so you cannot tell from reading the file if player X is playing a double turn, for example. It doesn't either records the points scored by players. JCZ reads the saved game  file and rebuilds all the missing information tp10053 in including in his notation.

(I was saving this part for later...  :o)

So let's start with the questions:

1. does it use some kind of grid as well?

Yes, JCZ uses a similar coordinate system. The only difference is that the Y-axis grows downwards (to the south) so some coordinate examples here:

* Start tile:  [0;0]
* Tile to the immediate north: [0;-1]
* Tile to the immediate west: [-1;0]

So, in the example above the tile was placed in coordinate [-2;0], that is, to tiles west from the start tile.



2. how does it handle tile rotation?

Regarding tile rotation, JCZ uses a rotation-oriented notation expressing the angle in degrees instead of cardinal points. Here is the equivalence:
* N = R0 (the north side of the tile points north)
* E = R90 (the north side of the tile points east)
* S = R180 (the north side of the tile points south)
* W = R270 (the north side of the tile points west)

So getting back to the example above:

The JSON excerpt tells JCZ to place tile BA.Rr applying a rotation of 270 degrees.

JCZ stores the BA.Rr tile as ffrr (it is not normalized so the north side is a road) and the road connects sides S and W:

(https://github.com/farin/JCloisterZone/blob/master/src/main/resources/plugins/classic/tiles/BA/Rr.jpg?raw=true)

So after applying the R270 rotation the tile is placed with configuration frrf, so the road connects sides S and E.



3. what about meeple placement?

JCZ presents a key difference in the approach to meeple placement.

* In your case you designate the feature indirectly by the role of the meeple (K = knight --> city, R = robber  --> road, M = monk --> monastery, F = farmer --> field) and maybe add an indication to resolve ambiguities: a cardinal direction to select the feature if more than one is present on the tile.

* JCZ identifies the feature by the cardinal directions of its connections to the sides of the tile (once rotated and placed).
   - N, E, S, W or any combination of them, such as NE will indicate a road or city connecting those sides of the tile.
   - NL, NR, EL, ER, SL, SR, WL, WR (cardinal direction + left or right half as seen from the center of the tile outwards): are used to build sequences of the tile half-sides connected by a field.
   - Special identifiers in case the tile contains features with special treatments: CLOISTER (for monasteries, abbeys, shrines, German Monastery... as a monk), MONASTERY (German Monastery as an abbot), INNER_FARM (for cccc tiles with one field), INNER_FARM_A and INNER_FARM_B (for cccc tiles with two inner field, for example, the tile with two cities crossing thanks to a bridge),...

Getting back to the example above, the rotated tile to position frrf: will contain the following areas:
* A large field: NL.NR.EL.SR.WL.WR
* Road: SE
* A small field:ER.SL

As you can see, the meeple is placed on the large field. So the type of the meeple is inferred from the sides.

Additionally, JCZ encodes the type of meeple placed. In the example, we have 0.small.2, that indicates:
* "0": the player id: Player 1 (players are numbered starting form 0)
* "small": the figure type, in this case, a normal meeple
* "2": Internally JCZ keeps track of the number of the meeple placed (1 up to 7 for normal meeples). In this case the second normal meeple was the one placed.

Another interesting choice of JCZ is that provides coordinates for tiles and figures placed independently, so placing a figure and placing a tile can be dissociated as for example when using a magic portal.



Additionally JCZ files contain an number of messages (actions) that may happen during game, just a starting list so you may have an idea:

- PLACE_TILE: places a tile
- DEPLOY_MEEPLE: places a meeple or a special figure, e.g. a normal meeple, a wagon, a builder, a pig, a shepherd,...
- RETURN_MEEPLE: remove meeple from tile due to crop circle, festival, princess tile, siege escape
- MOVE_NEUTRAL_FIGURE: places or moves a neutral figure, e.g. the dragon , the fairy, the mage, the witch,...
- DEPLOY_FLIER: Deploy a flier
- PLACE_TOKEN: place a token such as a little building,
- CAPTURE_FOLLOWER: capture a follower with a tower
- PAY_RANSOM: pay for a captured meeple
- EXCHANGE_FOLLOWER: exchange followers
- CIRCLE_REMOVE_OR_DEPLOY: Crop circle action
- FLOCK_EXPAND_OR_SCORE: action to decide what action takes a shepherd
- BAZAAR_BID  / BAZAAR_BUY_OR_SELL: Bazaar related meesages



So what next?

Cheers!
Title: Re: Carcassonne game notation system for tournament play
Post by: CarcFox on August 02, 2019, 05:29:49 AM
In my opinion the biggest challange is accurate description of tile configuration without adding way too much complexity - ideally a set of rules that would enable us to describe any theoretical tile configuration (with as little exceptions as possible). Consolidated tile reference only describes the edges of the tiles and their connectivity with other tiles. It doesn't actually tell you anything about inner layou. In "special" notation, this is not a problem since there is only a limited number of configurations.

I thought of a good system to explain the tile configuration better and with less ambiguities: instead of marking with different capitalizations if a feature is connected or not, we could mark with different capitalizations (and eventually apostrophes) different cities/roads on the same tile. I was thinking of C,c,C',c' starting from the "north" side and proceeding clockwise (if that's needed, in most cases C and c are sufficient).  So the tile with two cities crossing each other would be a CcCc, a tile with four distincts road would be a RrR'r'. This could be refined but it's a massive improvement in clarity and consistency since to tell if a two feature are connected you just need to check if they have the same capitalization and apostrophe.

Note that this would eliminate the need to signal a rotation. For example a CCCR could be CCRC or a RCCC, depending on how the tile is placed, since every string starts from the north element (which varies depending on the rotation).

Plus, you could use this system to refine the placement of meeples too. Writing simply "K" could cause ambiguities in some cases, which are avoided by writing "KC" or "Kc".
Title: Re: Carcassonne game notation system for tournament play
Post by: DIN0 on August 03, 2019, 07:24:37 AM
I am preparing a longer post which should be out in the following days.
I am working on solving the generalized layout nomenclature only... no special features yet. I may have borrowed a few things...
Feel free to post any suggestions in the meantime.
Title: Re: Carcassonne game notation system for tournament play
Post by: Meepledrone on August 03, 2019, 08:21:35 AM
Hi tp10053,

This topic can lead to long dissertations. I experienced it myself trying to split my reply in several posts.  ;)

That was the idea behind sharing all this information so you could compare your approach with another point of view and borrow any ideas that would help you in your endeavor. If so, it was worth the effort and the long posts.  :(y)

Cheers!



Title: Re: Carcassonne game notation system for tournament play
Post by: DIN0 on August 03, 2019, 11:29:07 AM
Hi tp10053,

This topic can lead to long dissertations. I experienced it myself trying to split my reply in several posts.  ;)

That was the idea behind sharing all this information so you could compare your approach with another point of view and borrow any ideas that would help you in your endeavor. If so, it was worth the effort and the long posts.  :(y)

Cheers!
Hi, Meepledrone,

many thanks  to you for your detailed explanations! :(y)
Title: Re: Carcassonne game notation system for tournament play
Post by: DIN0 on August 03, 2019, 11:50:48 AM
So I  have decided to do the folowing... My original notation system is a good basis after all, however - what needs to be updated for this purpose is the consolidated tile reference (ctr. for short). Therefore I have created a document which will be in attachment of this post. In this document I have written down what I like to call "generalized tile reference" (gtr). It takes ctr and upgrades it, so that it contains internal information about the topography of the tile. So far I only bother my self with basic features ( cities, roads, fields aka. edge-making features).

Note that gtr is designed to describe any hypothetical tiles, I even include some in my examples.

I will discuss any suggestions in this thread and I will update the document in the attachment of this very post as to not waste much space in the thread itself.

I will also update "open questions" segment of this post as we work through them.

OPEN QUESTIONS:
How to describe city or field segments that share an edge? (hills and sheep) solution proposed
Can anyone suggest example tiles that might challange the proposed solutions?

Edit 3 - 9th august 2019
Title: Re: Carcassonne game notation system for tournament play
Post by: CarcFox on August 04, 2019, 03:40:09 AM
I came up with a system that fixes some of the problems and that in theory should work for all the “vanilla” tiles.

Basically it’s the one from my last post, with tp10053’s / and // symbols to note city-road junctions. Pennants are noted with a + after the city they affect (this fixes the problem with that strange A&M’s tile). Also, if a corner is touched by a city that hasn’t an edge of the two the corner is in (aka a “witch hat” city) or by an internal farm, this should also be noted by a C/c/c’/C’/F/f/F’/F (depending on which city/field is touching the corner) followed by an !. Corners are noted after noting the tile from the left of the corner. Cloisters are notated with an L prefix (since its exact position in the tile doesn’t matter (?)). Internal fields that do not touch corners (do they even exist?) can be notated with an (F) suffix. 

So, for example, the un-notable tile from P&D in the pdf would be a Cf!c+cC!f!F

It’s a bit cumbersome but keep in mind that many other tiles are way simpler. If you find a tile that still poses problems of course post it!
Title: Re: Carcassonne game notation system for tournament play
Post by: DIN0 on August 04, 2019, 07:20:06 AM
I came up with a system that fixes some of the problems and that in theory should work for all the “vanilla” tiles.

Basically it’s the one from my last post, with tp10053’s / and // symbols to note city-road junctions. Pennants are noted with a + after the city they affect (this fixes the problem with that strange A&M’s tile). Also, if a corner is touched by a city that hasn’t an edge of the two the corner is in (aka a “witch hat” city) or by an internal farm, this should also be noted by a C/c/c’/C’/F/f/F’/F (depending on which city/field is touching the corner) followed by an !. Corners are noted after noting the tile from the left of the corner. Cloisters are notated with an L prefix (since its exact position in the tile doesn’t matter (?)). Internal fields that do not touch corners (do they even exist?) can be notated with an (F) suffix. 

So, for example, the un-notable tile from P&D in the pdf would be a Cf!c+cC!f!F

It’s a bit cumbersome but keep in mind that many other tiles are way simpler. If you find a tile that still poses problems of course post it!
Hi CarcFox,
Yes, + symbols could be allocated to city segments instead of whole name, but I don't think a single tile should force us to do so. We could perhaps generalize it so that you should only allocate the pennant if its location is somehow unclear from the tile description (only one case)

Regarding the fields:
The fact that cccc tile consists of more than one city segment, let's say CCCc or CcCc, already tells you that there is in fact "something in between" something internal - which is by default a field. If there is something different, then it will be noted further in the tile name, but I don't do special features yet (I have an idea for the future though). The only instance when you could not tell, would be an internal field that does not touch any corners - which you mentioned. It does in fact exist, namely the Spiel'16 promo tile, but I was already thinking about putting SP16 somewhere on that one.

As for the city corners, what you suggest might work, but it is indeed way too cumbersome, so if you don't mind...
I came up with a simpler and intuitive way of noting this. Symbols are allocated after the segments they describe (reason why i think it is intuitive in italics):
C. touching in the middle of the opposite tile edge (one central dot - center of the edge)
C.. touching the corner closest in clockwise order (one dot right next to the other)
C:. touching corner further clockwise (added dot in clockwise order)
C:: touching in both corners (segment is effectivelly in all 4 corners)

I have updated the pdf document where I discuss this in more detail with examples.

Title: Re: Carcassonne game notation system for tournament play
Post by: CarcFox on August 04, 2019, 01:06:45 PM
I like this solution very much! The only thing that slightly bothers me is that to note a tile in which all the 4 cities on the edges are separted would require using a triple apostrophe (CC’C’’C’’’). Using the same capitalization (and not the change of it) to note connection would reduce this to a CcC’c’ . It’s only aesthetical but I like it better.

Another small nitpick: how would two distincts roads crossing on each other (with a mini-bridge) be distinguished from two roads crossing one underneath each other with a tunnel? Maybe tunnels would be considered some kind of special feature tho.
Title: Re: Carcassonne game notation system for tournament play
Post by: DIN0 on August 04, 2019, 02:11:48 PM
I like this solution very much! The only thing that slightly bothers me is that to note a tile in which all the 4 cities on the edges are separted would require using a triple apostrophe (CC’C’’C’’’). Using the same capitalization (and not the change of it) to note connection would reduce this to a CcC’c’ . It’s only aesthetical but I like it better.

Another small nitpick: how would two distincts roads crossing on each other (with a mini-bridge) be distinguished from two roads crossing one underneath each other with a tunnel? Maybe tunnels would be considered some kind of special feature tho.
Thank you!

 I am not sure I understand your first point. I only ever use a single apostrophe to differentiate between continuous segments whose edges do not immidiately follow each other, such as the very first example in the document. The tile you describe would be simply CCCC. Unless you mean different tile ? Could you please clarify?

Yes, I was planning on making the tunnel a a distinct special feature.
Title: Re: Carcassonne game notation system for tournament play
Post by: CarcFox on August 05, 2019, 08:52:01 AM
My bad, I simply got a bit confused. It would be a CCCC indeed.
Title: Re: Carcassonne game notation system for tournament play
Post by: Meepledrone on August 06, 2019, 01:13:35 PM
Hi guys,

I think the proposals are awesome. I have some remarks:

Features touching Middle Points
====================
* C. indicates a city touching the middle of the opposite side.
* F. indicates a field touching the opposite side but not at the middle of the side (the meeting point is a bit off to the right if looking from the center of the tile). So the half cities in CCCF. are not symmetrical.
* In this case, I would also suggest to represent the CCCF. tile as C(cC)cF. in order to indicate the side combines two independent cities and maintain the uppercase/lowercase notation.
* Actually the parenthesis notation could be the generic use for each side, but omitted when a side has only one feature. For example: C(cC)cF. = (C)(cC)(c)(F.)

Odd cases
=======
* Inns on two roads: The C1 tile below is coded as FR!RR as the inn is on the RHS road.

(http://wikicarpedia.com/images/f/f1/Inns_C1_15.jpg)

The same tile in C2 has a little change and the inn affects both the RHS and the LHS roads. So the C2 version of tile should be FR!RR!

(http://wikicarpedia.com/images/e/e6/Inns_And_Cathedrals_C2_Tile_C.jpg)

* Monastery location on the tie: The location of monasteries matters for wagon movement in C1.

So this tile could be (LC)ccF or LCccF, where the C1 wagon could move between the monastery and the city.

(http://wikicarpedia.com/images/e/e8/Princess_And_Dragon_C1_Tile_04.jpg)

And this tile could be CC(LF)f or CCLFf where the C1 wagon could not move between the monastery and the city.

(http://wikicarpedia.com/images/0/09/Goldmines_C1-01.png)


* Tile with bridges CC'cc'+: In this case the shield only affects to one of the sections crossing. We would need to attach + to one of the crossing segments in order to be able to rotate the tile correctly when placed. My suggestion: C+C'cc' or (C+)C'cc'

(http://wikicarpedia.com/images/f/f5/Abbey_And_Mayor_C1_Tile_02.jpg)


* Fields matter: If you check these two tiles, they would have the same definition CRrF but farms are different :

- From Base game:

(http://wikicarpedia.com/images/1/11/Base_Game_C1_Tile_17.jpg)

- From Abbey & Mayor:

(http://wikicarpedia.com/images/d/d3/Abbey_And_Mayor_C1_Tile_09.jpg)

Another example with CRcr:

- From The Princess & the Dragon:

(http://wikicarpedia.com/images/2/26/Princess_And_Dragon_C1_Tile_16.jpg)

- From Goldmines:

(http://wikicarpedia.com/images/9/94/Goldmines_C1-02.png)

Both cases show the same definition but the field configuration is different. So farms require a specific coding to tell apart those cases.

* Roads and cities (fields matter - part 2): One case where more than one road connects to a city like, for example CcRR, but fields are not clarified.

(http://wikicarpedia.com/images/b/bc/GC11_C1_Tile_04.jpg)

The same definition would also be associated to tiles with roads ending at one village (2 fields) or two separate houses (1 field). In this case the roads are connected to the city generating 3 separate fields  touching the city. If both roads ended at one junction connected to the city, there would be only two farms touching the city plus an additional farm between the two roads not touching the city.

So in the end, even if we implicitly indicate how city segments and roads are connected to tile borders, we would need additional information on field configuration to avoid ambiguities. Another separate matter is that we would need to tag tunnel roads.

Coding fields
========

One case we need to address is (C+)(C')F(c') or C+C'Fc' (notice the pennant is in the smaller city segment):

(https://github.com/farin/JCloisterZone/blob/master/src/main/resources/plugins/classic/tiles/AM/CCc+.jpg?raw=true)

Here we have an issue with the inner field and the bridge connecting the city segment with the pennant to a "remote field." This is one possible approach:

1. Add an schematic sequence of inner fields to the tile description
2. Indicate what city/bridge segments are connected by a bridge

Applying these to ideas in the case, the coding would be:

(C+/b)(C')(F/b)(c')*IF[N]

Where :
* "/b" indicates the elements the bridge connects, in this case the city segment north and the field south
* "*" is just an arbitrary connector
* "IF[N]" indicates "Inner Field along side N"

Additionally, check the attached image covering different cases with the same coding as the following tile (CcRR), but with additional information on the field configuration in order to provide a unique signature for each of them:

(http://wikicarpedia.com/images/b/bc/GC11_C1_Tile_04.jpg)

Each field is identified by the half sides and the city segments(s) it touches. So for example, CcRR*F[SR:N.E//SL.WR:N.E//WL:N.E] indicates there are three fields touching the city touching sides N and E:
* The first field touches half side south right (SR) as seen from outside the tile.
* The second field touches half sides south left (SL) and western right (WR) as seen from outside the tile.
* The third field touches half side western left (WL) as seen from outside the tile.

You may see in the other examples how there is a case that the second field does not touch the city at all CcRR*F[SR:N.E//SL.WR//WL:N.E].

If this approach seems okay for you, I will explain the whole system I've been thinking of, that uses a 8x8 grid to position elements and even describe road by segments (regular, bridges, tunnels) and end connectors. I don't plan to use all this information but it may be interesting to have a full-fledged notation to describe the tiles fully and then a shorthand notation to eliminate those aspects not needed for a particular purpose.

For example: road endpoints may not necessary for tile description unless you have very sophisticated cases or you need to keep track of valid transitions for the wagon in C1. Check the second illustration attached for a sneak peek.

Your comments are all welcome.

Cheers!
Title: Re: Carcassonne game notation system for tournament play
Post by: DIN0 on August 06, 2019, 05:13:47 PM
Hello Meepledrone,

thank you for your feedback! I am going to adress your remarks in order you wrote them. Some of them are actually explained in my GTR pdf. document , but I will adress them anyway:

*Features touching Middle Points
I understand what you are saying, but the fact that those two tiles are slightly asymmetrical doesn't affect their functionality in any case. By indicating that the field or city is touching thee middle of the opposite  side, it should be obvious enough that the field/city on that side is separated. However, I really like your idea of indicating this fact and that it maintains the uppercase/lowercase notation. I just personally find it unnecesary, because it adds that little bit of complexity which can be avoided by a simple . dot.
I will definately keep this on my mind as I believe it can be discussed further, especially if something would arise that would utterly require it.

*Inns on two roads
That is interesing, I didn't know that. Yes, in that case it will be FR!RR!

* Monastery location on the tie
I will save this one for later...

* Tile with bridges CC'cc'+
I discuss this tile in my document at the very beginning - the order of hierarchy in determining starting point. In this case, city segment containing pennant is prioritized over the other, therefore you know pennant belongs to the first C in CC'cc'

*Fields matter
Yes, I agree!
That is why I came up with / for touching and // for separated The tiles you show would be: C//RrF for base, and for Abbey & Mayor: C/RrF. This is also in my document albeit with different examles. Same gous for crcr tiles. P&D C//Rc//r, goldmines: C/Rc/r. I will soon add these examples to my document.

Basicaly all of the following remarks about roads and distict fields were already adressed by my /, // system - everything is detailed in my document which you can find attached to the first post on page 2 of this thread. I update it regularly.
I appriciate your detailed system, but it is too complex for these purposes and the same can be achieved with what I described earlier... so I rather would not use it.
I am going to describe all the tiles in your attachment from left to right using my method:
Cc/R//R/
Cc/R/R
Cc//R/R
Cc//R//R/
Cc//R//R//
Cc/R//R//

The last configuration is too unrealistic to happen so I will not describe it for now. I too have used hypothetical tiles in my document as you can see, but I keep it to tiles that are more likely to be released in future.

Lastly, the CC'cF+ tile with city bridge was already discussed between me an CarcFox. We settled on making that the exception from general rule and in this case allocate the pennant to specific city segment.

Title: Re: Carcassonne game notation system for tournament play
Post by: Meepledrone on August 07, 2019, 02:32:04 AM
Hello Meepledrone,

thank you for your feedback! I am going to adress your remarks in order you wrote them. Some of them are actually explained in my GTR pdf. document , but I will adress them anyway:

Hi tp10053,

No problem. I checked your document and just wanted to point out some alternatives to your proposal. Just in case they may be interesting to you.

*Features touching Middle Points
I understand what you are saying, but the fact that those two tiles are slightly asymmetrical doesn't affect their functionality in any case. By indicating that the field or city is touching thee middle of the opposite  side, it should be obvious enough that the field/city on that side is separated. However, I really like your idea of indicating this fact and that it maintains the uppercase/lowercase notation. I just personally find it unnecesary, because it adds that little bit of complexity which can be avoided by a simple . dot.
I will definately keep this on my mind as I believe it can be discussed further, especially if something would arise that would utterly require it.

I agree this may be an overkill for know as of know. We'll never know what new tile configurations HiG may create after H&S. You can check the All the Rest of Possible tiles for a good testbed of possible tile configurations:

http://www.carcassonnecentral.com/community/index.php?action=downloads;sa=view;down=146 (http://www.carcassonnecentral.com/community/index.php?action=downloads;sa=view;down=146)

*Inns on two roads
That is interesing, I didn't know that. Yes, in that case it will be FR!RR!

* Monastery location on the tie
I will save this one for later...

* Tile with bridges CC'cc'+
I discuss this tile in my document at the very beginning - the order of hierarchy in determining starting point. In this case, city segment containing pennant is prioritized over the other, therefore you know pennant belongs to the first C in CC'cc'

I saw that. I just wanted to suggest the use of parenthesis as a means of attaching + to any city segment in between in case any ambiguity or exception would require it. There is no ambiguity in A&M tiles CC'cc'+ but it served as a good example. However, our dear A&M exception CC'Fc'+ would be a good candidate for that (C+)C'Fc'.

*Fields matter
Yes, I agree!
That is why I came up with / for touching and // for separated The tiles you show would be: C//RrF for base, and for Abbey & Mayor: C/RrF. This is also in my document albeit with different examles. Same gous for crcr tiles. P&D C//Rc//r, goldmines: C/Rc/r. I will soon add these examples to my document.

Basicaly all of the following remarks about roads and distict fields were already adressed by my /, // system - everything is detailed in my document which you can find attached to the first post on page 2 of this thread. I update it regularly.
I appriciate your detailed system, but it is too complex for these purposes and the same can be achieved with what I described earlier... so I rather would not use it.
I am going to describe all the tiles in your attachment from left to right using my method:
Cc/RR/
Cc/Rr
Cc//R/R
Cc//R//R/
Cc//R//R//
Cc/R//R//

The last configuration is too unrealistic to happen so I will not describe it for now. I too have used hypothetical tiles in my document as you can see, but I keep it to tiles that are more likely to be released in future.

Now I see I didn't process correctly your notation, especially the trailing / and // as the wrap around to find the next city/road. So we have these two cases:
* The city side marks the relationship with the next road side listed (one or more sides later)
* The road side marks the relationship with the city or next road side (it may require to read the encoding as a cycle for the trailing indications)
I think (?) I understand now. Let me know if I missed something. I also see the implications with fields and it can condense a lot of information.

After revisiting the examples in your doc I have some comments/questions:

* A trailing // is not necessary as it would be assumed always by default, right?
* Tile C/R/C/R: I still have a conflicting feeling about this one as cities are not really connected to the junction. The short roads are an exception and don't allow the C1 wagon to move from the main roads to the city and vice versa.

(http://wikicarpedia.com/images/5/55/Inns_C1_17_new_junction.jpg)

* Regarding the six examples above:
   - Tile 1: You used Cc/RR/, why not Cc/R//R/?
   - Tile 2: You used Cc/Rr but the roads are not connected (there is a juctions with only two roads as in the H&S tile) . So should the tile be coded as Cc/R/R/?
   - Tile 3: I assume Cc//R/R is equivalent to Cc//R/R// and the trailing // can be omitted as you did.
   - Tile 4: No comments
   - Tile 5: You used Cc//R//R// and the trailing // could be omitted (Cc//R//R) as I commented earlier, right?
   - Tile 6: You used Cc/R//R// and the trailing // could be omitted (Cc//R/R) as I commented earlier, right?

* What would be the encoding for the example Tile 2 variation attached (the road touches the city but the two-road junction is elsewhere)?

* These are the H&S tiles that gave me the idea for some of these road configurations. So this is just a hit of new tiles with awkward configurations for roads HiG may design in the future. You saw what happened to cities sharing a side. ;)

(http://wikicarpedia.com/images/d/d9/Hills_And_Sheep_C1_Tile_05.jpg)

(http://wikicarpedia.com/images/d/d2/Hills_And_Sheep_C1_Tile_12.jpg)

* Regarding junctions, C1 and C2 have some requirements I don't know we should take into account for the notation:
   - The C1 wagon movement constraints: features that end roads and allow the wagon to move or not. For example you can move the wagon from a road to a connected monastery and back. On the other had, you cannot move the wagon either to a fair ending a road  or to another road connected to the fair.
   - The C2 rules about roads leading to Leipzig: junctions with villages allow an indirect connection to Leipzig, a junction with trees or any other feature block such connection.

Lastly, the CC'cF+ tile with city bridge was already discussed between me an CarcFox. We settled on making that the exception from general rule and in this case allocate the pennant to specific city segment.

OK. I wrote above about my view on this exception. No big deal for me anyway.

Besides regular fields, any comments on my proposal to encode inner fields?

Cheers!
Title: Re: Carcassonne game notation system for tournament play
Post by: DIN0 on August 07, 2019, 05:19:20 AM
Hi Meepledrone,

I will check the link you provided soon.

Now I see I didn't process correctly your notation, especially the trailing / and // as the wrap around to find the next city/road. So we have these two cases:
* The city side marks the relationship with the next road side listed (one or more sides later)
* The road side marks the relationship with the city or next road side (it may require to read the encoding as a cycle for the trailing indications)
I think (?) I understand now. Let me know if I missed something. I also see the implications with fields and it can condense a lot of information.


I believe you got it 100%! That is exactly how it works.

After revisiting the examples in your doc I have some comments/questions:

* A trailing // is not necessary as it would be assumed always by default, right?
* Tile C/R/C/R: I still have a conflicting feeling about this one as cities are not really connected to the junction. The short roads are an exception and don't allow the C1 wagon to move from the main roads to the city and vice versa.


*I will adress trailing // with the other tile examples.
*I believe such notation is necessary for field configuration. Wagon movement I will adress in wagon movement
section of this post.

* Regarding the six examples above:
   - Tile 1: You used Cc/RR/, why not Cc/R//R/?

Originally, I had Cc/R//R/ written down, I guess I was just being overly simplitic with that one - Cc/R//R/ is indeed better
   - Tile 2: You used Cc/Rr but the roads are not connected (there is a juctions with only two roads as in the H&S tile) . So should the tile be coded as Cc/R/R/?
Correct! That was my mistake. I will edit these.
  - Tile 3: I assume Cc//R/R is equivalent to Cc//R/R// and the trailing // can be omitted as you did.
   - Tile 4: No comments
   - Tile 5: You used Cc//R//R// and the trailing // could be omitted (Cc//R//R) as I commented earlier, right?
   - Tile 6: You used Cc/R//R// and the trailing // could be omitted (Cc//R/R) as I commented earlier, right?

Yes, all of these are equivalent. There is an interesting question about what can be regarded as "default", as this may differ between individual people. With each tile you expect some default (most frequent?) configuration of touching or separated roads and so is inclined to only mark any deviations from said default ( so that they can reduce the amount of writing). Ideal case of course wouuld be if nothing was ommited from notation, but some cases are truly not necessary. Like I said it is individual, for example the last three tiles you provided above... I prefer to include the trailing // to better differentiate them from Tile 1.

* What would be the encoding for the example Tile 2 variation attached (the road touches the city but the two-road junction is elsewhere)?
I admit, it would be the same. This is where the limitations of my system begin to show. Luckily, cases like this are functionaly identical. Now I know what you are going to say - wagon! Which brings me to...

Wagon movement
My way of thinking goes like this: if notation provides sufficient way of determining the correct tile, then you don't need to describe possible wagon movement in the tile description itself, because you can already see it clearly on the specific tile.
Additionally, the presence of any special feature which the wagon cannot cross will be included in notation later.
Title: Re: Carcassonne game notation system for tournament play
Post by: CarcFox on August 07, 2019, 05:29:20 AM
Isn’t that crazy tile at the end just a plain C..+/C/Rc/ ? The first witch hat city, its continuation and the other city are all connected to the only road. Things might get messier if multiple different roads connect to various cities in a non-obvious way tho. In that case one could start using “/“ and “/‘ “ etc. to distinguish between connections to different roads. Just an idea, let me know if I’m misunderstanding something.
Title: Re: Carcassonne game notation system for tournament play
Post by: DIN0 on August 09, 2019, 12:14:15 PM
Isn’t that crazy tile at the end just a plain C..+/C/Rc/ ? The first witch hat city, its continuation and the other city are all connected to the only road. Things might get messier if multiple different roads connect to various cities in a non-obvious way tho. In that case one could start using “/“ and “/‘ “ etc. to distinguish between connections to different roads. Just an idea, let me know if I’m misunderstanding something.
It is not so easy... we don't know if the tunnel entrances are outside the city or inside - that changes configuration. just compare the only two real tiles with tunnel (not from The tunnel miniexpansion). One is from P&D, other A&M, C//Rc//r and C/Rc//r respecively.
Note that non of them has both entrances inside the city. If there were such a tile, it would be indistinguishible from a bridge going over the city C/Rc/r as in goldmines.
Regardless of the  case, hypothetical tile from Meepledrone has touchpoints which would make it unclear as t which one is which...
But as I said, we don't really have to bother, because such crazy tile will most likely never be released.
Title: Re: Carcassonne game notation system for tournament play
Post by: DIN0 on August 09, 2019, 02:37:05 PM
GTR document has been upated with more examples :gray-meeple:
Title: Re: Carcassonne game notation system for tournament play
Post by: Meepledrone on August 10, 2019, 02:52:33 AM
Hi guys,

Please find here a proposal for the notation to cover inner fields and tunnels.

https://www.dropbox.com/s/ux4ds6u8r2qglxd/Tile_Examples_v1.3.docx?dl=0 (https://www.dropbox.com/s/ux4ds6u8r2qglxd/Tile_Examples_v1.3.docx?dl=0)

I suggest some changes and additions to the coding system to cover inner fields, tunnels and bridges. The file cannot be attached to this post due to its size.

One key change is simplification of / and the addition of other codings to be more specific with the role of the road segment and control de ending point. Part of the process took me to simplify // too for the reasons commented below.

One of the motivations was the multiple meanings the coding had for/:

* A normal road connecting a city and a road edge or two road edges

* A short road connecting a city and a junction (like in C/R/C/R)

(http://wikicarpedia.com/images/5/55/Inns_C1_17_new_junction.jpg)

* A road touching a city but not ending there (C/FRr)

(http://wikicarpedia.com/images/5/53/Abbey_And_Mayor_C1_Tile_07.jpg)

Actually the same coding C/FRr would define also the tile attached below with a city and a roundabout.

Another minor issue was that // has several meanings too:

* Providing emphasis to indicate separate features and could be omitted and many cases

* Indicating two roads connected to the same city were not sharing the end point, for example in Cc/R//R/:

(http://wikicarpedia.com/images/b/b8/Trad_c1_tile_15.jpg)
 
* Indicating that a road was not touching a city becasue it was entering a tunnel, for example in the following examples:

- C//Rc//r

(http://wikicarpedia.com/images/2/26/Princess_And_Dragon_C1_Tile_16.jpg)

- C/Rc//r+

(http://wikicarpedia.com/images/f/f0/Abbey_And_Mayor_C1_Tile_08.jpg)

So these uses for tunnels and separate endpoints are ambiguous so I propose some restrictions to the use of of // and additional notation to deal with tunnels.

Moreover, I think the description (C/FR/R//) for the following tile has to be reviewed as it describes a junction and not a bridge:

(http://wikicarpedia.com/images/3/34/Trad_c1_tile_20.jpg)


In a nutshell, you'll find in the document attached a review of the notation to address the issues I found and some examples to illustrate the use. The  scope covered is the following:

* Extended support for roads to allow for better control:
   - Road type: normal or short
   - Road endpoints: road edge, junction, city gate, tunnel
   - Layout characteristics: bridges and touching points with city walls.

* Support for cities and fields sharing edges.

* Support for city with bridges allowing fine control to discern between city segments and bridge connection as desired.

* Support for non planar connections between elements like bridges that connect cities to remote fields

* Support for inner features (fields and roads with tunnels) described by their vertices.

Your comments are most welcome.

Cheers!
Title: Re: Carcassonne game notation system for tournament play
Post by: CarcFox on August 11, 2019, 01:26:25 AM
I think that document is pretty much the ultimate tile reference for vanilla tiles. Props to you for coming up with the ideas for tunnel/bridges and all the things you added and for having condensed all of this discussion in a fleshed out document!

Meeple placement is a little more straightforward, since we only need a way to indicate on which road/city/field the follower is placed. For Knights KN,KE,KO,KS (knight north/east/south/west) and for some H&S tiles KNE/KNO etc. Pretty much the same for thieves (maybe a TI for T “internal”) is needed) and for non-internal  farmers. Internal farmers seem a bit more problematic with this system.

 Perhaps notating the continuation of a feature by keeping the same capitalization would solve this problem since we could put the type of the meeple followed by the letter of the feature they’re in. But perhaps there are more convenient ways.

Edit: Nvm, I came up with a far better idea. Just use the letter of the meeple+a number that denotes on which feature it’s placed. The numbers are assigned depending on the position of the city/field/road/cloister in the field notation. E.g. in CcR/R a T1 would be a thief on the south road and T2 on the east one. Since internal fields are also noted this solves that problem too. Let me know what you think of those methods. I personally feel this one is the best.
Title: Re: Carcassonne game notation system for tournament play
Post by: Meepledrone on August 12, 2019, 07:26:32 AM
I think that document is pretty much the ultimate tile reference for vanilla tiles. Props to you for coming up with the ideas for tunnel/bridges and all the things you added and for having condensed all of this discussion in a fleshed out document!

Thanks. I just wanted to put some examples together and ended up with a comprehensive guide of the tile notation plus the additions after a few days of work. :o

Meeple placement is a little more straightforward, since we only need a way to indicate on which road/city/field the follower is placed. For Knights KN,KE,KO,KS (knight north/east/south/west) and for some H&S tiles KNE/KNO etc. Pretty much the same for thieves (maybe a TI for T “internal”) is needed) and for non-internal  farmers. Internal farmers seem a bit more problematic with this system.

 Perhaps notating the continuation of a feature by keeping the same capitalization would solve this problem since we could put the type of the meeple followed by the letter of the feature they’re in. But perhaps there are more convenient ways.

Edit: Nvm, I came up with a far better idea. Just use the letter of the meeple+a number that denotes on which feature it’s placed. The numbers are assigned depending on the position of the city/field/road/cloister in the field notation. E.g. in CcR/R a T1 would be a thief on the south road and T2 on the east one. Since internal fields are also noted this solves that problem too. Let me know what you think of those methods. I personally feel this one is the best.

Figure placement requires:
1. Tile coordinates: We cannot assume the figure is placed on the last tile placed. Meeples can be placed with a magic portal or a flying machine. Meeples can be also placed on an acrobat tiles, on the Wheel of Fortune crown, on a district of the city of Leipzig or the city of Carcassonne.
2. Tile rotation: We need to take into account the rotation applied to the target tile. 
3. Target feature: We can address the feature by type but assuming a meeple type can be a bit limiting as there are other figures. Consider the Mage, the Witch, the Fee, Gingerbread Man. Other figures have other placement requirements. 
4. Figure identification: We need to define how to identify figures. Something like <player#/neutral>.<figure type>.<number>; for example:
- neutral.dragon.1: the dragon
- neutral.bigtop.1: the bigtop
- player1.normal.6: player 1's normal meeple #6
- player4.big.1: player 1's large meeple
- player6.shepherd.1: player 1's shepherd

What do you think?
Title: Re: Carcassonne game notation system for tournament play
Post by: CarcFox on August 20, 2019, 01:27:22 AM
Hi meepledrone, sorry if I'm a bit late.
I think that the main concern atm should be to resolve any ambiguities in placement that manifest themselves using "vanilla" tiles. A coordinate system would be useful for expansions but perhaps it's better to use it only when it's necessary and not by default. I wrote something about a similar system for the plague and the dragon previously in this thread, too.

Anyway, what do you think should be done to differentiate the placement of a knight on different cities in the same tile? Is the system I proposed in the edit in my previous post ok in your opinion?
Title: Re: Carcassonne game notation system for tournament play
Post by: Meepledrone on September 29, 2019, 03:38:59 AM
Hi meepledrone, sorry if I'm a bit late.

Hi CarcFox,

It seems I missed your post. Sorry.

(So I'm even later :o)

I think that the main concern atm should be to resolve any ambiguities in placement that manifest themselves using "vanilla" tiles. A coordinate system would be useful for expansions but perhaps it's better to use it only when it's necessary and not by default. I wrote something about a similar system for the plague and the dragon previously in this thread, too.

I totally agree. Something simple is enough for vanilla cases, but it has to be open when needed, that is, when the placement happens on a previously placed tile.

I think you are referring to this, right?

Meeple placement is a little more straightforward, since we only need a way to indicate on which road/city/field the follower is placed. For Knights KN,KE,KO,KS (knight north/east/south/west) and for some H&S tiles KNE/KNO etc. Pretty much the same for thieves (maybe a TI for T “internal”) is needed) and for non-internal  farmers. Internal farmers seem a bit more problematic with this system.

Anyway, what do you think should be done to differentiate the placement of a knight on different cities in the same tile? Is the system I proposed in the edit in my previous post ok in your opinion?

If you were referring to the text I quoted, it would work fine. My only concern is that you would need to define a set of letters for all types of figures. In this case, I'm more inclined to use the feature as a reference and indicate the figure type separately, being the default a normal meeple. Examples: CN, CE, CO, CS, CNE, CNO. In this case, if you place, let's say, the Mage, you can say CN.Mage or CN.M if we agree M represents the Mage.

What do you think?