Cypher Creations Prototypes

Technical Designer

Thanks to my work on Strawhart I was offered a job as Technical Designer at Cypher. I was brought on to help conceptualize, prototype, and develop Cypher’s next major project. Unlike previous projects, I’d be conceptualizing and designing long term game projects that had to be unique, enjoyable, and within our team’s scope. I was also tasked with investigating new UE5 tools we could potentially leverage in our projects, examples including Epic’s Gameplay Ability System, Enhanced Inputs and Metasounds. Since these are ongoing projects, my day to day tasks change depending on general progression. Early in the project I was mainly doing design and research work, while now I’m building systems in C++ and Blueprint.

Project Tasks

Long Term Design From The Ground-Up

The goal of our project was to become a full retail game, ideally financed via outside publishers. This meant that our game concept had to be rock-solid. The conceptualization phase was rigorous and methodical. Concepts would usually start from a spark of inspiration or based on market observation. We’d usually pitch these concepts with a design doc or a steam page mockup; this helped us think of our concepts from either a game design or marketing standpoint.

One idea that seemed to resonate with most of our team was the gene concept. The basic structure was a third person, rogue-like, action game where the player dispatches enemies by stealing genetic traits from one creature and grafting them on to another. The idea was interesting and novel, but more design work had to be done before any serious development could be done.

Our initial design attempts were misguided, we would lift mechanics from our references without really knowing why and we’d let vague notions of what could be cool or fun drive our creative processes. Because of this approach, our main mechanics weren’t fleshed out and the overall design was disjointed. After yet another fundamental rework of the design, we started to look to Masahiro Sakurai’s “Game Essence” theory for guidance. Sakurai emphasizes the appeal of a game’s push and pull; the excitement of managing risks and being rewarded. How Mario interacts with enemies in the original Super Mario Bros is a prime example of game essence. Mario’s primary method of attack, his jump, requires him to be as close to the enemy as possible, which is where he is also at his most vulnerable.

The “Risk and Reward” prestended in Super Mario Bros. explained by Masahiro Sakurai.

With the application of game essence, our design choices immediately became more coherent. We were able to isolate our main mechanics and develop states of empowerment and weakness around those. Questions we struggled to answer previously became straight forward once we started thinking about the risks and rewards involved. For example, we knew that one of the most exciting mechanics should be the process of stealing genes from enemies. We want the player to employ these gene abilities deliberately, so stealing these genes couldn’t be done passively through normal gameplay. How brazen and careless a player is in their enemy encounters should determine how likely they are to retrieve a gene. Our lead programmer dubbed this relationship our “sliders.” As combat slider rises, the slider to pilfer useful genes from enemies diminishes. We used this method of thinking to justify all sorts of mechanics, like how a sprint mechanic increases the player’s movement capabilities, but decreases their ability to sneak up on enemies. Our revitalized approach to gene’s design showed its potential as a game idea, and we moved forward with the project.

Investigative Prototyping

Part of my role in the prototyping process was investigating new tools we could utilize. This prototype was both my and Cypher’s first Unreal 5 project, so we had a lot of tools to potentially choose from. The plugin that immediately got our attention was Epic’s Gameplay Ability System (GAS). While still experimental, GAS seemed like it would be a perfect fit for our gene project; its modular approach to abilities and VFX means we could implement genes generically across all different types of enemies. Furthermore, with GAS’s built-in replication, we could maybe even make our game multiplayer compatible in the future. The process of learning the system has not been easy; GAS requires all of our designers and programmers to fundamentally relearn how to implement certain actions. Despite the efficiency that implementing GAS would bring to our project, adjusting to the unique system is going to be an arduous process.

Epic’s Enhanced Inputs were also something on our radar. Since our player could have multiple different abilities granted and removed manually, we’d need input mapping contexts to do the same. Enhanced Inputs were much easier to understand and implement compared to GAS. One notable implementation was our weapon input mapping context. Each weapon stores a particular IMC depending on the input required to activate the weapon. For example, our bow weapon has the “charge weapon” IMC which then allows the player to fire the bow after the primary fire key is held. While we’re still working out some oddities, Enhanced Inputs are now a staple too in Cypher’s Developmental arsenal.

The last new tool I was incharge of investigating was Epic’s Metasounds. While I’m no audio engineer, I figured I could break ground with metasounds and then relay some of my findings to our audio engineer. I was able to make a dynamic music system (with premade tracks) that fades between tracks depending on the current context. Each context has its own priority so some tracks will override others. While advanced audio is still far off from our current stage of development, hopefully my proof of concept will lead to an audio system as modular as our input and abilities.

Industry Development

As the prototypes transitioned out of a purely design phase, I was expected to begin programming the systems outlined by our design. While I was still doing work for the “Gene” prototype, our other project “Crossroads” required programming assistance. I was tasked with programming an inventory, item and a world grid system based off of the systems found in the Animal Crossing series.

The design outlined a data asset which would outline the particulars of the item. Similar to items in Animal Crossing, each item had an overworld size, whether or not it could be placed in the world, how many of these items can fit into a single inventory stack, among other things. The Item Data Asset was a C++ class rather than a Blueprint class because the OverworldItem class needed a reference to its relevant data asset on construction. After inheriting from the base Item Data Asset class, designers could easily create new Item parameters completely in-engine.

The WorldGrid class was done entirely in Blueprint. The design never specified map size so I tried to make the grid as modular as possible. The grid extent was determined by two scene components and the individual box size was determined by a float. Each point on the grid was a custom data structure with the point’s grid coordinates, its place in world space, and whether or not its “valid”. When the player attempts to place an OverworldItem on the grid a range based on the player’s location and direction is calculated. If the overworld item is able to fit in the current range, the placement follows through.

The processes of developing these systems illustrated to me the main difference between amateur and professional development: I now had to think of my systems in the greater context of my team. I was constantly developing with my team in mind, whether it be for designers or for other programmers. I employed these skills by making my systems easy to understand and scalable. This skill more than any other is what I hope to hone through my continual work at Cypher.