Step 1: Find Plans!
It's Wednesday, and time for me to sit down and officially get both ready started on implementing Spoons for Volity. (This is also known as getting your act together.)
Because Volity games involves users connecting to a server, a game developer needs to write two separate pieces of software for a Volity game. One piece of software runs on the user's machine to create the game window and is usually called the user interface, or UI; the other piece is called the referee and runs on the server and runs the actual game. Both of these pieces of software plug into other pieces of software which do the heavy lifting for you, allowing you to focus on the important parts: the user interface, and the logic behind the game.
The architecture which does this is smartly designed and works well for the casual user, but does pitch a few curveballs at the casual developer. Most notable among these is the fact that while the user interface is put together using a XML-based technology very similar to HTML+JavaScript (though better suited to graphically -oriented layout), the referee must currently be written in either Perl or Python. This is very nearly the programmer's equivalent to the separation of church and state; you must be platform-agnostic to some degree to fit in well in the Volity universe, regardless of whether you're more comfortable with the client side or the server side coding.
So, step 1 in any volity project (I'll cover step 0 - getting your computer set up for development - in another admittedly out-of-sequence post) is to figure out three things: what the user interface needs to do, what the referee needs to do, and how the two of them need to communicate. These three things will vary depending on the rules of the game you're implementing, as they will essentially be modeling the play (in the UI) and the rules (in the referee) as well as the interaction between the two.
So, to plan out how the game of Spoons is going to be developed, we need to figure out how to model the play from the player's perspective, and we also need to model the interactions between players that the rules prescribe.
From the player's perspective the play is not at all complicated. The player is dealt a starting hand of four cards, from a deck with four identical number cards for each player. With this hand, the player alternates between passing a card to the player on his/her right, and picking up the card passed by the player on his/her left. Turns do not exist, so a player can pass a card as long as the player to the right has received it, and can pick up card any time after the the player to the left has passed it. When the player has four of a kind he/she can grab a spoon out of the pile, at which point all other players must attempt to grab a spoon. The player left without a spoon gets a mark against him or her; when the player has reached the prescribed number of marks, that player is out of the game. A player may also bluff by grabbing a spoon without four of a kind, but if that player doesn't let go of the spoon quickly enough, he or she may regret it: if all the spoons are grabbed but no-one has four of a kind, everyone except the player without a spoon gets a mark. The last player not eliminated wins.
Okay, that's a nice brief rule set (at least compared to Puerto Rico or Settlers of Cataan), and it gives us a fairly basic set of possible moves to send to the referee:
This does mean, however, that the referee in this case has a fair amount to keep track of: the hands each player holds, the cards being passed from one player to another, and who has grabbed a spoon and who hasn't. Each player's move will change the game status for two of the players (passing cards) or all players (grabbing a spoon or letting go of it), and the changes will occur in no predictable order. As a well-designed Volity UI should allow for a whole-board redraw at any point in the game anyway (to facilitate people who come in late to watch, or start sharing a seat with a player halfway through a round), it makes a certain amount of sense to have the player expect a single whole-board update from the referee rather than separate updates for the cards and the spoons.
So, we have an early architecture mapped out: in addition to the standard plumbing for joining, leaving, and pausing games, we need to have the UI be able to tell the referee that the user is passing a card, that the user is receiving a passed card, that the user is taking a spoon, and that the user is putting a spoon back, and we need to have the referee be able to tell the UI the current state of the table so that the UI can re-draw the table to reflect the current state of the game. The mechanisms used for the UI to tell the referee to perform a players move and for the referee to tell the UI to redraw the current game are called Remote Procedure Calls (or RPC's for short) in the Volity documentation. The software frameworks supporting both the UI and the referee handle the gory details of this, but the programs will still need to send the RPCs at the appropriate time.
So, now we know where we're going. Tune in in future weeks for Steps 0, 2, and beyond.
Because Volity games involves users connecting to a server, a game developer needs to write two separate pieces of software for a Volity game. One piece of software runs on the user's machine to create the game window and is usually called the user interface, or UI; the other piece is called the referee and runs on the server and runs the actual game. Both of these pieces of software plug into other pieces of software which do the heavy lifting for you, allowing you to focus on the important parts: the user interface, and the logic behind the game.
The architecture which does this is smartly designed and works well for the casual user, but does pitch a few curveballs at the casual developer. Most notable among these is the fact that while the user interface is put together using a XML-based technology very similar to HTML+JavaScript (though better suited to graphically -oriented layout), the referee must currently be written in either Perl or Python. This is very nearly the programmer's equivalent to the separation of church and state; you must be platform-agnostic to some degree to fit in well in the Volity universe, regardless of whether you're more comfortable with the client side or the server side coding.
So, step 1 in any volity project (I'll cover step 0 - getting your computer set up for development - in another admittedly out-of-sequence post) is to figure out three things: what the user interface needs to do, what the referee needs to do, and how the two of them need to communicate. These three things will vary depending on the rules of the game you're implementing, as they will essentially be modeling the play (in the UI) and the rules (in the referee) as well as the interaction between the two.
So, to plan out how the game of Spoons is going to be developed, we need to figure out how to model the play from the player's perspective, and we also need to model the interactions between players that the rules prescribe.
From the player's perspective the play is not at all complicated. The player is dealt a starting hand of four cards, from a deck with four identical number cards for each player. With this hand, the player alternates between passing a card to the player on his/her right, and picking up the card passed by the player on his/her left. Turns do not exist, so a player can pass a card as long as the player to the right has received it, and can pick up card any time after the the player to the left has passed it. When the player has four of a kind he/she can grab a spoon out of the pile, at which point all other players must attempt to grab a spoon. The player left without a spoon gets a mark against him or her; when the player has reached the prescribed number of marks, that player is out of the game. A player may also bluff by grabbing a spoon without four of a kind, but if that player doesn't let go of the spoon quickly enough, he or she may regret it: if all the spoons are grabbed but no-one has four of a kind, everyone except the player without a spoon gets a mark. The last player not eliminated wins.
Okay, that's a nice brief rule set (at least compared to Puerto Rico or Settlers of Cataan), and it gives us a fairly basic set of possible moves to send to the referee:
- Pass a card. This is allowed when the game is in play, and the player the card is passed to does not have any passed cards that have not been picked up, and there or no cards waiting that have been passed to the player.
- Pick up a card. This is allowed when the game is in play, and the player has three cards, rather than the usual four, in his or her hand (which will happen every time a card is passed out of the player's hand).
- Grab a spoon. This is allowed when the game is in play, there are spoons remaining, and the player does not already have a spoon.
- Let go of a spoon. This is allowed when the game is in play, and the player already has a spoon.
This does mean, however, that the referee in this case has a fair amount to keep track of: the hands each player holds, the cards being passed from one player to another, and who has grabbed a spoon and who hasn't. Each player's move will change the game status for two of the players (passing cards) or all players (grabbing a spoon or letting go of it), and the changes will occur in no predictable order. As a well-designed Volity UI should allow for a whole-board redraw at any point in the game anyway (to facilitate people who come in late to watch, or start sharing a seat with a player halfway through a round), it makes a certain amount of sense to have the player expect a single whole-board update from the referee rather than separate updates for the cards and the spoons.
So, we have an early architecture mapped out: in addition to the standard plumbing for joining, leaving, and pausing games, we need to have the UI be able to tell the referee that the user is passing a card, that the user is receiving a passed card, that the user is taking a spoon, and that the user is putting a spoon back, and we need to have the referee be able to tell the UI the current state of the table so that the UI can re-draw the table to reflect the current state of the game. The mechanisms used for the UI to tell the referee to perform a players move and for the referee to tell the UI to redraw the current game are called Remote Procedure Calls (or RPC's for short) in the Volity documentation. The software frameworks supporting both the UI and the referee handle the gory details of this, but the programs will still need to send the RPCs at the appropriate time.
So, now we know where we're going. Tune in in future weeks for Steps 0, 2, and beyond.
posted by Craig K | 10:38 PM
|
0 comments
