Dark Energy

Heroic moment. The teal ship charges through the choke point to revive their teammate under fire.

Dark Energy is a 2D Soulslike with a focus on multiplayer teamwork. I emulated many of the classic features of the genre. These include earning “souls” from killing enemies that you use to level up certain statistics. You lose all your “souls” when you die and have one chance to pick them back up again. There are items hidden in alternative paths throughout the world that can give you alternative attack patterns. You have a certain number of healing items that you get back when “resting,” which also respawns the enemies. Combat is slow, deliberate, and impactful.

This game is still in development, though it is on pause. We still have plans to eventually release it. The primary barrier to that is finding a dimension where we can differentiate ourselves from classic souls likes. Ideas we’ve had include: roguelike upgrades that reset when you rest, a deck building element that replaces items, or a heavy commitment to skill trees. None of these ideas have made it past ideation.

Genre: Coop Soulslike
Timeline: Worked on throughout 2024
Engine: Unity
Platform: Windows
Team size: 2
Responsibilities: Concept, Programming, Design, Art
Itch Page: https://buildsgames.itch.io/dark-energy (Try the demo!)
Github: https://github.com/WillyBMiles/Dark-Energy-Scripts

Highlights

• Synchronization was simplified by making every attack and ability in the game into an animation that can be synced by a built-in animator syncer.
• Combat is slow and deliberate, forcing the player to learn moments of weakness and attack patterns to efficiently deal with combat situations.
• Level design effectively tutorializes each enemy by introducing more limited versions of that enemy before allowing the player to fight a full powered version.

Challenges

• The animation based system is prone to bugs. Due to the way that hot-swapped animations work, the synchronization code required more and more manual intervention. As the number of abilities grew, more needed to be added to the player base prefab. Switching to an item-animation system rather than a character-animation based solves both problems.
• Large connected areas meant a lot of performance loss when pathfinding and pushing updates to a large number of enemies at once, not to mention the network cost of synchronization. Robust interest management prevent too many objects from running at the same time. A memory based pathfinding solution turns a computationally difficult task into a simple table look up.

Animator for player ship. Most animation states represent a trigger types for one of the item slots, for example, light, heavy, and sustain.

As is tradition in the genre, attacks and ability are uncancellable but interruptible by damage. This extends to literally every action in the game other than moving. Each action exists as a state on the player’s animator, and the animation triggers everything.

The animation itself contains most of the info for the action, including timings and hitboxes, but also any dashing or self targeted effects like invulnerability from dodging or damage reduction from shielding. This is all triggered through animation events or just directly changing values or bools on scripts attached to the ship. 

The main aspects that aren’t stored in the animation are any values that are affected by items and player stats. Any item effects are stored in a ScriptableObject for the item, the same one that contains the animations, as well as it’s name, icon, description and other information like that.

Speaking of items, each weapon and “tool” has it’s own animations associated with, for example, light and heavy attacks, but the Animator only has states for two different weapons and one tool. When you swap weapons or tools the game swaps the animations associated with each state for the ones from the newly equipped item.

This system makes a lot of sense because the player can only be in a single state at a time which matches the design, though it is somewhat inflexible if that design changes. Additionally, it meant I could use Mirror’s built-in Animator syncer to sync all of the abilities for me.

However, there are two major problems with this approach. First, animations belong to the player GameObject rather than the items and are used in its animator. This means every hitbox, animation, effect and so on from each item in the entire game needed to stored on the player prefab. This makes the player prefab huge and unwieldy and, because animations rely on the specific hierarchy of the GameObject, it means the hierarchy can’t be changed for better organization.

The second problem is functional. Because every object is stored on the player, the idle animation for the player needs to reset every item to default. This adds more possible points of failure and more busy work when a new item is created. More importantly, it means that whenever a player switches items it must always visit the Idle state firs, otherwise multiple effects may play at the same time. Unfortunately this creates a major tradeoff. the game is networked so it’s hard to guarantee that sequence of events when looking at another player, especially using the built-in solution.

Luckily, both of these problems can be solved by making each item its own GameObject with its own Animator. It does mean I’ll have to sync item switching myself instead of using the out-of-the-box solution, but it’s worth it for the extra stability.

The animator for enemies. All enemies use the same animator controller. It’s very straightforward, allowing up to 10 separate attacks. All enemies share a single death animation so that doesn’t need to be its own state.

The state for this enemy. The nearby enemy will likely be defeated before the players before this enemy is approached.

The second encounter is two of them in a choke point.

These values can be changed to affect the enemy as well.

The shielding enemy has no attacking states.

Unity does not natively have a 2D pathfinding system, so I decided to create my own. My main goal with the system was to make it as efficient as I could. I knew that pathfinding is a performance hog and I didn’t want to have to worry about that.

My first order of business on that front was to define my graph for pathfinding. I manually placed nodes throughout the level, such that anywhere that the player could go would be seen by at least one point. Additionally, I ensured that all topographical loops or paths that could be traversed by travelling from one node to another.

Each green node is a node on the pathfinding graph.

Every node holds a precalculated path to every other node.

After placing these nodes I can press the “Precalculate” button. The code for that is reproduced here. Essentially, each node keeps track of their immediate neighbors and the distance between them. Then it recursively pathfinds to every other node in the graph and records the adjacent node that an agent should travel when travelling from the origin node to any final node.

This entire process is done in the editor and stored on the nodes. This means that runtime pathfinding is just a matter of figuring out which nodes to travel between and then looking up the proper path. The system presents a major tradeoff of space for efficiency, needing to store the path between all nodes but massively speeding up in game pathfinding.

    public void Precalculate(bool chain)
    {
#if UNITY_EDITOR
        allNodes.Clear();
        allNodes.AddRange(
          FindObjectsByType<Node>(FindObjectsSortMode.InstanceID));
        foreach (Node n in allNodes)
        {
            n.FindAdjacent();
        }


        foreach (Node n in allNodes)
        {
            n.FindAllPaths();
            UnityEditor.EditorUtility.SetDirty(n.gameObject);
            UnityEditor.EditorUtility.SetDirty(n);
        }
        
        if (allNodes.Count > cameFrom.Count)
        {
            Debug.LogWarning("Node graph is unconnected!");

            int minimum = int.MaxValue;
            Node minNode = null;
            foreach (Node n in allNodes)
            {
                if (n.cameFrom.Count < minimum)
                {
                    minimum = n.cameFrom.Count;
                    minNode = n;
                }
                    
            }
            Debug.LogWarning($"Least connected node: {minNode.name}");
        }




        foreach (Ship s in FindObjectsByType<Ship>(FindObjectsSortMode.None))
        {
            s.Precalculate();
            UnityEditor.EditorUtility.SetDirty(s.gameObject);
            UnityEditor.EditorUtility.SetDirty(s);
        }

        foreach (ManagedInterest mi in 
          FindObjectsByType<ManagedInterest>(FindObjectsSortMode.None))
        {
            mi.Precalculate();
            UnityEditor.EditorUtility.SetDirty(mi.gameObject);
            UnityEditor.EditorUtility.SetDirty(mi);
        }


        if (chain)
        {
            NodeGroup nodeGroup = FindObjectOfType<NodeGroup>();
            nodeGroup.Precalculate(false);
        }
        
#endif
    }

Node groups hold all nearby nodes and ships.