Spartakids

Spartakids is a third person networked cooperative boss battler where players swap weapons and perks, working together to take out the boss.

Spartakids was made over 3 months for the 2022 Ubisoft Competition in the Unity Engine with a team of 8 people.

Gameplay and systems designer

Designing Combat

Player Actions

The combat of Spartakids started with the idea of taking on a giant monster and the first area we tackled was the player's actions. I knew with the limited time we had we needed to be careful about how much scope we took on. In our initial concepting meetings where we concepted the ideas we thought about all of the weapons we could create and how switching them could make for engaging gameplay. There were two major issues, the first was that each of the weapons needed to be distinct and have unique combat fantasies. We couldn't make a big sword that dealt massive damage with slow attacks and a big axe that dealt massive damage with slow attacks because then switching between them would not mean anything. The second major problem was scope as we only had ten weeks to work on this project total. After communicating with the programmers about what could be done over networking, we decided to go with two weapons: a ranged weapon and a melee weapon. While we could have made more weapons with unique playstyles, the separation of melee and ranged allowed for us to have broad archetypes for these two weapons.

Weapon concepts for Spartakids made by Alina Coffey

Compass bow and marker sword

After looking at all of the concepts we settled on a sword and a bow as the normal fantasy weapons and thought about how we could tie it back to the theme of student XP. We wanted them to be made of something that kids in school would have access to and created a sword made out of markers and a compass that was used as a bow. These allowed them to be believable in this child's imaginary world and with these settled on I started working on how they would function in game.

DPS based on weapon level

I started by creating a spreadsheet of potential damage and how it would scale with weapon level which would be gained in two ways. The first was by damaging the boss while the second was by the other player sharing their XP for that weapon. Additionally I started thinking about how to differentiate them. My first thought was because the player with the sword would be up in the bosses face, they should deal more damage or be more durable than the player with the ranged weapon. These thoughts had some major issues first of which is making sure the bow feels good as just making the sword better is not very fun. This is where how the boss interacted with the players started to really matter.

Boss Balance

This lead to the creation of a second spreadsheet which incorporated the boss into the equation. This also led to more fleshing out of the XP sharing mechanic and what it would look like. Because weapon XP was linked to boss damage, both weapons had to deal near identical damage to ensure that one did not completely dominate over the other. This led to more number crunching before it was deemed that this mechanic had spiraled far out of the scope of the ten weeks we had to work, so we needed to pivot. The pivot allowed the weapons to deal different damages opening up many doors. I decided to allow the ranged weapon to have higher DPS with a catch, the player had to stand still and charge their shots to deal maximum damage, while the player with the melee weapon had to engage the boss so it didn't attack the ranged player. This gave both weapons their own way to be unique in their playstyle while still allowing for balance. This still required us to come up with a new way to make the game interesting as just having weapons that swap would not be engaging for long.

XP and boss duration based upon player damage

Perk System

From here I designed the perk system, a much scaled down version of the weapon leveling and XP sharing systems I made earlier. Now at certain health thresholds the boss would initiate an arena wide attack that did damage over time until both players got into the safe zone that spawned. While they were in this area they would select a perk to get, swap weapons, and have the opportunity to swap perks as well. This allowed progression to still be tied to damaging the boss but not as strict in its requirements with weapon XP nor as complex as balancing around sharing XP. Additionally with the capability to swap perks, it opened up the opportunity for weapons specific perks that could tie into the mechanics of the weapons. Two great examples of this is a quick draw perk which reduced the amount of time it took for the bow to get to max charge, and the bladework perk which gave the sword extra damage and movement speed when they hit the boss.

Perk screen with a mouseover describing the rage perk

The idea for this initially was out of scope again as I designed the perks to have several levels and taking the same perk multiple times would level it up. The players had limited space so communicating with the other player to look for matches could be a large benefit. Unfortunately again this was slimmed down due to the limited time we had to finish and polish the game. Because of this I decided to ramp up the power of the perks to really make them feel impactful. This pared down version still had the communication between selecting and trading perks but without the overhead of needing to know the intricate mechanics of the game. An additional benefit to this system was there did not need to be as many intermissions in the fight leading to a smoother and a more fun experience.

Players selecting their perks, then swapping

Reflection

This game was a an excellent lesson on how to manage scope. Before this, I didn't fully understand how to balance between volume of work and quality of work. I made several extra mechanics that never got into the game because we didn't have the time to integrate them well so I should have been more focused on polishing the mechanics we could get in. The other side to this is knowing how quickly different parts of game development work. It is easy to come up with many different mechanics that could go in a game, but actively thinking through, prototyping, and testing them takes much longer. In this project I was unsure about how my actions would affect the networking so I was not as in build as I could have been. This gave me all the time to think through the mechanics but once it came to bringing them to the team and to implementing them, the whole thing fell apart. Additionally each of the mechanics would have needed art and sound, both of which were out of scope with the other necessities the artists were working on and the fact that we did not have a dedicated sound developer.

As I look back on this project, the second takeaway I have is knowing the place for different types of work. The mechanics I made were not necessarily bad mechanics, they just were not sustainable for this project due to many factors the primary one being scope. Knowing what and when to work on things is imperative. If we had a couple years to work on this instead of ten weeks, many of these mechanics could have worked with further iteration. This extends beyond complexity of mechanics and into other parts of game development. Working on the narrative of a game at the very end cane be difficult as all the mechanics have to be contextualized into whatever story is being told. Or it works the opposite way of the narrative being forced within a strict confinement of mechanics. The story does not have to be finished down to the final bit of polish before any mechanics can be worked on, but having a baseline to work off of is much more helpful than blindly working without knowing where it is going.