Introduction
•
People like to play so we invented games and placed them on boards.
•
Now we can play against the computer or against human opponents
all over the world – or right next to us.
•
When we play against human opponents we want to have a ranking
that will show others how good we are.
•
Maybe it will scare opponents or we could just rub someone’s nose in
The Board Games
Business Process Game
•
Each game is different, but they do have things in common:
•
All of them have two players.
•
We know which player starts first.
Game Database Model Requirements in a Nutshell
•
The idea is to design a database model that would store all the data
related to a single game instance.
•
The game is played via website, while the database is used to store
information about players’ actions and success rates.
•
Our data model should cover all four previously‐mentioned board
games.
•
It would also be nice if it was flexible enough to cover additional
Players and Matches : Player
•
The
player
table is where we’ll store a list of all
our registered players.
•
All attributes in the table are mandatory.
•
The user_name and email attributes are the
alternate (unique) keys.
•
Only one player can use a username, and each
player’s email address must be unique.
•
We don’t want one person with multiple
Players and Matches: Player (cont’d)
• The nick_name attribute contains the user’s screen name; rating is based on the user’s results. For example, a player’s chess rating is calculated using the match result, with the player and opponent ratings factored in. Ratings change over time, so we cannot easily calculate our current rating based only on the results of our previous matches.
• If we wanted to create a site where a user plays a game and we don’t store any data, we wouldn’t need other tables. If we allowed people to play games without registering first, even the player table wouldn’t be necessary.
Players and Matches: Game
• The start_time attribute is mandatory and will be inserted at the beginning of the game. The end_time attribute will be filled in when the game ends, so we must leave it optional.
• All of our example games are for two players. For them, the max_number_of_players will always contain the value 2. Also, we’ll need to have two records for that game in the participant table before we start.
• Some board games can have different numbers of players. In this case, we will want to increase or decrease the maximum number of players that can join a single match.
Players and Matches: Game(cont’d)
•
In all four example games – as in most board
games – the board dimensions are fixed.
However, in some games it’s possible for the
player to choose a board size. It’s wise to
reserve an attribute for that purpose. The
reason
we’ve
chosen
the
varchar
type
for board_dimensions is to keep our model
flexible enough to store all possible notations
(e.g. 8x8, 5x5x5). We’re leaving the front end to
interpret it.
Players and Matches: Game(cont’d)
• The move_time_limit attribute is the timeframe each player has to make one move; game_time_limit is the total time that players have to finish the game.
• Both of them can be used to force players to move or to finish the match.
• For tic‐tac‐toe, checkers and Nine Men’s Morris, it’s important that players move within a reasonable time.
• Chess has a time limit for the whole game, but not for individual moves.
Players and Matches: Participant
• The participant table is where we’ll connect players and matches. The attributes player_id and game_id are references to the player and game tables. Together, they form the alternate (unique) key of the table.
Players and Matches: Participant
•
The
result
table is a simple dictionary storing all
possible endings.
•
For two‐player games, the set of values might
be: “player1 wins”, “player2 wins”, “player1
wins on time”, “player2 wins on time”, “player1
wins due to disconnection”, “player2 wins due
to disconnection”, “draw (agreed)” and “draw
(material)”.
•
For chess, we should add a few more options:
Pieces and Moves : Piece
• By placing game pieces, players can win or lose their match. But not all pieces function alike in every game.
• In some games, all pieces have the same abilities; the color of the
pieces determines which player owns them. That is the case for checkers and Nine Men’s Morris. Tic‐tac‐toe basically has a single piece of two different shapes (X and O) that may or may not be different colors. Chess, on the other hand, has 6 types of pieces in two colors. Piece descriptions are stored in the name attribute of the piece table.
• We can use the starting_position attribute to differentiate pieces of the same type when they move on the board. This data can also simplify analytics. Games like checkers and chess have defined starting positions; tic‐tac‐toe and Nine Men’s Morris will leave this attribute empty.
• In all four example games, the board is a 2D array (or matrix) and we
Pieces and Moves : Move
• The move table stores all the moves made during that game. The attributes game_id, piece_id, participant_id and move_type_id are references to the tables containing games, pieces, game participants, and move‐type data.
• The move_order attribute saves information about move order in the game. It starts at 1 and increases by 1 after every single move.
• The move_notation attribute exists only for certain games. In chess, it’s in a human‐readable format that enables us to recreate whole match. For example, Nf3 describes moving the knight to the f3 square. When players move game pieces, the resulting string is formatted so we can simply store it.
Pieces and Moves : move_type
• Now we know what piece is moved, where it started, and where it moved to. All the logic of the game is implemented on the front end, so these stored moves should be enough to simulate a match. The move_type dictionary is an add‐on to the model that gives us more information to simplify analytics.
• The idea is to have at least these two values: “placing element to a square” and “placing element to a square and taking opponent’s element”. In chess, for instance, the sequence of moves where players exchange pieces is crucial to determining the next stable state on the board. We can then analyze that state and conclude which player is in a better position.
