Author Topic: Carcassonne game notation system for tournament play  (Read 9707 times)

Offline DIN0

  • Viscount
  • ****
  • Posts: 837
  • Merit: 37
  • Carcassonne is only complete with 11th expansion:)
    • View Profile
Re: Carcassonne game notation system for tournament play
« Reply #15 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
« Last Edit: August 09, 2019, 02:35:03 PM by tp10053 »

Offline CarcFox

  • Labourer
  • **
  • Posts: 11
  • Merit: 1
  • I haven't updated my profile yet!
    • View Profile
Re: Carcassonne game notation system for tournament play
« Reply #16 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!

Offline DIN0

  • Viscount
  • ****
  • Posts: 837
  • Merit: 37
  • Carcassonne is only complete with 11th expansion:)
    • View Profile
Re: Carcassonne game notation system for tournament play
« Reply #17 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.

« Last Edit: August 04, 2019, 02:13:49 PM by tp10053 »

Offline CarcFox

  • Labourer
  • **
  • Posts: 11
  • Merit: 1
  • I haven't updated my profile yet!
    • View Profile
Re: Carcassonne game notation system for tournament play
« Reply #18 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.

Offline DIN0

  • Viscount
  • ****
  • Posts: 837
  • Merit: 37
  • Carcassonne is only complete with 11th expansion:)
    • View Profile
Re: Carcassonne game notation system for tournament play
« Reply #19 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.

Offline CarcFox

  • Labourer
  • **
  • Posts: 11
  • Merit: 1
  • I haven't updated my profile yet!
    • View Profile
Re: Carcassonne game notation system for tournament play
« Reply #20 on: August 05, 2019, 08:52:01 AM »
My bad, I simply got a bit confused. It would be a CCCC indeed.

Offline Meepledrone

  • Owner
  • Chatelain Grand Officier
  • *
  • *
  • Posts: 6292
  • Merit: 456
  • It is full of... Meeples!!!
    • View Profile
Re: Carcassonne game notation system for tournament play
« Reply #21 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.



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!



* 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.



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




* 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'




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

- From Base game:



- From Abbey & Mayor:



Another example with CRcr:

- From The Princess & the Dragon:



- From Goldmines:



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.



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):



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:



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!
« Last Edit: August 06, 2019, 05:00:06 PM by Meepledrone »
Questions about rules? Check WICA: wikicarpedia.com

Offline DIN0

  • Viscount
  • ****
  • Posts: 837
  • Merit: 37
  • Carcassonne is only complete with 11th expansion:)
    • View Profile
Re: Carcassonne game notation system for tournament play
« Reply #22 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.

« Last Edit: August 07, 2019, 05:21:33 AM by tp10053 »

Offline Meepledrone

  • Owner
  • Chatelain Grand Officier
  • *
  • *
  • Posts: 6292
  • Merit: 456
  • It is full of... Meeples!!!
    • View Profile
Re: Carcassonne game notation system for tournament play
« Reply #23 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

*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.



* 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. ;)





* 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!
« Last Edit: August 07, 2019, 02:35:08 AM by Meepledrone »

Offline DIN0

  • Viscount
  • ****
  • Posts: 837
  • Merit: 37
  • Carcassonne is only complete with 11th expansion:)
    • View Profile
Re: Carcassonne game notation system for tournament play
« Reply #24 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.

Offline CarcFox

  • Labourer
  • **
  • Posts: 11
  • Merit: 1
  • I haven't updated my profile yet!
    • View Profile
Re: Carcassonne game notation system for tournament play
« Reply #25 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.

Offline DIN0

  • Viscount
  • ****
  • Posts: 837
  • Merit: 37
  • Carcassonne is only complete with 11th expansion:)
    • View Profile
Re: Carcassonne game notation system for tournament play
« Reply #26 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.

Offline DIN0

  • Viscount
  • ****
  • Posts: 837
  • Merit: 37
  • Carcassonne is only complete with 11th expansion:)
    • View Profile
Re: Carcassonne game notation system for tournament play
« Reply #27 on: August 09, 2019, 02:37:05 PM »
GTR document has been upated with more examples :gray-meeple:

Offline Meepledrone

  • Owner
  • Chatelain Grand Officier
  • *
  • *
  • Posts: 6292
  • Merit: 456
  • It is full of... Meeples!!!
    • View Profile
Re: Carcassonne game notation system for tournament play
« Reply #28 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

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)



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



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/:


 
* Indicating that a road was not touching a city becasue it was entering a tunnel, for example in the following examples:

- C//Rc//r



- C/Rc//r+



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:




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!

Offline CarcFox

  • Labourer
  • **
  • Posts: 11
  • Merit: 1
  • I haven't updated my profile yet!
    • View Profile
Re: Carcassonne game notation system for tournament play
« Reply #29 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.
« Last Edit: August 11, 2019, 01:32:02 AM by CarcFox »


Share via delicious Share via digg Share via facebook Share via furl Share via linkedin Share via myspace Share via reddit Share via stumble Share via technorati Share via twitter

  Subject / Started by Replies / Views Last post
lamp
Project 1A: Carcassonne Game Notation

Started by DIN0

80 Replies
12280 Views
Last post June 16, 2022, 03:03:47 AM
by DIN0
xx
Rating System for Reviews, by BIG GUY

Started by Big Guy

44 Replies
24917 Views
Last post September 17, 2014, 07:57:43 AM
by Gerry
xx
CundCo Shop - coming soon with new system and navigation

Started by kettlefish

23 Replies
11877 Views
Last post October 02, 2015, 06:47:59 AM
by Hounk
xx
Illustrated Game report: Skipped mother-in-law to play mega-carc vs my son.

Started by What If?

3 Replies
3458 Views
Last post February 08, 2017, 01:44:22 AM
by Chooselife
xx
Play with expansions only - no base game

Started by cicerunner

5 Replies
1532 Views
Last post October 07, 2020, 03:35:17 AM
by Paul