Aliens Predator CCG: Deductive vs Inductive Planning

Via The Fresh Prince of Beleren

With the full sets of Alien Predator cards recorded into a spreadsheet, they are prepared for data merging and printing. The problem I ran into was deciding which of the ~350 cards in the Premier set of Aliens Predator.
The way that customizable card games are built means theres a lot more options available than you would ever use.
There is not even a maximum number of copies that makes a 'complete' set because Items and Locations have no limit when included in decks. The lack of hard restrictions on what can be included stumped me for a while - I know I have a print limit, and need to filter the card list down to something workable. But with 367 different cards to assemble into 3 distinct decks with their own requirements felt very daunting.

My first plan was to create a set of cards for each faction for the player to build a deck with. I started evaluating which cards to give to each faction, since lots were written to be faction agnostic - even if the card wouldn't be valuable to your faction. I got a fair bit through the Marine faction when I decided to take a different approach:

I simply scrolled through the card records, picked ones that looked important for the faction, and put them into a print queue. It's not perfect or balanced, but the time it would take to get those up to par would be too long. I need playtesting to see if the game is worth keeping as-is, so I need playable decks. And that's exactly what I made!

Aliens Predator CCG: Card Design Part 1

Aliens Predator Card Designs

A problem with all the cards is the font used in the name. It has readability issues and could be improved. Second, the Resources and Restrictions listed along the left side of the cards are printed vertically. That's hard to read without turning the cards or craning your head, and this text is often required to tell if you can play a card or not.

Locations form the 'map' where the game takes place. Characters move between adjacent locations, and can search them for equipment and supporting characters. I like the graphic card frame and the prominence of the image. 

Main Characters are under the direct control of the players. They move, attack, and search for supporting characters and items. These frames look interesting, but the flavor text overlaps some of the graphic elements making it harder to read.

Supporting Characters are found by main characters and are used by the different factions to win the game. The contrast on the card is nice - they look really plain, and wildly different than the other character cards for easy distinction.

Events are played for temporary buffs or penalties. I like the design but the texture under the effect text makes it harder to read than necessary.

Items are used by the Humans and the Predators. The Human Item frame is very solid. I like the graphics and the texture doesn't interfere with the Effect Text and the Flavor Text. The Predator frame has wasted Effect Text space, and the texture underlays the Name and Flavor Text entirely.

These cards were redesigned with the release of the Resurrection expansion, and to match the Terminator CCG which used the same rule system.

Dune CCG: New Card Faces

The Dune cards hold a ton of information - There are symbols, number attributes, type and timing information, all kinds of stuff. There are about 17 variables contained in each card which makes them tough to design, all that information needs to be organized in a readable and clear manner.

My goal when making these templates was to prioritize learning the game above all else - with complex rules and detailed cards, making the information clear to new players is vital to keep them playing.

The first step was to simply remove the image field. I don't have the resources to create art at this point, so diverting that space to rules text was a given. From there I identified each part of the card that had information important to the player and to give each piece a place on the card.

As an example, some effects refer to one of the five broad card types: Holdings, Plans, Resources, and, Personas, and Events. But the cards in the original game don't list that information - they use a different card frame to indicate card type. I don't think that's enough of an indicator, so I made the card type explicit under the card's Name.

I also added labels for Allegiance, Talent Requirements, Cost, Command and Resources to make those markers more clear. In the base game they are

Personas are the main 'actors' in a game of Dune. They can make battle, begin intrigues, duel other personas, and arbitrate over contracts. They can be improved with Resources like liaisons, vehicles, and weapons.

Plans are temporary special powers that you can play to alter the game. Each Plan's subtype shows where, under which conditions, and what phase it can be played during.

Resources are attached to Personas and Holdings to amplify their abilities. A card's Command is the limit of Resource cards that can be assigned to them.

Holdings are the other key card in Dune. They represent locations or large scale government operations. They often generate resources, and can be upgraded with Resource cards.

Events are special, far-reaching one-time effects that have a larger effect the more turns a player 'charges' them up by playing them face down on the field. When revealed, they trigger their special effects.j

After playing through with a set of these cards, I'm considering how to make room for the art with a redesign. The first alternative I'm thinking is to replace the 'skill box' with Magic: The Gathering Keyword-style text, like Battle 3. Other alternatives include breaking the skill box into 3 separate modules, or to have a full stat line like Warlord CCG.

CCG Regeneration: Card Back Designs

I've finished transcribing all the Dune CCG cards and developed templates for new printings:

Image of a card with a blue background, a light blue geometric pattern, with a gold geometric pattern in the foreground. The card is labelled 'House'.

Image of a card with a purple background, a light blue geometric pattern, with a gold geometric pattern in the foreground. The card is labelled 'imperial'.

