Page: Guide.ModelingDesign21 - Last Modified : Thu, 25 Sep 14 - 1621 Visits

Let start our crash course with Relation databases. I know that there are many web sites that will explain in details how Relational databases works. But it might be hard to find the right web site for your level of knowledge. It might also talks about things that you might not necessarily need for the board game design method I am exploring. So I decided to make my own (More work for me).

As I previously said, I won't go into all the details, if you want to do so, go find another website after reading this page. Now relational database will change your way of life and the way you percieve information. Once you know how they work, every time you see somebody use Excel, you'll say that it could be more easily done in Access ... which is true.

I often propose access as Database software, not because it is the best, but because that is what people have (Most people have MS Office). I have developped many applications in Access at work and it seems to do the job pretty well. It's not perfect, but it works. So one thing you could use in your learning is MS Access, or the open source alternative like Libre Office Base or Kexi for those running linux. There are other software available that I have not explored yet which could also do the job.

Now, we don't necessarily need a software to model a database, it can be done on paper but if you want to make it look nice, or want to design a real application without much coding, it's better to use a software. In my case, i'll use one to make better screen shots.

Organisation of Data

Relational Databases are a way to organise information so that it could be read by a computer. Informations are stored in a table which looks like a spread sheet. But the difference is that the number of columns never changes unless you want to add or remove features to your database. Else adding new data will never require adding fields to a table, if you need to do this, then you have a wrong design.

A computer manage each entry one at a time, and he expect a specific number of fields of different type. If the number of field was variable, it could require recoding all the time.For example, let say I want to hold data about a fleet and it's ship, I cannot do it like this:

Fleet Table

Fleet Name	Ship1 Name	Ship2 Name	Ship3 Name
Main Fleet	Jimmy	Jack	Joey

Because if I want to add a 4th ship that would require adding an extra column which is illegal. Instead, fleets and ships will be placed into separate tables and linked together through a primary and foreigh key.

Fleet table

PK	Fleet Name
1	Main Fleet
2	Side Fleet

Ship Table

PK	Ship Name	FK_Fleet
1	Jimmy	1
2	Jack	1
3	Joey	1
4	Jerry	2

Here PK stand for "primary key" and both fleet and table have a key of their own. FK stand for Foreign key which in this case FK_fleet is linked to the primary key of fleet.

So in this case, to know which ship belongs to which fleet, you use the fleet PK and you take all the ships that has the same FK_Fleet number. In the example above, the main fleet has 3 ships, and the side fleet 1 ship. We could add thousands of ships to any of those fleets without any need to add new columns to the tables.

Data Type

Each field of a table has to be of a specific data type. This will help the computer interpret the information. In the end, all information is stored as a byte, which is a series of 8 ones or zeroes. That series of bit can be reinterpreted as a character,as a number or as a date. So it's important that the computer know how to display that information.

Now you might say that in board games, information does not need to be displayed by a computer, which is true. But information could be displayed differently. For example, you could use numbers, but you could also express that number in a series of icons. We will talk more about that later in this guide.

For now let stick to data types commonly found in common database. Here are a few database examples:

• SQLite: Text, Integer, Blob
• MS Access: Text, Memo, Numeric, Date, Currency, AutoNumber, Boolean, OLE Object, URL.
• MySQL: INT, TINYINT, SMALLINT, MEDIUMINT, BIGINT, FLOAT, DOUBLE, DECIMAL, DATE, DATETIME, TIMESTAMP, TIME, YEAR, CHAR, VARCHAR, BLOB, TINYBLOB, MEDIUMBLOB, LONGBLOB, ENUM

This is just to give you an board idea of what data types could be. We are not going to use all of them for a board game design. Here is a list of things that we will possibly use.

• Text: Text is used in board games for component's name or title but also for special rule text or flavor text.
• Number: Numbers are also an important data type in board games. Since we are humans, we'll make no distinction between integers and floating point numbers, so we can all group them as numbers.
• Images: This data type is normally more aesthetic but it could happen that the game rules depends on pictural information. For example in pattern matching. A game like Tsuro.
• Date: We might not use complete dates, but many games, especially war game, can keep track of months or year instead of turns. It's very similar to numbers, but it has a different meaning, and indirectly has a different behavior. For example, when the 12th month is over, you start over to the 1st month and increment the year.
• Boolean: This is basically a yes/no value. Or is a property true or false, like a flag on a mailbox.
• Enumeration: This is a variable that could take a specific list of values. This is wonderful for types components. For example, in Magic the gathering, you have various type of cards: lands, Enchantments, Instants, Summon, Sorcery, etc. So a card type can only take one of the following listed value and nothing else. This is what enums are used for.

Another aspect I will add are constants. In computer software, changing the value of a variables is a piece of cake. In board games, it is much more complicated because you need the necessary components to keep track of that modified information. On the other hand, constant information is the most common type of information, since once it's printed on a card, it remains at it is. So for each variable in the table, you should be able to determine if the value is fixed or variable.

Here is a fictional example of table definition for ships.

Field Name	Data Type	Constant
Name	Text	Constant
Attack	Number	Constant
Hull	Number	Constant
Damage	Number	Variable
Class	Enumeration	Constant
Experience	Number	Variable
Entry Year	Date	Constant

So this is just an example to give you an idea of how it could be used. Damage received and Experience level of the ship is the only variable elements of the ship. Everything else could simply be printed on tokens or cards. Class is an enumeration for various types of ships like Destroyer, Cruiser, Battleship, etc. The entry year could be a regular number, but in that case it has an additional meaning of being a date not just any number.

<< Expectations and Drawbacks | Table of contents | Object Oriented development >>