Dear Engineers,

Hello everyone! Since our Early Access launch on January 21, 2021, the Dyson Sphere Program has somehow already reached its 5th birthday. We are incredibly happy to have walked this unforgettable five-year journey with all of you. Over these five years, we want to extend a special thanks to every single Engineer. Thank you for your companionship and for the understanding, support, encouragement, and patient waiting you've shown us through the difficulties of development. It is because of you that Dyson Sphere Program continues to grow and improve.

The past five years have been a journey of shared progress. For the future of the sea of stars, we remain your fellow travelers.

We know what you're most curious about: the upcoming update plans for the Vehicle System and Space Stations. Regarding the Vehicle System, we have already completed a massive amount of design and verification work. Our goal is to create a high-freedom, flexibly scalable vehicle editing system that allows every player to hand-build their own custom ride. Furthermore, these vehicles must adhere to certain physical laws to fit the game's sci-fi atmosphere.

In terms of design, we want players to be able to customize the position and keybinds of every single thruster, allowing for precise vector thrust maneuvers.

(However, things have currently... flipped.)

As seen in the "failed demonstration" above, introducing these designs creates a chaotic physical system where a tiny change can make the vehicle uncontrollable. We aim to minimize the player's mental burden—using the simplest possible solutions to design vehicles that are both cool and easy to operate—and this requires more time to fine-tune the entire system.

Of course, this also requires us to develop a user-friendly Vehicle Editor.

(Installing components)

(Deleting components)

(Scaling operations)

Since the "Rise of the Dark Fog" update, everyone has been closely following the development of the vehicle system for two years. We may have to ask you to wait just a little longer.

In the first half of last year, we poured our hearts into refactoring the multithreading system. This was to "sharpen the axe before cutting wood"—extracting every bit of CPU performance possible before the vehicle system goes live. Over the last five years, with every update, the game's volume has grown, and the code structure has become increasingly complex:

● Every new feature must ensure it doesn't impact the overall efficiency of the base game.

● Every new feature must consider the impact on all save files and player experiences since the start of Early Access.

● Every new feature must fully evaluate the interaction between new and old features. This correlation is like a matrix where both rows and columns are expanding—the time complexity is O(n²).

Because of these "invisible" underlying tasks, we need more time for polishing. Thank you for your patience; we will continue to push forward to bring you an update worth the wait.

The Vehicle System is positioned as a highly flexible creative system, serving as a major expansion and supplement to existing gameplay. Additionally, current combat system in the game focuses on the ground; Space Combat is still being refined and has much content yet to be implemented. The addition of vehicles will significantly enrich the overall dimension and strategic depth of combat, while also driving us to comprehensively optimize existing combat mechanisms (ground + space).

To maintain whole system harmony and keep the learning curve manageable, we are integrating the Vehicle System and the equally flexible Space Station System into a single design framework, which we internally call the "Creation System."

Beyond combat, the Creation System will include more factory-focused gameplay, potentially boosting overall production in the future.

To provide a more complete and coherent experience, we plan to release the following content simultaneously in a future major update:

● Vehicle System

● Comprehensive Ground Combat Adjustments

● Space Station System

● Space Combat System

These four systems are tightly linked and interdependent, so we want them to debut together. This will be the final major content update before the game's official release.

In short, the design and development complexity of the Creation System is no less than that of the combat system. We hope it brings a massive shift to the game experience. Before we serve the Creation System, we will continue to provide QoL updates. Please give us a little more time, we look forward to the day it launches!

Next, we will release a QoL update bringing a series of practical features and optimizations. Here is what's coming:

We've heard it from players, and after opening an old save or stepping away for a while we've felt it ourselves, staring at the screen and fall into a deep philosophical crisis—Who am I? Where am I? What was my production logic? Or perhaps you return from another planet and can't find your way around your home base to pick up items. Or, you travel a thousand miles with Titanium only to realize you can't find your Logistics Station in the sprawling industrial maze.

To solve those issues, we've added a brand new building: Holo Beacon.

It can be placed anywhere as a map marker and annotation tool, helping you plan production lines and label key locations so you never lose your way in your massive interstellar factory.

It's more than just a marker; it integrates a Memo System where you can write notes and reminders at any time.

There are some usage scenarios:

◆ Map Marking & Navigation

Place beacons on a planet's surface to label resource points or factory zones. These are clearly visible even in Planet View (M Mode).

◆ Production Line Annotations

Add notes to complex logistics hubs or processing zones to explain supply/demand logic or future plans.

◆ Planetary Info & Guidance

Beacons aren't just for the ground—they show up in Planet View, the Starmap, and even against the starfield to guide you through deep space.