I wanted the card backs to be very distinct in color, but have a matching design to reinforce the relationship between the House Deck, which represent an individual House's resources, and the Imperial Deck, which represents unique assistance from other forces within the galaxy at large.

I used purple for the Imperial background color to reference the Imperial Deck's higher status, and I used blue to indicate that the House Deck is still of 'nobility' but to a lesser degree.
Both card backs use patterns to add texture to the background color. I chose different patterns to further subtly differentiate the cards from each other.
Both cards use a

"Purple was the color worn by Roman magistrates; it became the imperial color worn by the rulers of the Byzantine Empire and the Holy Roman Empire, and later by Roman Catholic bishops. Similarly in Japan, the color is traditionally associated with the emperor and aristocracy.^{[7]" - Wikipedia}

"Blue has been an important colour in art and decoration since ancient times. The semi-precious stone lapis lazuli was used in ancient Egypt for jewellery and ornament and later, in the Renaissance, to make the pigment ultramarine, the most expensive of all pigments. In the eighth century Chinese artists used cobalt blue to colour fine blue and white porcelain. In the Middle Ages, European artists used it in the windows of cathedrals. Europeans wore clothing coloured with the vegetable dye woad until it was replaced by the finer indigo from America. In the 19th century, synthetic blue dyes and pigments gradually replaced mineral pigments and synthetic dyes. Dark blue became a common colour for military uniforms and later, in the late 20th century, for business suits. Because blue has commonly been associated with harmony, it was chosen as the colour of the flags of the United Nations and the European Union.^{[2]" - Wikipedia}

Deck Building Adventure Game, Part 3: First steps

So now that I've got my goals ready (Challenge, Fellowship, and Expression) it's time to build what the game is.

Italic is a game mechanic term
Bold is a thematic term


Who:
The game is built for Player(s). The target group is teens through adults because of the complexity of the interactions. The themes of the game would suit players that enjoy cooperative games with strong thematics, a moderate amount of chance, and many options. The game is not designed for those who desire strictly low chance, a competitive atmosphere, or an abstract setting.

What: (The big one)
I want a game where the player acts to [ overcome challenges using the resources available to them ]. That's the core gameplay loop - most of the play in the game will be this.

A supporting loop is that [ overcoming challenges provides additional resources ] and that [ failing to overcome challenges provides penalties ].

[ Failing too many or key challenges will result in a Lose condition ].

The challenges for a match are selected from a large pool.
Challenges are divided into Sets that share a Theme or Setting.

Where:
Physical copies of the game are built to be played on a table with ample space. Digital copies would be suitable for Windows, Android, and iOS.

When:
1-2 years of hobby time to generate the game, test it, and make prototypes

Why:
To have a cooperative game that combines the play of deck builders with the progression and persistence of adventure games

Deck Building Adventure Game, Part 2: Goals and Research

Goals

By defining the goal of the game first, I can measure every mechanic against that goal to determine if it furthers the objective or interferes with it. Using Marc LeBlanc's Eight Kinds of Fun, I've listed the types of fun the game should provide in order of importance:

• Challenge <- Primary

The core concept of this game is to generate challenge. The game presents a problem and various tools; the players must then find a way to solve the problem with the tools at hand. 

• Fellowship 

A secondary consideration is the feeling you get from cooperating to accomplish a goal. Mechanics should reinforce cooperation and interaction.

• Discovery 

The feeling of experimentation with card combinations and seeing new interactions created by different game systems interacting.

• Expression 

Playing a deck styled after tactics you prefer and find satisfying

• Narrative <- Secondary

Framing the context and theme of the game in a way where players can construct a narrative out of the sequential events.

• Fantasy

Imagining yourself in the situation implied by the cards

• Sensation <- Tertiary

The tactile feel of the cards, the duende of the art

• Submission

Using the game to pass time

When designing mechanics and dynamics, they should refer to each of these priorities. With all this in mind, here is the basic template for my deck building adventure game:

A Cooperative (Felloswhip) deck-builder (expression) where the players work together to defeat obstacles provided by the Game deck (challenge).

Tabletop Spaceship Wargame Design Part 10, Researching Firestorm Armada v2

Firestorm Armada is a fleet system that is as complex as Battlefleet Gothic but using different mechanics to accomplish dynamics.

Weapons roll pools of six sided dice to determine how effective the shots are at damaging the target.

Weapons have a profile that describes how many dice they roll at each range. These dice are rolled and compared to
Dice that turn up as a 6 'explode' and add another die to the pool.  Instead of each success dealing a point of damage, the total number of successes are compared to the target's armor. If successes >= Armor, the ship takes a hit.

