Bringing My Talking Tom Friends 2 to life with animation and physics

As the sequel to My Talking Tom Friends, one of Outfit7’s most successful titles, My Talking Tom Friends 2 feels like a natural next step to give players an updated experience. The mobile game brings together popular characters from the first iteration for a next-level virtual pet adventure in a fun-filled new town.

We sat down with Mihec Pezdirc, fellow software engineer at Outfit7 and Črt Kristl, the team’s principal software engineer, to discuss how they optimized performance across devices, built a scalable animation system, and managed content complexity.

What were the biggest technical challenges when building the game?

Mihec Pezdirc: Optimizing the game to run smoothly on devices from iPhone 5S and low end Android phones to the latest Android phones was a big challenge. We focused on performance, size, battery efficiency, and visuals.

With almost 1,000 animations, we built a custom system to keep app size used by animations low, between 10 and 15 MB. Switching from pre-rendered visuals to a dynamic world required dropping older standards like OpenGL ES 3.0. We also enable ASTC texture compression and compute shaders for high-end devices. ASTC also reduces app size, which helps in markets with storage and download limits.

How has working in Unity helped with the core gameplay and minigames?

MP: Unity’s flexible Editor enables efficient collaboration between developers, artists, and VFX teams. We built custom tools and Timeline extensions for cinematic moments.

Črt Kristl: From a developer’s perspective, Unity’s fast iteration is a major advantage. You can tweak code, recompile in seconds, and instantly test changes. We’ve also automated much of our pipeline with custom post-processing tools and asset workflows, saving significant manual effort.

How does the custom Scriptable Render Pipeline (SRP) shape the look and performance of the game?

MP: Our custom SRP optimizes rendering for mobile, tailoring effects per device tier. It still maintains visual consistency. We control shadow rendering and screen space ambient occlusion (SSAO) directly, saving GPU time with single-pass downscaled SSAO and a static shadow map camera. This reduces CPU overhead and increases and stabilizes shadow quality.

How does leveraging the C# Job System and Burst compiler impact the game’s visuals?

ČK: The C# Job System handles animation pipelines – retargeting, IK, and look-at transformations – and runs jobs across characters efficiently. It also supports CPU-heavy systems, like cooking minigame simulations, in parallel with the GPU.

MP: Burst compiler and Unity.Mathematics for Single Instruction, Multiple Data (SIMD) improved performance and helped us solve early challenges with managed code performance. This allows the game to run smoothly even on lower-end devices.

What role does Unity Physics play?

ČK: Unity Physics is key in the cooking minigame, where all objects, from food to the conveyor belt, are fully physics-based. Rather than moving objects manually, everything runs on Rigidbodies. Once parameters like drag and mass are tuned, the system becomes stable and allows reliable interactions such as stacking food.

MP: Having not used Unity Physics extensively since Unity 5, we’re impressed by its improvements. Outside the minigames, we disable most physics on lower-end devices, and we only enable lightweight operations, like sphere or capsule casts for tap and drag interactions.

ČK: Unity’s low-level physics controls give us flexibility to fine-tune gameplay, which lets us ignore specific collisions or handle contact resolution manually without extra overhead.

How does the character conversation/comment system work?

ČK: We maintain a large Excel sheet of all conversations, each tagged with a unique identifier. Designers update this sheet, and Unity imports it to build a conversation graph.

Character actions, like sitting or eating, determine which conversations are available. For example, when three characters sit on a bench, the system randomly selects a non-repeating conversation. It then applies cooldowns to keep interactions fresh.

MP: Custom logic handles interactions like greetings, requiring proximity and respecting cooldowns to keep them organic. The system aims for a relaxed, natural flow, using simple conditions and timeouts instead of complex mechanics. This makes it efficient and designer-friendly.

What other performance-related issues did the team encounter during development?

ČK: Rendering and shaders were very challenging on mobile. We categorized devices by CPU/GPU performance, then created shader variants to activate only what each device needed. We benchmarked compute shaders, and pre-warmed commonly used shaders during the splash screen to avoid long load times without causing frame hitches or crashes.

MP: We optimized scene loading by dynamically loading assets and effects rather than embedding them in prefabs. This keeps transitions smooth even on low-end hardware.

What milestones did the team reach during development?

MP: We achieve key metrics by optimizing app size and memory without sacrificing performance. We balance LZMA and LZ4 compression depending on the asset type. By using custom asset bundles and selective compression, loading times on older devices improved. We automated the build pipeline and made these optimizations fast and repeatable.

ČK: We’re proud of the new action system. It’s a state machine that tracks character activities. This setup lets multiple developers create interactions independently, without breaking the system.

What advice would you give a developer looking to build a long-term mobile franchise?

MP: Plan your distribution and marketing early, and don’t rely on app store visibility. Create something unique, or better than what’s already out there, and be ready to iterate and fail multiple times.

ČK: Make games you genuinely enjoy. Passion for your own creation often matters more than analytics.

To read more about projects made with Unity, visit the Resources page.