Getting the Game Going

For the game of 36, the first thing that needs to be created is a player class that will be used for each player in the game. This will be used both to control the player's game play and to act as a score card. While the game will support up to 6 players, each player has to be tracked separately. As I have screen real estate to deal with, I decide that each player score card could only be 75 pixels high but could take up the entire 640 pixel width. This width would then be divided into 3 sections. The label section where the player identifier and overall score would be is on the left. In the larger middle section would be the roll history. Finally, the right side of the screen would contain the user interface and the total score for this round of the game.

This is where the first problem came up. The thing that a lot of non-programmers don't understand about programming is that programming is not about writing code. The language that you use for programming is not really important, though you should choose a language that is appropriate for the task you are trying to accomplish. The important thing about programming is not the language the program is being written in, but that the problems be solved. Every project is really just a series of problems that need to be solved. The programmer's job is to figure out how to solve these problems within the constraints of the project. With that being said, what was this problem? The results area is suppose to show the previous rolls. The number of rolls in the game is anywhere from 5 to 36.

The easiest way of solving this problem would be to assume that there is going to be 36 rolls and just make the size of the displayed die the size needed to fit the 36 dice in the container. I don't like this solution because I want the dice to be as big as possible. For this reason my first job was working out the display system for showing the results of the earlier rolls. I wanted the display to adjust the dice size based on how many dice rolls had been made. The dice would start off really big. Once enough rolls were made, the dice would shrink to a middle size until two rows were filled. Finally, the dice would shrink again to the smallest size which would for sure hold all the dice needed. The advantage of this is that bigger dice are nicer looking and easier to read. The middle size would be the size that most players would need, while in the rare event that a player rolled a huge number of ones or twos the game could handle it. The dice look their best within the constraints and everything will fit nicely in the display.

The next step was to add the actual user interface. This is where things get a bit tricky. The game has to be controlled by an outside force because there are multiple players. That being said, each player is a separate entity so having the game controls within that player's box does make sense. The solution to this problem is to use player states that can be controlled by the outside force which we will call the manager. When the manager is ready for a player to take his or her turn, the manager simply tells the player to go into it's input state. When the player has made his move, an event is sent out so the manager, who should be listening for events, knows that it is time to move to the next player or determine the final results of the game. We don't want to have to code the manager right now so for now the manager is boiler plate code that assumes that it is always the player's turn. We will turn this simple manager into a real class later.

Figuring out the possible states that a player can be in is very simple. They can be waiting for their next turn, in their turn, have decided to stay in which case they get no more turns, or have taken too big of a chance and rolled over 36 in which case they are dead. Once all the players are staying or dead, there are two additional possibilities. They could have won the hand or they could have tied the hand. Each of these states are easy to set up as all that needs to be done is assign a frame label to each state then go to the appropriate frame when that state is activated. A bit of vector artwork (done in flash, though I suppose I could have used Illustrator) needed but nothing major.