TALE OF TWO CROWS
About the Game
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. 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.
My Roles
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
I also performed a number of additional tasks, including:
Coordinating efforts of game designers, artists, and engineers
Integrating art assets in-engine
Implementing game systems into built levels
Iteration on gameplay systems
Bug fixes
Design Work (Designing Cooperative Gameplay in a Competitive Game)
One role I played on this team was gameplay designer. 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. After these failed attempts, I took a step back and tried to think about real-life situations where competitors are placed in a situation where they are forced to work together. The field of politics came quickly to mind.
In politics, “players” in opposing parties are sometimes able to come together and agree on things. They are often forced into these situations by external circumstances, such as the threat of government shutdown if a budget agreement cannot be reached. Through some give-and-take, they are able to come to agreements that neither party is truly satisfied with, but it avoids something worse. “Compromise” is a good word to describe this aspect of competitive-cooperative behavior.
Another possibility for cooperation between competitors is when they agree to something that is mutually beneficial. This can happen in business when two competitors both pitch in to make some external service more accessible to both of them, thus increasing their profitability in the long run.
With these thoughts on politics and business in mind, I created the following chart:
This chart is a simple mapping of competitive and cooperative behavior between two competing parties. The top-left box (HURT YOU) is normal competition, meaning that if we are opponents, I need no additional motivation to do things in this category. I would perform acts to hurt you simply because we are opponents. Similarly with the bottom-right (HELP ME), I need no additional motivation to perform acts that will help me.
The other boxes correspond to the cooperative situations I mentioned above. If we are competing, in order for me to be willing to help you there has to also be a benefit for me. And if something is going to hurt me, I may be willing to find some compromise to avoid it.
With these ideas on motivation in mind, my team and I worked on tackling the design issue of cooperative play in our competitive game. We had to come up with situations where there was mutual benefit if the players would work together, or an extra detriment if they were not willing to.
We came up with the following ideas that we implemented in the game. First, 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 for 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.
Second, a reason to attack the boss itself. Why attack the boss and stop the spawning of minions if you could just get more and more power-ups the longer it was alive? A simple fix was to put a cap on the stats a player could have, and we did add that. But we also modified the behavior of the boss itself to better encourage cooperation. The longer the boss stayed alive, the less it would spawn minions that drop health boosts. The minions would come in greater numbers, swarming both players. In this situation (i.e. if a game drags on because of a desire to rack up stats), the players are forced to work together to take down the boss to avoid being overrun.
In addition to providing players motivation to cooperate, we also provided opportunities to do so. For example, we modified the AI of the enemy minions so that they would follow and attack the nearest player. Players are able to exploit this behavior if they work together, with one player drawing away minions while the other takes shots at the boss.
My biggest takeaways from tackling this design challenge are that a lot of inspiration for game design can come from studying real-life institutions and behaviors. I also learned a lot about reward mechanisms and how they do not necessarily need to be tangible. Sometimes earning opportunities can be more rewarding than receiving something solid like a stat boost.
Learning Outcomes
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.
