Shocklane

Shocklane is a racing couch game with combat at its core. Your vehicle is in a elemental state (water-fire-plant) that you can switch at any time. When vehicles collide, the element dominating the other wins! Earn points by being first or colliding with other players.

Shocklane was made with a team of 6 students during our studies at ENJMIN (producer, audio designer, programmer, artist, UI/UI/UX designer, and myself game designer). We had 3 months to build an interactive experience that would be played in the schools hall by visitors and jurors, in 10 minutes rounds. We were given an open space with PCs and server infrastructure.

Contents

Designing Shocklane

Defining the vision

Shocklanes original pitch was to have a RPG at the races heart. It meant creating a build of 2 among 4 elements before the race, level them up during the game and use a handful of interactions related to them : collisions, shortcuts, driving physics, etc. to win the race. The pitch was from our audio designer, Martin Rabiller.

With this pitch and our constraints, we defined some experience pillars at the project start :

Couch game fun

• Player-player interaction : the fun factor is your interaction with other players on the couch
• Accessible gameplay & controls : you can pick up the controller at any moment
• Friendly rivalry : Shocklane is the game you would spend an afternoon with friends on

Tension

• Players should always feel on the edge : through speed, through the danger of collisions

Tactics

• Through RPG and elemental interactions, player should be able to build strategies to win

Designing gameplay

For context : Shocklanes development was organized for iteration, in an agile framework. Our process was inspired by SCRUM. This empowered us to test early, make important redirections without losing too much work or time, and more broadly to iterate efficiently.

1 : Finding the path

At first I designed Shocklane faithfully to its pitch. The core feature was to select 2 elements prior to a game, and switch among them during the game. All other gameplay features were tied to it :

• Driving physics are different for each element
• Collisions are element-based
• Every elemental collision is different water - fire triggers different effects from fire - wood
• Shortcuts are unlockable by colliding with some elemental obstacles
• Finishing a lap makes the active element level up so its interactions are stronger

However this approach had big issues :

• Players focus on their own vehicle and gameplay which is contradicting our first pillar
• Elemental shortcuts separates vehicles but they are supposed to collide!
• Some players hard-counters others in collisions, as one only has 2 elements at disposal
• Driving needs a lot of cognitive load although physics changes between elements feels great

So we decided for a major redirection. We went back to our first pillar and work based on it.

The fun factor is your interaction with other players on the couch.

This led us to a massive shift :

2 : Refining the loop

Once this big redirection was done, the core gameloop was much clearer. The design goal I set was then to make it shorter, more reliable and more fluid. I achieved this through targeted iterations.

Players generating collisions

Originally, I gave players 2 actions to collide with others : a nitro ability and a lateral dash. (Nitro was element-specific and conveyed each elements feel). These 2 actions proved to be uneffective : nitro also allowed to avoid collisions, and in general it was clumsy to play with 2 actions.

To address this, I merged the two actions ine one : a grapplin.
It automatically targets the closest vehicle ahead and gives a speed boost in the direction of the grappled vehicle. This design avoids all the problems of the former actions. On top of that, it also gives a very clear sign about the collision to happen: there is a visual link between the 2 vehicles.

Keeping players packed

Playtests showed players were spacing a lot along the track. Its usual in racing games, but it meant the grapplin was out of range at all times. To solve this problem, I designed 2 features.

Rubberbanding. This is a classic mechanic making vehicles have a higher speed the later they are in the race. Usually, its balanced for couch gaming so that all players have a fun moment. For Shocklane, I went much more agressive than that. (There is no finish line!) Here, it fulfills the role of keeping vehicles in grapplin range, in a pack.

Disco balls. If a vehicle is far behind others, some disco balls spawn above the track. Disco balls can be grappled, but don't trigger the grapplin cooldown. This way, a late player can spam their grapplin until they reach the vehicle pack.

Other features help by their design in minor ways. The grapplin can only target vehicles ahead of the players vehicle. The level design is narrow and uses bouncing guardrails.

Managing cognitive load

To focus players on interacting with each other, I needed to free cognitive load from driving.

I reworked the driving inputs. I originally put acceleration on the right trigger, as it allowed me to give each element a different acceleration feel. I remapped it to A (Xbox), and made the acceleration reach max speed fairly quickly.

In relation, I designed the level design grammar to be very straight-forward. First, track turns follows the exact turn angles of the vehicle (normal turn at max speed, drifting turn at max speed). I designed a matching signage for each of these turn types. Last but not least, I designed the track to be traversed with the acceleration input held all track long.

Efficient collisions

Until very late in production, Shocklane featured 4 elements. Our UX designer came up with the idea to cut 1 element, as managing 4 of them was heavy on cognitive load.

Design-wise, I found this to have massive advantages :

• less neutral collisions (neutral collision = fire - fire, wood - water. Theres no winner - loser)
• so faster gameplay loop!

