Hyper Syntax

Pilot a ship with up to 3 friends as everyone vies for a collectible ring among an ever growing web of dangerous light trails.

Overview

Players pilot one of several different ships in Hyper Syntax, all of which leave a trail of light that follows and stays behind them permanently. Colliding with anything in the environments, including any player’s trails causes the player to crash and be out of the game until they respawn. Each ship, in addition, has access to special abilities: A booster to go fast, an EMP to disorient enemy players, and a phasing engine that allows players to pass through light trails unharmed. Using these abilities, players all aim to capture and hold onto the ring for a set amount of time to win.

Intent

Before joining the team, the game was intended to be a split-screen couch multiplayer game. The intricacies of the maps, the speed at which players move and the growing intensity of the light trails were meant to encourage visceral competitive play. The build I initially worked with featured jerky controls, virtually no player balancing, issues with game modes not being played as intended, etc.. I outline my work below more specifically, but my role was, almost exclusively, to create as fluid of experience for players to enter a state of flow. I wanted Hyper Syntax to be the kind of game that players would sit down and be enthralled to the point of not even noticing the sun going down.

Collaboration

We had a total of 5 game designers on this project, though I was the sole systems designer. As such, I had a lot of pull in what kind of changes needed to be made. My primary responsibilities were system conceptualization and design as well as balance tweaking. I would work on my own and create things like unique ship archetypes or bring the game to QA testing; I would also work with others, delegating tasks and identifying particularly problem areas that we needed to focus on. With the other designers focusing on Level Design, Audio Design or GUI design, I was tasked with strengthening the backbone of Hyper Syntax.

Iterative Design

As mentioned above, the general gameplay was already finalized and my role was to create new systems, or fine tune existing ones, to enhance the feel of the game and balance the experience for competing players.

Note, all items are expanded below. My primary contributions were as follows:

Initial Game Modes

Hyper Syntax had two game modes when I joined the team: Deathmatch and Race Mode, and each came with their own issues.

Deathmatch was meant to be played as a combative experience in which players had only one life. Using EMPs to disorient their opponents and cause them to crash into light trails, the last one standing would be victorious. Because the controls were very twitchy and the EMP is such a close range a weapon, however, the reality was that people were too scared to be aggressive. What resulted was our testers circling the outer perimeter of levels and simply try to outlast the others. It was less a 'deathmatch' game and more of a multiplayer 'Snake' game in 3D.

To fix this, I proposed a simple idea, changing Deathmatch to Capture the 'Flag.' Rather than having to simply survive, we gave players the ability to respawn and changed their objective from 'survive' to 'hold this objective;' in this case, a gyroscopic set of rings. The changes to the mode were fairly small and simple and, within a week, our testers were spending a significant amount of time actively pursuing other players.

This change required us to create some new systems and assets like a progress bar, pick-up/drop systems, and respawning. These small tweaks greatly impacted the experience and, in the end, the effort payed off immensely with our players behaving competitively.

As for Race Mode, we were having trouble balancing the racing experience. The person in first would not have to deal with light trail spawning and, as such, would have an easier time defending their position. We tried hard coding a rubber-banding effect, enhancing speeds or stamina regeneration the further you were behind the first player. However, our attempts to implement these were clunky at best and players felt the assistance was too apparent and almost condescending.

In an effort to create a catch-up mechanic that rewarded players for their skill, I developed a new ship mechanic: Light Trail Grazing. This mechanic had two major consequences in that it gave players that fell behind a chance to win based on their own ability and it gave players in the lead more to think about in terms of their trail placement. Ultimately, however, Race Mode was cut due to time constraints and our desire to further focus on the new CTF game mode.

Designing Ship Abilities

Each ship in Hyper Syntax is equipped with the same abilities for players to utilize:

• The Boosters allow for increased movement speed.

• The EMP that disorients enemy ships and forces them to drop the objective.

• The Phasing Engine that allows players to pass through light trails unaffected.

  All of these systems utilize a universal Power Pool that depletes as you use these abilities, and regenerate as you did not.

The Boosters and EMP were present in the game before I joined. As such, my job was to find each of their values and scale their draining of the Power Pool accordingly.

The Phasing Engine was of my design. Our cohorts and our testers voiced the same concern very early: There just wasn't enough that the player could do and, as games grew longer, the light trails became unbearable (especially around objective spawn locations). My response was to allow players to, at the cost of their already established Power, become invulnerable to the light trails for the duration.

It started off as a shield that would enable the player to bounce off of level objects and trails unharmed. However, due to how we handle physics, and because of the loss of player agency, we decided that it would be too much to implement effectively. My immediate response was to keep the theme, but simplify it. Rather than the player bouncing off of the light trails, what if they passed through them? Player agency was maintained, as they did not bounce wildly, and we already had systems in place for players to be invulnerable during a period as they respawn. The change was conceived of, prototyped and implemented within a matter of days to be put in front of testers who found it incredibly intuitive and made the game far more playable during periods where the light trail coverage becomes wild.

