March End! April Kickoff!

March has come to an end!

I set out to make a card game and I came out with a card game. Time prevented me from fine tuning it, but I did come up with a core game and a decent base of cards.

I learned some things about myself, love, life, and board games.

Let’s chat about it.

 

My Card Game

Project As A Whole

What I set out to do:

“This month, my goal is to attempt to make a game that can bridge that gap between immersion and off putting complexity so that I can share games, in general, with those I know who aren’t well versed in similar game mechanics. I do not know if it is possible, but I will explore my theory and approach in next week’s blog post.”

From the get go, I had a very clear goal in mind, but not a solid idea of how I would get there. In the end, I prefered to have my project evolve naturally and see how it shapes up against my mission statement. I have some experience developing board and card games, but it is a hobby of mine, not a focus. With that said, I at least know where to start.

Where To Start

I ended up sticking to a card game for several reasons. First, it seemed easier to create and prototype. The game data is simply spreadsheets separated by card types. From there, half sized index cards were my best friend and I cranked out assets for the playtest. I focused on a battle based game because I wanted to figure out the strengths and weaknesses of a physical game versus a video game when it comes to game mechanics. I also did not want to spend all my time writing cards and dialog.

Enough vague chatting about self awareness, here are the cards and here are the portals!

 

Core Concept

To minimize exceptions to rules, I wanted the game to exist within one core mechanic. This resulted in a battle system. What came out is a turn based strategy game. (This month was purely about mechanics, so don’t get caught up on names, terminology, or fiction outside of it’s functional purposes).

The set up is that the players are working together to close a portal. The portal is in the center and there is one player in each “slot” around the portal. While the players attempt to close the portal, the portal has it’s own defenses of monsters and abilities. Each portal is different and has different win conditions and setups to give the game a healthy amount of variety and replayability.

Each player takes their turn in order, taking two actions to use an ability, attack the monster in front of it, defend, etc. Once all the players go, the portal rolls for it’s ability for the turn. This could be to spawn monsters, progress it’s win condition, or change up the “board state”. Finally, the monsters attack the players, and the round is over.

 

Game Elements

Since the game exists within a tight system made up of modular pieces in the form of cards, each individual asset is easy to make and test. Here is an overview of each card type.

Players

The Brawler

Player cards were some of the most fun to create. Each player consists of a theme, two abilities, and health points. At their core, each player is simple. However, each player is designed to fill a role. Here is an example Player, the basic glass cannon.

Brawler
Action: Make an attack role at +1, roll one less defense die until your next turn.
Passive: +1 attack die
Health: Higher (I never got a chance to balance appropriate life totals within the game so I made rough estimations).

Being a co-op game, the players become strong when the work together. Strategizing is key. In the case of the Brawler, it may pack a punch, but the Brawler will be shredded if the enemies get in a few good attacks. Other players could heal or tank for the glass cannon.  I tried to keep that type of synergy in mind with every player.

On their turn, a player may make 2 of the following actions and each action only once:

  1. Attack
  2. Defend
  3. Rotate Portal
  4. Swap player spots
  5. Roll for Items
  6. Roll for Events
  7. Trade Items
  8. Heal yourself for one

Enemies

Like Players, enemies are simple by themselves and fill roles. Unlike the players, I designed the enemies to be of different power levels. Creating highs and lows for the players can build tension and make the feel powerful and accomplished. It is also important that enemies have varied strategies and abilities to hit the players’ weak spots. Here is a sample Enemy:

Acid Balloon

Text: When Acid Balloon is killed, deal 3 damage to the attacker and 1 damage to their adjacent players.
Health: 1
Attack: 1/4+
Defense: 2+

Some of the values on the balloon seem a little strange, let me give some context for the combat.

 

Combat

One realization I had during play testing was that I never wanted the players to roll for the enemy. In a game, the computer manages all moves for the AI, but in board games, there is no luxury of a computer. Since the players have to do everything, it seemed weird for them to roll for the enemies that are attacking them. Because of this, all enemy stats are checks that the players then have to beat.

When an enemy attacks, it attacks a number of times equal to the first number in the attack stat. The player then rolls a number of dice equal to their defense value. For each roll they make that equals or beats the second number of the enemy’s attack, they block one damage. If an enemy attacks more times than the player can defend, it is an automatic damage.

When a player attacks an enemy, they roll a number of dice equal to their attack stat. For each die that beats the enemy’s defense number, they deal one damage.

Dice checks and attack stats are not new to games in general, but I do feel that the bastardized combination of the two is confusing. I like what the system does for the game, but i will have to pay special attention to how I write the rules and how I display the stats on the final cards.

 

Portals

Portals are the both the boss and the battlefield in the game. The enemies alone have no random element and are predictable in battle. The portal stands as the driving force. They spawn monsters, have unpredictable turns, and define the win condition for the game.

I wanted the portals to be dynamic. As the game progresses, the portals also progress, becoming stronger and more unpredictable. I also wanted each portal to have a different impact on how the game is played to the point that it is almost an entirely new game with each portal. Here is a sample portal:

Scattered Thoughts

Setup: Any portal shape. Shuffle in the special enemies to the monster deck.
Health: 4 * number of players
Weakness: When a player kills one of the special enemies, deal 1 damage to the portal
Defense: –
Win Condition:  Accumulate 10 points

Dice Check:
On dice check, fill all spawn points.

d6

Result

6

Special Enemies deal 1 damage to the player in front of them

5

2/3 health: Special Enemies deal 1 damage to the player in front of them

