Breach the Castle, Kill the King

A single room with a perfectly executed plan.

Breach the Castle, Kill the King is a cooperative action dungeon crawler. It is intended for exactly four players, each taking on the role of a simple but distinct character: Mage, Hunter, Warrior, and Rogue. The Mage can shoot a fireball that explodes and can hit multiple enemies at once. The Hunter can quickly fire a bow and arrow to hit single targets. The Warrior has a short ranged sword but can take an extra hit due to their shield. Finally, the Rogue is also short ranged but can sneak through doors and past enemies without alerting them.

Enemies have their alert level over there head, showing how quickly they will respond when they see a revealed player. This, along with enemy type, helps players inform which enemies to prioritize in a given room.

Because almost everything, including the players, dies in one hit players have to be very careful. The gameplay loop consists of cooperatively making a plan for how to tackle each room then experimenting and refining that plan until it is distilled, efficient, and repeatable. Respawning is quick, and players have to beat a certain number of rooms in a row before earning a checkpoint, which means players may be beating the same room multiple times in succession. This can certainly be frustrating but it’s also satisfying to know a room is “solved,” especially because each room only takes a few seconds once it can be do it consistently.

Genre: Coop Action Puzzle
Timeline: Original Demo made in June 2023, work continued throughout 2023 and 2024
Engine: Unity
Platform: Windows
Team size: 2
Responsibilities: Concept, Programming, Design
Itch Page: https://buildsgames.itch.io/breach-the-castle-kill-the-king (Download the demo!)
Github: https://github.com/WillyBMiles/BTCKTK-Scripts/tree/main

Highlights

• Four players with simple and unique abilities work together to plan an attack on a room that only takes a few seconds to complete.
• Each room is designed like a puzzle with the added skill test of perfect execution. Though each room can usually be completed multiple ways, some methods come with a higher burden of execution enabling players to iterate on their solution if they need to retry.

Challenges

• At first, enemy behavior was too easy to exploit by slowly moving around corners and shooting the enemy before they could even spot the player. This dominant strategy was slow and boring when the game was supposed to be snappy and explosive. Extra safeguards were put in place to prevent players from undermining the intended gameplay loop: enemies detected you quicker and didn’t care much for walls.
• Game designers rarely strive for repetition. I used it as an asset. Each room only takes a few seconds to complete when done perfectly, which forces players to make interesting mistakes and pushes them to become reckless.
• Creating plans and perfectly timing those plans was difficult when everything was precise and relied on each other. Especially in later rooms it became difficult to tell what the plan was and when it would occur. To solve this I added a system of pings that let players both ping an enemy to claim them and to start a global timer that counted down “3-2-1-GO” to help coordinate attacks.
  

Combat must be brutal and unforgiving, but also knowable and fair. This is especially relevant for the archer enemies that do not move. In order for the concept of the game to make sense, rooms must actually require teamwork and good timing. I wanted to do this while preserving game feel and the expected controls of an action dungeon crawler. So, I needed to let the enemies cheat.

In early itertions of the demo, players easily outsmarted the enemies as the ranger by slowly peeking out from a corner and shooting an enemy before they could be spotted. This undermined the game’s main conceit by allowing a single player to complete rooms without even forming a plan. A simple center to center-style player detection system would clearly not work.

This enemy is on high alert, meaning they will attack the player instantly. There’s simply no way to get past them without getting killed.

public (Vector3, Vector3) GetVisionExtents(Vector3 origin, bool addTowards = true)
{
    Vector3 right = Vector2.Perpendicular(transform.position - origin).normalized;
    Vector3 towards = (origin - transform.position).normalized;

    Vector3 add = addTowards ? towards * radius / 2f : new Vector3();
    return (transform.position + right * radius + add,
       transform.position - right * radius + add);
}

The method that calculates the left and right extremes of a player perpendicular to where the enemy is looking. This ensures they always see the edges of players right as they become visible. Adding towards ensures enemies have a slight advantage in hitting players before they can ever be hit.

