top of page

YIIK: The Dark Card Game - D001

Writer: Lannie Neely IIILannie Neely III

Updated: Jan 13

Devlog 001: January 12th, 2025

I’ve been developing a game based on YIIK and its battle system, called The Dark Game. As of right now, this is a completely unofficial side project. My hope is to create a pitch that the developer, Ackk Studios, will find interesting and fun.

Design Requirements

When I work on games, I usually have a set idea of what I want from them. Some of these are sensibilities I carry into every project, like having “Simple Choices, Deep Outcomes.” You can see this style in Last Word, To the Moon: Bestest Memories, and even Fleuret Blanc from back in 2012. But each project is unique; a list of ideas for YIIK would have to come not only from my predispositions, but from what makes YIIK’s battle system unique in structure and feel.


Here are some of the ideas and sensibilities that I found important:


  • Simple Choices, Deep Outcomes

    • The game must have few, yet interesting, decisions at every moment.

  • Karta Versatility

    • The game must include the Karta as versatile elements.

    • Each Karta must have more than one use, with uses conflicting with others (like the choice of keeping a Karta equipped for stats versus killing it for a one-time skill).

    • Characters must each equip 3 Karta.

    • Karta must act as shields for the majority of attacks, in order of front to back.

  • Bleed System

    • The game must include a Bleed system.

    • If a character starts bleeding (which can happen if they are attacked without any defending Karta), they slowly lose base HP every turn.

  • Speed System

    • There must be a speed mechanism that affects turn-taking.

    • The speed mechanism must be intuitive and extremely easy to use.

    • The speed system must not require lots of math.

    • The speed system must not make one player feel like they are being completely ignored while the other player gets lots of turns.

  • Character Statistics

    • Character Statistics must be few in quantity.

    • Character Statistics must be small enough in number that the arithmetic comes easily. No calculators, no tables!

  • Momentum

    • Something in the system should make it get faster and swing wider as it goes on, rather than slowing down.

  • No Excess

    • During every game, most of the components must be available to use.

    • There should not be a box full of unused components.

    • The price of manufacturing should be a metric in efficiency.


1-v-1 Card Game

The basic game I'm going for is a head-to-head game, similar to a TCG in its style of turn-taking, attacking, and protecting base HP.


  • Each player will have a Character.

  • Each Character will have HP and some other basic stats.

  • Each Character will have 3 Karta equipped.

  • The equipped Karta will modify stats and act as shields to the Character's base HP.

  • The first player to reduce their opponent's Character HP to zero wins.


This is a sort of basic DNA, and, as is appropriate, you can feel that the YIIK battle system already takes a bit from Magic the Gathering or Yu-Gi-Oh! in this regard. There are a lot of differences, however—where to start!?


The first thing I focused on when tackling this project was the Karta. These tarot-like cards feel like the heart of the system, and so I wanted to make sure they were given the most attention.


Karta and Excess

So, how do I take advantage of the Karta's versatility? Specifically, how it would run against the “No Excess” guideline?


For a nice tight box, every piece should be in play. Yet, in YIIK’s Karta system there are only three Karta equipped at any time to a single character. How can I have a deck full of all different Karta, possibly in triplicate, without relegating most of them to the storage chamber?


Leaning into the Versatility

Best practice: I should use what I have. Karta are supposed to be versatile (Karta Versatility), and I have too many (No Excess), so I needed to figure out a way to use every part of the buffalo.


In YIIK proper, Karta have four major aspects:


  • HP (works as a shield for the character)

  • Stat Mods (modifies character’s stats)

  • Hand (an aspect, good or bad, that applies while equipped)

  • Use (a unique skill that kills the Karta)


In order to work this into a physical card game, I needed to take liberties with these pieces of usability. There is an innate power given to the player while “in hand,” and another power that happens “when used.” What I decided was to allow the player to equip three Karta to the character, then keep the rest in their actual hand. This would separate what was possible for the Karta depending on which state it was in: Equipped, or In Hand.


Already, this created an interesting dynamic. Whenever you got a Karta, you had to decide if you’d rather equip it to your character for a permanent effect, or to keep it in your hand so that you could use its unique skill.


Counting Cards

There are 14 unique Karta. I wanted to print 3 of each, giving us a nice 42 cards. Assuming we had 3 Karta equipped for two players, and 5 Karta in each player’s hand, that would be 16 Karta cards being used every game. Not a bad start.


However, that left 26 that would be left completely unused. I would find the solution to this until later, but for a starting point, that was good enough.


