Twilight Tactics: A deckbuilder on a tactics grid.

Twilight Tactics was a spinoff from a prototype for Twilight Tower. I love tactics games and I love card games, so I put the two together.

Team

Casey (me): Technical Game Design, UI/UX, Team Leadership
Collin: Illustration
Justin: Music and Sound

Engine: Unity
Project Length: 1.25 years

This project consumed me (when I had time off from my client work) for over the last a year of the pandemic.

Game Design – Basics

You have to move upwards through a grid with “Move” cards as sand pursues you. You encounter challenges along the way that you have to “Progress” through to remove them from your path until you can find an exit.

Your characters lose stamina every turn, even more by challenges, so you have to find ways to restore it.

Your deck of cards is shared between your two characters Prisoner and Friend.

Game Design – Prisoner’s Mechanics

You fill the shoes of Prisoner, a somewhat unsavory, manipulative character. His primary mechanic is called “Influence”. At the start of every day (turn), he gains +1 influence.

Many cards take influence into account to calculate how much Progress (damage) they will do. Prisoner is designed as a “front row” character, so he has more stamina and he pairs best with close range cards.

Prisoner can do a lot of damage, he’s even capable of one-shotting many targets, if you manage your influence effectively. In order to do that, he relies on his travel companion, Friend…

Game Design – Friend’s Mechanics

Friend’s mechanics are based on range. His stamina is much lower than Prisoner, so he needs to stay back. Fortunately, he can play cards further away because of his natural passive of +1 range.

Scouting

Friend’s range also make him a good choice for using Scout cards, which reveal the map around where it’s dropped.

Momentum

The interesting thing is that some cards have the “Momentum” tag. This basically means Damage = Base Damage * Target Range. These cards are very weak at close range, but the farther Friend is from the target, the more damage he can do with these cards. He’s the natural choice for Momentum cards because of his passive +1 range.

Friend can be even more powerful when powered by cards that increase range.

Enemies / Quests

To fit with the narrative layer, I called them “Quests” that you need to “Progress” in-game. But really they’re just enemies with hp bars.

Each enemy has their own way of targeting players and special effects.

Enemy Templates

Using Unity’s scriptable objects, I programmed up a system to quickly produce new enemies from a template. I then created an array of abilities they go through at certain event points and fed them with drag and drop functions that I could mix and match with different enemies. (I’ll talk more about the code later)

So creating a new enemy was as easy as duplicating a template in the Unity editor, editing the title and description. Setting up their damage and health, then dragging ang dropping functions to their abilities.

The Floor Keeper

Before this enemy was created, the optimal strategy was to go straight up and hope you never hit a wall. My philosophy on enemy design is that they should interupt optimal play so the player has to improvise more.

The Floor Keeper interupts optimal strategy by creating a wall that forces you to explore left and right to find and defeat it in order to drop the wall.

Narrative

To break up the tactics card play, I interspersed narrative and art between levels.

Randomizer

Initially I made a randomizer to test enemy and card mechanics, but it was so fun to play that I decided to end the demo with an infinite randomizer.

Just a preview of some of the code that went into making the randomized level layouts. The gif above is an earlier version of what this code does.

It basically goes through the grid, marks off the boundaries, staggers the edges with walls, distributes walls throughout the map, sets up any Floor Keepers, then traps, then distributes enemies along two tiers of difficulty.

Card Architecture

I set up cards as templates that I could quickly customize in a modular way to create emergent mechanics. The momentum and speed of creation improves a game design dramatically.

Card Templates

Like the enemies section above, I set up cards as scriptable object templates that I could adjust variables on in the Unity Editor and then drag and drop abilities to for different card-playing events such as dropping a card on a part of the grid.

The drag and drop abilities were split into functions for each relevant milestone event.

Here’s an example of some of those functions filled in for a specific ability.

Card Objects

The object housing all these actions and variables were broken into their own components: Visuals, Animations, Tooltips, and Dragging behaviors.

Rubber Ducking

To give you a glimpse of the amount of work done on this project, rather than spam you with code scripts, I’m sharing a handful the near-daily patch notes I sent to the team on Discord throughout the process. This helped show momentum and keep everyone motivated. I was always able to tackle the larger tasks on the weekends, or take out large swaths of things that were bothering me.

The User Experience Layer

Due to there not being many games of this type to draw on advice from, I had to forge a path into an unfamiliar user experience.

It felt like building the “experience layer” on top of the mechanics was more difficult than the mechanics themselves. For every confused playtester, I needed to come up with a new guidance systems for the player that had to tie directly into and sometimes interfere with the mechanics.

Gridlines

Since the base of the grid code didn’t have anything set up to show connections between grid pieces, I had to add an system on top of that for knowing how to draw lines to help players understand what is and isn’t in range.

Dear Player: You will “complete this quest” if you drop this card here.

Dear Player: You’re going to get hit if you stay here.

UI Systems

In order to figure out how to display all the relevant information on enemies I needed to try several different stress tests showing a high number of ideas being communicated at once and make sure it all looked right and didn’t break their bounds.

Playtesting

In order to find your way through an unfamiliar user experience, you need to collect a lot of data, which requires constant playtesting. I am forever in debt to my playtesters for the amount of time they spent giving me such quality feedback.

The following images are examples of the types of notes and task lists that would be created during and after playtest sessions.

By the way, for more information on my philosophy of playtesting, check out my video on that exact topic!

One thing I would do different is instead of using the nomenclature of “Quests” instead of “Enemies” and “Progress” instead of “Damage” or “Health”, is just go with the known terms. I was being too stubborn towards trying to keep the original concept of the first Twilight Tower alive.

Prototyping

Last and least, I want to share some images from the journey prototyping towards the version of Twilight Tactics you saw above.

The first image was a failed prototype, which led to the paper prototyping in the second image, and led to design mockup iterations that ultimately became Twilight Tactics.

In Closing

This project took over a year of my life. It was a very fulfilling project. It taught me a lot about design, about programming, and let me really practice creating card mechanics. There are quite a few card playing paradigms left on the cutting room floor.

While I got a ton of great experience with playtesting, I already knew how to do it, and I feel like I wasted way too much time and effort worrying about the user experience layer before I finished proving the game design in the prototype. If I could do this again I would spend much more time testing janky mechanics than trying to make tutorials and signposting. That’s a polish layer on top of an established design. I could’ve gotten to that a lot faster with Twilight Tactics than I ultimately did.

It’s a fun game! I do think the design has a lot of exciting ramifications. Who knows, maybe one day I’ll pitch it for a full game.