Twilight Tower 2: A deckbuilder that seamlessly mixes narrative with combat.

Previsualization

Upon landing on the initial game design, we put together a previs for pitching purposes.

Engine:

Unity

Project Length:

1.5 years

Team

• Casey (me): Technical Game Designer
• Edward: Lead Programmer
• Collin: Illustrator
• Justin: Musician and Sound
• Chris: Dialogue Writer

For this project I was lucky to be able to hand off the lead programming role to Edward, a software engineer, who also serves as a Unity consultant for Risk of Rain 2 (Gearbox).

My Contributions:

• Team leadership and project management
• Initial concepts and early prototyping
• Creative direction
• Game design documentation
• UI Design and gameplay mockups
• Previs script and direction
• Iterative game design prototyping
• Card logic programming and gameobject creation
• Narrative design (basically ‘level design’ in this project) and implementation
• Stat flow and balance
• Ran playtesting
• Pitching and convention representation

Project Results:

• Created several iterations of a prototype for pitching purposes
• Recieved funding offers over $100,000
• The prototype was a finalist for best art at DevGamm

Original Twilight Tower Results:

• 1st place in a color palette game jam
• After a month of polish:
  • Featured by Itch.io
  • Recieved publisher interest
  • Finalist for best narrative at BIG Festival
  • Finalist for best game jam at GDWC

Art Direction – The Core Design Pillar

A narrative experience where dialogue options aren’t as simple as “oh I want to do that”. In Twilight Tower 2, every decision has a cost, and it takes skill to choose them. You’re running out of time, you’re starving to death and your morals are being challenged. Decisions are the difference between dying and living with what you had to do to survive.

The Game Design

Twilight Tower 2 takes the branching dialogue choices of a narrative game and turns them into a card game. Each option requires a specific amount of cards played to them in order to be chosen (ex: choice 1 requires 7 cards). Your skill with your deck will allow you to place more cards each turn. Every turn that you are unable to make a choice will have negative consequences (ex: increase exhaustion).

Some choices may require less cards, but you may not want to make that choice (ex: it’s easy to select ‘Leave your friend behind’). The first choice to meet their required number of cards will be selected, and external factors can influence choices (ex: Anxiety places cards on ‘Run Away’). More complex mechanics will continue to build depth in this system, such as a card that allows you to relocate cards in play.

Game Design Documentation

As the a game designer on the project, my primary job is documentation. A LOT of documentation. I mainly kept notes on my side in OneNote for the folder structure, and then passed the official documentation to the team in Google Docs. Figjams are often useful for structure-related documenation as well. Visual documentation was best done in Figma itself and then disseminated as images. It’s all about finding the best communicator for the job.

Card Design

Designing card mechanics requires a lot of planning, a lot of testing, and a lot of tools that promote creative momentum and iteration.

The lead programmer created a scriptable object system for the cards, which allowed me to maintain creative momentum when creating cards. He also set up a system for me to be able to script special reusable actions and drop them on to as many cards as I need. This makes iteration with cards lighting fast.

To keep a more birds-eye view of the cards and build out concepts for them in bulk, I keep them in a spreadsheet and track many variables for comparison. This helps promote balancing as well as diversity in cards.

I also program my own spreadsheets in Unity to be able to adjust the flow of data through curves and see the results change in real time.

In the example here, I show how increasing an input value can result in a chance for it to spawn another card by running it through an algorithm and mapping it along a growth curve. It then runs the chance 1000 times and outputs the average. That way I can get a feel for the results at all sizes of input value.

What sort of test environment would be complete without console debug tools? We’re using the Quantum Console asset here to create test combat events on the fly. In this example, I used it to test different card combinations on an event to find the most fun combos and tweak the cards and events.

Putting the Tech in Technical Design

I may not have been the lead programmer on this project, but our programmer did architect a rich palette for me to script new actions for cards, which we call GEASOs (Game Event Action Scriptable Objects).

After scripting these, I can drag them to as many cards as I want and they will take effect at a time depending on where I dragged the GEASO. So the action could occur when you hover the card (change it’s size and color to show it’s hovered), or after I drop the card on a choice (play it’s special effect), or while dragging (drop some sparkles). It’s a very powerful system.

Narrative Design

My job was to create the flow through the narrative of the game by creating events that show off our narrative-combat engine. I started by planning out the events in FigJam and then transferring them to Dialogue System for Unity.

I would then repeatedly play through the game and iron out the details and flow of numbers across the experience. All of this would lay the foundation for our writer to come in and lay in dialogue.

The programmer modified the Dialogue System for Unity to allow me to add all sorts of values to the choices – like what the consequences to your stats were if you selected this option, what sorts of rewards you would get, and what types of card tags would vote for this choice.

UI/UX Design

Since my professional background before game design was in UI/UX, the task fell to me. I collaborated with our illustrator to build out the UI.

Project Management

The programmer and I split up project management duty. We often used Google Docs or FigJams to get a birds eye view of the work that needs to be done. And then put in our weekly task lists into Notion.

I utilize the Now/Next/Future/Future+ system for prioritizing and organizng tasks and backlog. I was also QA so upon completion of any programming task, it was dragged to QA and assigned to me. I would either send it back or drag it to completed.