Platform: PC
Developed: September 2023- April 2024
Role: Systems Designer
Team Members:
Flint Babineaux: Lead Producer Henry Foley: Lead Artist
Alissa Liu: Lead Designer Zach Navarro: Environmental Artist
Gerrit Pottmeyer: Level Designer Catherine Davey: Enviromental Artist
Jacob Davis: UI Designer Daniel vanDuzer: 2D Artist
Nicolletta Rothschild: Lead UX Designer Lily McMurtrie: Vehicle and Weapon Artist
Nicolas Delbue: Lead Programmer Nicholas Kasprzak: AI Programmer
Merle Roji: System Programmer Tommy Wagner: VFX Programmer
Noah Cichowlas: Lead Sound Designer
Intent
Riptide is a Sci-Fi naval action game for the PC where the player controls a customizable warship that fights through waves of enemies.
Gameplay
Once the player selects a level, they are brought to the outfitting screen where they customize their starship with a number of weapons and components. From there they enter the level where they have to complete a list of objectives.
Once in the level, the player can freely aim and fire their weapons using the mouse, while their ship is controlled using a modified version of tank controls WASD controls the direction the ship is facing, while shift and control change the speed.
Each level has two parts. The first where the player enters the level and clears out all the enemies their, and the second where another wave of enemies spawn in that the player has to defeat. Throughout one level and the outfitting screen before it, different characters will be talking to the player giving them more insight on where they are and what they are doing.
Personal Contribution
I was responsible for determining how the player ship would move and fight. Some key pillars of Riptides intent was that the players ship felt like it has mass and inertia and that their positioning relative to the enemy would matter in combat.
These pillars led to two game mechanics, ship acceleration and firing arcs.
Whenever the player tries to move, either to turn or increase their speed, the ship takes some time to reach the intended speed. When the player turns the turn begins slowly, when the player attempts to speed up or slow down it take time before the player reaches their chosen speed. This gives the feeling that the player ship is large, and that it takes a good amount of energy or effort to move it around. This also means that the player has to commit to each of their moves and plan ahead as it is possible to over shoot a turn, or run into an obstacle by not slowing down in time.
Firing arcs refer to the mechanic where each of the players guns has a limited area where they can fire. The front two guns can only fire 180 degrees ahead of the ship, and the two rear guns can only fire 180 behind. This means that what weapons the player has facing the enemy matters, as they are the only ones they can use. It also means that the only way to get the most damage out of any loadout is to face near perpendicular to the enemy.
When ever the player tries to move, either to turn or increase their speed, the ship takes some time to reach the intended speed. When the player turns the turn begins slowly, when the player attempts to speed up or slow down it take time before the player reaches their chosen speed. This gives the feeling that the player ship is large, and that it takes a good amount of energy or effort to move it around. This also means that the player has to commit to each of their moves and plan ahead as it is possible to over shoot a turn, or run into an obstacle by not slowing down in time.
Firing arcs refer to the mechanic where each of the players guns has a limited area where they can fire. The front two guns can only fire 180 degrees ahead of the ship, and the two rear guns can only fire 180 behind. This means that what weapons the player has facing the enemy matters, as they are the only ones they can use. It also means that the only way to get the most damage out of any loadout is to face near perpendicular to the enemy.
I was responsible for creating the outfitting screen both in the design of the player's loadout and for the technical implementation of the scene itself.
The player loadout has 6 slots; 4 weapon hardpoints, which make up the players offensive abilities and 2 component compartments, which modify the player ship's base stats.
What the player can equip is limited by their power use. Each weapon and component has a power use stat. As the player attaches more weapons and components to their ship, the more power they use. It is possible to go over the max power allowance in the outfitting screen without filling all of the loadout slots. Power use acts as a limiter on what the player can attach to their ship, limiting their loadout so it does not become two overpowered.
From a technical standpoint, the functionality of the Outfitting screen is contained in two blueprints, "OutffitingShip" and "OutffitingScreen". "OutfittingShip" is mainly to add a visual to the screen overall, as it displays attached weapons and highlights selected hardpoints.
"OutffitingScreen" is a Blueprint widget that is made up of several smaller parts. Each of these parts can be moved around near freely without needing any changes to the blueprints code. This allowed me to easily modify the screens layout across the game's development.
Each of these parts has a distinct function, show the ship stats panel which shows how the ships stats change as new components are attached, to the equip sub menu which lists out all the available weapons or components that can be placed in a selected slot.
Outfitting Screen Gameplay
I was responsible for implementing the technical side of the level select screen. The screen involved 3 separate parts. The Radar map, which displayed the unlocked levels and had a moving cross hair to show which level was selected. The Level selector themselves, which were a separate widget that contained information for the upcoming level and updated themselves based on whether the level was unlocked or not. And finally the info screen, which displayed a short description of the level and an icon.
When the player entered the level select screen, they could freely select any unlocked level. Once selected the "crosshair" would move across the radar screen to center on the selected level. The info screen would display the information of any moused over level selector. If nothing was moused over the screen would be blank or display the information of the selected level. Finally, to enter the level the player would click the big red button on the bottom right.
The final piece of my contribution to Riptide's development was balance work on the different weapons and components. This proved somewhat tricky as the weapons and components were in different states of implementation over most of development and testing time commonly had to be allocated to higher priority topics. When approaching a weapon or component, my goal was to make each be unique from all of the others, as well as have a relatively clear niche within a players loadout. The railguns are the best example of this, as they were one of the first two weapons added. The began as a reliable slow firing high damage weapon to complement the faster autocannons. However this role was eventually taken over by the long guns. As such the fire rate of the railgun was greatly reduced, and its damage increased. The speed at which its projectile traveled was also increased. This turned the railgun into a long range high damage weapon good for taking out targets from far away, but mostly useless against faster enemies at close range.
I was responsible for writing and update Riptide's Game Design Document. While parts of the document are pulled from other team members work, most of the document is my own work. There are several sections that link to other documents that provide the viewer more in depth information about a particular concept within the project. Otherwise, all content is categorized into a wider section based on how they fit into the project, with the two largest being Game States, which describe each of the game's scenes and the Mechanics and Systems section which breaks down the games features. I created a number of visuals for different sections of the document to provide more information. Some of these were created from scratch while other we built using in engine screenshots or existing art assets.
Project Takeaways
Every year at Champlain the Game studio classes allowed me to become more familiar with how to work with other from other disciplines, as well as get familiar with the general structure of game development. The Capstone project, which Riptide was, was this all writ large. I was able to practice these things on a project with a longer time framer, a greater scope and a larger team. This was the first time I was on a team with defined discipline leads, where marketing was considered, where we as a team were making decisions sometimes a month or more in advance. This led to me thinking about game development on a much greater scale then before. For the first time I felt I was making a game rather than a school project. Ultimately my biggest takeaway was how to operate on larger teams and bigger projects.
Another takeaway was a better understanding of the process of turning a design goal into an actual system. This mostly came about when I was designing how the player ship moved and fought. I started with an intended experience, I want the player to feel as if they are controlling a large ship. From there I looked at other games that had this experience, mainly World of Warships, and worked from their. To make the ship feel big, we made it slow, but this wasn't enough as the player could still turn on a dime and instantly accelerate. So we added an acceleration mechanic, which made it feel as if it took effort to move the ship arround. It also had the intended side effect of forcing the player to think about their moves. It enforce the idea of a capital ship, the players guns are all turreted rather than forward facing. The track the players mouse so the player feels like they are aiming. The position of the turret was also made to matter as well, as they weapons on one end of the ship cannot turn to shoot through the ship. This melded with the movement system well, as the player position would now matter in combat. If the player has a weapon they can use on the front of their ship, and they are being attacked from behind, it would take them more time to turn around and start firing than if they had had a gun on the back already.
On a more particular scale, I became better at the use of testing data. One thing that my team did was ask particular questions about the game each week to testers. Questions like, "is the ship moving too fast or too slow" and "Is this weapon too powerful or too weak". If we had simply followed the feedback we were given the project would have became a mess. What I learned was that each tester had their own set of biases and preconceptions whenever they sat down. What felt just right to one player would be to fast for another or so on. So when it came time to tweak damage values or speed based on feedback we adopted the approach of first asking ourselves what our intended experience was. "How do we want the ship to feel?", "What is this weapon's intended role?" From there, we could better sort what feedback was useful and what it was really saying. When it came around to weapon balancing, which none of us had any real experience with, the approach helped immensely. It allowed us to shift our focus so that the weapons would be fun to use, rather than getting lost in making minor changes to a bunch of variables.