Adam Weesner

From the outset, I wanted a strong emphasis on object oriented design. Each card, player, and town are neatly modularized and well-documented so that other game designers and artists (who are less experienced in C# programming) could fully edit parameters to their heart's desire.

​

The player object is rather simple. Each player has a hand with randomly drawn cards. Furthermore, players own towns across the island, and this is stored in an Town object list variable. The image below captures what parameters are available:

Players can obviously place a card down inside a town, but how was this accomplished? I wrote a script that passes a card object from the hand to the node (a town). I use a lerp function to smoothly animate the transition. The lerp function will take the card object in its current position and continually transform it to match the target destination. I also utilized a curve for the animation to give a sense of inertia.

Let's touch upon my implementation for triggering. When a player or AI sends a group of cards to occupy a town, the selected cards are packaged in what's known as a "card carrier". The card carrier will travel along a path at a set speed determined by a shortest path function. If a card carrier runs into an opponent's carrier or a town, it will collide with them. It can either attack or occupy a town (if it's unoccupied or player-owned).

Towns were an interesting obstacle in development. What I ended up going for is a region-based system. That means that a region controls a certain amount of towns. If a player controls all the towns in that region, they'll obtain 1 extra card per draw. Below is an image of how regions are laid out in the editor:

Much like a player or card object, towns are fully editable within the inspector too. The key parameter to note is the connections. Connecting a town will create a adjacent node graph:

One last thing to touch upon; adding cards to a town works in a very similar way of adding cards to a hand. A card is placed as a "stationed" card if no garrison exists.

Card combat! Exciting! This is a rather extensive topic, so let's dive in. Once a card carrier collides with an opponent carrier or town, combat initiates.

Now that combat has begun, it's time to sort out who's who in the battle. The combat logic itself is mathematically in nature. In essence, the first card from each combatant is selected to battle it out. The code sorts out the difference between the card's values and determines the winner. The loser card is destroyed and the winner's value is subtracted by the difference. Once one side's cards are depleted, the winning side either continues on its way if the enemy was a card carrier, or it occupies the town it was attacking. It's important to note that if another carrier collides with the two combatants in progress, then they are dynamically added into the fight as well. In other words, you could have multiple sets of cards all battling it out all at once.

The AI design I followed was using a decision tree. Before we get into the vernacular, let's discuss briefly of the AI player object. Below you'll find an image of the parameters we can edit:

• Draw Card Wait

  • How long until the AI draws a card.

• Place Card Wait

  • How long until the AI places a card inside a town.

• Send Card Wait

  • How long until the AI sends 1 or more cards to another town.

• Card Speed

  • How fast the card carrier's move.

• Card Value Probability

  • The chance that the AI will draw a low or high-value card.

• Max Cards In Town

  • How many cards the AI will place in a town.

• Cards Required To Attack

  • How many cards are required for the AI to decide to attack another town.

​

As mentioned before, I used a decision tree for AI decision making. One strategy that the AI can use is as follows. The AI will first send a card to an unoccupied town. Then it will check if it has more than 4 cards in any given owned town. If it does, then it will send those cards to attack a town.

The handling of cards relies on dragging and dropping using the mouse. Once a player begins dragging a card object, it will update the position of that object according to the mouse. If a player lets go of the mouse while dragging, a line trace is fired from the position of the mouse to the map. If it hits a town, then it checks if it's owned by the player. If so, then it adds the card using a lerp function (for animation).

Several effects are in place, such as enlarging the cards once hovered over, highlighting green once selected, and rotating their object if dragging them. Speaking of, once cards have been placed inside towns, more than one card can be selected. This means that if 4 cards are selected, then the drag will include all 4 cards. See below the implementation: