Developing The Spell Brigade, Online Co-Op Action Game About Wizards

The Spell Brigade builds on the “bullet heaven” formula but adds full four-player co-op. What were the earliest design goals when adapting a traditionally solo genre into a multiplayer experience?

Gianluca: The co-op was there from day one. The very first prototype already had that built in because we needed to verify whether or not the bullet heaven chaos times 4 would be manageable. Another important design goal was to create this sense of camaraderie while still being able to damage each other. It made for a unique vibe between players where they would try to help each other out, even though it could backfire because of their insane power output. This aesthetic is kinda what we focused on for The Spell Brigade – a bunch of derpy wizards that are way too powerful for their own good.

The very first prototype we built:

In a few weeks, we had something like this:

From a technical standpoint, what engine are you using, and what made it the right choice for handling large numbers of enemies, projectiles, and multiplayer synchronization?

Luk: We didn’t actually pick the engine based on these requirements. Instead, we looked at how the knowledge of engines was spread in the team. Since all of us have worked on projects in Unity before, and we didn’t feel there were any hurdles we couldn’t tackle with Unity, the choice was unanimously made to go forward with this engine.

Unity has plenty of solutions ready to tackle any technical issue we come across. 

Bullet heaven games often involve thousands of entities on screen at once. How do you approach performance optimization across gameplay systems, rendering, and networking?

Luk: From the get-go, we decided that we wanted to approach optimization pragmatically. That means no premature optimization, but a conscious approach where performance problems get tackled when they arise, and benchmarks aren’t met.

We have guidelines in place for systems that are known to be performance bottlenecks. One instance of this is how we wanted to handle animations of hundreds of enemies at the same time. Whenever possible, our enemies use vertex animations to reduce the pressure on the CPU and offload this to the GPU.

One of the first tests of our vertex animated enemies in a group: 

Fundamentally, how do you differentiate between a bullet heaven and a bullet hell game?

Gianluca: In a bullet heaven, essentially, you are the bullet hell. But in our game, it’s a bit different, because if you’re playing a bullet heaven game with 3 other players, that means multiple bullet hells is going on as well. So we like to say we’re kinda both. There are some enemy attacks that also have bullet hell patterns, so your positioning is key to survival. That’s what we love about this genre. Because the input is so simple (basically just moving around), as a designer, you can look for more subtle ways to add complexity to a very accessible game.

Can you walk us through your core gameplay loop from a systems perspective – how enemies, spells, upgrades, and progression all interact under the hood?

Gianluca: To summarize our core loop, you run around and use your spells to kill enemies, gather XP, and level up, so you can get new upgrades. In between, you try to find items that can make you even stronger, as well as complete side objectives that can give you augmentations, which are stronger, more unique upgrades that alter the way your spells work. If your spells gain enough levels, you can also infuse them with multiple elements, so there are a whole lot of possibilities per spell.

You basically do all this to get as strong as possible so you can survive long enough to beat the boss and complete the mission. By doing this, you earn gold, which you can use to unlock new wizards and permanent upgrades. You will also be completing a lot of quests, which will unlock more spells, cool outfits, new worlds, modifiers, and much more. Over time, you will increase the ranks of your wizards, and eventually you can even ascend your wizards, which unlocks even more cool rewards. But those are secret, I will not spoil them here.

A view of all skins for only one wizard, the mighty Aldric:

What tools or workflows do you use internally to prototype and iterate on new spells, upgrades, and combinations quickly?

Gianluca: When implementing new content, let’s say, a new spell, we usually start with a quick brainstorm, and let our designers pin down the rules and general direction. Then, we usually do some quick prototyping until we have something worth taking to the next level. In the meantime, our artists will concept some directions for the visuals. By that time, the programmers will usually have a version implemented in the game, which can easily be equipped on a run to test. Any necessary models, VFX, or animations are then added.

Since we have many elements and upgrades per spell, this can take a bit longer to fully polish. Meanwhile, design can usually finalize the values and balancing. At this stage, we would also do a test session with some of our players on Discord. The visuals may not all be there yet at this point, but this does not compromise the playtests, and they understand the process. There are a lot of parts here, but we’ve made many of them, so the process for content types like spells, wizards, or enemies is streamlined at this point.

Some early footage of our test scene, where we can mess around with all kinds of spells, elements, and enemy effects:

From an art pipeline perspective, how do you create assets that remain readable amidst the visual chaos of combat?

Pieter: It’s one of the hardest parts of making a bullet heaven game for sure. At a certain point, you just feel like you’ve used all the colors you can use. Sometimes we regret the vibrant color palette for each world, as it’s harder to make enemies and spells pop in a saturated green meadow or a bright snow plane. But at the same time, we realise that it’s also what makes the game stand out.

An example of how a spell can look in all different elements:

We have a color palette for each world, but all that kind of flies out the window once you start introducing spells in any type of element and color. The Astral Riftlands, for instance, is a much colder, darker world. Fire, acid, lightning, and ice spells mostly contrast nicely here, but as you can see, there are some combos that will stand out less.

So while we still take color usage into great consideration in the design process, we’re also aware that the visual clutter is kinda part of the genre at this point, and there’s only so much you can do. Also, our players don’t seem to mind. In fact, they love sharing the most intense screenshots of their builds, which are pretty fun and groovy to look at.

VFX plays a huge role in communicating gameplay. What does your workflow look like for creating and optimizing spell effects, especially when multiple players are casting simultaneously?

Pieter: Since each spell in our game has 21 variations of elemental combinations, we need to keep the VFX simple and easy to adjust. We always start by making the basic variation of the spell, and keep in mind what parts of the spell can be changed for elements or other upgrades. That means a whole lot of assets, so correct naming conventions and prefab structure are most needed here, especially when artists, designers, and programmers need to be able to easily access all of them. It all comes together while playing, so it’s important to have a proper test scene where we can experience each spell as a player.

Multiplayer synchronization can be tricky in fast-paced games. What were the biggest challenges in ensuring responsive, consistent co-op gameplay across players?

Luk: For sure, responsiveness is something we constantly keep in mind when developing new features. No feature gets pushed through without it having been reviewed from a client and a host perspective.

In order for everything to feel as smooth as possible, we use client prediction for enemy movement. Spells from players are also owned by each client, even though damage and hits are server-authoritative. Whereas this is great for the responsiveness of the game for clients, this brings a pretty big caveat to the table. Spells need a deterministic way to target enemies. We have to make sure that from every player’s standpoint, a spell is being cast on the same enemy in order for the game to feel consistent.

For some spells (like the Hex Bomb picture above), this is easy because it just fires behind the character. Other spells like Aurora Wings are more tricky, it uses some more complex targeting logic to find paths from one enemy to the next that are pleasant to look at for the player.

The 1.0 update introduces systems like Ascension and expanded progression. How did your pipeline evolve to support long-term progression systems alongside moment-to-moment gameplay?

Gianluca: It’s tougher to balance for sure. We have a bunch of sheets and graphs that can calculate the perfect flow for that kind of stuff, but that can never fully anticipate a player’s flow and engagement. So while we usually have a pretty good idea, we do need to actually test it to optimise. For internal testing, we have access to some nice tools that can simulate a late-game save for us so we can make sure everything works. But for external QA or beta playtests, we often prepare a type of save file that will allow testers to start from a certain point, as if they’ve played a certain number of hours. Still, there’s always something to miss. And so far, we’ve mostly relied on the feedback of our Early Access players. After all, real players with 50 real hours of playtime can give the most natural feedback.

Testing late-game features is as important as the early ones, but they’re often a harder experience to emulate properly. Tools help out a great deal. Here’s an early test of a late-game size mastery - thank god we tested this:

What tools and software are central to your development pipeline across disciplines (engineering, art, audio, design)?

Luk: I’m very proud of our CI pipeline and our test suite. We have a ton of convention tests that span different departments. For instance, every enemy needs to have visualizers assigned for status effects inflicted by Dark, Acid, Ice, … So we have a convention test that goes through all enemies and makes sure those are assigned correctly. No surprises at runtime, yay!

More examples of this are making sure all audio for the game is routed through FMOD, or that the layer obstacle colliders need to be assigned, or that no asset should have a missing reference assigned to it. I can’t remember the number of times these tests have saved us from a broken game state!

As a small indie team, how do you structure collaboration and iteration across design, engineering, and art when building such system-heavy gameplay?

Gianluca: Over the last few years, we’ve slowly but surely integrated agile development into our workflow. That means we have weekly sprints with daily standups, and work towards bigger milestones. In Early Access, those milestones were basically the updates, and it worked pretty well for us to have a version of the game that was constantly stable and ready for release. The main challenge during development was to make sure that designers, artists, and programmers could constantly complement each other without creating big blockers or bottlenecks. Some content types require more art, some require more programming work, so it’s basically a giant puzzle that you have to figure out. And usually, we’d have the update ready about 2-3 weeks before release, so we could do some playtests and gather feedback from our infamous Early Brigade on Discord, and implement some more improvements to the update.

Here we visualized the behavior of the tornadoes in the Pyrestorm Pit, so design and art could work on the feature without much hassle:

Bolt Blaster Games, Developer of Spell Brigade

Interview conducted by David Jagneaux