Recommend
2 
 Thumb up
 Hide
13 Posts

Piecepack» Forums » General

Subject: Piecepack notation? rss

Your Tags: Add tags
Popular Tags: [View All]
Anika Henke
msg tools
Has anyone ever thought of a piecepack notation?

We started a discussion in a different thread:

trevorld wrote:
selfthinker wrote:

How can people create all the different diagrams easily?
Ideally there should be some kind of piecepack notation, similar to any of the notation systems for chess. If we had a handful of pre-defined boards, that would be doable. But because the boards can be pretty much any configuration, with probably hundreds of variations, I very quickly gave up on that idea.

I have an unpublished draft of some ideas for a piecepack game notation system adapting notation from games like FIDE chess (PGN), Tak, and Shogi for easily representing piecepack games that can be played on a pre-defined rectangular grid (the vast majority of them) that one will be able to in the future use to make game diagrams and animations using piecepackr. Right now my priority for my limited free time is finalizing the public beta for piecepackr as well iterating on my customizable piecepack ruleset and rulebook prototypes but I'll make a post in a few months when I have a prototype working for a toy example like Tic-Tac-Toe. However assuming you don't want to tediously place all the initial pieces on a "blank" table using a "drop" notation for which piece to place (and how) then you would want to you tell piecepackr (or whatever program written to support that notation) to use a pre-written function that sets up the starting board and initial piece set-up (as mentioned besides arbitrary rectangular boards I already have such a function written for 14 piecepack games and the list is growing). For games with random starting boards (like Alien City) you'd want that starting board function to accept a 'seed' for a pseudo-random number generator so one can quickly generate different "random" boards. Then you once you have set up the board either using the "drop" notation or a pre-defined function one could move pieces around in a more intuitive manner using a chess/Tak-style algebraic notation with the addition of other "sugar" for piecepack game actions like flipping/rotating a piece or placing a piece in over/under/between other pieces although ignoring such notation "sugar" at a bare minimum all you really need is the notation to "drop" an arbitrary piece onto the board ("configuration", "piece", "suit", "rank") at an arbitrary location ("x", "y", "angle", "side", plus some notion of "z" within an existing stack of pieces) and the notation to "pluck/remove" any arbitrary piece from the board. Then all other moves for a diagram/animation can (verbosely) be expressed as a combination of "drops" and "plucks".

I'm not optimistic though that there is a game notation system for easily representing such piecepack dexterity games like Piecepack Soccer.

And I found a reference to some ideas in a mailinglist thread from 2007:

porter235 wrote:
I was inspired by board2diag [...]
You would include in your html a chunk like

<pre class="ppdiag">
+ + + +
+
+ + + + +
+
5C AC NC:d + +

+ + + +

-----
cC 6,1.5 45 ul

</pre>


[...] The cryptic line would place a coin of Crowns on 6 column, 1.5 row angled 45deg(0= straight up) shifted to the upper left corner of the tile.

NC:d is the Null of Crowns facing "down" or south.

This way the basic board layouts can be "drawn" in ascii and then coins, dice, pawns, and other markers could be added on top.

It seems to me, whatever syntax/notation would be used, having two different sections make sense. First you have to define the grid, and then which pieces go where.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Trevor Davis
msg tools
selfthinker wrote:

And I found a reference to some ideas in a mailinglist thread from 2007

Thanks for the link. I somehow missed that thread.

selfthinker wrote:

It seems to me, whatever syntax/notation would be used, having two different sections make sense. First you have to define the grid, and then which pieces go where.

If have a sensible default grid like Cartesian coordinates (likely alternatively expressed using chess-like file/rank coordinates) in one inch increments then all you only really need is a section of which/where/how pieces (including tiles) are placed (and removed). You could then infer your grid using the (cumulative) game state from that section.

However it would certainly be nice to support extra sections like a section for pre-defined macros (so users playing a game like Bughouse chess could use something like `q` when placing a captured black queen instead of the notation for a 5-valued coin face [perhaps taken from a second expansion piecepack] oriented 180 degrees ("down") [without any 3d tilt]), a section to re-define the grid (such as use Cartesian coordinates with two inch increments or more exotic coordinate systems), a section that allows users to use a helper function (that perhaps takes a specified seed) to set up a (random) starting board for them, and other metadata typically stored in such game notation formats like who/where/when/how the game took place.
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Trevor Davis
msg tools
Although I still need to add a bunch of things (like Piece macros, "Complex" Piece Notations, more move types) the default Movetext parser used by my prototype "portable piecepack notation" parser I've been working on currently supports the following "Simplified" Piece Notation


* Pieces: t, c, d, p

