Ludii Forum
Stacks - Printable Version

+- Ludii Forum (https://ludii.games/forums)
+-- Forum: Questions (https://ludii.games/forums/forumdisplay.php?fid=13)
+--- Forum: About Ludii (https://ludii.games/forums/forumdisplay.php?fid=14)
+--- Thread: Stacks (/showthread.php?tid=221)

Pages: 1 2


Stacks - slimy_asparagus - 10-28-2020

All the Ludii documentation I can find is quite hard to follow. And looking at examples only goes so far. Therefore I cannot really get a sense of Ludii's capabilities in some areas.

For example suppose I have a game where the pieces have a different symbol top and bottom and can be flipped. There is no capture but pieces can stack arbitrarily, whilst retaining their identity as separate pieces. Can Ludii handle the following:

1. Can I move a piece onto the top of a neighbouring stack? (I am sure the answer is yes, but I include the question for completeness.)
2. Can I move an opponent's piece from the middle of  a stack to the bottom of a neighbouring stack?
3. Can I flip an entire stack upside down?
4. What capabilities would Ludii ave with regards to representing such a stack?

Thank you.


RE: Stacks - Eric Piette - 10-28-2020

Hi,

1. Yes, you have a stack parameter in some move ludemes such as (move ...) (fromTo ...) (step ...) to move on the top of a stack.

2. I never tried and we do not have game with that. But if you know the level of the "middle" yes you should do that.
In the ludeme (move (from <YOURSITES> level:FROMLEVEL) (to (sites Around (from)) level:0))). Should do what you except.

3. We have a ludeme (flip ...) to flip a single piece, that ludeme will flip a full stack in the future, I do not have implemented that yet.

4. Not sure to understand the question here. You mean a stack of pieces with two faces? That will be just a normal stack and in each piece you will have to define the (flips ...) state values. You can look Reversi for an example using these flips values.

Regards,
Eric


RE: Stacks - slimy_asparagus - 10-28-2020

(10-28-2020, 03:48 PM)Eric Piette Wrote: Hi,

1. Yes, you have a stack parameter in some move ludemes such as (move ...) (fromTo ...) (step ...) to move on the top of a stack.

2. I never tried and we do not have game with that. But if you know the level of the "middle" yes you should do that.
In the ludeme (move (from <YOURSITES> level:FROMLEVEL) (to (sites Around (from)) level:0))). Should do what you except.

3. We have a ludeme (flip ...) to flip a single piece, that ludeme will flip a full stack in the future, I do not have implemented that yet.

4. Not sure to understand the question here. You mean a stack of pieces with two faces? That will be just a normal stack and in each piece you will have to define the (flips ...) state values. You can look Reversi for an example using these flips values.

Regards,
Eric


Thanks. That is quite helpful.

Specifically with regard to the "flip" ludeme. I take it from the lower case (and from what I read) that is a built-in and not defined. As such I would just have to wait for that to be available.

With regards to my last question, I am asking is there something a "stack viewer" like you have in VASSAL?

I was looking at implementing this in Zillions. I have not come across any impossible barrier yet but it is definitely hard work there too.


RE: Stacks - slimy_asparagus - 10-31-2020

Okay I am beginning to make some progress. I have attached the latest and best code.

Now you can do the following:

1. Player 1 moves its piece onto the board.
2. Player 2 moves its piece onto the board (next to player 1's piece).
3. Player 1 moves its piece onto the top of player 2's piece.
4. Player 2 now tries to move its piece.

This is where things get stuck. Player 2 picks up player 1's piece rather than its own. This should not be happening. (I had a scenario where this could but that is a long way down the road.)

Also I don't understand why I need to have ("MoveWithinBoard") in the piece description but ("MoveOntoBoard") in the play rules.


RE: Stacks - Eric Piette - 11-02-2020

Hi,

your define "MoveWithinBoard" using a step move needs to know from where you can step. That is expressed by the (from) ludeme. However that ludeme needs to iterate each piece. That's what is doing by (forEach Piece). That ludeme described like that refers to each piece owned by the mover and look where they are placed to compute the moves described in each piece in modifying the value of (from) by the place of the piece. That's why the moves description of that ludeme should be at a piece level. However, that's also possible to put that description directly in the play rules in doing (forEach Piece "MoveWithinBoard").
But that's better to describe the moves belonging to a piece directly in the description of the piece in our opinion.

The other define "MoveOntoBoard" refers from a set of sites to another. Consequently the moves do not belong to a specific pieces and is better to be directly in the playing rules rather than the pieces themselves.
Minor remark about it, you currently does not check if some pieces are still in the hand of the mover. Consequently that's possible to move from an empty sites to any outer sites.
A more accurate description can be:
(move
(from (sites Occupied by:Mover container:(mover)))
(to (sites Outer))
)

Another minor comment is for
(hand Each size:1)

the "size:1" is the default parameter, consequently just (hand Each) is enough.

Concerning that "Player 2 picks up player 1's piece rather than its own." I am not sure of what should happen in that game, but if you can put your piece on top of an enemy piece and then be able to move that stack only if the top piece is to you you can use (forEach Piece top:true).

Regards,
Eric


RE: Stacks - slimy_asparagus - 11-02-2020

(11-02-2020, 09:15 AM)Eric Piette Wrote: Hi,

Thanks for your response.


(11-02-2020, 09:15 AM)Eric Piette Wrote: your define "MoveWithinBoard" using a step move needs to know from where you can step. That is expressed by the (from) ludeme. However that ludeme needs to iterate each piece. That's what is doing by (forEach Piece). That ludeme described like that refers to each piece owned by the mover and look where they are placed to compute the moves described in each piece in modifying the value of (from) by the place of the piece. That's why the moves description of that ludeme should be at a piece level. However, that's also possible to put that description directly in the play rules in doing (forEach Piece "MoveWithinBoard").
But that's better to describe the moves belonging to a piece directly in the description of the piece in our opinion.

The other define "MoveOntoBoard" refers from a set of sites to another. Consequently the moves do not belong to a specific pieces and is better to be directly in the playing rules rather than the pieces themselves.
Thanks again. So what I understand is that "MoveOntoBoard" cannot be defined inside the pieces definition (as it would need to be in Zillions).


Is it possible to define "MoveWithinBoard" inside the "play" section? I can understand if this is less than ideal from your point of view. However I am getting the impression that the language is fairly fragile, and that as I try to express the rules of the game I will arrive at a point where it cannot be done in the piece definition because of X and cannot be done inside the play definition because of Y.


(11-02-2020, 09:15 AM)Eric Piette Wrote: Minor remark about it, you currently does not check if some pieces are still in the hand of the mover. Consequently that's possible to move from an empty sites to any outer sites.
I am not sure I understand this comment. Surely this would just resolve to a non-possibility?


(11-02-2020, 09:15 AM)Eric Piette Wrote: A more accurate description can be:
    (move
        (from (sites Occupied by:Mover container:(mover)))
        (to (sites Outer))
    )
Okay, I don't see how this addresses the point you raised above. Surely this just says "Any piece can be moved from whereever it happens to be to anywhere on the edge of the board." How would this help me define "MovesOntoBoard"? Surely it would entirely break it?


(11-02-2020, 09:15 AM)Eric Piette Wrote: Another minor comment is for
(hand Each size:1)

the "size:1" is the default parameter, consequently just (hand Each) is enough.

That piece of code is a placeholder for "(hand Each size:2)". So I would rather leave it as it is.
(11-02-2020, 09:15 AM)Eric Piette Wrote: Concerning that "Player 2 picks up player 1's piece rather than its own." I am not sure of what should happen in that game, but if you can put your piece on top of an enemy piece and then be able to move that stack only if the top piece is to you you can use (forEach Piece top:true).
In terms of what I am trying to do that is both correct and incorrect.

It is incorrect, because I am focussing only on certain aspects of the game. If I could totally achieve my goals for this stage it certainly would not be a very interesting game. And in particular for what I am trying at this stage the top piece in no way inhibits the movement of any piece of the stack. Perhaps it is better to describe it not as a stacking game, but as a 3D-game where a piece falls to the lowest possible level. (Except that the stack concept is more helpful for some of the other rules.)

However it was correct in that I guess about 60-70% of the time the top piece does inhibit the movement of opponents pieces below. But I am not trying to express that just yet, because I would need to increase the handsize to 2 and start differentiating the pieces and so on. And my goal at the moment is to get stacking right before I worry about anything else. I am guessing that the thing Ludii is most likely to let me down on are my stacking requirements. So I want to do that before I attempt anything else.


RE: Stacks - slimy_asparagus - 11-14-2020

So  I noticed the documentation on game logic and I appreciate that.



It has made me give it my best shot.



What I need to specify what I am trying to do at this stage (it does include some placeholders) is that "MoveWithinBoard" means:



You can move a "Cross" piece you own from a space it occupies on the board to a neighbouring space on the outer edge.



I have tried to express this with:

Code:
(define "MoveWithinBoard" 
    (move         
    from (sites Occupied by:Mover) if:(is In (to) (sites Hand Mover)) level:(level))     
   (to (sites Outer) if:(= (range (from) (to)) 1))     
   )
)

I also moved the usage to rules section. However I get the following compile error:

Code:
Empty substring from '(move (from (site...'. Maybe a wrong bracket type '}'?



RE: Stacks - slimy_asparagus - 11-14-2020

Okay by studying the formal grammar I managed to make some small progress. It still does not compile though. The error is now:

Code:
Unexpected syntax '(range (from) (to))' in 'if:(= (range (from) (to)) 1)'.

I attach the file.


RE: Stacks - Eric Piette - 11-16-2020

Hi,

(range) is a RangeFunction and can not be used like that but only in the ludeme waiting for such ludemes. You can look the grammar to know what is excepted by each ludeme for such bug.

I looked in more details what you try to do with the condition about the range but I do not understand. Can you explain it in plain English here in order for me to help you?

Regards,
Eric


RE: Stacks - slimy_asparagus - 11-16-2020

(11-16-2020, 08:55 AM)Eric Piette Wrote: Hi,

(range) is a RangeFunction and can not be used like that but only in the ludeme waiting for such ludemes. You can look the grammar to know what is excepted by each ludeme for such bug.

I looked in more details what you try to do with the condition about the range but I do not understand. Can you explain it in plain English here in order for me to help you?

Regards,
Eric


I am afraid of XY communication problem here.

So to be clear the "Y" problem here is I am trying to restructure my syntax to see if that helps my "X" problem. Specifically I wonder if I can express "move Step " using the "move <from> <to>" syntax.

The "X" problem is how do I make a player move the piece from a stack that is a.) one of their pieces and b.) a piece of their choice. (I admit with only 1 piece each b.) is redundant but it will be relevant in the future. ) At the moment it (as described earlier in the thread) moves the top piece even though that belongs to the opponent.