Dev Blog Archive

Player physics is a defining feature of Tribes, but is also among the most challenging features to develop. Although every Tribes game has skiing and jetpacks, they each have very different implementations. In fact, skiing began as a bug in Tribes 1 and has evolved over the years with various sequels and mods.

Getting the player physics feeling "right" is as much of an art as it is a science. While we are very pleased with our implementation as it has evolved from alpha testing to release with help from our great community, we also want to let you tweak the underlying system and play matches with other players' changes.

We have set out to develop a pipeline that gives advanced users control over very specific values, yet presents these changes to the general population in a very simplistic way. Many of the physics variables will be modifiable through command-line functions in any offline environment, i.e. roaming maps, target practice, etc. We are taking great care to make sure that these changes are instantaneous, given the iterative nature of testing player physics. Once you have a new set of player physics defined, you may submit the changes to our system which is managed by HiRezAPC. If popular enough, these changes will be "bundled" into a named preset that can be selected when creating a custom server. For example, suppose one preset is named "Low Gravity." When setting up a custom server, I can choose "Low Gravity" from the Physics Preset list which will apply all of the settings for playing with low gravity.

Given the naturally complex nature of player physics, we don't have any current plans to modify the underlying algorithms. Player modifications are based on scaling factors for each property, where a scale of 1.0 is the default value in the base game. So while things like gravity, air control, acceleration, speed, etc. will be modifiable, the core systems will remain intact.

We will have more information shortly on the exact list of variables that you can play with, along with a formal description of the submission process for inclusion in the official list of Physics Presets. We are excited to see what you can come up with!

Hey everyone! Wanted to update that we are looking into a number of class/weapon balance tweaks over the next few patches. We actually had a meeting today with HirezAPC (our new community manager) to make sure we address as many top issues as we can.

Also wanted to release some stats for you guys. In a recent thread, CaptainSarcastic asked: "I'd like to see a general breakdown of kills by class, for instance, and/or match scores by class."

Please see the attached images. Sorry it's not more comprehensive, we are talking around options there as well. The stats in these images are limited to higher rank players, except where explicitly showing by rank. So no new players spoiling the class data, but it does include players of various awesomeness.



admin note:
there were 4 attachment in the original dev blog post. however since i can't seem attach them all in a single post, i'll attach the 4th one in the post that follows.

The following is a list of balance adjustments being tested internally today. None of these items are guaranteed for the patch yet. They have all come from various forms of community feedback.

-Increased Sentinel’s Drop Jammer radius by 50%.
-Reduced Raider’s White Out grenade radius by 10%.
-Reduced Technician’s TCNG Quick-Fuse damage by 12.5% and radius by 4%.
-Reduced Technician’s TCNG damage by 10% and radius by 6%.
-Reduced Infiltrator’s Sticky XL damage by 20% and radius by 14%.
-Reduced Infiltrator’s Sticky Grenade damage by 16% and radius by 16%.
-Reduced duration of Brute’s Fractal Grenade and Extended Fractal both by 1s. Reduced knockback on each individual beam substantially.
-Reduced Infiltrator’s Jackal damage by 5% when stuck to a surface. Reduced early in-air detonation damage by 24%. Increased time between shots from .25s to .35s.
-Reduced Brute’s Plasma Cannon hit-box size by 28% and reduced starting clip size from 10 to 8.
-Reduced Raider’s Plasma Gun hit-box size by 28% and reduced starting clip size from 10 to 6.
-Reduced Raider’s NJ5 SMG damage by 10% to be more in line with other Raider SMG options.
-Reduced Doombringer’s Mine detonation range by 10%.
-Reduced Soldier’s Short-Fuse Frag damage by 20% and radius by 16%.
-Reduced Soldier’s Grenade XL damage by 9%.
-Reduced range of the Sonic Punch perk by 36%.
-Increased radius of Raider’s Jammer Pack by 42%.
-Increased damage falloff on Sentinel’s SAP20 and Phase Rifle to be more similar to BXT1. (This is a nerf).
-Decreased damage on Pathfinder’s Holdout Shotgun by roughly 5%.

We also reviewed a number of general nerfs to automatic weapons, but based on later community feedback are planning to hold off on them. Please discuss! ;-)

followup by HiRezScott on Mon Dec 03, 2012 4:01 pm

Based on community feedback, changed a few items from above:

- Backed off on the damage adjustments to Infiltrator's Jackal. The only nerf is the fire rate going from .25s to .35s.
- Reduced Soldier's AP Grenade damage by roughly 8% and radius by 4%.
- Increased falloff on Pathfinder’s Shotgun and Holdout Shotgun by 10% (a nerf).
- Increased falloff on Brute’s Automatic Shotgun and The Hammer by 10% (a nerf).

Hey all! As Mick hinted, we are looking into implementing shielded Base Turrets and Radar stations. Our main goals with this change:

1. To reduce the effectiveness of a single player disk-sniping base assets.
2. To put additional emphasis on generator play.
3. To solidify class roles designed for base destruction (Juggernaut, Infiltrator, Etc).
4. To make sure the system is intuitive (visually) for new players to understand what works and what doesn't. New players in general find Base Turrets very difficult, so we want to make sure they understand quickly how the mechanic works.

Shields would absorb damage before Health, and rapidly regenerate. A single player shooting a Spinfusor at a Base Turret would not have enough damage burst to get through its shield before it regenerates, but two players shooting Spinfusors would. Weapons more focused on asset destruction (Mortars, Stickies, etc) would have enough burst to blow right through the shields and deal health damage. Like in previous Tribes games, shields would be tied to the generator, and would be offline while the generator is down.

followup by HiRezMick on Mon Dec 03, 2012 4:29 pm

A very related issue that we'll be testing here is having things like mortars explode on impact for certain targets, such as base turrets, sensors, etc.

followup by HiRezSean on Tue Dec 04, 2012 3:38 pm

I'll just leave this right here.

[EDIT] VirTW mentioned after seeing this that the bubble helped a lot to visually indicate, at distance, that the shot connected. Sounds like a very valid point so I'll be adding a particle effect that gives the same shield orb effect on top of visuals below.



followup by HiRezSean on Wed Dec 05, 2012 7:20 pm

Per user feedback:

The following will be available when the next patch drops, later this week.

Process for Changing Player Physics Part 1

Objective

This document covers how to change player physics and how to keep track of your changes. Please refer to the initial post, On Modifying Player Physics (viewtopic.php?f=345&t=96145) for a broader overview.

Player physics can be modified only in “standalone” environments, which includes roaming and training maps. Players can experiment with various tweaks to the values of many different physics variables.

Part 2 will explain how to select presets for a custom server and for information on working with HiRezAPC for additional community-driven presets.

Chat Console Commands

Note: These commands only work in a “standalone” environment, which includes roaming and training maps.

/SetPhysicsProperty <propertyname> <value>: Sets the value of a specific property. Properties are listed below in their own section.

/SetPhysicsProperty reset: Resets all properties back to default (1.0).

/PrintPhysicsReport: Copies all of the physics properties with their current values to the Windows clipboard for easy pasting into a text editor and prints all the current values to the log. It may be easier for your workflow to run the game in windowed mode and running the game with a “-log” command line parameter.

Physics Properties

All properties are scaling floating point values with a default value of 1.0.

• MaxSpeedDecelRate: Rate of deceleration back to max speed when the player is traveling over the max speed for the current physics type.
• AirControl: Base amount of air control for jetting and falling.
• JumpZ: How high a player can jump.
• GroundSpeed: Ground speed while walking.
• ImpulseMass: Mass of the player as it relates to being impulsed from explosions.
• Gravity: Gravity value when in freefall.
• SkiPeakControlSpeed: Center of the bell curve where strafe control is highest.
• SkiControlWidth: Width of the strafe control bell curve.
• SkiMaxControl: Max level of ski control when at peak of bell curve.
• SkiSlopeGravity: Additional gravity when skiing down a slope.
• SkiMaxSpeed: Max speed achievable via skiing alone.
• SkiTerminalSpeed: Absolute speed cap for skiing.
  [li]SkiFallVelocityTransfer: How much velocity transfers when hitting a surface from falling to skiing. There is a bug currently where this won't work and is controlled by JetForwardAccelPercent. This will be fixed in the next patch.
• JetMaxSpeed: Max speed ever achievable by jetting alone.
• JetTerminalSpeed: Absolute speed cap for jetting.
• JetAirSpeed: Global air speed multiplier for jetting.
• JetBoostMax: Max ground speed that still allows you to get a boost when you launch in the jetpack.
• JetForwardAccelPercent: Controls how much forward acceleration is applied to acceleration while flying. There is a bug where this also controls SkiFallVelocityTransfer. This will be fixed in the next patch.
• JetMaxThrustSpeed: Speed at which thrust acceleration falls off.
• JetAccelRateAtMaxThrustSpeed: Constant acceleration rate when at or above Max Thrust Speed.
• JetBaseAcceleration: Constant acceleration rate when below Max Thrust Speed.
• SplatLandMinDamage: Minimum amount of damage to take when cratering into the ground.
• SplatLandMaxDamage: Maximum amount of damage to take when cratering into the ground.
• SplatWallMinDamage: Minimum amount of damage to take when cratering into a wall.
• SplatWallMaxDamage: Maximum amount of damage to take when cratering into a wall.
• SplatMinSpeed: Minimum speed the player needs to be going before cratering.
• SplatMaxSpeed: Maximum speed that deals maximum damage for cratering.

Max Speed vs. Terminal Speed

While Tribes: Ascend isn’t speed capped (well, at least in the realm of achievable speeds) we do employ a mechanic that attempts to limit the speeds achievable by jetting or skiing alone. This mechanic exists purely for game-balance reasons. The problem with a standard speed cap is that the game physics feel wrong if players don’t gain speeds when falling or when impulsed by an explosion.

“Max Speed” therefore represents the limit on this soft cap. If a player is traveling at a speed over this limit, they are gently brought back to Max Speed based on a ratio between the Max Speed and the Terminal Speed, multiplied by the global “MaxSpeedDecelRate.”

The Terminal Speed is the absolute cap and is designed to be so high, that it is unachievable with the default values. The setting works though, if you want to experiment with a speed cap.

Ski Control

Tribes: Ascend allows players to correct their lateral movement while skiing. This feature is designed with a “sweet spot” that allows for optimal control at mid-to-high speeds.

There are several reasons why we implemented ski control this way. At low speeds, the base implementation has very minimal correction because players could actually ski in circles up and down a hill and it generally felt strange. At high speeds, the base implementation has minimal correction because of balance concerns; try hitting a highly skilled player zipping around the map with a lot of course correction!

SkiPeakControlSpeed, SkiControlWidth, and SkiMaxControl control the shape of the bell curve.

Stages of Flying

There are three stages to flying:
Initial Thrust: This has the most acceleration by default
Standard Thrust: Players will still gain speed, but at a slower rate than the initial thrust
Max Speed: The maximum speed achievable by jetpacking alone.

There is also an added boost that most players leave on by default: jump-jetting. Tribes: Ascend simplifies the benefit of jumping and then jetting at the apex by auto-jumping by default when the player presses the jetpack button. Changing the JumpZ will impact the balance of the initial thrust phase, but be aware that some players choose to separate jumping and jetting!

“Splatting”

Because Tribes is so fast, players take damage when “splatting” into things. Splatting is divided into two types: walls and ground. The default values yield the same damage values for both types of splatting, but we have made controls separate for you to change them, if you wish.

There is a range of valid speeds to be considered a “splat” which is universal, represented by SplatMinSpeed/SplatMaxSpeed. There is a corresponding percent-based range for wall and ground damage values, represented by SplatLandMinDamage/SplatLandMaxDamage and SplatWallMinDamage/SplatWallMaxDamage.

Been busy bouncing around on a variety of tasks, one of them being the second iteration of the player-driven physics system. We've had great feedback on the physics controls released with our most recent patch and I've seen some really promising models coming from the community.

Among items for the next list include a way to do bulk entry, verification messages, and a host of new controls for you to play with including lots of flag controls, ability to change jetpack energy consumption, and dividing impulse mass between light, medium, and heavy armor types.