After testing out the game I found the exploding dice to be untenable. It resulted in lots of unfun situations, either impossible comebacks or annihilating any chance of a comeback.
The armor system also generates situations where a ship's turn results in nothing if they don't score enough hits. For me that doesn't fly. My target is a few ships, so each activation should be impactful. With the armor system, perfect tactics can be denied an effect due heavily to dice rolls.

Tabletop Spaceship Wargame Part 6, Questions with multiple answers

The game it starting to take a shape with these early builds. The next large step is to decide core foundation mechanics.

As an example, I'm going to jump ahead in the game's development to consider what kind of map and movement system will make up the game. There are may solutions to this problem, and each of them has objective quality - but only one overall system can be incorporated into my game.

This is where the core concepts of the game outlined in Part 3:

Emotion: Triumph

Goal 1: Accessible

Goal 2: Fast 

Goal 3: A wide variety of tactical options

Comparing a given mechanic to the list of game goals will guide this subjective business.

Movement

Freeform or Grid based

Freeform movement:

Requires a measuring component

Requires some method to measure turning radius

Rules must be coded for infinite vectors and subjective tests for relative positioning and terrain

Allows full freedom of movement within the constraints of a piece's characteristics

Imprecise

Grid based movement:
Requires a grid map to play on
Rules can be coded for a limited number of vectors and objective tests for relative positioning and terrain

Restricts movement and options to the grid
Precise and objective

Comparing these options leaves me with a single conclusion: in order to maintain the accessibility of the game and the rules, it will use a grid map to govern movement, firing arcs, line of sight, terrain features, and range measuring.

This places the burden of all those tasks onto the map component. This reduces the strain on the player by reducing the number or elements in flux at a given time and adds predictability for how the map and ships will behave.

This is going to be my method for making these kinds of choices in the future.

Tabletop Spaceship Game Part 5, Iterations!

Now that a ship's displacement of theory has been spun, let's get to the base model of the game. In order to test systems in a productive manner, I need a functional core set of mechanics. I've seen that starting with anything more than a base set of mechanics causes confusion and misleads priorities.

With that in mind, and what we've covered before, what does a wargame need?
1. Victory Conditions
2. Movement
3. Attacking

Solid. Let's expand these, to minimum functionality. Each of these iterations is going to be painfully basic, but this process is important to actually 'figure' the game out.

0.01:
Victory Conditions:

• you win when the other player's ship is destroyed.

Movement:

• Your ship can move anywhere on the play space.
• The play space is infinite size.
• Your ship may move at any time

Shooting

• Your ship can shoot any number of times
• Your ship deals 1 damage per shot
• Your ship hits automatically
• Your ship damages targets automatically
• Your ship can take 1 hit before being destroyed

This version is unplayable. Why it's unplayable is important for putting barriers in place. This ruleset results in both players ships exploding instantly since ships can shoot infinite times at any point in the game, automatically hits, and automatically damages the target. There is no meaningful choice, and no reasonable way for the game to provide satisfactory play.

The first step I'm taking is to introduce a 'turn' mechanic. 

------------------------------------------

Turns:

• Players alternate turns. 
• A player can [only] act on their turn. 
• Flip a coin. The winner of the toss gets the first turn.

Good. Where earlier both sides would blast each other simultaneously, Turns ensure that only one player will be able to act at a time. But there is still the problem of movement and Attacking happening at any time in the turn - let's regiment that a bit. Also Attacking should happen only once per turn. And let's restrict it to a single target while we are at it. Let's see what we've got here:

[brackets] fence in variables that may change later. This helps keep eyes on the prize

Capital letters highlight important game concepts, such as Victory Conditions.

Each player controls [1] Ship

Turns:

• Players alternate turns. 
• A player can [only] act on their turn.
• On their turn, a player [Moves] and then [Attacks] 
• Flip a coin. The winner of the toss gets the first turn.

Movement:

• Your ship can move [anywhere] on the play space.
• The play space is [infinite] size.
• Your ship may move at [any] time

Attacking

• Your ship can shoot [Once] per Turn
• Your ship deals [1] damage per shot
• Your ship hits [automatically]
• Your ship damages targets [automatically]
• Your ship can take [1] damage before being destroyed

This is better. But still inadequate. The first player will win every match guaranteed. The restrictions added previously help lay the foundation for future rule systems required to make this game more interesting.

So what's next. The current problem is that the first player wins, guaranteed. This is not fun, it's not a game at this point. So there needs to be some additional factors to add complexity, depth, and choice to this prototype.

The most direct way to make sure the first player doesn't always win is to introduce chance. 

Attacking

