top of page



Tale of Two Crows is a top-down competitive arena shooter with cooperative gameplay elements. Each game begins with two players working together to defeat minions of the plague, culminating in a co-op boss fight.


At the end of the boss fight, the game shifts into a PvP game, and the last player standing is crowned the winner. During the co-op portion of the game, each player can collect power-ups and health pick-ups to give them an advantage over their opponents.

Tale of Two Crows was made by a team of 11 using Unreal Engine 4. It is a prototype created over the course of one month as part of the Master of Entertainment Arts and Engineering program at U of U.


In addition to my role as a game designer, I also worked extensively in-engine to build our game using Unreal Blueprints. For the first half of development (about two weeks) my team had only 5 members (including artists and designers), but I was the only one with experience in Unreal Engine. Therefore, much of the initial work of building the game fell to me. I took on much of the responsibility of building our initial game from the ground up, including:

  • Player mechanics

  • Enemy mechanics/behaviors

  • Boss mechanics/behaviors

  • Level events/triggers (i.e. level transitions, door triggers, etc.)

  • Game state (player health, win condition, game-over end screen, etc.)

  • Local multiplayer

  • UI


Designing Cooperative Gameplay in a Competitive Game: Challenges and Theory

The Challenge: Exploitation Instead of Cooperation

Because the game is a competitive game but involves PvE elements, one of the fun, yet difficult, design challenges we faced was how to get competing players to cooperate.


We came up with several ideas that fell apart because one player could use them to exploit the other player and prevent cooperation from happening.



Designing Cooperative Gameplay in a Competitive Game: Solutions and Implementation

Solution 1: Stat-Boosting Power-Ups

The first thing we needed was a reason to attack and defeat the minions that the boss would spawn. Some players of the game would refuse to shoot enemy minions as they could be an obstacle and a detriment to their opponent.


We solved this issue by having some minions drop power-ups upon defeat that players could collect to get boosts to health or other stats.


This encouraged players to actually fight the minions, even when they swarmed their opponent, because there was benefit to them in the form of stat boosts.





In addition to the previously mentioned lessons I learned about game design and reward systems, this project taught me a lot about the value of scoping down and focusing a game’s development.

Halfway through development (about two weeks in) our team doubled in size. The new members brought much needed fresh perspective and their own ideas about improvements and polishes that could be done to the game. At first, we thought we would be able to implement many new ideas because of the increase in manpower; however, we quickly learned that despite the extra hands we wouldn’t be able to add everything we wanted. For example, we had plans for additional boss mechanics. The boss would have a tail attack in addition to his minion-spawning breath attack. The boss arena itself would also have extra triggers and interactables that could help the players and provide more motivation for cooperation. 

However, after looking at our time-table and resources, we realized that these added mechanics wouldn’t be feasible to put into the game by our deadline. As a team, we decided on what work would take priority and what would become a stretch goal. As we focused down the scope of our game, we were able to take the time needed to really polish the systems we had. The game we ended up with was not as grand as the one we had planned for, but it was one we were happy with nonetheless.



bottom of page