Dual Eclipse

Unity Engine

Development Start: January, 2024

Release Date: September, 12th 2025

PLAY GAME

In early 2024, I knew I wanted to push myself beyond prototypes and game jams. I wanted to ensure I was taking the steps needed to become a professional Game Designer. There were many lessons I could only learn by taking an idea and fully developing it from start to finish.

This game was effectively my Frankenstein. There was no tutorial for making a trick-taking dungeon crawler. I combined various Udemy courses, YouTube tutorials, and Unity forum posts to bring my idea to life.

Below I’ll describe what went well, the challenges I faced, how I overcame them, and what I would do different in future projects.

Project Organization

Throughout the development of Dual Eclipse I was fully employed in research grant management at UCLA, so I needed to utilize my personal time wisely and establish really strong structure. Thankfully I had years of experience managing complex projects, so I already had a strong sense of how to organize workloads and target deadlines.

Trello was an essential tool for tracking and organizing tasks. I could quickly create cards that I color-coded for urgency and the type of task. At a glance I was able to determine what kind of work needed to be done, what kind of bugs I needed to address, and organizing priorities.

Once a task was complete or changed to a different status, I would move it to the appropriate column. This created a clean process where items moved from left to right on my Trello board. I was never confused about the status of my project and able to maintain focus even during my busiest times.

DOTween leveled up ‘card feel’

DOTween is an asset for Unity that offers a library of efficient tween animations and C# features.

The early implementation of ‘card feel’ was quite dull. There was no reaction to selecting a card at all. During development I grew more familiar with DOTween and begun to connect that dots with how ‘card feel’ was handled in Balatro. It was clear I needed to animate card visuals without disrupting the basic functions of the Card object and its logic.

A major lesson I took away from my early days of learning development in Unity, was to utilize Child Objects intelligently. Each Card was effectively a Game Object with various Child Objects containing UI components. This allowed me to easily Tween the Image Component by using some built-in Unity Events.

OnPointerEnter
- Tween to pop this card up.
- Enable this card’s Selected Shader.
OnPointerExit
- Tween to pop this card back into position
- Disable this card’s Selected Shader.

You could now strum a hand of cards back and forth while considering your next move. It felt fantastic! Not only was ‘game feel’ improved, but there was now greater visual clarity as well.

The lessons I learned improving the ‘card feel’ in Dual Eclipse will greatly improve my how I organize and implement ‘game feel’ moving forward.

Left: Early implementation of the player’s hand of cards. Right: Improved ‘card feel’ using DOTween

Player Feedback is more than feedback

Don’t just correct design problems, but embrace player misunderstandings as an opportunity for new great ideas. Avoid tunnel vision, but don’t get crazy.

Design a tutorial for ‘Player Zero’

An early build of Dual Eclipse attempted to follow a Balatro style of teaching mechanics through experimentation, success, and failure. When I started to put the game in front of people, they were confused and deeply reliant on asking me questions. The difficulty was tuned to my own perspective, so it was also too hard. Players were hitting a brick wall instead of an on-ramp.

Games like Balatro and Slay the Spire had Poker or Magic: The Gathering to lean on. Even if you don’t player Poker, you likely understand what a Pair or Full House is. Trick-takers are not as widely known (especially in videogames) and my game was already experimenting with trick-taker norms.

In my excitement to design an original trick-taker system, my unintended hubris presented me with the problem of needing to both convince and teach new players an unfamiliar system.

My first instinct for this problem ended up being informative, but boring. I turned the wheel too hard and prepared a tutorial at the start of a new game that walked through a full combat encounter. This iteration of the tutorial had a structured order of cards to player and covered the full aspects of trick-taker combat. While it did succeed in preventing confusion, it failed at convincing ‘Player Zero’ to give it a chance.

The ‘Player Zero’ I am referring to is someone who has a strong aversion to the game you are making. Someone who is going to groan when they hear card combat. Someone who is going to read the tutorial and retain nothing.

The weeks of work on the structured tutorial ate up time in development, but it was invaluable for my growth as a designer. I’m glad I went through it, because it made me understand how easy it can be to get trapped in a designer bubble and how to let go of work for the greater good of the project.