• Your ship can shoot [Once] per Turn
• Your ship deals [1] damage per shot
• Your ship hits [on a D6 roll of 4, 5, or 6]
• Your ship damages targets [automatically]
• Your ship can take [1] damage before being destroyed

Ok. With this setup, any player has a 50% chance of missing. This allows the second player to win, while also allowing the possibility for the first player to win. However, this introduces a new problem specific to this mechanic: The game could last infinite turns if players keep rolling below 4 on their Attack Die.
Time to solve that with a turn limit! Each player gets 6 turns. If a ship isn't destroyed by Round 6, the game is a Draw.

Alright. This is quite crude,  but it's a start. Further posts will detail further revisions and development.

Tabletop Spaceship Game Part 3, Foundation

The Atomic approach

Utilizing a reductive method to start from the smallest elements of a game, and after identifying and understanding each, combining them into stable molecules and compounds to support the original intent.

Designing Board Wargames by George Phillies

This lecture series on Youtube proved a good place to start for me to understand wargames from a longer and wider perspective than my own. I'm incorporating pieces of these lectures in addition to Mark LeBlanc's work to create a solid foundation that I can reference when creating mechanics further in the design process.

I will utilize material covered in this video:

Introduction, Features of All Games

Representation

What you see in front of you when you look at the game.

The game is represented by the various miniatures or tokens arrayed on a [gridded/open ] play map with reference cards for each faction set to the side. Several colors of dice will be available and a track marking victory progress for each player. Templates and measuring aids will be available as well, with a rules reference sheet and full rulebook out of the play area.

Mechanics

Mechanics are things you assemble to get a game - mechanisms that execute to make the game function.

Mechanisms slated in the game at this point are to remain mostly undefined to fit my atomic approach.

Confirmed mechanics:

Player Turns

Dice Rolling

Modular Board

Variable Player Powers

Capture / Eliminate

Movement

Resource Management

Risk & Reward

Game Modes

Piece Elimination

Victory Points

Loss Avoidance

Possible mechanics:

Reference Cards

Force Construction

Factions|Open Purchase

Catch Up

Secret Unit Deployment

Time Track

Action Point system (Star Fleet Battles, Federation Commander)

Rock Paper Scissors

2+ players

Team play

Player Elimination

Cooperative Scenarios

Wagering resources / Press your Luck

Campaign Play

Route Building

Card Driven Battle / Campaign

Deck / Pool Building

Point to Point movement

Simultaneous Action Selection

Action Programming / Pencil and Paper, recording orders

Variable Unit Command / 'Chit-pull system'

Grid Movement

Memory

Area Control / Influence

Pick up and Deliver

Style

emphasis of a specific mechanic, what mechanic the game relies on.

This will have to be rather light at this point, because so little of the game is established picking mechanics to emphasize is premature.

Theme

What is the game about

The game is about fleets of spaceships fighting.

Components

What falls out of the box when overturned

Play Surface

Dice

Tokens

Chit Counters

Reference Cards, Sheets, Rules

Rulebook

Miniatures

Templates

Ruler

Terrain tiles

'Shape'

Term from Japanese game Go, Thin and elegant or Thick and clumsy

How much space the game uses in a player's life

The target for this game is to have a very thin presence for play and setup, and ideally a thick space in overall time playing.

Voice

I / We / First Person

You / You / Second Person

*He/She / They / 3rd Person*

The player's actions reflect the decisions and participation of hundreds or even thousands of imaginary officers and crew.

Content

Subject of the game

What are the resources?

This overlaps quite a bit with Theme, and so far isn't well defined with the current rules (or lack thereof) at this time. Content is what distinguishes this game from others like it.

As the game goes through iterative design, I'm going to revisit these elements and fill them in.

New project! Tabletop Starship Wargame, Part 1

Hey there. After playing Star Wars Armada and X Wing miniatures, it stoked the fire of an old desire to create my own table top wargame system with spaceships.

Each game I've played in that genre has left me with some issue or another, and I've experienced enough different systems that I've got a good idea of what I want in and what I want left out.

I'll start with the elements from the games I have experienced that ended up being sticking points that have lead to me creating my own system.

I have played Call to Arms: Babylon 5, Call to Arms: Star Fleet, Battlefleet Gothic, Star Wars: Armada, Star Wars: X Wing, and am familiar with Halo: Fleet Battles, Firestorm: Armada, Federation Commander and Star Fleet Battles.

The goals for this game system are as follows:

1. It should play fast.

2. It is Capital Ship Fleet scale

3. Fighter Craft play a role

Ideally, here are some additional preferences:

A. Construction rules will be provided so players can create profiles for their own imagined ships

B. The ruleset should be flexible enough to represent a wide variety of ships.

C. The game should scale up in a reasonable fashion.

With these thoughts in mind, we begin.