September 2018 – May 2019
Team Size: 4 (1st semester pre-production), 12 (2nd semester production)
Role: Lead/Systems/Technical/Level Designer, Gameplay Programmer
Arachnotron is a fast-paced wall-climbing third-person shooter, with a focus on three-dimensional action. Starting with the idea of a game about a spider-tank, I worked with an artist, programmer, and producer to create what’s shown above in just under 3 months. I worked with the programmer on the team to create the wall-climbing system that lets the player traverse any surface smoothly, as well as designing and constructing the level & the boss battle at its conclusion. We took the game into a second semester of production at Champlain’s game studio, with an expanded team of 12.
For the first semester of prototyping, I split my time between designing & coding the wall-climbing system and combat mechanics, and designing the game’s first level. I spent a lot of time tuning the wall-climbing system to mitigate any disorientation: By controlling how the spider-tank moves around corners and how the camera follows, I was able to get it to the point where most testers have an easy time understanding how they can move around the room.
The level design also played into this, with numerous technical constraints from the wall-climbing meaning the shape of the level had to be carefully controlled, as I detail below. To further enhance the feel of playing a robotic spider, I also developed the procedural animation system for the legs of the spider-tank, using the inverse kinematics system the lead programmer created.
The wall-climbing system started as this, simply making the player stick to the walls and transition smoothly over edges:
With the addition of the leg animation, it really made the spider-tank feel like a spider-tank:
Systems and Combat Design
When it came to designing the Arachnotron’s abilities & the game’s combat system, I wanted to ensure it would emphasize the wall-climbing without feeling unfamiliar to anyone experienced with third-person shooters. From the very first inception of the combat system, I wanted to create the sense of having a powerful robotic arsenal of weaponry, so I approached weapon, ability, and enemy design with these ideas in mind:
- All challenges should emphasize the wall-climbing movement system
- Don’t force the player to retreat: To make the spider-tank feel powerful, and because back-pedaling onto a wall you didn’t see behind you would be confusing.
- Don’t require precise aim: Make the player think more about where & what direction they’re shooting from instead of where exactly they need to aim.
- Carefully balance speed: So that when the player is focusing on combat, they can take some focus away from visualizing the 3-D traversal, and when not in-combat, they can focus on moving faster through the level.
I designed the spider-tank’s combat abilities as a two-turret weapon system. The first weapon is attached to the spider’s back, can turn in a full 360 degree rotation, but cannot aim very far up or down. The second weapon is attached to the spider’s head. It’s used with the right & left mouse-buttons, bringing the camera in similar to an aim-down-sights function familiar from other games. It can only aim forward, but the spider-tank turns toward where the player’s aiming and moves slower while it’s out:
Here’s what this looks like with the first two weapons in the game:
The restricted firing arcs encourage the player to use the wall-climbing to get good attack angles on the enemies throughout the game. They’re restricted enough that the player has to think about how to use the level geometry around them, but not so restricted that the player gets frustrated, unable to shoot something that’s coming after them. By combining these two weapons with thoughtful level geometry, I aimed to create situations where the player would really think about the 3-D space, and how they can position themselves with the wall-climbing to most easily destroy the opposition.
Other parts of the combat system were made to emphasize the feeling of playing a powerful robotic spider-tank. The player can sprint indefinitely, but stops when they shoot, so that they have the option to move quickly, but it never becomes overwhelming in the midst of a battle.
Each section of the four-part health bar regenerates over time, but once lost is gone until a health-kit is found. Each of these sections is actually more durable than the last, with the last part having nearly three times the durability of the first. This way enemies seem more dangerous at first, but when the player is close to death, they’re not actually in as much danger as it seems, and a health-kit is usually close-by.
Enemy and Boss Design
With the player’s abilities built and tested in a time-trial target range, I set out to design enemies that would provide an interesting challenge to the movement and combat systems we had in place. Overall, I split up enemy design into two categories:
- Flying enemies – Weaker, but dangerous in many situations for how they can reach the player anywhere. Easy to destroy, but numerous.
- Grounded enemies – Stronger, but dangerous in specific situations because they have slightly more complex attacks and weaknesses such as directional barriers or defensive lasers on their back. The player would have to approach these more thoughtfully.
Each enemy was designed to fit a certain role, to get the player to think about the wall-climbing in a slightly different way when fighting each one.
Bosses in this game are closer to level design than standard enemy design. Given the nature of the wall-climbing system, we wanted the spectacle of climbing a giant robotic enemy and destroying it piece by piece to be the climax of each level. I wanted to avoid giving them health-bars or having the player simply blast away at the same thing for a while, so I took the approach of making each boss based on the non-combat challenges of the level before, but with danger & combat integrated into it this time.
I prototyped the bosses the same way I did the level design. This structure and simple flowchart became the Fuel-Walker boss:
The player uses what they’ve learned in the first level of climbing everything and destroying the yellow fuel canisters, to get the boss to open its core, climb in, and destroy the canisters that are stored inside. For the second phase, the boss rotates its legs to stand on the ceiling just like the player can. It ramps up its attack pattern as the player tries to destroy the other compartment of fuel.
Level design in Arachnotron was more challenging than I had anticipated. With the ability to climb on anything, and even jump between walls, it was almost impossible to direct where the player would be looking and moving at any point. Every wall, nook, and cranny had to be tested rigorously to make sure the wall-climbing system wouldn’t allow the player to just phase through the walls, so I established a few simple rules for the level geometry the team would have to follow to make sure it worked everywhere.
No acute angles, no jagged edges, and no thin extrusions. These rules helped both designers and artists keep the level geometry navigable from any direction the player might approach from:
After going through a few test room designs, I got to work on the first level. I started with a philosophy of trying to ensure no wall felt more like “up” than any other, because I thought it would be less disorienting for the player if they didn’t have to worry about it:
In testing, I eventually figured out that having a clear up & down in the room actually helped players get their bearings, especially players who were less used to full 3-D movement. With that revised design philosophy, I re-designed the first level, especially the first and third rooms, to be easier to understand for a first-time player. The first room was re-shaped to have a clear up & down axis, and the third room was completely re-done to be more in line with the other two’s focus on enemy encounters and simple door locks, instead of the maze like puzzle in the version above.
The many technical and design considerations that make good level design in this game very challenging, so we took to using VR drawing tools to sketch out plans and iterate rapidly. It was hard to envision what the level would look like to the player, crawling every which way on the walls, but in VR we could look around, scale, and rotate it in any way we wanted! This let us more quickly plan out how the level would look from the many different angles the player could approach each part of the space
Here’s a flythrough of the sketch I made of the first level. The other level designers brought on for the 2nd semester were able to use this tool to envision the designs for the two new levels we created:
When production resumed in January with an expanded team, I changed my focus from gameplay programming & systems/level design, to more of a technical design role. Because I built the wall-climbing system at the core of the game, I was familiar many little technical considerations that would have to go into the art, design, and programming of the game. With this, I put a large part of my focus on helping to streamline the process of building new levels.
For creating level functionality, each level uses a different type of power canister (shown below), which were set up with visible power lines to show the player what connects to what in the space. I also created a simple bank of scripts that use a messaging system alongside these canisters, for designers & artists on the team less familiar with C# scripting to set up the functional parts of a level quickly and easily:
The other main point of focus for me in the later months of production was working with the lead artist to create two more boss fights for the new levels we were building. In collaboration with the work the other designers were doing on the new levels, I designed each boss fight to use the mechanics introduced in that level. Similar to my work on the spider-tank’s legs, I also built other procedural animation systems for the bosses, like the mandibles of the millipede boss that react to the sounds it makes, and adapting the inverse kinematics system to make the arms move and track dynamically throughout the fight:
For the final boss, I adapted the spider-tank’s leg animation to combine better with premade animations created by the lead artist, and integrated it with the attack & battle phase system the lead programmer built. We’re currently working on developing the final boss to mirror the player’s abilities to some extent, so having it move the same way without player control was an important first step: