Forums: Volity programming with Python

I decided to try to implement a volity version of the game Quarto [1] and Lineo [2] (but with a very different, simpler 2D interface).

During my years of university, I programed in Pascal, scheme and ADA. I also played with C and Eiffel for myself, and PHP for a personal site. After a lot of reflexion, I finally choosed Python for the referee part, I hope it's a good choice.

For the UI part, I just played a little with JavaScript. I'm comfortable with XML and I defined for testing some elements of my future UI: I think SVG won't be a big problem.

Before really programing that game (wich is a big project for me), I wrote a first draft of the RPC calls, and I want to know your opinion, advices and criticisms about it.

from-Referee-to-Clie­nt RPCs

must_give_piece(seat­)

received_piece(seat,­north, south, east, west)

must_put_piece(seat)

put_piece(pos, north, south, east, west)

false_win(seat, direction, feature)

must_end(seat)

win(seat, pos, direction, feature)

tie()

from-Player-to-Refer­ee RPCs

give_piece(north, south, east, west)

put_piece(pos)

think_win(direction,­feature)

end()

EXPLANATIONS :

0) Each pieces have four boolean features, which are east, north, west and south (a structure with the four features instead?). Pos is a number between 0 and 15 (like in the tic-tac-toe example).

1) Between minimizing the communication Referee<->Client and never doing the same thing twice, I choosed the second. Is it a good choice ? (For example, After puting a piece, the UI can deduce his player must now give a piece, but the referee already (and must) know that, so instead I create the must_put_piece call)

2) There's no begin(seat) call, because must_give_piece(seat­) can do that. If UI send bad received_piece or put_piece calls, the referee can send again the must_give_piece or must_put_piece calls.

3) The primeval rules say "if a player has not noticed the alignment and passes a piece to the opponent, the later may indicate the alignment". For me it's an important and very useful (I know what I mean :)) subtle, so I create the calls: think_win and false_win (you don't want your adversary know your error;)). And for the last turn, the must_end and end calls. (it doesn't prevent this possible variant for beginners: the computer detects automatically the victorious alignment)

4) Those rules also say "if none of the players sees the alignment during the move during which it is created, it loses any value and the game continue", that's why the think_win call only ask for one direction (vertical or horizontal) and one feature (east, north, west or south), wich are relatives to the last put piece.

5) a possible (in a distant future) variant for advanced players: create line or SQUARE of 4 pieces (with at least one common feature). In the think_win(direction,­feature), we can extend the direction value with: left-up, left-down, right-up and right-down.

Finaly, my less bad idea for a name is Quadruple (it's the same word in french and in english).

So, what do you think about all that thing?

[1]http://en.wikipedia.­org/wiki/Quarto_(boa­rd_game) [2]http://en.wikipedia.­org/wiki/Linéo

I'll just quickly respond to a couple of points.

1) I'd say you made the right choice here. It's better to have the referee keep all of the state, because then if the client crashes, or has their network cut, they can just rejoin and be fully updated. Also, then you have to do less work in the client :)

2) looks good too.

3) Instead of using a separate RPC call for false_win, you could instead use an RPC response that the referee would send back if the client sent an incorrect winning solution. It could be just like playing a piece in an already occupied location, or choosing a piece that has been played.

I don't understand the must_end() and end() calls. Can the last turn not be handled just like any other turn? I may not understand the game entirely, though.

4) What about diagonal lines? Are they allowed?

5) It might be a solution to have the client totally spell out the winning line (or shape) in an array of positions, and have the referee verify that the solution involves the last-played piece. Example: think_win(feature, positions). That would be a little more complex to program, but more flexible for the furure. Hopefully you wouldn't have to change the RPC calls when you implement the advanced player options.

Anyway, just some thoughts. In general it looks good :) Looks like a cool game, too. I'm looking forward to helping test and play it (though see my other post that I'm about to make for info on my availability)

I'm sure jmac will chime in at some point too, given some time.

> "3) Instead of using a separate RPC call for false_win, you could instead use an RPC response that the referee would send back if the client sent an incorrect winning solution. It could be just like playing a piece in an already occupied location, or choosing a piece that has been played."

If I understood, an RPC response is only for the client wich sent the RPC, but the false_win call will be sent to the two players, sothat the other player know your mistakes (it's important from a psychological point of view ;)).

> "I don't understand the must_end() and end() calls. Can the last turn not be handled just like any other turn? I may not understand the game entirely, though."

During the game, after giving a piece, it's too late to use the think_win call, and the other player can use it. But at the last turn, you put the last piece on the board and give nothing to the other. The must_end() and end() calls enable the other player to use the think_win call for the last time. I don't find a way to avoid those calls wich are useful only at the end :(

> "4) What about diagonal lines? Are they allowed?"

Ouch, I forgot the diagonal lines! Luckily, I can say that the direction can be vertical, horizontal or diagonal in the think_win call, and change nothing else.

> "5) It might be a solution to have the client totally spell out the winning line (or shape) in an array of positions, and have the referee verify that the solution involves the last-played piece. Example: think_win(feature, positions). That would be a little more complex to program, but more flexible for the furure. Hopefully you wouldn't have to change the RPC calls when you implement the advanced player options."

Two thoughts about that suggestion:

1) you talk about winning "shape", I'm afraid you imagined crazy variants with funny shapes like in tetris ;)

2) More seriously, I also can use an array of four booleans instead of east, north, west and south: wich is the best way?

> "though see my other post that I'm about to make for info on my availability"

Thanks for your very useful response. I'm now waiting for the happy piece of news :)

SECOND DRAFT

piece is an array of 4 booleans

position is an integer between 0 and 15 (like in the tic-tac-toe example)

feature is an integer between 0 and 3

positions is an array of 4 positions

from-Referee-to-Clie­nt RPCs

must_give_piece(seat­)

received_piece(seat, piece)

must_put_piece(seat)

piece_on_board(piece­, position)

false_win(seat, feature, positions)

must_end(seat)

win(seat, position, feature, positions)

tie()

from-Player-to-Refer­ee RPCs

give_piece(piece)

put_piece(position)

think_win(feature, directions)

end()

EXPLANATIONS

1) Austin gave me (voluntarily or unvoluntarily?) an insane idea : why not play with three or five features? We have 2^3=8 pieces or 2^5=32 pieces, so we can't use a nxn board. But after a little reflection, I found it's possible with unconventional boards and unconventional victorious shapes.

For the moment (and perhaps for ever), I'm not interested in exploring that way, but those RPC calls seems now to be compatible with such an extension (if I correctly understood, an RPC's array can be dynamic), so I will leave the door opened for anybody who will be interested.

2) I still don't find a way to avoid the must_end() and end() calls, any idea?

A warning: you can't put information in the RPC replies that the referee sends back (to UI RPCs). That is, you can put information there, but the UI can't receive it. This is a long-standing feature request, but we seem to never really need it, so I've never gotten around to it.

Thanks for that very important warning.

I think I found an elegant way to take into account the necessity for the players to notify themselves their victory (and now without must_end() and end()). the new RPC calls are simpler, but it's too long to explain why it works...

Now I think I can begin to program, but I will have a lot of works for three weeks, so don't expect news about my project very soon.