# How can I architecture the cards and boards of this board game?

I want to create a board game (at least it's structure and engine, not the graphics), and since It's the first time I do this I don't know where to start.

It's a turn based strategy card game where cards that act differently, some are placed and moved on the board, some are placed but don't move, and some are played from the hand but not placed on the board.

Well, I don't know how to translate this to code. I thought that I should have a interface for the Cards, but since there are various types of cards that act very differently it doesn't make sense . Then I thought that there should be a class for each Player which stores which of his cards are played, which are left etc.. Something like this:

public Class Player
{
private List<Card> PlayableCards;
private List<Card> OutOfGameCards;
}


But there's a fixed amount of cards of each type, so its useless to have a List<T> (besides as I said I don't think I'll have a Card class). Then How should I approach this? Having the cards as individual variables? It doesn't sound right.

The next thing is the Board, it's formed by 8x8 squares where the cards are placed. How do I identify each placed card with a card in the code?

Maybe something like this:

public Class GameBoard
{
private Square[][] SquareGrid;
}


If I do it this way its easy to separate each square and access it by it's position (SquareGrid[3][4]=3x4). But do I store which card is in each Square? Or do I store in which square is each card? After that there's a "special zone" outside this board and everything gets more messy.

• As a tip, I suggest you create a Card class as it can be really useful to store the effect of that card, even the actions related to each card. Otherwise you'd have chunks of codes every time a card is played or acted with/upon to decide what that card is and what it will be doing. Highest chance those codes will end up cluttering in your GameBoard class or some global utility class which already has other codes. Might as well put them where they belong. – Ben Ong Dec 19 '16 at 7:23

If you look at a lot of the verbs in card games, like draw, discard, play, shuffle, these can all be generalised as moving cards between zones. I used these concepts in a card game, which had these core types:

• Cards, which describe the card in isolation
• Zones, which contain cards and dictate how you can move or use cards within them

Anything that holds cards is a zone, and most zones will have special rules:

• A Hand is a zone that is only visible to a single Player
• A Deck is a zone that is invisible, and only permits drawing (removing) cards from the top
• (In poker) the Community Cards is a zone that is visible to all players, but, depending on the game, has a maximum card limit, and can only be added to, or shuffled back into the deck at the end of a round

I would argue that it's easier for the zones to store which cards are in them, and not the other way around, because it's more natural to examine zones and find all the cards within them.

The answer is going to depend on some more specifics about the design of the game, so I'll be making some assumptions:

1. Discarded cards are no longer relevant to the game. Unlike games similar to Magic the Gathering, where the "graveyard" can come back into play. This also doesn't mean we can't reshuffle a deck if cards run out, e.g. Monopoly Chance cards.

2. The cards themselves aren't actors. Again, something we'd see in Magic the Gathering. There's a lot of card games where cards have meta effects, changing game mechanics.

3. As a turn based game, we don't need to over optimize for performance.

With those, here's some suggestions on how to organize your data.

## The Deck

Create a class for your Deck. If you are certain what cards will be used, for example a standard poker deck, feel free to hard code them in there. Otherwise, maybe have the Deck object take a list of cards in its constructor.

We'll need some form of a "shuffle" to ensure players get random cards. The basic approach is to hold some flag that tells you if a card has already been chosen. Then each draw is as follows:

• Select a random index
• Check if the index hasn't been drawn, if so select again
• Draw that card
• Mark that index as chosen

There's a chance of those first two steps repeating quite a bit when the number of cards left gets low.

I'd suggest Deck having a Shuffle method, that produces a list of cards by selecting at random until all cards have been chosen. Then each turn you just move one ahead in that list. This will also help you keep count how many cards are left, and let you do some look ahead if you want to make a cheating AI or anything.

## Player's Hands

Keep this simple, just a list of cards that they have. This is where the assumption of the discard no longer being important makes our lives simpler.

## Game Board

A matrix should work fine for this. We're assuming the cards don't change the board. I think you'll find that most of the time, you just need to know what cards are where. Player plays a card at 3,3 is there a card to the left or right of it, 3,2 3,1.

The assumption that the cards don't have behaviors makes this simple. If you aren't running unique code per card, then the code isn't being run from the card and it doesn't need to know where it is. Even if you do, it's still possible to have some lookup code Board.findCard(cardId) that gives the coordinates.

• I think that a better approach for deck shuffle is to remove a random element from the original list and add it to the shuffled list and if you need the original list do a copy of it before removing things. With the mark approach, the probability to pick a card without a mark in the last time is 1/Number of cards, for example in a 100 cards deck you have a 1% change to select a not marked card. – PhoneixS Mar 29 '17 at 16:32
• @PhoneixS true, but if you can do 1 million of those checks in a second it's not a huge deal. It's kind of the question of memory vs computation, and unless you have an incomprehensible number of cards, probably won't matter. I am assuming the deck object could be shuffled many times (new game, out of cards), so with marks you don't have to copy the deck on each shuffle. – Chris Mar 29 '17 at 20:38