Shadow Over Karth is a 2D action combat game about a man on the search for his kidnapped family.

Project Highlights

Working on Shadow Over Karth

When making the original conceit for this game, the plan was to originally focus on narrative and use that as the primary force of engagement and have the hybrid combat system simply be an extension of that narrative. After setting up the original combat system though, I got a little carried away with extending out the combat and building complementary systems to help make it more fun. Hence why I put so much emphasis on developing different enemies, progression, and levels with less time spent on dialogue, storytelling, and worldbuilding. I felt this project ended up well and the combat feels pretty good. It also gave me a great opportunity to design and build some combat mechanics that I wanted to get experience with.

The largest element I pulled from CrossCode is how they use the cursor to determine if an attack should be ranged or melee. While this mode is only an affordance on PC, it feels fluid when the change in state is clearly shown to the player. This approach also works well when you think about where a player’s cursor is when playing an action game like this. It is often on the enemy they want to attack, so letting the distance between the foe and the player determine what type of attack happen is fine, because the player initiating an attack implies the intended range of that attack. This system also affords the ability for players quickly move from target to target, since their attacks are only limited by the target they are selecting, allowing players to blend a melee kill into a snipe on a faraway slime.

But why should players use both? Why not just run and use the melee attack all the time, since it is much more accurate and lethal? This is a problem that does need to be considered. My solution was to interlock the two types of combat, so the player needs to use both or risk death. I do this through the ammo economy and enemy types. Using melee attacks earn you ammo, which you can then use to make ranged attacks, and players will always be needing more ammo. The ammo economy allows me to frame your ranged attacks more like an ability, than a staple of the system. Having players think this way attempts to get the player to remember they have access to this extra attack, since using it feels good. I will expand more about enemy design in that section, but the idea is to make enemies that need you to use both attack types.

If I were to keep developing this system, I would want to look at the balance combat options. Dashing is the only defensive move the player has and it is strong, often allowing players to stack dashes and be immune. I would want to investigate adjusting the cooldown between dashes to be a little longer. Quick attack and heavy shot are both in a good place and I feel as if they are in a good spot where they are. Heavy attacks are a little too strong, like dashes I would want to add cooldown time to make it less potent. Light shots are underused since heavy shot appears to do more with less effort. I would want to investigate apply a bonus effect to the shot, such as a slow, so players can use it as suppressive fire and kite away. I would also love to do some work on the feel of each element, as almost all actions need some VFX, SFX, and stronger feedback.

Enemies are designed with the intent of creating diversity in players attack patterns. Enemies such as slimes or constructs are hard to hit with melee attacks, implying the use of ranged attack to defeat them. Enemies like the wizard will have players dodging to avoid attacks, making attacking enemies in a specific pattern difficult. These are intentional and encourage the player to use their whole skillset to beat challenges.

One thing I did well when planning out my AI was considering my enemies as a template. This approach allows me to have 4 AI/behaviors but have 7 different enemies. By simply tweaking some values, I can make a whole new enemy, that encourages players to approach the encounter differently. Green and blue slimes demonstrate this well, as the blue slimes force players to kill them or take the damage, something the easier green slime does not care about. These small variations also help keep combat feeling fresh, as it feels as if there is more to fight and learn.

An area I think is weak is my encounter design. Levels in this game were slotted low on my priorities, so my encounters are somewhat rushed and not as polished as they could be. I had some good ideas, but areas could totally use some polish. Another aspect that could use some work is reducing how relentless the AI can feel. Simple "move to player" logic makes their pursuit endless and makes combat overwhelming. I think finding ways to diversify movement so they do not just run at you could make them feel more real. I also think looking into staggering could be cool, as this gives players the ability to help control the speed of the battle when necessary.

Progression Design in Shadow Over Karth

The progression system I have implemented for Shadow Over Karth is simple but works well for what I needed it to do. While progression originally was not something, I intended on doing, something players mentioned during playtests was that they felt the enemies kept getting stronger, but they are not at all. I needed some sort of reward structure that the player would want and use. With limited time to develop new content entirely, I instead looked to provide upgrades through simple stat changes.

The general Idea behind this system is to have the player earn XP through defeating enemies and to then provide breaks where they can spend that XP to upgrade their abilities in any way they like. A big focus for me was also allowing player to reverse upgrades, in case they felt as if an upgrade was not worth it or if they want to try a different setup. My favorite part of this system is the XP itself, as I love how they magnet to the player and show how many were collected, contextualizing for the player how tough an enemy was.

Dialogue System in Shadow Over Karth

This game was my first attempt to try and make narrative and story a major focus of the game. Since my narrative design skills are limited, I decided that the best way to develop my story would be to make a dialogue system that I could use to build character and create a plot. While the dialogue itself is not the strongest, the system I built for it works great!

The general idea behind it is having a dialogue listener on the player that reads the object it is interacting with to know which conversation to pull from a database of all talks. It then fetches a class containing all the dialogue and information to display in the window. Once all the things have been said, the conversation ends. The listener then checks if there are events based off the dialogue ID and runs those events if they are there. Option select is done by nesting dialogue containers and treating decisions as the start of a new holder. If a path were to cause the conversation to stop, the class could jump out of conversation at any point and run the post-events.

I think the system I made works great but would love to see better interfacing with the system. Dialogue is written as code in classes and figuring out where a conversation goes can be complex. Events are all laid out as an if statement that has to be edited or expanded on manually by references the dialogue ID. one way, I could tackle solving this would be looking into importing external files that will create all the needed dialogue, making the writing process much easier. Another solution is Building a GUI that work like a behavior tree.