A large part of balancing these abilities was done through a method I describe below. However, we did have to do things like up the Power cost of the EMP to prevent players from spamming it. We made a number of changes like this; however, these affected every ship relatively equally and we had to balance the ships themselves and how often they could use these abilities in conjunction with their speed and maneuverability.

In addition to the above, I designed the Light Grazing ability that allows for ships to regain energy faster while in close proximity to a light trail. This was designed as a means for people to catch up in Race Mode. By skimming trails, they would have an increased opportunity to boost or EMP and be more likely to approach the leader. This system enabled the player to weigh the risks versus rewards of traveling too close to light trails to catch up while the person in first was discouraged from flying in an easily followed straight line.

Ultimately, this mechanic was meant for Race Mode and, with it being cut, so to was Light Grazing. This was due to the meta for CTF becoming more about positioning yourself in front of your opponent, rather than tailing them, to hit them with an EMP and make them drop the rings. Due to this, players with the rings often opted for erratic and unpredictable moves, creating odd trails that were nearly impossible to closely follow. It was for this reason that I suggested the system be removed Hyper Syntax.

Designing and Balancing Ship Statistics

One of my primary contributions to Hyper Syntax was having a variety of ships. Initially, there was only one model and the way it handled was universal for each player. I felt that a game like this could use ships with different strengths and weaknesses to encourage people to develop tactics, strategies and play styles of their own. 

There were dozens of alterable statistics on the ship, including things like the cost of EMPing or the amount of Energy the ship has access to. I parsed through the list and consolidated my efforts to create a variety of ships around only 5 attributes: Top Speed, Maneuverability, Boost Speed, Max Power and Power Recharge Rates. By manipulating their values on 3 different ship prefabs, I was able to create new ship archetypes that felt distinct while remaining balanced.

Ship Archetypes

Balancing the ships was a fairly innocuous process due to my use of spreadsheets. When I joined the team, the team had already found their desired metrics for their single ship. I created these ships by taking those base values from the original ship and altering the specified stats. 

These were the initial stats that I proposed while making the three ships. However, the metrics were not perfect. By observing testers over many sessions, I observed two key factors: Players wanted to be able to boost frequently as well as EMP on a moment's notice. Because of this, I reduced the cost of boosting across all ships and the EMP was altered to allow players to use it without having enough energy. Instead, if players used the EMP without having enough Power,the ability would fire it would take more time to recharge.

In the end, each ship archetype took on a play style and difficulty curve of their own. For instance, the high speed and maneuverability of the Light Ship makes it more difficult for many beginners to control. For testing, I had players play each ship once and then play a fourth with their favorite of the three. I quickly noticed a trend while doing this: Those that had played our game before were much more likely to pick the Light Ship a second time: Only about 25% of first time testers chose this ship again while repeat testers chose it 40% of the time.

Leading Camera

Immediately after joining the team, there were two things I focused on specifically. The first was the feel of the ships, and how twitchy the controls were. With values already in place, it was a simple matter of iterating numerical balancing until the game was as smooth as possible. Once that was fixed, I focused on the camera.

In the right video, as a player turns, their camera follows strictly behind them. While making sharp turns, especially with the speed of the game, players were susceptible to flying into objects they simply did not know were there. I sought to fix that by designing a Leading Camera system.

It works by rotating the camera towards the direction they are turning rather. While moving right, for instance, what is going to be to your right is far more important than what is to the left. As such, while you are turning to the right, the right side of the screen has the most 'actionable space,' or space that is relevant to what the player is doing. The system itself is fairly straight forward and I created the documentation below to quickly prove the problem and the ease of the solution to my peers.

You can see the Leading Camera in action in the video below. Of note is the subtlety of the system itself, but you will notice how the ship pulls to the opposite side of the screen while turning, maximizing the player's understanding of the area around them. While hardly noticeable in the end result, the complaints about running into things that could not be seen vanished immediately after implementation. This highlights the importance of seemingly small or insignificant systems that can go a long way in enhancing the quality of life of a game.

Quality Assurance and Analysis

During my trip to GDC 2015, I attended a talk by Mike Hines of Amazon regarding 'player flow' and how to achieve it. He described player flow as 'focus in the moment; the mental state of operation in which a person performing an activity is fully immersed in that process.' It's that ‘forgetting you had to go to the bathroom’ kind of effect. Moreover, he went on to describe four ideas that are necessary for players to enter flow: Clear Objectives, Few Distractions, Actionable Feedback and Approachability of Controls.

I took this lesson and revamped how we handled testing from the ground up to assure that our players were achieving flow. What excited me about this approach was how quickly it seemed to accurately reflect our position. For instance, in the first week of this testing method, we knew going in that our player feedback left much to be desired. 

I kept track of what changes were made and used the data to measure how much we improved or hindered our players' experiences based on the previous weeks. By using this method, we were able to discern what areas needed more attention than others and act accordingly as well as determine how effective our decisions were. This process immensely helped us by honing our attention on what changes we needed to prioritize and ultimately led to Hyper Syntax being as successful a project as it was.