A memo system integrated directly into the game interface. You can create notes with icons, colors, and checkboxes directly on planets, the starmap, or blueprints, making complex planning and interstellar exploration more intuitive and organized.

Beyond Holo Beacons, Memos are integrated into several systems:

◆ Blueprint Descriptions

Insert I/O annotations into blueprints to make the logic clear when sharing or reusing them.

◆ Personal Notes & To-Do Lists

You can also write down your interstellar To-Do list directly on the Planet Panel. Memos support rich text formatting like checkboxes, icons, and text colors.

In our previous DevLog

(Full Breakdown of the ' New Multithreading System '), we mentioned that AMD generously lent us a machine equipped with a Threadripper 9985WX to test high-parallelism performance. This not only fills a gap in our testing for "god-tier hardware," allowing us to identify and fix bugs that would never surface on standard consumer-grade platforms, but also provides invaluable data on how different logic sections perform across various thread counts. This gives us a much clearer perception of potential performance hazards and bottlenecks.

Consequently, we conducted a round of targeted "deep optimization" on this device. However, average players can rest assured: this optimization isn't just for those who want to feel the raw power of their "performance monsters." Even for the vast majority of players using mid-to-low-end consumer platforms, this update will provide a significant boost to frame rates and the overall gameplay experience.

◆ Conclusion First

In conclusion, the results of this optimization are illustrated in the following figure:

This meme might have been used a few too many times, but on this Threadripper, the frame rate doubling is the absolute truth. Here are the test results for an extreme save file with 6.8 million Universe Matrices running on a system with a Threadripper 9985wx + 64g ddr5 5600MHz×8 + win10:

Before Optimization(~95–100ms per non-critical frame):

After Optimization(~43–46ms per non-critical frame):

For the same save file on an Intel i5-14400F (6P4E), the non-critical frame overhead was reduced from 290ms to 205ms. Additionally, the per-frame overhead for a 300,000 Universe Matrix save dropped from 14.5ms to 11ms, and a 100,000 Universe Matrix save dropped from 8ms to 6ms. Generally speaking, players with factory scales below 50k Matrices will see a 5%–10% improvement in final frame time, while those exceeding 100k can expect a significant boost of 20%–30%. For top-tier platforms like the 9985WX, not only did the 6.8 million Matrix save drop from nearly 100ms to less than 90ms for two combined frames, but the logic frame time for a 1.2 million Universe Matrix save also plummeted from 22ms to 11ms.

◆ Specific Details

This optimization primarily focuses on the Dynamic Task Allocation Algorithm and Cache Hit Rate. Below, we will briefly introduce our optimization logic and the experience we've gained.

◆ Dynamic Allocation Logic

When running the original game logic on a high-end processor like the 9985WX, a prominent feature in the performance profiler was the appearance of dark red regions following many parallel phases. We've labeled this overhead as "Scheduler Overhead", which primarily involves task scheduling, allocation, and the data synchronization required for inter-thread coordination.

For players on standard consumer-grade platforms, this overhead should be nearly invisible. For instance, when running on a 14400F with 16 threads, this overhead averages less than 0.001ms per parallel phase. However, on the 9985WX, this overhead scales explosively as the thread count increases.

The reason lies in our previous implementation of the common "Work-Stealing" strategy: once a thread completes its own tasks, it identifies the target thread with the most remaining work and "steals" half of it. To prevent multiple threads from competing for the same target simultaneously, our design only allowed one thread to perform a steal operation at a time. Other threads had to wait for that thread to update the remaining task data before they could proceed.

This logic performs admirably at lower thread counts, but issues arise as the scale grows. To make this easier to visualize, let’s use an analogy to helping you understand: Imagine an Adventurer's Guild. Whenever an adventurer finishes their quest, they return to the guild to find the next most valuable quest on the Quest Board. To prevent two adventurers from fighting over the same quest, the guild uses a "random draw" system: the hall master calls out one person at a time to pick a quest. Only after that person finishes picking can the next person be called. When the guild is small, most people are out in the field; the hall is mostly empty, and at most, only one or two people are waiting.

But as the scale expands—more quests, more people—the time it takes to pick a quest increases, and the crowd in the hall grows. Hardware architectures like NUMA or CCD are like the guild being forced to open branch offices. However, all branches still share a single Quest Board, and only one person in the entire organization can pick a quest at a time. Every time a branch office starts or finishes a pick, they have to call every other branch to sync the status. This causes the "quest picking" time to skyrocket. We even saw cases where Adventurer A finished a quest and returned to wait before Adventurer B had even been called for their turn. If B was unlucky, the wait time became massive. This led to the extreme phenomenon where increasing threads from 16 to 128 (8x) caused the maximum wait time to jump from 0.001ms to 5ms (a 5000x increase).

Looking at the big picture: in a 16-thread environment, after threads finish their initial share and "return to the guild" to steal work, an average of 15.9 threads remain productive. However, at 128 threads, that average could drop to only 3 or 5 threads actually working at any given moment while the rest "wait for their number to be called," leading to a net loss in efficiency.

To solve this issue, we have refactored the Dynamic Task Allocation System. We now allow a small probability where two threads might steal from the same target simultaneously—the first takes half, and the second takes half of what remains. By accepting the trade-off that a stolen target might not strictly be the one with the most tasks, we enable multiple threads to pick their "most valuable" tasks at the exact same time.

Furthermore, we now group threads into sets of 32, restricting stealing to within the group.This strategy serves two purposes: it limits the time an individual thread spends searching for a target, and it prevents the extreme "diminishing returns" seen at high thread counts—where the n^{th} thread in line might only receive a meager 0.5^n of the remaining tasks. With Thread Affinity enabled (which is the game's default setting), this also significantly reduces the frequency of data synchronization across NUMA/CCD boundaries.

Returning to our guild analogy: multiple adventurers can now pick quests simultaneously. If two happen to pick the same quest, they follow a strict sequence where the second person takes half of what the first left behind. Instead of all branches sharing one board, only 3–4 neighboring branches share a board, drastically reducing communication costs.

The final optimization result is clear in the new performance charts—the previously glaring red "Scheduler Overhead" regions have essentially vanished.

◆ Optimizing Memory Bottlenecks

Regarding memory performance, we must first thank our community for their incredible passion and insight. Since launch, many keen-eyed players have noted how memory performance impacts frame rates. Some modders even released memory-specific optimization mods, providing us with invaluable insights and experience.

That Dyson Sphere Program places higher demands on memory than many other game genres is not surprising. The game features a massive number of independently operating entities, each with its own unique data. To keep performance under control, we have deliberately avoided overly complex logic in entities that players may build in large quantities. As a result, most entity logic remains straightforward: the CPU “reads data → makes a small change → reads the next data,” which naturally leads to very frequent communication between the processor and memory.

In addition, while the game is highly parallelized and deliberately follows sequential memory access patterns during data traversal, memory performance can still become the primary limiting factor on newer consumer platforms.

For those curious about which part of their hardware is the "limiting factor," here is a general guide: Modern Consumer Platforms (e.g., Intel 12th Gen+, AMD Zen 2+): With high core counts, large caches, and strong pre-fetching, the bottleneck usually tends to be limited by memory bandwidth. Earlier Consumer Platforms (e.g., Intel 7th–10th Gen, AMD pre-Zen architectures): With smaller caches and limited concurrency, the bottleneck often leans toward memory latency. Legacy Platforms: The raw performance of the processor itself is likely the primary constraint.

When designing our data structures, we always consider memory and performance—we avoid designs that are obviously cache-unfriendly. However, we must also balance this with maintainability and scalability. Hardware evolves rapidly; over-optimizing too early can sacrifice development efficiency and increase maintenance costs, only for the optimization to become obsolete as technology changes. Therefore, during the middle stages of development, we continue to keep on feature implementation. Once a stable version is achieved, we pivot our focus to systematic optimization.

In this update, we have optimized the data structures for common buildings like Production Facilities and Sorters. Specifically, we have separated rarely-used data to "slim down" the structures, reducing bandwidth pressure during sequential traversal. For data shared by a large number of buildings(such as recipes), we have consolidated them. This ensures that when the CPU accesses multiple same-type buildings using the same recipe, the relevant data is much more likely to already be in the cache. We have also implemented low-cost caching for data that is frequently accessed but stored far away in memory, while eliminating unnecessary non-local memory access.

Since a processor's cache management is essentially a "black box" to us, many optimizations require empirical testing. A change might provide a slight boost on one device but a noticeable performance hit on another. To address this, we tested over twenty different variations and built twenty internal builds of the game, ultimately selecting the dozen-plus optimizations that showed the most significant, consistent improvements for this update.

◆ Other Optimizations

Beyond the two major optimizations mentioned above, we have also refined other areas that showed significant room for improvement in late-game saves, particularly on enthusiast-tier hardware like Threadripper.

For instance, fully constructed Dyson Spheres no longer require intensive per-frame calculations. We have also replaced standard thread locks with Read-Write Locks in "multiple-reader, single-writer" logic scenarios to improve concurrency. Furthermore, the pre-calculation logic for power system demand has been relocated to a stage that better supports multi-threaded parallelism and cache hits, which significantly mitigates performance issues caused by False Sharing.

◆ Future Directions

Optimization is a journey without a finish line. We still have several optimization milestones on our future roadmap(such as refining the Cargo System and addressing sudden stutters in the Logistics System that can occur in extreme save files). However, these modifications are broad in scope and involve intricate logic; any unexpected issue could carry significant risks. Because each change requires extensive testing to ensure stability, they were not included in this current update.

Furthermore, for a long-term project, premature optimization can often disrupt the development rhythm and increase the complexity of code maintenance. We intend to revisit these plans once the current versions are stable and the team has sufficient bandwidth. This will allow us to thoroughly validate and refine these solutions before steadily introducing them to the game.

Unity's native text components (Text/TextMeshPro) offer limited support for Chinese typesetting. Originally designed for Latin scripts (specifically English), their underlying mechanisms do not account for the complex layout rules of non-alphabetic languages like CJK (Chinese, Japanese, and Korean).

The core issue lies in the fact that native text components rely on spaces for layout with line-breaking logic is tied to word-dividers like spaces and hyphens. Since languages like Chinese do not use spaces to separate words, the native component cannot accurately determine where a line break should occur. It simply forces a break at the last character before the margin is exceeded. Consequently, this often leads to punctuation errors, such as a "，" or "。" appearing at the start of a new line, or an "（" being left hanging at the end of a line.

To resolve these issues, support our various design needs (such as the rich text used in Memos), and ensure better formatting for newly added languages, we have completely remade the text component within the Unity engine. While this task demanded a significant amount of time and effort, we believe this remake is more than just a technical milestone for the team—it is a vital step toward bringing Dyson Sphere Program to a broader global community.

The remade text component features the following capabilities:

◆ Custom Character and Mixed-Language Spacing

The new component allows for fine-tuned control over character spacing and the specific kerning between Chinese, English, and numerical characters. This can be adjusted based on the specific text to ensure a clean, aesthetic layout.

◆ Smart Justification and Line Breaking

As the text container width changes, the component automatically adjusts spacing for a more natural visual flow. Additionally, we have built-in rules for Chinese punctuation, ensuring that line breaks now follow standard typesetting conventions.

◆ Icon Mapping

The new component supports the insertion of in-game icons directly into the text (such as planet names, Logistics Stations, etc.). This allows players to create much more vivid and informative text content.

◆ Advanced Extensibility

We have also developed a wide range of extended features for the new component, including:

Checkboxes Support

Hyperlink Support

Table Support

These powerful features provide a solid foundation for the future implementation of an in-game Wiki. Furthermore, this architectural work serves not only the current version but will also benefit the team's future projects. The time and heart invested in this are well worth it; we are truly paving the way for the future.

Alongside our routine development, we are pushing full steam ahead with German and French localization. This is both a fulfillment of the promises made to our backers during the crowdfunding campaign and a major step in bringing Dyson Sphere Program to a wider community.

By integrating into the German and French-speaking communities, we are doing more than just translating words—we are building bridges. We want more players across the globe to be able to immerse themselves in the world we’ve built without any barriers. This is not the finish line; we will continue to roll out more official localizations in the future so that engineers from all over the world can explore the same starry sky together.

Of course, localization involves much more than text translation. It requires a reconstruction of the UI and systems to ensure that players of different languages can experience the game's complex mechanics with clear information and comfortable layouts.

In German and French, phrases are often significantly longer than their English counterparts. For example:

能耗倍率

Energy Cost Ratio

Taux de consommation d'énergie

Energiekosten-Verhältnis

We are actively studying the characteristics of these languages to find the best expressions for the game interface. Where necessary, we will adjust the UI layout to balance visual aesthetics with readability, striving to provide a smooth and complete experience for all players.

To advance our localization efforts more efficiently, we have developed our own internal localization tool. This allows the team to compare source text with various translations clearly and preview how the text appears in-game in real-time, ensuring accuracy and stylistic consistency.

The tool also supports flexible parameter adjustments for multiple languages, allowing us to optimize the interface layout based on the length and typesetting habits of different languages, keeping the display clear and coordinated.

Five years have passed since the first glimmer of a Matrix Research Lab was lit. Today, countless magnificent Dyson Spheres weave across the galaxy. This vast and grand spectacle exists only because of the wisdom and hard work of every single one of you. Your creativity and passion have collectively painted this cosmic canvas.

New tools, new languages, and new technical remakes—all these changes and upgrades are here to better support your boundless imagination. Looking further ahead, vehicle systems, space combat, and space stations are already on the horizon.

The universe is vast and limitless.

Let’s keep building toward the future together!

(A Special Shout-out: The header image for this update was captured by zensstrive, one of the winners of our "Lunar Mission" screenshot contest. Thank you for sharing your journey through the stars with us!)