+ If missing assumed to be a tile if has both rank and suit
or neither rank and suit otherwise
assumed to be a coin.

* Side Up: f, b

+ If missing tiles are assumed to be "back" up
if missing suit and/or rank.
+ If missing coins are assumed to be "face" up if missing suit.
+ If missing pawns and dice are assumed to be "face" up
(and only pawns can be "back" up).

* Suits: S, M, C, A

+ If missing assumed to be "Suns" for tile faces,
coin backs, pawns, and dice.

* Ranks: n, a, 2, 3, 4, 5

+ If missing assumed to be "null" for tile faces,
coin faces, and dice.

* Direction: ^, <, >, v

+ If missing direction should be assumed to be straight up

* Ordering of elements should not matter but the following ordering may
improve readability (omitting any unnecessary elements as necessary):

1. Piece
2. Side up
3. Suit
4. Rank
5. Direction

* Simplified piecepack piece notation does not support angles that
aren't a multiple of 90 degrees nor 3D tilts
* Simplified piecepack piece notation does not support piecepack
expansions / accessories or other game systems

Examples:

* ``t`` tile back
* ``Aa>`` ace of Arms tile (face) oriented "right"
* ``C`` Crowns coin back oriented "up"
* ``cC3b^`` (3 of) Crowns coin back (explicitly) oriented up
* ``nv`` null coin face oriented "down"
* ``<dM4`` 4 of Moons die (face) oriented "left"
* ``pM`` Moons pawn
* ``p`` (Suns) pawn
* ``d`` (null of Suns) die


Example (currently working) use of Simplified Piece Notation in an example prototype Portable Piecepack Notation file to record a simple game that can be used to generate diagrams and animations:


---
Event: Example Tic-Tac-Toe Game
Result: 1-0
...
setup. t@b2
1. S@b2 1... M@a2 {? (1... M@a1)}
2. S@c1 2... M@a3
3. S@a1 3... M@c3
4. S@b1 {X wins}


In terms of JCD's original idea:

Quote:

Version 0.2 will support only a single layer of tiles set up in a
grid. Must allow you to express tiles offset by 1/2 a tile. Must allow
you to display either side of Tile, in one of the 4 cardinal
orientations.

One possible ASCII notation for a single layer of tiles that would support his requirements would be to use four ASCII characters per tile in a 2x2 grid with + for tile back quadrant, S,M,C,A for suit symbol quadrant, n,a,2,3,4,5 for rank symbol placed in opposite quadrant of suit symbol, and - for other tile face quadrants. Example ASCII single-layer tile diagram:


S--M
-na-
++
++
-32-
A--C
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Daniel Ajoy
Ecuador
Quito
flag msg tools
mbmbmbmbmb
Quote:

S--M
-na-
++
++
-32-
A--C

Is this representing half-tile offsets?
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Trevor Davis
msg tools
DanielAjoy wrote:
Quote:


S--M
-na-
++
++
-32-
A--C

Is this representing half-tile offsets?

Yes, assuming 2" tiles then a half-tile offset should be 1". Each ASCII character in that thought experiment represents a 1" quadrant of a tile (or 1" square of nothing if an ASCII space). That text diagram thought experiment would theoretically correspond to the following piecepackr diagram (assuming the table was black):

1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Daniel Ajoy
Ecuador
Quito
flag msg tools
mbmbmbmbmb
The proposed format seem flexible to write in, but a bit confusing, consider:


S--M
-na- ++
++++++++
++++++
-32-
A--C


This is a still imperfect alternative:


[S ][ M]
[ n][a ] [ ]
[ ][ ][ ][ ]
[ ][ ][ ]
[ 3][2 ]
[A ][ C]


The tiles are more visible. But you still can't represent pieces on top of the tiles.
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Trevor Davis
msg tools
DanielAjoy wrote:

This is a still imperfect alternative:


[S ][ M]
[ n][a ] [ ]
[ ][ ][ ][ ]
[ ][ ][ ]
[ 3][2 ]
[A ][ C]


The tiles are more visible. But you still can't represent pieces on top of the tiles.