I used a State Machine to organize the various phases in Dual Eclipse so I did simple checks when entering combat states to create a dynamic tutorial.

Is this the start of the player’s first combat encounter? Is this the player’s first Parry? Has the player cast a Spell yet?

The final iteration of the tutorial was designed around telling the player about mechanics only when they were relevant. Additionally, the difficulty of the first level was tuned down significantly. What I saw from new playtesters was room to make mistakes and learn the game in pieces. I had circled back to my original goal of learning through playing by focusing on a dynamic tutorial system.

Despite this major improvement, there was a lot I would do differently in the future. I had structured my Combat System around a full hand of cards and all suits. This had the potential to overwhelm new players and certainly did not address the concerns of ‘Player Zero.’ It would have been much better to start with less cards and less suits. This way the player only starts with a few decisions and the complexity naturally ramps up with the progression of the game. Not only would a new player get easy wins that felt good and taught them mechanics, they would tie the evolving complexity to their own progression. I will absolutely take this experience and the lessons I learn with me into future projects.

Important systems deserve good UI

One of the accomplishments of the UI in Dual Eclipse is that everything has a tooltip. If you aren’t sure what it does, you can hover over it and get info. After my troubles with the tutorial, I had to make sure players were having fun and understanding the game. I put a lot of effort into consistency of language and clarity in these descriptions. This was worth it, because the improvement to player understanding was very noticeable during playtesting and the release of the game. As the game evolved, I had to evaluate the workload of implementing UI.

There was already a lot of UI on the screen and a lot of information. The last thing I wanted was for players to have to toggle back and forth between screens and break immersion. My solution was to push the tooltips philosophy to the max. All temporary, permanent, and enemy effects were added to the main screen. This shortcut to adding complexity without requiring new screens of UI helped reduce the workload significantly, but it also pushed a busy UI to be even busier.

At the end of Dual Eclipse, Class effects that impacted cards were on the opposite side of the screen as the cards themselves. A player needs to look back and forth the screen to connect these fun mechanics. This didn’t encourage a player to fully embrace the connections I had designed for them.

Juggling the UI workload and producing a final result that is quite busy helped me understand the importance of planning systems and the impact on UI. A good system deserves good UI and the connections between these systems should be as legible as possible.

Backstabbing with Linear Algebra

An important design pillar for Dual Eclipse was to have 3 distinct classes and the Rogue deserved the iconic backstab ability. Many solutions to enemy engagement were solved by the node system I had implemented. The world was essentially a board of 2x2 increments, so I could always search one node away to check for an enemy. The problem was that these nodes only accounted for distance, not direction.

I didn’t know how to resolve this at first and my imagination went wild. I started thinking about creating child objects that would be triggered only from behind and that the player could have a child object in the front that only checks for these triggers on the back of enemies. Confusing? Yup! This clearly was a mess of a solution and it was time for Linear Algebra to save the day.

After some research, I landed on using Dot Product and Unity has Vector3.Dot defined. Additionally, I was already aware that Unity had Tranform.Forward defined as well. In short, I could compare a target’s Forward Direction against the Forward Direction of the one engaging.

Dot(Vector3 target, Vector3 engager)

The dot product from this function would provide me with a normalized float between 1 and -1 that would help me determine if one object was in front or behind.

The resulting logic was simple: when engaging an enemy, verify if it is from behind. If so, a backstab occurs!

Not only was this a much more elegant solution, it was also reusable for enemy behavior. The script wasn’t dependent on any player components, so the same logic could be easily repurposed. Now enemies were able to surprise the player from behind as well.

The big lesson I took to heart here, is to know when to pump the breaks on a ‘bad solution’ to a problem. It’s easy to start sprinting for a solution, but sometimes you are tired, stressed, or just need to a moment to digest the issue. Reflecting on the greater impact of a project is just as important as doing the work to get it done.

Cohesive Design and Worldbuilding

Portal to Velus had logical connections; movement between areas was not rdanom, but connected to themes. Followed the narrative path; very little backtracking or none