Karta Update

So, if we had stats and abilities that were available when equipped, it stands to reason that using the card from hand would use its Karta Skill (originally the “Use” option). In the YIIK system, your hand and your equipment are the same, so using a Karta would unequip it. I decided to keep that, but also, you could use a card from your actual hand and discard it. This lets you use 3 Karta as stat modifiers with the last-ditch gambit of using their skill, while also letting you use the skill if instead it was kept in hand. For clarity, I decided to list out these differences:


  1. Equipped - Added to Character before starting

    1. HP (works as a shield for the character)

    2. Stat Mods (modifies character’s stats)

    3. Innate Aspect (an aspect, good or bad, that applies while equipped)

    4. Karta Skill (a unique skill that kills the Karta)

  2. In Hand - Held in hand and discarded with use

    1. Karta Skill (a unique skill that discards the Karta)


Hm. Looking at this, it wasn't quite enough. There was an interesting decision between what to equip and what to hold, but it heavily favored equipping. I decided that any other action the play could take on their turn should be an aspect of the Karta in hand.


Attacking

Normal Attacking was still something not considered. Karta and their skills were such a priority, that the simple act of Attacking had just been sitting on the shelf, gathering dust. What if I could merge the issue of Karta being lackluster while in hand with the lackluster-ness of Attacking? What if Attacking always required you to discard a Karta from hand?


I pushed forward with that. 


Imagine, you have in your hand 5 Karta. They all have neat skills, but none of them attack inherently. You want to attack. So you have to decide which Karta to discard in favor of that attack. This means, next turn, you have one less Karta skill available. This could work.


Furthermore, what if the Karta itself decided which type of attack you used? YIIK has attacks called PIERCE attacks, so what if the only way to use a PIERCE attack was to discard a Karta with the PIERCE ability? I rebuilt the Karta functions:


  1. Equipped - Added to Character before starting

    1. HP (works as a shield for the character)

    2. Stat Mods (modifies character’s stats)

    3. Innate Aspect (an aspect, good or bad, that applies while equipped.

    4. Karta Skill (a unique skill that kills the Karta)

  2. In Hand - Held in hand and discarded with use

    1. Karta Skill (a unique skill that discards the Karta)

    2. Attack (type is based on the Karta)


Discarding Too Much

That felt much better, for the moment. But then we had another problem. If all of your actions (Attack, Karta Skill) made you discard a card, what then? After a few turns, you will have discarded all of your Karta. We needed a way to get them back.


Defending

Defend command to the rescue! (Defend had also been gathering dust. I dusted it off.)


Whenever you Defend, you refresh your hand with your discarded Karta. This gives us three different actions on a turn:


  1. Attack

    1. Discard a Karta.

    2. Attack using the Karta’s type.

  2. Karta Skill

    1. Discard a Karta.

    2. Use Karta's unique Skill.

  3. Defend

    1. Refresh hand with all discarded Karta.


This was feeling better, but after a few rounds of testing, it was obvious that Defend wasn’t doing enough. Defending was a weak turn. No one liked defending. It felt bad. We needed to beef that up.


Beefing Up Defend

When it comes to issues like this, I try to find multiple problems and pair them up into the same solution. 


Defend command too weak? Hm. What’s another problem we have? Oh! That’s right, we still have 26 Karta being completely unused. So how about this...?


When Defending, not only do you refresh your hand of all of your discarded Karta, but you also draw a new Karta from the deck?


Suddenly, this Defend command was actually looking pretty tasty. Every time you Defended, you opened up new options for the upcoming turns. Plus, because you would then have another Karta in your hand, you extended the amount of time required until you absolutely needed to Defend again.


  1. Attack

    1. Discard a Karta.

    2. Attack using the Karta’s type.

  2. Karta Skill

    1. Discard a Karta.

    2. Use Karta's unique Skill.

  3. Defend

    1. Refresh hand with all discarded Karta.

    2. Draw a new Karta from the deck and add it to your hand.


This wouldn’t be the last thing we did to spice up the Defend command, but at this point it was looking pretty solid. A trio of options on a turn seemed like it would be enough, fulfilling the “Simple Options” requirement. Every turn you Attack, Use Karta Skill, or Defend.


At this point, the pieces really felt like they were coming into place. But there was (and is) still a lot to do!


In the next Devlog, I’ll talk about Stats and how we're approaching a simple, hassle-free Speed mechanic.

Comments


bottom of page