I redesigned the system to raycast from the centers of enemies to two points on the edge of each character to determine if an enemy should engage that player. This was a bit better, though a quick player could still take out an enemy with just the right angle. This would not do. The final iteration of the system allows archer enemies to cheat. They can detect a player before they even turn the corner, before the player could ever have a chance to hit them. The arrow does not check collisions with walls and it moves so fast that it’s undodgeable. If an archer enemy wants you dead, you’re dead.

This system worked well for the host, but in a multiplayer game all players should have a good experience. Clients are given authority for their own objects and attacks. The clients send messages to the host to tell it where they’re going and when they’re attacking. The client also determines which enemies they’ve hit. This allows the client’s game to show enemies are dead when the local player hits them which is more satisfying than waiting for a round trip to the server for that information. Unfortunately, because enemies are server authoritative, the corner problem reappears as a client can pop around the corner and kill an enemy before the server has time to respond.

So, the final system also gives clients authority over when the enemy attacks. The client will run the same raycasts and attack patterns as the server. It then sends a message to the server when they’ve been hit and killed so that they will die just as fast as the server without needing to make a round trip

List<RaycastHit2D> tempHits = new();
bool Hit(Collider2D collider)
{
    
    if (!NetworkController.instance.hitboxes
      .TryGetValue(collider.transform.gameObject, out HitBox hb))
    {
        if (hitSound != null)
            AudioSource.PlayClipAtPoint(hitSound, transform.position);
        return true;
    }
    
    if (mustHaveVision && 
      Physics2D.Raycast(origin.transform.position,
        hb.transform.position - origin.transform.position,
        origin.visionFilter, tempHits,
        Vector2.Distance(hb.transform.position,
        origin.transform.position)) 
       > 0){
        return false;
    }

    if (!canHit.Contains(hb.character.faction) || //can't hit characters out of faction
        (hb.character.dead > 0 && hb.character.dead != id) || //can't hit dead characters usually
        charactersHit.Contains(hb.character)) //can't hit same character multiple times
        return false;
    charactersHit.Add(hb.character);
    if ((HasAuthority && hb.character is not PlayerCharacter) //if not player character authority matters
        || PlayerCharacter.IsLocalPlayerCharacter(hb.character as PlayerCharacter)) //if player character only the local player character decides
    {
        if (!dontApplyEffect)
            shape.ApplyShape(id, abilityIndex, origin, transform.position, hb.character);
    }
        

    if (hitSound != null)
        AudioSource.PlayClipAtPoint(hitSound, transform.position);
    return destroyOnHit;
}

Standard hit code. Damage actually goes through authoritatively only if an enemy hits the local player or the local player hits an enemy, otherwise it’s just visual.

Combat design in Breach the Castle, Kill the King draws many parallels with puzzle design in other games. A primary difference between the two is a higher emphasis on execution in this game. Even if the players know the final “solution,” getting the proper timing and precision can still cause them to fail, particularly with four different players all trying to coordinate together. Traditional wisdom in puzzle design says that once players know the solution to the puzzle it should be easy to complete to avoid frustration.

I wanted to flip this and make the players think more about ease of execution as an element of the puzzle. Each player’s unique character class excels at different tasks. Could the assassin quickly kill 3 enemies at a table? Probably, but the mage’s fireball will do it a lot easier. This becomes part of the puzzle as players figure out which classes can take out multiple groups of enemies in which situations.

A fairly standard room. A difficult to reach enemy for the Rogue, a high priority archer for the Hunter, a table of enemies for the Mage and some close range threats for the Warrior. Is that the best way to complete the level though?

Similarly, the game tests players’ ability to repeat their solutions. Most rooms are doable in multiple ways, but the timing may be tighter and mistakes may be more unforgiving with some solutions. The game only gives a checkpoint if the players can complete three rooms in a row without everyone dying. This generally means completing the first two rooms in a row without anyone dying as well; rooms are quite hard to complete without all four players. Players often repeat the first two rooms several times before completing the third room and so are incentivized to devise solutions that are forgiving and repeatable.

These considerations inform how I design rooms. The first two rooms in a set are generally easier and have more of an obvious design, while the third is often more complicated, obtuse, and requires more precision.