Introduction
Several months ago, we shared our concerns about the current power system with you, and at the same time, present a power system proposal that would tackle some if not most of the mentioned problems.
We’ve received a large amount of constructive feedback since then through posts and other power ideas you came up with. We greatly appreciate that, it gave us a lot more insight to further refine our own ideas.
At first, we tried to salvage the original proposal as much as we could but in the end, too much was adjusted and there was little cohesion left between our core mechanics. We reached a point where we just wanted to start from scratch again, keeping our vision and your feedback in mind.
This also explains why it took us this long to get another proposal ready for public.
Goals/Rules
First thing we did, was figuring out which criteria our new system should fulfill.
These are the ones we used for power and anything tied to power consumption:
Predictability: Placing a block leads to predictable outcomes
Simplicity: The game should only describe the rules to the player, not telling the player exactly what to do
Make every block matter without losing its importance with different ship sizes
Depth: The system needs to have equally viable choices within each possible situation, creating additional gameplay possibilities where possible, keeping complexity unchanged.
Performance: Game limits must not be avoidable, using the least amount of these limits is better to minimize any potential exploits
Performant: Must perform well from a game engine perspective
Creativity: Allow as much creativity as possible
Logical: Needs to make sense to the player
Solution focused: Must solve any current game issues with that particular system
With these goals/rules, we went over the current power system and any of our new ideas including the heatbox mechanic we shared before. We combined the things we liked into a new system that is explained below.

Power consumption model
Purpose: to create a system so that all reloadable systems are more comparable to systems that have a constant power consumption, essentially leveling the playing field.
Internal capacity
Weapons, tools and some other systems now have their own internal power capacity, enough to fire themselves once. This power capacity would slowly discharge over time so you need to have some power recharge to keep it topped off.
After firing it, the internal capacity would recharge using the available recharge rate. The maximum amount of power recharged for that system would be limited by its reload speed.
Priority queue
A system to prioritize power consumption in case you don’t have enough to run the entire ship. There would be different groups such as weapons, shields, thrusters, … with most likely sub-groups. We would have a fixed number of priorities you can use, and all systems with the same priority number would share power equally.
For docked entities, they just walk down towards the main ship till they find an entity with a powered (active) reactor. They would use the priority queue and power recharge of that entity only.
Chamber Tree
Purpose: adding a large amount of customization and depth, creating a whole new layer of gameplay.
It allows us to move several ship systems into one cohesive design.
This system can be compared to skill trees used in other games. The difference here is that you’re physically designing and building the skill tree, which consists of building chambers and connections in order to progress down a pre-made tree.
Reactor Chambers: tree nodes
Reactor Conduits: tree branches

Main Reactor
The main reactor group consists of a single block type that touch each other. Power will scale linear which means only the block count will affect its statistics so it’s easy to build them. The shape and reactor placement matters way more than it did before if you also have to build it in tandem with the stabilizers and make sure they’re well protected from weapon damage.
Each entity gets the same limited amount of ‘Tech Points (TP)’ to spend and only 1 active reactor group per entity is allowed at any given time. You do have the ability to put other inactive reactor groups down that you can switch to later for robustness and versatility. You spend these Tech Points for each Chamber that is connected to the current active reactor group.
Chambers
Each main Chamber Tree grouping has a corresponding Chamber Block you can place.
Using the above example, these would be:
Shield chamber
Mobility chamber
Jump Drive chamber
Electronic Warfare chamber (Cloaking/Scanning)
Chambers are built by placing a touching group of touching Chamber Blocks.
Each chamber you build represents a node in the chamber tree, The shape of each chamber doesn’t matter, only the block count does. It needs to reach a certain size compared to the biggest reactor group on the entity in order to function. It does not matter if the biggest reactor group is inactive or active. This is to avoid exploits of building small reactors with low chamber requirements on huge ships and then switching the active reactors when needed.
In order for a chamber to be activated, TP’s (Tech points) have to flow into it. This happens at a fixed pace such as 1 TP/ 1 sec per chamber and only when it is fully filled does it activate before it moves on to any of the other connected chambers.
Disconnecting chambers manually will immediately make those chambers non functional and the spent SP’s get added to your pool again.
This means that while players can design ships with multiple configurations and switch between them, it will not be as viable to do so in battle, as the configuration has a ‘boot up time’.
Conduits
These are lines of blocks that physically connect chambers with each other. On top of that tree is always the main reactor. However, a chamber can also be linked to other (inactive) reactor groups.
The conduits will require power per block to function although this is only a concern if you spread out the chambers as far as possible.
Reactor HP
Right now, we’re leaning towards removing SHP and its penalties. Instead, we’ll use Reactor HP instead. The existing system balance would need to be altered to counter the removal of the SHP penalties although not by much. The idea is that if someone targets a specific sub system such as thrusters (and they have the ability to roughly find them), they would be able to kill enough blocks to effectively disable it without relying on SHP penalties to do it for them. Overheating/loss of control would then be tied to Reactor HP and/or to a future mechanic such as hacking.
Reactor HP would be the same as Structure HP, but only the active reactor and its linked chambers affect it:
Reactor: 100 RHP
Conduit: 25 RHP
Chamber: 50 RHP
Each chamber is classified in 1 of 3 stages. As soon as the RHP% reaches one of the stage thresholds, all the chambers of that stage would have their effects disable.

