Connor Runyon

Card Design and Iteration

The current version of Cardinomicon features over 120 cards with varying statistics, passive effects, active abilities, and more. Consequently, a large portion of the overall design work was dedicated to creating and iterating on these cards. While I personally created some cards featured in the game, my main role regarding card design was editing and balancing cards created by others.

One design pillar of Cardinomicon was to ensure no cards were strictly unviable; that is, there should be a reasonable justification for the usage of every card in the game, even if that usage is somewhat niche. To accomplish this goal, I developed and utilized several cost-estimation algorithms that gave a rough indication of the mathematical power of a card; then, I used these estimations in conjunction with playtesting observations and my own understanding of the meta game (developed through personal play, observation, and my intuition honed from playing other card games) to gradually tweak cards. I always aimed to balance the cost and value of a card relative to other cards without compromising what made it unique or fun in the first place.

Quantitative-backed Design

I devised most of the quantitative logic and algorithms used by the design team to develop cards and mechanics. Given the mechanical complexity and strategic depth inherent to card games like Cardinomicon, qualitative design choices needed to be backed up by solid math to ensure dynamic, tactical gameplay.

For example, the existence of a board in Cardinomicon meant that the practical value of a simple statistic like Attack could be dependent on several other factors that influenced a card’s area-of-control. While this impact could theoretically be guessed on a whim for each card and revised later, this approach is unwieldy and inconsistent at-scale.

Instead, I worked to model the relationships between mechanics to quantify abstract values in a logical manner. Then, in response to playtest data, I revised the models themselves, thereby maintaining the consistency in calculations between every card in an instant. These algorithmically calculated values proved invaluable to the team when quickly designing cards, as they made first-pass balancing easy and relatively accurate.

Prototyping, Playtesting, Refining

Although Cardinomicon was always planned to be a digital game, the design team began their work with a barrage of paper prototypes. Starting with extremely simple cards and mechanics, we gradually added more content and features into our prototypes with each version. This rapid prototyping and playtesting allowed us to quickly and cheaply iterate on the core gameplay loop and content before the first digital prototype was even up and running.

The fast turn-around time on paper prototypes allowed me to refine my balancing algorithms often to increase their accuracy, and it was also a useful pipeline to gradually add and test more cards and content.

Feature Implementation

While my primary role on Cardinomicon was system designer, I also contributed a considerable amount of time to technical development, including programming new features and bug fixing existing ones.

Given my technical proficiency and coding experience, I served as the primary point of contact between the tech and design teams, working with other designers to implement features they needed but could not implement themselves and with engineers to develop system architecture based on the design team’s needs.

Aspects of the project I developed personally include status effects, state-machines for piece visuals, hand sorting, streamlining action confirmation, and more.