4

1/3 health:Special Enemies deal 1 damage to the player in front of them

3

Heal all special enemies 1

2

Discard a damaged enemy and spawn a new enemy

1

 

Special Enemy

Text: If this monster is in play for three turns, discard it, replace it, and add a point to the portal

Health: 2
Attack: 0/2+
Defense: 3+

Damage Effects:

-2/3’s health: Check Dice Chart

-1/3 health: Check Dice Chart

Let me break it down for you.

First and foremost, the setup dictates what the player needs to do to prepare the game for the specific portal. The portal shape sets the number of players and minions that can be on the board at once. This portal uses all shapes meaning it can be used with any number of players. At the moment, I haven’t found a reason to limit a portal’s shape, but I like the notion of it. This portal also has special enemies tied into it’s win condition and play style. To begin, you shuffle the enemies into the deck. As they appear on the game board, they will be the means to win or lose the game.

Next is the portal’s health. I set it based on the number of players because the players gain advantage the more there are. This allows the portal to scale with the number of players.

Each Portal loses health differently as demonstrated in the weakness. I designed the portals to take damage based off of their unique mechanics. It may complicate each portal, but I also like that it makes each one different.

If the portal could be attacked directly, they would have a defense.

The win condition is how the portal defeats the players.

 

Next is my favorite part of portals, the die chart. Every round, the portal has a random effect on the game. The players roll a die and follow the chart to see what happens.This is the one time I make an exception for the “players don’t roll for enemies” rule. Seeing as this is more of a world event than an enemy action, I don’t feel like it breaks the immersion.

The Special Enemies are the enemy cards that would be added to the enemy deck for the portal.

Damage Effects are how the portal progresses throughout the game and becomes a more dynamic opponent. In this case, as the portal becomes damaged, it opens up more slots on the die chart making it more dangerous as the game carries on.

 

Items and Events

The last elements are Items and Events. They are pretty simple and give the player options outside of combat. Items are permanent buffs players can have and trade. The top one is revealed and the player may choose to roll for it or a random one. To roll for it, the player rolls one six sided die. On a “6”, they get the item.

Events are similar, except they have one time effects that happen immediately. They are also easier to get since the player rolls two dice. If they get a six on either die, they draw the top card (it isn’t face up) and play it immediately. Here are some sample cards:

Spikes – Item

Enemies that attack you take 1 damage

Chilling Breeze – Task

An enemy of your choice cannot attack this turn

Now that you, hopefully, know more about my game, we can get on with the post mortem. Finally, right?

 

What Went Right

I made a game and I was able to play it.

Seriously though, the pipeline was great! I made the game in a few hours and tested out some kinks by myself. Shortly after, I was able to have some friends test it with me and tweak it. I cannot stress how useful that was. Paper prototypes are a valuable tool for video games, but it is more often than not an approximation of gameplay (unless it is some turn based strategy game); In this case, it was the entire game and was testable after only a few hours

Secondly, the core combat system that is the game is solid and expandable. One particlar aspect I enjoyed was the theme of adjacent enemies and players effecting each other. Players can buff and heal the allies next to them and some enemies hurt players next to the one they attack. A lot of strategy emerged from planning who is next to each other, what order they take their turns in, and who they are facing off against. Thanks to the circular nature of the game board, one mechanic I am excited about is the ability to rotate the portal, causing all the matchups to change.

I didn’t even scratch the surface of the places this game could go. That is the advantage of a strong core system. Unfortunately, that is also where things went a bit wrong.

 

What Went Wrong

What went wrong? I’ll tell you what’s wrong. My battle system. It is a solid battle system with interesting choices and mechanics embedded into the gameplay, but as the month wrapped up and I started to consider what I would write, it suddenly dawned on me. This system works the same, if not better, in a video game environment. All my concerns about having the players act for the enemies would be gone with the aid of a computer. On top of that, I could have enemies be more dynamic, have more variations, and have more of a battle logic and strategy.

That isn’t to say the game doesn’t work as a board game, but in the future, the hard part will be defining the elements that make the game most enjoyable in a physical space.

One last, minor thing. As rules are still trying to be figured out, some of the cards on the lists don’t make a lot of sense. Hopefully their themes come through, but not every one of them is playable in the system right now.

 

What Else I Would Do

Play tests play tests and play tests. There is a lot I could do with the game like I mentioned, but that also means there needs to be A LOT of playtesting and with A LOT of people. I would need as many as I could find. Of course, forming a community around the game would both be the easiest and most difficult solution. Easier said than done, I know, but the internet and even local hobby shops could have people willing to check out my game.

The second thing I would do was define the board game and card game elements. What spatial and physical aspects of the game make it a pleasure to play on a table top instead of the virtual space? I don’t quite know, but I sure as hell would find out!

 

April

And last but not least, we come to next month’s project. Err… I mean this month’s project (yeah, i know it’s already April).

This month, I will publish an iOS game. As much as I like these small experimental projects, I am only dipping my toe into large year long endeavors. This month,  I want to make a finished project. It would not be big or flashy by any means, but it will be simple, fun, and available on iOS. Something with the scope of Flappy Bird, but no, not a Flappy Bird clone, and no, I do not expect it to make me money at all. But it will be mine, and it will be awesome.

But before then, here are the links to my game one last time:

Cards
Portals

 

Cheers!
See you next month.

Jordan

Posted in Development Blog, Game Design, Uncategorized

Leave a Reply

Your email address will not be published. Required fields are marked *

*