Chambers would also be seen as unstable, meaning that they would do additional explosion damage if destroyed. It would scale in such a way that going above the minimum block count would be a viable option to spread out its explosion damage. Your ‘oversized’ chamber would still lose a similar amount of blocks, but because you have more RHP in the pool, it would not affect you as much as if a minimum sized one was used.
Reactor Switching
With only 1 active reactor on an entity, switching to other previously inactive reactor groups will give you a lot more options when it comes to versatility and redundancy. Activating/deactivating reactors can be done through logic (with sensor support) or through hotbar slots.
The current and maximum amount of RHP you get of course will change if you switch to another reactor. Each reactor group that was damaged when it was active, will remember their current and maximum RHP. If you ever switch back to that reactor group, it will use those values again unless you did a global reboot.
The linked chambers for each reactor don’t care if they were ever damaged, the max and current HP will always be reset for them if they become a part of an active reactor group. However, their size still needs to reach the minimum size requirement (determined by the biggest reactor group on the ship) in order to get their effect.
Building/Crafting
There would be some GUI based information such as the ability to see the entire tree without having to build something first.
The chambers themselves are built with the specific major branch block placeholders that you need to craft. By going up to these groups and pressing a key, you’ll be able to select which node you specifically want.
Chamber Tree Example

Extra
For this reactor system to work properly with existing mechanics, we had to include some extra rules and special cases:
Logic interaction
Ability to turn reactors on or off. Toggling between states will have some form of penalty/spooling up time tied to it.
Sensor blocks would work with reactor size, combined with the ability to turn them on or off you could disable turret based reactors if not providing power, allowing the turret to inherit from a bigger reactor in another chain or to automatically switch over to other backup reactors.
Docked entities
All effects you get from the chamber tree nodes are only inherited from the 1st encountered entity with an active reactor. If the active reactor is already on the entity itself, there’s no inheriting. The same applies for inheriting power regeneration and the power priority queue.
An active reactor and its stabilizers form a bounding box which is only used to check between docked entities. If either bounding box overlaps, the lowest child entity will disable the reactor and this keeps happening going down the chain till there is no overlapping.
Information warfare
Knowing where the reactors are of your opponent’s ship is quite important now and we don’t want people to just randomly shoot ships either. Going back to the old core drilling where you always knew where to shoot is not an option either. The ability to find reactor related blocks is something that will be tied to the scanner blocks and also the Scanner + ECM tree with the reactors.
In best case scenario, you can see exactly where they are, lighting up green through the hull’s ship. This would of course scale properly with transparency and intensity so that the most important reactors are easily seen
In worst case scenario, those reactor groups would not show up or appear bigger than they are and they may even move around randomly (scrambled).
In which scenario you end up depends on how strong and upgraded your scanners are, and how many points the enemy invested into countering it.
Other Systems
Thanks to the new system, there are a lot of great new gameplay elements we can add, as well as improve on old ones.
Weapons
Passive effects were always a bit troublesome. They require ratios to mass, which creates a dynamic that leads to a lot of blocks. Solving the effects via the chamber not only give the effects a lot more purpose, it also makes the whole thing a lot more consistent and logical.
Jump Drives/Jump Inhibitors
Jump drives as well as inhibitors would be changed in the new system to be more fitting for the needs of the players without resorting to chain jump drives.
Since it is clear to us that every ship is eventually fitted with a jump drive, we would just give every ship a very basic one from the get go. The chamber tree then could be used to specialize ships for jumping, increasing jump distance, reducing recharge speed or other buffs like u***lity in combat.
Cloakers/Radar Jammers
The new system also allows us to finally implement information warfare in a consistent and logical manner. Ships can be specialized for hiding information or for finding information. Ship cloaking and radar jammer as well as countermeasures can be moved to the chamber tree, as well as mechanics to determine the actual outcome of information warfare.

然而看不懂

看起来很厉害
然而看不完

不错不错，然而并看不懂