James MarlandTechnical Artist - Tools, Pipelines & Shaders

Breakdown 4 of 5

Gameplay programming

I programmed the parts system, made all item behaviour and reworked the vehicles to use arcade physics.

Overview

Alongside the tech art and producing, I was the team’s main programmer. It’s all Blueprint and I created the higher-level systems as well as indivudal logic like items and AI. I also did playtesting and bug fixing.

The game itself is a elimination racer: once every car but one has finished a lap, the last car is elimnated. Along the track are item boxes than give a range of items depending on position, this lets gameplay be more dynamic.

Realistic to Arcade Physics

The template provided by Escape Studios used Chaos vehicles that meant they had physically-accuratly weight, grip, aceeleration. While this makes sense it can make movement complex to adjust and often times mean in needs to build momentum first. Almsot immeditly playtesters pointed out how unresponsive and clunky this felt to control.

It became clear an alternative was needed, so I moved the vehicles onto a third-party plugin, the Arcade Vehicle System (Furious Production LTD, 2021). It lets the stats change at runtime, and because it isn’t based on real physics, the controls are much more responsive. Playtest feedback on the driving improved straight away, and by the industry feedback session the notes said the car felt smooth to control, with good turning and suspension. I built the rest of the driving on top of the plugin, expanding and balancing the AI opponents and adding rotation bias to stop the cars flipping over.

The parts system

Customisation was one of the three design pillars in our treatment, and the parts system is how the game delivers it.

The Borderlands Treatment slide. A tagline describes a fast-paced chaotic elimination racing game with customisable powerups and vehicle parts unlocked through level progression, set in an enclosed urban circuit. Three design pillars, Frenzied, Customisable and Destructible, sit next to primary, secondary and tertiary engagement loops, each with a still of armoured vehicles in a desert.
Our treatment, with its tagline, three pillars and engagement loops.

Every player car starts as 1 of 3 shells, the Technical, the Monster or the Outrunner, and is fitted with 1 of 3 engines, 3 exhausts and 3 sets of tyres, so every combination gives different stats. The fourth car, the Cyclone, is a one-wheeler that only the AI drives. Each shell has its own base stats before any parts go on.

Each part is a data asset with its own meshes and stats, adding speed, mass and health on top of the shell’s. The shell also holds meshes for full, half and low health, so the car’s model changes as it takes damage.

When you change a part, Update Vehicle Parts adds up the stats, swaps the shell, engine, exhaust and wheel meshes, and applies the new settings, with separate exceptions for the Cyclone and the Outrunner.

The Update Vehicle Parts function in the BP_Vehicle blueprint, with comment boxes for setting the shell by type and health level, the engine, exhaust and wheel meshes, a Cyclone exception that hides three of the wheels and affects the rotation caps, an Outrunner exception, and a large box that adds the part stats and applies engine, suspension, collision, mass, health and animation settings
Update Vehicle Parts in BP_Vehicle.
Part handling and swapping in action.

Items

There are seven items, most of them named after Borderlands manufacturers, like the Torgue Cannon and Vladof’s Fury. I wrote the final behaviour for all of them, plus the item and damage systems underneath. The full showcase of the items is in the gameplay video above, the Auto Turret is shown below.

The auto turret knocking out a rival.

Race state and UI

I also built the race logic, like the gaemplay state, start light countdown and the lap, position and elimination UI. A lot of these improvments came from playtest notes. There was also a lot of work around balancing track limits. The final solution was a authored hard wall to stop any odd clipping and all props inside those limits were made to be destructible, so the player can still drive through them.

Driving through the destructible props.

Problems and fixes

  • Template issues - While Chaos vehicles was a big pain point there was some other aspects that required me to do a fair bit of refactors to support continued development on core functionality.
  • Arcade Vehicle plugin quirks - Moving to the plugin meant settings up the vehicles from scratch and learning how to use it. Some of the quirks meant I had to do some weird workarounds to get suspensoon and rotation to work properly. I also had problems with the camera not following the vehicle, collisions and acceleration stopping randomly.
  • Cyclone rotation - The Cyclone is a one-wheeled vehicle and I couldnt get it to stablise, I ended up having to stop the player from being able to use it.
The car stalling on a slope instead of accelerating.

Reflections

Gameplay is the weakest part of the project. It’s fine for a vertical slice, but it lacks the depth we planned in the treatment. We cut the secondary and tertiary loop so the team could focus on other areas, and without levelling up to earn new items and parts, there’s no bigger reason to keep playing. I also learned to research limitations of tools earlier. The whole Chaos detour could have happened even earlier if I knew what it was capable and not capable of.

Sources