Gameplay Loop

The original concept for the game was to combine two unlikely genres: dating sims and collectible card games. It was a challenge to figure out how these two sections should intersect. 

In the final game, the dating sim portion was less in-depth than we had originally envisioned. Originally the dating sim would have taken up roughly half of a playthrough. There would be different outcomes depending on different dialog options, like collecting cards or gaining new insight into your opponent’s deck. We had to adjust the scope of this section because of the complexity of the card game. In the final game, the dating sim section ended up serving as a way for the player to regroup and strategize between battles. It became more of a complementary feature to the card game, which became more of a highlighted part of the overall game.

A Shift in Focus

As we rescaled the game, the overall gameplay loop became shorter and shorter. Originally you would be able to re-challenge the suitors, and dialog exchanges would be much longer. As the game got shorter, I decided to prioritize replayability in my design. I took inspiration from the rouge-like genre, specifically rouge-like deck builders like Slay the Spire and Baltaro.

To push into a more rougue-like design, I introduced more random elements. I built the shopping system, which would refresh its wares with random cards after each card battle. The shop helps make each playthrough unique, as it contrasts with the collection of cards you would get during each playthrough from defeating the opponents. This random element makes each playthrough feel distinct and unique, introducing another strategic layer.

To further incentivize replayability, I introduced a scoring system at the end of each playthrough. At the end of a game, the player would be scored on a scale of 0-4 (which correlates to the amount of characters they defeated). This was a quick and effective way to make the entire gameplay loop feel much more conclusive. The player is encouraged to play the game again to reach a better score.

Card Game Design

Design Philosophy

We only had 3 months to build Queen of Hearts, and a large portion of development time was dedicated to the dating sim portion. Because of this, it was important that I design a simple card game that could be easily implemented into the game engine.

In traditional trading card games, the player would choose which cards would attack, who their targets would be, who would defend, etc. We didn’t have the luxury to integrate those many systems. Because of that, a lane based card game was a good fit for Queen of Hearts. Those systems could be streamlined into simple phases, where attacking and defending are done at the same time and there is no need for targeting.

Paper prototype

Before building it in Unreal, I made a paper prototype version of the card game. This was the sole version of the game for the first 3 weeks of development. I was able to iterate on this game several times, which allowed me to polish it and fix design issues before we spent development time translating it into the game engine.

Teaching the Player

A challenge we ran into was how to teach the player the card game. I made a tutorial sequence at the beginning of the game. This was lifted from a document I had typed for the paper prototype- playtesters read it before playing. The tutorial sequence walks the player through all the relevant aspects of the card game. I also included a quick help button during gameplay which brought up a diagram of essential rules and mechanics.

A common issue we had in playtesting was players not understanding how combat damage works. Basically, whoever takes more damage during a combat phase would take their total damage, minus their opponent’s total damage. For example, if Player 1 took 5 damage and Player 2 took 3 damage, then Player 1 would end up taking 2 damage.

I illustrated this in gameplay by having a UI element, which would directly explain what was happening in a combat phase.

Eventually players got the hang of the system, however I think there is a more elegant solution. If I were to continue to work on this game, I would make it so the damage that is tallied during a combat phase is distinct from the damage that is given at the end of a combat phase. I think these values should have separate terms, the final value that actually affects the player’s health could be called “damage” while the value that is tallied up to determine “damage” could be called “hits.”

Production

Queen of Hearts was my first producer role on a project. I managed the timeline for the project, including all the sprint goals and build milestones. Of course, our timeline had to constantly adjust as development went on. It was my job to adjust our timeline and manage our scope.

I also managed secondary deliverables: presentations, playtest summaries, and the post mortem discussion. I particularly enjoyed representing the team during presentations, and answering the questions that came up.