I agree that is a better solution for the given design constraints JCD was considering. As a standard I would add an optional choice to mark the upper left corner (if empty) with an unused ASCII symbol (maybe ^) so such an ASCII diagram could be included in YAML "mappings" (which is how my prototype "portable piecepack notation" will get its metadata for things like game setup so that even though the default movetext parser probably won't support such a setup scheme an alternative movetext parsers could be written to support it).

Given that most browsers support Javascript and SVG images these days not sure that a browser plugin really needs an ASCII diagram backup especially since most browsers these days also support Unicode and you can represent piecepack pieces on top of the tiles in a Unicode text diagram (although ideally you may need to provide fonts for your website for users to view them properly and although it would be a pain to type up such diagrams manually the ppgames R package has an experimental function to generate such diagrams called cat_piece from the same data frames can can be used to generate SVG/PNG/PDF/etc. diagrams with pmap_piece which are also generated as output when parsing "portable piecepack notation" files using ppgames experimental read_ppn's parser).
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Michael Van Biesbrouck
Canada
St Catharines
Ontario
flag msg tools
designer
badge
Avatar
mbmbmbmbmb
You can use colour to indicate levels, perhaps ROYGBV or shades of grey with black being the lowest level. You will need to use a character to represent spaces and deal with coins being thinner than tiles.
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Trevor Davis
msg tools
mlvanbie wrote:
You can use colour to indicate levels, perhaps ROYGBV or shades of grey with black being the lowest level. You will need to use a character to represent spaces and deal with coins being thinner than tiles.

The Block Elements has "Full Block", "Light Shade", "Medium shade", and "Dark Shade" characters, the Wikipedia article claims "Light Shade" is commonly used to represent spaces. The Mesomorph dimensions are suggestions not requirements for a standard piecepack - the simpler solution would be to assume tiles and coins (and perhaps dice and/or pawns) are all the same thickness (which is often the case for DIY piecepacks). Although you may want to use color instead to match the suits (which would also make it look more realistic although hiding depth - or maybe make choice based on game).
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Trevor Davis
msg tools
mlvanbie wrote:
You will need to use a character to represent spaces

Actually depending on your scheme just using the space character may be fine if you customize the background color instead. Both terminals and web pages (i.e. CSS) seem capable of customizing both the background and foreground color for each character although the color choices for terminals are somewhat limited:

https://en.wikipedia.org/wiki/ANSI_escape_code#Colors

https://stackoverflow.com/questions/5947742/how-to-change-th...

The tricky thing would be deciding what background/foreground color should be for the box-drawing characters representing parts of multiple tiles e.g. the 4-corner box-drawing characters when it represents the corners of 4 different tiles all at different levels.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Trevor Davis
msg tools
I've written an alpha-level draft specification for a "Portable Piecepack Notation" file format:

https://trevorldavis.com/piecepackr/portable-piecepack-notat...

Right now only has game setups for a dozen games (although can setup games from scratch) and only allows adding, removing, and moving the top pieces on a board but eventually I want to add even richer notation support and more game setups:

@ used to add piece to board
* used to remove piece from board
- used to move piece on board
: "displacement capture" move


I have a prototype parser in the experimental ppgames piecepackr spin-off package. It can read in piecepack games written in PPN format and make animations as well as make diagrams (image or Unicode plaintext) of individual moves within a game) with functions read_ppn, animate_game, plot_move, and cat_move:

https://www.github.com/trevorld/ppgames

Example games:

A simple game of Tic-Tac-Toe with no automatic setup:


---
Event: Example Tic-Tac-Toe Game
Result: 1-0
...
setup. t@b2
1. S@b2 1... M@a2 {? (1... M@a1)}
2. S@c1 2... M@a3
3. S@a1 3... M@c3
4. S@b1 {X wins}


A game of Four Field Kono with automatic setup:


GameType: Four Field Kono

1. b1:b3 1... d3:b3 2. c1:c3 2... a3:c3 3. c2-c1 3... b4:b2 4. a1-b1 4... b3:b1
5. d1:b1 5... c3-c2 6. a2-a3 6... b2:d2 7. a3-b3 7... c4-c3 8. c1-d1 8... d4-d3
9. b1-b2 9... d2:b2 10. b3-a3 10... b2-b1 {Player 1's loss is assured with the
separation of their two remaining pieces and they should resign in a real game}
11. a3-a2 11... b1-c1 12. d1-d2 12... c1-d1 13. a2-a3 13... a4-b4
14. a3-a4 14... b4-c4 15. a4-b4 15... c4-d4 16. b4-a4 16... d4:d2 {Player 2 wins}
3 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Anika Henke
msg tools
trevorld wrote:
(not sure why BoardGameGeek seems to be replacing - and d with smileys in code field)

You can tick the "Disable emoticons" checkbox when editing the post to prevent that.

This looks great, thanks for moving this forward. I've only skimmed things but will look at the proposed syntax properly on the weekend. That you've already written a working parser is amazing!
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Trevor Davis
msg tools
selfthinker wrote:

You can tick the "Disable emoticons" checkbox when editing the post to prevent that.

Thanks for that tip (which I've now selected).
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls