Physics

Getting to grips with Tentacular, Firepunchd’s chaotic kaiju “constructathon”

Optimizing the quest system Progression in Tentacular is structured by main and side quests, each with their own stories and levels organized as Scriptable Objects. The quest system contains all elements from the game as well as the scenes that Firepunchd needed to load during each build. This enabled them to manage progression from one centralized location. “Some games manage this data with long lists, but I prefer modules,” shares Cubasch. “I can just click or duplicate a module, and I really like that workflow.” Structuring quest data with Scriptable Objects helped manipulate game data and keep Reference Exception errors to a minimum. “If we need to add more stuff or delete, it’s very easy to make adjustments,” specifies Scaramuzzino. “The iteration of level creation was much smoother because of that.” Speeding up character design Scriptable Objects also influenced character creation. The team worked on a large number of individual character assets – eye color, hair color, clothing, and headgear – and used parameters to generate configurations randomly. This sped up Prefab creation considerably. Most background characters are fully randomized, whereas main characters are customized in the Unity Editor. These Scriptable Objects are then exported and dropped into the game, where Prefabs are generated at runtime. Managing localizations To simplify switching between languages, Firepunchd linked a Scriptable Object to the database containing Tentacular’s localization strings. The Scriptable Object has functions for checking against the font/typeface and presence of certain characters. “We probably could have done this with different tech,” admits Cubasch, “but because Scriptable Objects are so convenient to use, for us it’s always a good place to go.” “All of the localization strings are in a Google Sheets document. You can pull the data from a Google document using the Google API and populate the Scriptable Object,” explains Scaramuzzino. “This way, we can be sure that every time we build, we have the latest version of the localization files.”

Read More

Expanding the robotics toolbox: Physics changes in Unity 2022.1

Rigidbody uses both interpolation and extrapolation to give an impression of smooth motion while simulating at a comparatively low frequency. Internally, this is implemented by calculating the transform poses every update. In the case of interpolation, the last two simulated poses are used to calculate a new transform pose for this frame. In the case of extrapolation, the last simulated pose and velocity are used instead. Since it is designed to be lightweight, however, we don’t communicate these poses back to the physics engine. The poses are only presented to the systems outside of physics (e.g., graphics and animation). Because of that, for instance, a raycast won’t detect a body at the interpolated pose.  To keep physics from noticing the transform changes, the mechanism was to have a Physics.SyncTransforms() call each update right before pose write, followed by an internal method call to clear all transform updates for physics. That caused two classes of problems: If a scene has at least one interpolated body, all the transform changes to all the physics components were synced with the physics engine each update (even though they’re mostly needed once per FixedUpdate); and If a change was made to a transform that had a Rigidbody component with interpolation on it, interpolation for this object broke because the user-made transform change was propagated to the physics engine and effectively changed the last simulated pose (the pose is not stored separately – it’s just the pose that the physics engine uses currently). To address these problems, we updated the interpolation code so that it doesn’t need to sync all transforms for each frame. This change also improves performance; the new interpolation code runs faster than before (depending on the scene complexity).

Read More