Kyle Rasmusson
Technical designer
KYLE
RASMUSSON
Weapon Systems
​
The problem : Wanted to create incredibly flexible, modular weapons that designers can script easily.
​
My solution : Created a base system in C++ in UE4. Created three versions of the code; Linetrace, Projectile and a Blueprint exposed version. The latter allows designs to easily override specific functionality and implement almost anything within the existing framework.
Player Traversal!​
​
The problem : Needed to create Titanfall 2 Style traversal that also kept in mind the abilities of the team.
​
My solution : Built in an easy system for wall-running, added camera shake and other QOL tweaks. Additionally using tag and volume checking so that wall-run spots are intentionally placed, rather than Titanfall's style of 'almost everything is a valid surface'.
Modular Puzzle Systems
​
The problem : Wanted to create a series of puzzle systems that enable Level Designers to easily create fun and engaging puzzles out of modular systems.
​
My solution : Creating systems like cranes, rails, activators, input triggers, and systems that drive through animations. One main component is a player tool, the "ion cannon" that lets players manually activate and deactivate many systems.
Project Rubyshark is a fast paced high mobility first person shooter. We've taken design inspiration from games like Halo, DOOM, and Titanfall 2.
​
Our core design pillars are Fast paced combat, puzzle solving, and exploration. We established these within our first meetings, and this has been crucial in getting our designs off the ground quickly. We've been able to vet many ideas past our pillars, ensuring that they properly match.
​
I started the project, have worked with others to grow the team size to thirty developers, and have been guiding and mentoring the designers on the team.
​
I've had the pleasure to collaborate with the artists to ensure they have the proper tools they need, and that the vision for the game is cohesive in all areas of execution.
​
With designers, I had a heavy background in level design and have been running 1:1 sessions for each of our level designers, reviewing their work for the week, and brainstorming about ideas for puzzles and systems for the next area. This process has been amazing, and has honestly helped me grow significantly as a designer, and leader.
COMBAT
​
One of the key important areas in Rubyshark is the combat. Players need to be able to move around the space like it's second nature. Weapons need to feel unique, powerful and interesting.
​
Weapons: The foundational code was built in C++, with several hooks exposed to Blueprints. We'd brought on a designer to specifically work on weapon balance, tuning and prototyping many of the designs that we'd previously established. I've been working with him, making sure that the weapon systems are easy to build with, and have all the necessary features. This has led to exposing more functionality to BP, and collaborating to design systems like recoil.
​
Recoil : This was designed to be simple and predictable, taking inspiration from DOOM Eternal, where the recoil caps out at a max angle. This allows the player to get the feeling of recoil, yet allow the weapons to still be quite controllable, working with the fast paced nature of the game. The operation is pretty simple, there's an applied recoil, and queued recoil value, applied recoil factors into the used pitch, and queued recoil will transfer to the applied recoil over a duration, this allows for the smooth tracking.
Advanced Mobility : A CRUCIAL part of this game is how the player feels when they're moving. Every aspect of this has been tuned. Air movement, sliding, jumping, camera shakes, velocities. Everything needs to be tuned and designed such that they all serve their own purpose and all feel good to use. Players will be moving around more than any other action in the game, and being in fast combat means this needs to be intuitive, like second nature.
​
Enemy Design : We've been focused on designing enemies that require the player to keep mobile. To keep players moving, we need to give some incentive as why somewhere else is going to be more advantageous than where they're at, pretty simple, but it's sometimes powerful to give simple framing to your problems. We need to give players things to move towards, or away from.
​
1. Projectile Dodging : Borrowing some inspiration from bullet hell games, the projectiles move quickly, but smart players are going to be able to dodge projectiles.
​
2. Enemy accuracy : Simple, faster player, less accurate enemies. Enemies will try and approximate where the player will be, based on the player's velocity, but this equation, and the weapons themselves, get less accurate based on how quickly the player is going.
​
3. Death Drops : Enemies drop ammo and health on death, but the collectibles only last for a short duration before vanishing. For a little polish, I gave the collectibles a little arc when moving to the player. (It arcs UP and to the player's LEFT, so it wont get hidden by the gun.)
​
4. Enemies themselves : We'd designed a few enemy behaviors where the enemy themselves will charge at the player, dealing impact damage. This will be predictable enough for the player to dodge. Much like the Pinky's and Hunters of DOOM and Halo respectively, we've given a nice vulnerable spot on the back of these enemies.
MECHANICS
​
The core of Project Rubyshark is giving the player rapid, low information decisions. Humans are hard wired to solve problems, giving a positive rush when accurately solving a problem. So two of our core project pillars are focused around that idea. Fast paced combat, and puzzles. When reviewing with our designers and helping them design puzzles, I've focused on helping them work on simple mechanics that can mix and match, ensuring players can easily recognize and digest components of the puzzle. This approach also enables easy iteration, ensuring all we need to do to create new puzzles is quick mix and matching.
​
Ion Cannon : A lightswitch! It sends out a beam that turns things on or off based on user input. This lets level designers use targets and activators that the player can shoot. These can activate pieces of a puzzle, flip platforms, turn on mechanics for players to use. It's as simple as tracing for a proper hit and sending a signal based on if we're sending out the "positive" or "negative" signal. One extra polish item is how we trace for a valid signal. We're using a series of expanding traces until we return a valid hit, we specifically check for the first item that returns usage of the interface.
​
Anchor Controller : This system essentially operates like a crane, where designers can adjust rotation and movement parameters for the crane. Allowing players to create their own path is interesting and rewarding, given them the feeling they're directly impacting the world around them, moving platforms and pipes around to create new wall-run and pathing opportunities is one of the easiest ways to do this.
​
WallRunning : Pretty simple, we constrain the player to a plane, and handle their resulting velocity on the validity of the wallrun surface, and their inputs. One key change we've made, most games allow practically any surface to be a valid wallrun surface, however we made the scope decision to make these manually placed surfaces. Allowing practically any surface to be valid would prove to break the constraints of our time and expertise, so we scoped back on that.
​
Spline Mover : One of the core systems has been getting objects to move along a spline. There are several different variations and applications of this system. From creating platforms to walk on top of and dodge other obstacles, to having mobile wall-run platforms. We need some to spawn along the spline and properly loop, such as in a factory with moving cargo containers.
​
 |  |  |
|---|---|---|
 |  |  |