Page: Guide.ModelingDesign31 - Last Modified : Mon, 29 Sep 14 - 1642 Visits

There is a theoretical approach in object oriented programming called the model-view-controller (MVC) approach. The basic idea is that a software would have 3 types of objects:

• Model: These are data objects like those we have been working so far.
• View: These are object who's job is to display data from data objects to the user.
• Controller: These are object that should handle operation and behavior of other objects.

Personally, I like it when all objects are self contained and can do all 3 functions. Which means hold data, know how to display themselves and manage operation that can be done on themselves.

In this page we will talk more about the theoretic concepts of applying MVC to board games, you'll be able to see them in action in my game example later.

Model

We have talked a lot about data already in the relational database page I won't repeat it here. Now it's time to see how it can be transposed in board games. First be should define objects and define how they are related to each other (ex: ship are contained in fleets which can be docked in a base). Second we should start by listing the properties and variables we want our objects to have. Then we can take each variable determine which type it will be (Text, number, etc), and if it is going to be a fixed for variable value. This will have some impact on the type of component we will use like explained in the view section.

For board games, the less the values are variable the better it is since printed values remains as they are on cards and tokens. Making values variable generally require additional components and game space to keep track of them (Ex: dice, tokens, tracks). So we should only keep variables that really matter for our game. Another solution is to move variables. For example, keeping track of experience level for individual ships will be too complicated and a bit pointless. So instead, I decided to move the experience level to the fleet object. Now I only need to keep track of 1 value for the whole fleet instead of one value per ship. Else you can simply remove values or abstract them with other concepts.

View

The difference with board games and video games is that objects can only be displayed in one way while in video games, objects can be displayed in multiple ways. Here is an example from master of Orion 2 where a colony information can be displayed in detail, or as a list of multiple colonies.

Detailed Colony Display	Colony List Display

But in a board game, if your monster is displayed on a card, it cannot also be displayed in another way. In fact, it's not entirely true, you could have a list of all monsters in the game as a reference sheet to know what's in the game. But if you wanted to have a list of monster actually in play using tokens to complement the cards you would handle 2 different view, but now you need to do synchronization. Which means if a monsters gets damaged, you need to update that information on the list of tokens too which is not really convenient.

The the best solution is to only chose 1 view per concept. So each object should have 1 component where the information is displayed. It could be possible the split the information on multiple components, without duplicating the information. For example, my fleet object could have a dash board to keep track of experience, fuel, Morale, while have another board where ships can be placed in formation. In this case, the fleet information is on 2 different components, but no information is duplicated.

Once component are chosen, you need to decide how the information will be displayed: icons, numbers, keywords. Depending on your game, sometimes icons could be easier to read or take less space. You then need to decide where the information is going to be displayed on your components. Define the size of your components, and see where you can fit your information. Sometime the component size are restricted. For example, there are various card size standards that you'll probably want to use for your game. Decide which size fits best for you, no need to design your own. If you are using for example "The Game Crafters" you might want to check what components are available there.

Controller

For board games, the controller aspect is the rules related to the object or the actions the object could do. In computer software, you can sometimes see this by right clicking objects, like a file, which shows you everything you can do with that file.

We could try to define our game object this way by listing actions it can do. Let try it for a ship:

• Attack: Roll dice and compare value to hit target
• Damaged: What happens when you get damaged. Take damage tokens and if equal to hull the ship sinks.
• Repair: Can only done in a port with repair docks, it takes 1 week or month to remove 1 damage token.
• Formation: Ships can be moved around on the formation board, count as a free action during movement.

There are also common behavior to all objects known as constructor and destructor in programming:

• Create: What happens or how is a ship created. In my case, ship can appear in shops for purchase. But japanese ships can appear in the game as an encounter event, or be added to one of the main fleet.
• Destroy: What happens when a ship is destroyed. An non-japanese ship is returned to the drawing stack/bag, a Japanese fleet is returned on the turn track and will come back later.

Simply take a look at all the data your ship object has and try to determine the rules that are required to handle that data. One thing missing from the list above is that ships attacks in a specific order according to their weapon type. Knowing this I can leave a note so that when I design the combat turn order, I do not forget it.

By taking all objects and defining behavior, it will setup most of the game's rules but there will still be a few holes here and there that we will patch up. What I can see so far is the order of play which will tell when the actions above can be used. But order of play can also have some upkeep phases that will affect many object in the game. Most of the time it will call the object actions listed above.

<< Object Oriented development | Table of contents | Turn Sequence and Work Flow >>