[DevLog #02] How we packed a local AI voice actor without exploding PCs

We are the dev team behind Wilderness Relic Restorer. After countless sleepless nights of intense coding and debugging, we have officially completed our dual-platform build packaging and submitted our Steam Demo for review!

To celebrate this milestone, we're kicking off this [Build in Public] DevLog series. Instead of posting dry, robotic changelogs like "Fixed minor bugs," we want to share the actual, blood-pressure-raising technical hurdles we encountered—and how we ultimately beat them.

For our first post, let's talk about: How did we pack a fully offline "AI voice actor" into an indie game that’s only a few hundred megabytes?

🎙️ The Origin: Relics shouldn't just be seen—they should "speak"

In the world of Wilderness Relic Restorer, you play as a post-apocalyptic engineer scavenging and repairing long-lost relics from a bygone era. Every time you restore a broken pocket watch, a rusty radio, or an old tin box, you will hear a"Relic Whisper"—an echo of the last memory of its previous owner.

To make these whispers feel textured, diverse, and atmospheric, we made a bold decision: use AI Text-to-Speech (TTS) technology to generate real-time voice acting for the relics.

However, we need to clarify one thing first: real-time AI voice generation is selectively applied to core story relics (partial voice-acting), rather than all texts. Since players' PC hardware specs vary wildly, local AI synthesis speed cannot be universally guaranteed. To ensure the gameplay is never interrupted by waiting for voice synthesis, we adopted a "critical relics only" strategy, focusing our resources on the most narrative-heavy relics.

Even so, we immediately faced a massive philosophical dilemma:

“What if players are playing offline?” “What if our voice servers go down? Will that ruin the player's immersion?”

To respect our players' offline experience, we set a strict rule: No cloud servers. The AI voice engine must run 100% locally and offline, packed directly inside the game client.

🛠️ The "Russian Doll" Architecture

Our core game is built using Cocos Creator. However, lightweight offline AI voice generation (we use the excellent open-source project MOSS-TTS-Nano) relies heavily on Python and ONNX Runtime.

To make them play nice together inside a single package, we designed a "Russian Doll" container architecture:

• The Shell: We use Electron to pack the Cocos web build into a standalone desktop client.

• The Core: Upon game startup, a lightweight local Python TTS server is spun up silently in the background.

• The Bridge: The Cocos client talks to this background AI process via local loopback HTTP requests. The game sends text, the Python process returns a WAV audio stream, and the game plays it.

Sounds elegant on paper, right? Well, this is where the nightmare actually began.

💥 Dev Nightmares: The Blood-Pressure-Raising Moments

1. The 56-Second Freeze and Screaming CPU Fans

During our first packaged run, we double-clicked the game icon with childish excitement. What followed was a brutal 56-second black screen lockup. Our lead tester pinged us on Discord:"Uh, guys, I thought my PC was about to blast off. My CPU fans sounded like a jet engine."

After tracking the logs overnight, we found the culprit: WeText FST (Finite State Transducers) cache loading. Every time the offline text normalization engine booted up for the first time, it would try to parse and rebuild a massive text regex database from scratch. While this is tolerable on high-end dev rigs, on ordinary user CPUs, it completely pegged a single core to 100%, causing the main game process to freeze in sympathy. (This performance spike further solidified our decision to use AI synthesis selectively, as we must protect users' hardware from thermal throttling).

【The Fix】: We refactored the boot sequence. We pushed the AI engine initialization and pre-loading to a background thread and extended the HTTP connection timeout from 20 seconds to 60 seconds. We also added a smooth loading animation during the game's initial "system check." Now, by the time you reach the main menu, the AI engine has already warmed up silently in the background.

2. The Ultimate Boss: Spaces & Non-ASCII Characters in Windows Paths

If the 56-second freeze was "physical damage," this next issue was "magical debuff."

When testing on Windows, some players heard the voice-acting flawlessly, while others crashed to the desktop the moment they clicked "Appraise Relic." In the debug logs, we saw this error:

OpenFst: Can't open file: C:\Users\张三\AppData\LocalTemp\...

As it turns out, the C++ library OpenFst uses the legacy ANSI narrow-character file APIs on Windows. This meant a catastrophic design flaw: If a player's Windows username contains non-ASCII characters (like "张三"), or if the game's installation path contains spaces (like the default `Program Files`), the voice engine would immediately crash when loading model files!

For a game aiming for global release on Steam, this was unacceptable. We can't force players to rename their Windows accounts, nor can we stop them from installing games in directories with spaces.

【The Fix: How we tricked the system】: Since we couldn't easily rewrite the compiled C++ binaries, we decided to redirect them:

• Bypass the ASAR Limit: Electron's packed `.asar` file is read-only, meaning we couldn't write dynamically generated caches inside it.

• Path Redirection: We wrote a dynamic path resolver. On Windows, the game forces the creation of a "safe zone" directory under the Windows public folder: `C:\Users\Public\wilderness-relic-restorer\wetext_cache`— a path guaranteed to have zero spaces and zero non-ASCII characters.

• At boot, the game extracts the necessary model files to this public safe zone and points OpenFst there.

With this redirection trick, we completely bypassed the "non-ASCII path crash" that plagues many cross-platform indie developers.

📈 The AARRR Funnel: What’s Next?

Applying SaaS growth frameworks, we know a great game shouldn't be built in a vacuum. We treat this Demo submission as our first real market validation test.

During the upcoming Steam Next Fest, we will:

• Monitor the data: We'll keep a close eye on "Store Page Visits -> Wishlists" conversion rates, adjusting our screenshots and capsule art dynamically.

• Collect raw feedback: We will have an in-game bug reporter and a dedicated Discord channel. If the AI voice sounds robotic, has lag, or does something weird on your specific hardware, tell us immediately!

💬 Let’s Chat

If you are an indie dev, or if you're just curious about how we stuffed a local AI voice model into a standalone client, drop a comment below! Have you ever wanted to throw your keyboard out the window because of legacy Windows file path limits?

Once the Demo is approved, it will be free to play. Please add Wilderness Relic Restorer to your Steam Wishlist! Every single wishlist is the ultimate fuel for us to keep fixing bugs at 3 AM.

https://store.steampowered.com/app/4643810/ 👉 Click Here to Wishlist on Steam

See you in the next DevLog! (Next up: We'll talk about how we simulated tactile, physical feedback when repairing relics in Cocos Creator. Stay tuned!)