Rome was a dangerous place. I’m not just talking about Rome’s many wars and conquests or the games at the Colosseum, but the actual city streets of Rome itself. Mob conflicts and political assassinations were not uncommon at the time. In fact, the threat of street violence was so high that an upper-class patron would be known to surround himself with a protective entourage of clients in order to navigate Rome’s more seedy areas unharmed. This entourage was a reflection of Roman social hierarchy, where patrons acted as benefactors that would support clients through their wealth and connections in exchange for various favors and services.
This is an important learning goal that we wanted to capture in our game about Roman history, Saeculum. Unfortunately, in our first run of the game, the combat sections were rushed. They appeared in a few sections (primarily at war), but they were somewhat basic. Enemy characters would simply rush at the player and could be defeated by rapidly clicking the mouse button to attack, resulting in a lack of player thought or strategy. The system was also somewhat inflexible and difficult to reliably integrate into various scenes.
Another issue with our first iteration of the game was a lack of gameplay or action. Most of the time the player was just moving from cutscene to cutscene without much direct input. For our newest release of the game we’ve addressed this in multiple ways, such as an action-oriented debate system (which will be explained in another blog post in the near future). However, early on we identified a more robust and fulfilling combat system as one of the key elements to filling this interactive void.
With that in mind, here were our key goals for the revised combat system:
- Teach students that combat, both in war and on the street, was a major aspect of Rome
- Communicate the importance of clients and a patron’s entourage
- Break up the narrative with fun and mechanically interesting gameplay
- Be accessible to casual players (especially considering our target audience may have individuals unfamiliar with games)
We arrived at a final system that was both real-time and in first-person. The real-time aspect works to keep players engaged with various actions and maneuvers, while keeping it first-person made the combat seamless and consistent with the rest of the game.
During combat, players will become engaged with a number of enemies of various types. By clicking the mouse, the player can attack with a weapon such as a sword or dagger, executing combo attacks with multiple clicks. Generally, the player is tasked with analyzing the enemy party composition in order to strategize which enemies to prioritize. Each enemy type has different attacks and tactics, so the player will need to move, attack, and dodge differently, depending on the enemy.
While we wanted to include plenty of action elements, we also need to appeal to players that had never played games before (which is common in an online educational course). At the same time, we also wanted to make player actions and decisions deliberate and interesting, as opposed to relying on twitch reflexes and rapid inputs.
To this end, we took inspiration from games like The Legend of Zelda and Dark Souls (with the difficulty turned way down). These games encourage thoughtful observation of enemies (particularly their animations) to inform tactics and strategy. Timing and opportunity is also an important element in these games, whether it be delaying an attack when the enemy is guarding or striking when a counterattack presents itself. By incorporating these elements into our combat, we have increased our design space to allow for more interesting mechanics, such as enemies that can shield themselves, or enemies that attack differently depending on the direction the player approaches them. This encourages thoughtful actions on the part of the player, but we’ve also made sure that there is enough leeway for mistakes and experimentation (and perhaps a little button mashing, just for fun…).
In order to make this all happen, we introduced a number of technical improvements:
- A Flexible Player System – Our new player controller uses a flexible state system that allows us to easily expand its functionality. This is used to create multiple player attacks as well as control how the player transitions between these states (which is useful for creating combo attacks).
- Custom Combat Animations – Previously, all of our animations came from Mixamo (a company that sells 3D character animations) since we didn’t have the technical expertise for 3D animation. This limited the number and kinds of attacks we could implement since combat gameplay is so tightly related to animation. However, we now have team members that can provide custom animations, enabling us to be more creative with our character actions.
- More Robust Physics and Collision Detection – Without getting into too much detail, our previous solution for detecting collisions (such as a sword hitting a shield) was very simplistic. We simply checked to see if any characters were overlapping a small space in front of an attacker, regardless of the attack or animation. This had all sorts of problems, such as not realistically following or matching actual attack animations, or registering an attack as hitting an opponent despite them shielding. Our new solution uses colliders that are customized for each attack animation, allowing us to include all sorts of crazy attack patterns.
- Separating Game Data from Scenes – This is a new paradigm that was applied to the entirety of our project and is deserving of its own separate post to fully explain it and its benefits. To put it simply, we used Unity’s ScriptableObject to create data assets separate from the game scenes themselves, which made it easy to edit and test combat encounters and attacks.
So far I’ve addressed all of our stated goals for combat… except for one. In my next post, I’ll explain how we integrated entourage into combat. I’ll also give a sneak peak at some of the enemy types we’ve developed!