ECE-1021

HOMEWORK #6B Solution Notes

(Last Mod: 27 November 2010 21:38:38 )

ECE-1021 Home


PROGRAM B - The Mancala Engine

The rules of the version of the game that will be used in the Course Project is available on the Course Project page.

The engine's design is based on a couple of key observations that arise from thinking of how a person might act as an intermediary between two people (who can't see or communicate with each other) who want to play a game of Mancala.

Imagining that I am acting as a "gamemaster" and have the master Mancala board in front of me (which I never let either of the players see or touch). The only information that I really need to know is where all of the pieces are on the board, whether the game is over, and, if not, whose turn it is.

My interaction with the players is very well defined. The only information I need to tell the player whose turn it is is where all of the pieces are on the board (which I can do by taking a picture of the board and sending it to them). The only information I need to get back from the player is the bin that they wish to sow.

Now, given this information from the player, I could go ahead and update the board and apply all the special rules, but in the true sense of modular programming, I will pass the master board off to a trusted party (that I'll call the "movemaker") who is responsible for actually executing the move. One advantage of this modularity is that almost all of the variations between different versions of the game only affect how an individual move is executed and hence I can easily support these different versions by simply having a different "movemaker" for each version.

Upon considering what information the movermaker needs in order to do their job it can be readily seen that they need to know where all of the pieces are on the board, which player is making a move, and what bin they have chosen to sow. I give them the first of these by giving them access to the master board so that they can actually modify it (and hence why the movemaker needs to be a "trusted" party). The other two items I simply pass as specific pieces of information.

In looking over the rules, it can be seen that I, as the gamemaster, don't need to know or care about whether capturing is allowed or whether the player drops a seed in their opponents kalaha or any of the other rules about how a move is executed. But I do need to know whether the player gets to go again since the movemaker has no way of contacting the player to see what their follow-on move is going to be - that is my job as the gamemaster.

In theory I could examine the board once the movemaker is done with it but this requires that I remember enough information about that status of the board before I passed it off to the movemaker in order to determine if the player gets to go again and, much worse, it requires that I know the specific rules for that specific version of the game in order to make this determination. But that defeats the whole purpose of hiring a movemaker in the first place! So I am going to insist that the movemaker be responsible for determining this and communicating it back to me. They can do this either by telling me which player gets to go next or they can do it by telling me if the player that just played gets to move again. As long as we are in agreement as to how this information will be communicated it makes little difference what method is chosen. Each method affects the implementation of the gamemaster's logic and so it might be reasonable to code it both ways and see with is better (however "better" is defined).

The gamemaster must also know when the game is over - but this is itself somewhat dependent on the specific version of the game that is being played and, hence, a determination that should be made by the movemaker and communicated back. Although the details of how the game is ended vary from version to version, they all agree that if neither of the players have any seeds in any of their six bins that the game is over. So we will have the movemaker be responsible for detecting the end of the game and moving all of the seeds still in play to the appropriate kalaha before returning control back to the gamemaster.

Another area of responsibility that must be assigned is that of detecting and enforcing illegal moves. In our version of the game, as well as all versions that I am aware of, the player may elect to sow any bin on their side of the board as long as that bin has seeds in it to sow. If we feel that this is what will constitute a legal move in all versions of the game we are going to support then it is reasonable to have the gamemaster be responsible for this. Otherwise we would need to assign it to the movemaker and devise a means for them to communicate it back.