StarMade Ship Systems 2.0

 

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.

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:

1. Predictability: Placing a block leads to predictable outcomes
2. Simplicity: The game should only describe the rules to the player, not telling the player exactly what to do
3. Make every block matter without losing its importance with different ship sizes
4. Depth: The system needs to have equally viable choices within each possible situation, creating additional gameplay possibilities where possible, keeping complexity unchanged.
5. Performance: Game limits must not be avoidable, using the least amount of these limits is better to minimize any potential exploits
6. Performant: Must perform well from a game engine perspective
7. Creativity: Allow as much creativity as possible
8. Logical: Needs to make sense to the player
9. 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.

We came up with a system that is thought out quite well. Along the way, it has changed several times and there’s no doubt we’ll have to change it even more. Additional preliminary play-testing will help us nail down those specific mechanics if we’re planning to go ahead with this new system. This new system would also coexist with the current power system but hidden away through a config option.

 

 

 

When building this system from the ground up, we incorporated other aspects into it to address several flaws in systems such as weapons, jump drives, warp gates, cloakers and radar jammers. Those systems require more work but adding the possibility for reactors to influence them gives us a lot more flexibility to adjust it even more if needed.

 

The power system consists of 3 major components:

1. Reactor <-> Stabilizer relation
2. Power Usage/Consumption model
3. Chamber Tree

 

At the end of this Power System Proposal, there are a few info-graphics to help visualize the system a bit better. Make sure to read through this proposal first or you’ll be lacking context to interpret those infographics correctly.

 

Reactor <-> Stabilizer

Purpose: to not restrict player creativity, while still being manageable on all scales.

 

This defines how big your reactors can be without allowing you to fill the available space entirely and still have it function properly. That way, any ship size should be easy enough to manage when it comes to power and all of the blocks that depend on it. We can easily add more depth to the power system itself if we don’t have to worry that it will contain too many blocks at a certain ship size.

 

Our original heat box and power pylon ideas showed us that trying to accomplish this can lead to a series of restrictive rules of what you can do. Making the entire system harder to comprehend and decreasing the amount of freedom the player has.

The bidirectional relations between so many systems made most ideas invalid from the start, requiring you to constantly update any other part of your ship when adding or removing something else.

 

 

We decided to go for a 2-way relation between 2 specific power blocks, nothing else would affect them:

• Reactor blocks, they give you power
• Stabilizer blocks, these are needed to get 100% efficiency on the Reactor blocks.

To prevent a player from filling his structure with as many Reactor and Stabilizer blocks as possible, we add a single rule:

• The stabilizer groups need to be a minimum amount of distance away from any reactor group. The distance needed between the Reactor and Stabilizer groups all depend on the reactor sizes of that entity.

We use the total Reactor block count to determine the optimal distance between every Reactor and Stabilizer group. Doesn’t matter how big or small each group is, the minimum amount of distance you need to reach 100% efficiency will be the same for each.

 

The reactor’s power output depends on the stabilizers, and the amount of stabilizers needed depends on the reactor block count. This simple relation is unaffected by any of your other ship systems such as thrusters, shields and weapons.

Both block types are equally important and require protection + decent placement to make sure you keep the power flowing after sustaining damage.

 

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

 

Chambers are also just groups of touching blocks of the same type. However, each major branch in the chamber tree has a different block type needed for it, using the above example:

• Shield chambers
• Mobility chambers
• Jump Drive Improvements
• Cloaking/Scanning

 

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

 

[SPOILER][/SPOILER][SPOILER]

[/SPOILER]

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 usability 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.