- Joined
- Feb 17, 2012
- Messages
- 1,552
- Reaction score
- 2,604
Update1:
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:
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.
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 System Proposal 2.0
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:
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
Extra
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:
- Reactor <-> Stabilizer relation
- Power Usage/Consumption model
- 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:
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 modelThis 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.
- 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.
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.
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
Chamber TreeInternal 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 queueAfter 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.
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.
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.
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.
Main Reactor
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
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.
ChambersEach 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.
Each main Chamber Tree grouping has a corresponding Chamber Block you can place.
Using the above example, these would be:
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’.
ConduitsEach 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’.
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 HPThe conduits will require power per block to function although this is only a concern if you spread out the chambers as far as possible.
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 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
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.
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/CraftingThe 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.
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 ExampleThe 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.
For this reactor system to work properly with existing mechanics, we had to include some extra rules and special cases:
Logic interaction
Other SystemsLogic 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.
- For now we removed the possibility of having more than 1 active reactor on the entire entity and all of its chains. Power and Chamber effects will inherit from the lowest possible active reactor, any other active reactor will then be forced to shut down or its power recharge/effects will be ignored.
- 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.
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.
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.
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
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 JammersSince 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.
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.
- Only 1 active reactor allowed on the entity and its chains
Power and Chamber effects will inherit from the lowest active reactor (lowest == main ship) and any other active reactor will be forced to shut down or its power recharge/chamber effects will be ignored.
- Updated infographics for previous change on 17th of May.
Thanks for playing StarMade,
~ the Schine Team
Last edited by a moderator:
