[2023] Dev Log: Combat System

A lil somethin somethin: You can find the details for this event on the announcement page here.

Hi engineers!

In the months following Dyson Sphere Program: Rise of the Dark Fog's showcase at TGS 2022, we received a lot of encouragement and support from our players. This has greatly motivated our team to put more effort into developing combat-related content. Let’s have a glance at the visuals we are currently working on:






During the combat system development, some optimization of existing gameplay systems was also introduced. Such as a new distribution logistics system, more advanced Chemical Plants, Splitters with storage, more convenient conveyor belt tools …

In order to maximize the team production effectiveness, we split our workflow into two branches - The Rise of the Dark Fog (combat system) branch and existing content updates. So that we can do these two parts of work at the same time, and keep the combat system info confidential. But we need to make sure to merge the changes made in the Update Branch into the Combat Branch from time to time, to ensure that the work on both sides is always in sync.



However, we also have a piece of bad news here: During the year that the combat system branch has been running separately, its content conflicts with the main branch have caused many code and resource issues. We had to put huge amounts of extra effort and time to resolve these problems every time, and sometimes we even have to deliberately avoid modifying common resources and low-level codes, which distracts us a lot from the combat system development. To speed up the progress of combat system development, we have decided to devote our full effort to the combat branch. In other words, we will still be able to debug and modify the existing game contents, but not be able to add any new features before the combat mode is grounding.

This will give us an opportunity to refactor the combat system codes and some of the low-level codes. The game’s performance bottleneck became apparent after adding abundant content in batches – my old pc (GTX660Ti) could barely run at 10 or even 9 FPS. Seeing this, we decided to overhaul some unoptimizable, inflexible codes that burden the frame rate. We have done it once, so we had experience and were willing to find out better solutions. It’s a hard process, but we have determined to reach our goal: Dyson Sphere Program must perform smoothly after the combat system is implemented.


(made some hardware upgrades as well)

There’s a saying, “designers only make requirements, and programmers implement them”, is not for us. When a performance issue comes up, it never helps if the designers say “I don’t care, it’s the programmers’ duty to solve it.” or “forget it, the tech is not there yet.” We believe that the two departments must think and work together. Their work was never separated.

In Dyson Sphere Program, players’ factory objects can easily reach millions in scale, so performance is definitely a priority. The ultimate performance limit of a game is determined during the design phase, and then it depends on the technical skills of programmers to try to reach it. That’s why we ask designers to use the remaining performance space wisely to create as many possibilities as possible during the design phase. After going through a gameplay validation, we came up with design goals. The image below shows the hypothetical comparison of combat power between players and the Dark Fog.



We know that if the Dark Fog takes up the player’s development space (and CPU computing resources), the player will want to destroy it. So the activity of the Dark Fog and the player’s factories are roughly inversely proportional, and we used it to set the following performance optimization goals:



If players choose to leave the Dark Fog alone in the latter stage of the game, then the remaining massive Dark Fog hive will be a huge burden. And at this point, the Dark Fog’s entire production system (space nests, planet bases) is insensitive to players, so it doesn’t need to update as frequently as player factories.


(Dark Fog’s expansion logic)

After consideration, we set the Dark Fog nest’s update logic to once every 60 logic frames, and all nest updates are evenly distributed across each frame as much as possible to avoid updating too much logic in one frame. For example, if a player chooses the 60-Star startup build, then each logic frame will update one planetary system’s Dark Fog nests in turn. The following are some simple load-balancing codes:



The seemingly simple idea above rises other problems: if the Dark Fog updates once every 60 frames, what about other non-building combat units and transport units in space? How to blend the animations of the Dark Fog ground buildings?


(space units’ fleet matrix)


(ground units’ group behavior)

Well, in this case, We will have to take our BIG MOVE: using GPU to process some computations.
Just like the optimization of Logistics Drones, CPU doesn’t have to calculate the curve that transports aircraft go through from point A (xA, yA, zA) to point B (xB, yB, zB) to unload cargo, or the process of body rotation, ascent and descend, how the tail flame effects change, etc. All CPU has to do is just add up a “t” value.



And GPU will take care of the more complex mathematical operations:




The following is a performance test Save of a large number of transport aircraft. Feel free to download and try it out if you are interested:
MilkyWay Download[8.140.162.132]
Google Drive[drive.google.com]


(21,000 Logistics Drones update at the same time)



Since 99% of the time enemy combat units are performing wandering behavior, we can design to make their trajectories more computable by using parametric equations to represent their motion paths. This way, we can optimize most of the wandering enemies as we do with Logistics Drones.

Next, we plan to seamlessly switch between GPU and CPU calculations when they enter/exit attack mode and return to wandering.

However, this solution also poses some challenges, such as finding suitable attack targets for free-target projectile when attacking these enemies-- this indeed complicates simple problems, but compared to the performance “disaster” caused by full CPU simulation, we have to do this first and then deal with whatever comes next. Complexity cannot be eliminated, and performance optimization is about transferring runtime complexity to code complexity.

(nothing yet.jpg)

Apart from all that, we found out that when starting a new game with the highest difficulty level, the total amount of dark-fog buildings in 64 planetary systems reach 200k (just buildings). Even when we reduced the logic overhead to below 3ms, the Dark Fog still occupies about 50M of Save data.



For newly created Saves, players can’t sense the presence of the Dark Fog in other planetary systems, so they find it hard to accept such large Saves. Meanwhile, we believe far away or not, Dark Fog must develop according to certain rules, and the determinism of these rules will increasingly become important later on. Just like the consistent running logic of the “real universe” in games, leaving a planet doesn’t make factories on it lose their logical determinism.



Therefore, we have to split the logic and data of dark-fog growth into multiple deterministic LODs (Level of Details) and specify switching rules between levels.

And In order to ensure stability, we redesigned the nest growth process so that it could bake out a certain nest growth map based on fixed age and random number seeds in real-time without interference. This way, even when each nest contains up to 2000 buildings and units, we can at least transform distant nests that had not been encountered into several header data such as “age”, “random seed ”, etc. and generate relay stations and seeds simultaneously to ensure that unencountered Dark Fog can still expand outward.


(Minimalist data form)


(content in blue/red/yellow box presents three different LODs)

We are still working on refactoring the code for the combat system. We have basically finished the LODs in the blue and red boxes shown in the image above, as well as the self-replication and expansion of the Dark Fog nests. Once we finish refactoring, we will move on to optimizing the more complex aspects of combat.

For modeling, we need to improve the destruction effects for each building and the LODs for all dark-fog buildings, as well as the animations for each LOD.



For some complex effects that require a lot of rendering, we still need to use shaders to simulate them. A typical example is the hit effect of projectiles:



If we use the particle system provided by the engine directly, it will not be able to support a large number of effect instances. We need to use the method mentioned in our previous development log and convert each particle system into a shader-based simulation of these hit effects. Here is one of them:




(Take it easy, it's just a test)

At the end of this development log, we’d like to remind you again that players who prefer building and management can completely turn off the Dark Fog. In addition, players can also adjust some difficulty parameters for the Dark Fog in detail.


(The options shown above are only based on our current design and are not final.)

This is the end of the Dev log.

By the way, here's a good news: The producer couple's baby was born last month! Currently they are still in the hospital, one hand holding the baby and the other hand coding Dyson Sphere Program.

If you are interested in our previous dev log, feel free to check it out HERE!

Thank you for reading! See you next time!