BCMM From Playtests to Engine Rewrites
The final stages of the singleplayer campaign playtest ended up becoming far more than a simple balancing or stability pass. Over the course of more than 100 git commits, BCMM evolved through new runtime systems, crash safeguards, rendering optimizations and engine-level rewrites aimed at modernizing Bridge Commander without breaking its original structure.
Campaign Playtesting as a Stress Test
The playtest we conducted was not a showcase or a simple let's play, but an actual stress test designed to evaluate:
- How the campaign behaves
- Discovery of issues
- Engine quirks
- Bugs
- The new save/load system
- Edge cases
...and much more.
The end result was over 100 git commits -- some small, others introducing entirely new systems and features.
SP Stability & Crash Resistance
I honestly did not expect to encounter many issues after enabling additional mods in SP. I assumed it would mostly be a matter of enabling them and testing. Instead, what happened was that it exposed an entire array of stock game issues which somehow remained hidden because the original game never pushed certain systems hard enough for them to surface.
The test revealed numerous issues, including:
- Crashes
- Broken AI scripts
- Warp transition issues
- Broken warp sounds
As a result, BCMM gained:
- Over 10 crash guard rails
- Warp transition safeguards
- AI script protection
- Save/load fixes
- Fixes for immobile ships after warp
- Fixes for broken warp sounds
BCMM actively tries to prevent engine crashes instead of assuming "everything is fine" and hoping for the best.
Fixing the Original Game
The stock game actually has bugs -- go figure.
Many SP bugs and typos have already been documented over on the BCC modding Discord by community members, while others were discovered during our own testing pass.
Some of the more amusing examples include:
- In one mission, a Warbird AI attempts to flee after taking enough damage, but the logic was written in such a way that it would warp out regardless of whether the path was safe. The result? The Warbird immediately smashed into an asteroid.
- In mission E7M3, the USS Geronimo has its warp engines disabled after being rescued. According to the dialogue, the warp engines should later be restored, but a faulty condition check prevented that logic from ever triggering.
Bug Fixes Revealing Hidden Bugs
Yes, that happened too -- quite a few times.
One example involved fixing cutscene API-related issues, which then exposed problems in the call order of certain episode cutscenes. This resulted in players not seeing external camera shots of ships or other intended cinematic sequences.
Ironically, the actual fix was simple: correcting the call order and moving a single line higher in the sequence.
That became a recurring pattern during development -- fixing one issue would often expose another hidden underneath it.
Visual & GUI Pass
This ended up becoming a much larger pass than initially expected, eventually leading to entirely new systems and partial rewrites.
Some examples include:
- Six months ago we introduced new fonts into BCMM (Antonio and Okuda). These fonts are modern and significantly more readable, with Antonio becoming my personal favorite. However, the new font sizes shifted the positioning of some UI elements, so a GUI correction pass was required on various windows -- including SP-only interfaces such as Picard tutorial windows.
- NanoFX explosion and bridge effects were partially rewritten for better performance. The system now adapts its level of detail depending on the number of active objects in the scene in order to reduce rendering pipeline bottlenecks. The goal was to maintain visually impressive effects without destroying performance.
The overall objective was to strike a good balance between visual quality and framerate stability.
Adaptive Damage & Performance Systems
A new damage model was added which, in my opinion, feels significantly more realistic while still remaining fully optional through mutators.
The goal was to prevent ships from becoming excessively covered in battle damage while rendering damage only where it makes visual sense. The system also became smarter internally: damage rendering is now queued in order to reduce bottlenecks and prevent FPS dips during larger battles.
Runtime Intelligence Systems
The playtest revealed that several systems required modernization or complete redesigns, which led to the development of entirely new runtime systems.
One of the problems was the inability to properly raise or fake certain stock game events from Python scripts. For example, triggering a torpedo event normally required physically spawning a torpedo object simply to generate the corresponding engine event.
I wanted to avoid that entirely.
This resulted in the BCMM Event Proxy system -- a proxy/router/interceptor architecture that allows stock events to be raised safely without hacks. The underlying problem stems from the fact that these are SWIG classes with strict native signatures. Attempting to fake them using ordinary Python classes would instantly crash the game.
The Event Proxy system now safely handles this process and allows events to be raised transparently through an extendable API.
After finishing my playthrough, I also cringed a little at the extremely low resolution of the original 640x480 BIK videos. That immediately led to the development of BCMM's adaptive movie resolution selection system.
This system requires no stock script editing and does not depend on running the game in windowed mode. The logic is fully transparent.
The process works as follows:
- A movie override is registered
- BCMM catalogs the override internally
- BCMM detects the resolution of the available video
- Depending on the player's current resolution and available override formats, BCMM automatically selects the best available version
Meanwhile, the original game still thinks it is playing a normal 640x480 video, while in reality it may actually be rendering a full 1080p replacement.
Conclusion
Most of the work done here is not directly visible to the player.
We're talking about dozens upon dozens of small optimizations and safeguards whose sole purpose is to reduce engine overload, avoid lockups and hiccups, and maintain stable framerates during heavy gameplay scenarios.
Some parts of the original game logic are effectively ancient black magic. Certain combinations of API calls can literally freeze the engine entirely (deadlock the game -- fixed, by the way).
In short, BCMM attempts to:
- Be aware of engine limitations
- Anticipate bottlenecks
- Continuously monitor performance conditions and mitigate potential slowdowns
- Work smarter, not harder
BCMM is no longer simply expanding the original game. It is attempting to understand how the engine behaves internally and help it survive modern gameplay scenarios.
At some point during development, BCMM stopped feeling like a traditional mod and started feeling more like a new game built on top of Bridge Commander's engine.