It felt a bit crazy to the team to do such a massive change this late (especially art-wise). But our internal playtests and discussions led us to collectively agree on it. We cut the electricity and rebranded Wood into Plant.

3Cs : building a vehicle simulation

Vehicle simulation is the very first thing we implemented. We did so because we needed it for everything else, but also because the risk was high we would need to amend it later. Better take the risk early, when the scope can be modified.

As we were beginners in the field, we made extensive research, programmer (Baptiste Rousserie) and designer hand-in-hand. We watched GDC talks, read online resources, got feedbacks from multiple other students who attempted to do the same as us, and we benchmarked approximately 20 games. This led us to understand what is at stake when building such a simulation.

So we defined these properties our simulation had to match :

This led us to the following design (this document is not the one we used in production).

This great basis was then refined a lot through an iterative process. We did lots of testing, tweaking and added layers of complexity to this base model. Let me give a few examples :

• Early in vehicule simulation development, we had an issue with the vehicles flipping over. We had to add a specific system keeping track of orientation and adding forces if needed.
• This very system tricked us later, as we added barriers to the track borders. The system actually monitored the ground normal for alignment, so when detecting barriers it was sticking the vehicle to the barrier, thus putting it at 90 to the ground. We solved this by filtering colliders.

As you can see, we were right in our choice to build the vehicle simulation first. It indeed presented a lot of challenges we didnt plan on meeting originally. Only through meeting this risk we were able to progressively address it, through iterations. If we had started by building something else, this risk could have overwhelmed us by the time we went to face it.

Gamefeel : being. on. the. edge.

Building the gamefeel was a collective effort spearheaded by our UX designer. The major topic was the feeling of speed. We also wanted vehicles to be agressive and powerful, conveying the always on the edge feeling.

For speed, the answer was a collection of solutions. The level art uses a lot of visual references and repeating patterns. On the design side, I built the camera to be close to the ground. I also designed a dynamic FOV system, reacting to different speeds, speedboosts, etc. The camera position is also very dynamic, making the whole feel very lively.

I wont go in too much details, but we also adressed some other gamefeel topics. For instance, the vehicles are made to look powerful and agressive through their VFX, model, and reaction to interactions. Another example would be the pole position player: I made their controller rumble like a daunting pulsebeat, making sure to feel the high-risk / high-reward nature of their position.

Balancing Shocklane : an economy of points

Shocklanes balancing process started out of curiosity. I wanted to model the gameplay loop to see approximately how many collisions I would get in a typical game.

Unexpectedly, this enabled me to understand the actual economy of points happening in a game.

This model gave me independant balancing levers, a precise estimation of how much points would be earned from collisions or being in pole position, and an good estimate of games duration.

I went back to the vision to define the target balance. Collisions are conveying the core experience, while racing for the pole position is a gamefeel intention. So I made collisions the most impactful (67%), while being in pole position gives just enough points to gain an advantage (33%).

When we got close to the end of the project, we were able to generate logs from games, so I built a second Excel to check if the my model was describing actual gameplay. And the answer is yes! The model predicts extremely well the duration of a game and the average distribution of points.

As a nice bonus, the model gave me an average duration of the core gameplay loop : 8 seconds. This is totally confirmed by watching gameplay!

Documentation strategy

At Shocklanes start, we used Confluence as a wiki for our documentation. It created some issues :

• People went on it only when having something to do on it, so no discussion was triggered
• Led to wall-of-text design docs, hard to swallow for everyone (including me writing them)
• A wiki format needs a lot of maintenance work, which doesnt fit at all an agile process

The solution became very clear once I got to know about one-page documents :

I printed these one-page documents and posted them directly on the walls. Other students passing by would read them, as would do every team member, even those not concerned by a specific document. This new strategy had a ton of advantages. :

• You can grasp a feature in a glimpse. This creates a lot of benefits, most notably if a feature isnt understandable fast, then its a problem for a couch game.
• Everybody sees what each other has to do : team members see their work as part of the whole
• Lots of blank space to take notes, add modifications, discuss, etc.

Level design

I did all the level design that went into the end product, though we were two working on it during its production. The audio designer of the team (the person who pitched the game) was working on level design with me.

We did some research on level design, as I am not specialized in level design and even less in racing games LD. We found some great resources, which allowed us to build our design process.

• Build fast many maps with greatly varying level designs audio designer
• Playtest them with multiple groups of players UX designer + audio designer
• Define metrics according to playtests and car trajectory measurements audio designer + me
• Define grammar (LD Ingredients) me
  • Boucing guardrails, road width, turn categories & matching signage, disco balls
• Top-down map me
• Iterations me
  • Simplifications & geometry tuning, vistas adjustments with LA,

This process was carried to build the track, and created a good understanding of Shocklanes needs in level design. At the end of the project, we added a hub, for players to grasp controls when waiting for others to sit on the couch, and this knowledge was reused.