1. 29th of June, 2018: We've switched hosts and configurations for SMD, please report any issues. StarMade wiki is currently down, we will be bringing that back up over the next few days.

    StarMade Ship Systems 2.0

    Discussion in 'Game News' started by schema, May 16, 2017.

    1. schema

      schema Cat God

      Feb 17, 2012


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

      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:
      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.
      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’.
      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.
      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

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

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


      • 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
      #1 schema, May 16, 2017
      Last edited by a moderator: May 18, 2017
      • Like Like x 28
      • Useful Useful x 3
      • Creative Creative x 1
    2. Ithirahad

      Ithirahad Arana'Aethi

      Nov 14, 2013
      Tech Points? Please no... Just call these core CPU power units or something. Other than that, I'll just wait for more experienced systems specialists to weigh in on this :P
      • Agree Agree x 16
      • Like Like x 4
    3. siserith

      Jul 1, 2013
      really like how this is looking, for the most part, my only issue is not being able to have multiple reactors on at the same time, this seems counter productive and i cant see as to why you would not allow multiple reactors.
      • Agree Agree x 6
    4. Ithirahad

      Ithirahad Arana'Aethi

      Nov 14, 2013
      "Main weapons power is disabled!"

      "Switch to auxiliary!"

      Checks out fine to me.
      • Agree Agree x 5
      • Funny Funny x 2
    5. siserith

      Jul 1, 2013
      not really, what if you want to spread out multiple reactors across a large ship and run them at the same time to minimize powerless if one is hit,
      or being able to build individual reactors for individual systems.

      edit: i still cant see any reason to not allow multiple reactors at once, any real ship would have multiple reactors with redundant backups. and it just seems like intelligent design to have multiple running at once, ie, you have a main reactor for most of your systems, but you have secondary reactors for, say, engines, and another for shields, i mean this is only really an issue on ships larger than 400 meters but still, i am many others often build this large
      #5 siserith, May 16, 2017
      Last edited: May 16, 2017
      • Agree Agree x 6
    6. Deleted Account

      Jun 24, 2013
      I love it!
      • Like Like x 1
      • Agree Agree x 1
    7. wizardoftrash

      Apr 26, 2017

      love it
      • Agree Agree x 1
    8. Ithirahad

      Ithirahad Arana'Aethi

      Nov 14, 2013
      ...Also, from the video, what's to stop people from simply filling out their hulls as they do now? It doesn't look like there's any actual advantage to arranging things the way it was done in the video, with everything in small separate units.
      • Agree Agree x 4
    9. MrFURB

      MrFURB Madman of the Girders

      Jan 31, 2013
      No, no, this is stupi-

      Wait. Huh.

      You know what, this might actually work. Hey guys, it looks good!
      --- Updated post (merge), May 16, 2017, Original Post Date: May 16, 2017 ---
      I believe that filling hull with systems isn't forbidden, you just can't fill the whole thing with power reactors alone. Forcing empty space isn't something this proposal aims to do.
      • Like Like x 6
      • Funny Funny x 2
      • Friendly Friendly x 1
    10. therimmer96

      therimmer96 The Cake Network Staff Senior button unpusher

      Jun 21, 2013
      "Boost fuel" or *something*, but please not tech points.
      • Agree Agree x 4
      • Like Like x 1
    11. Lykozze

      Sep 17, 2013
      Sounds good and well thought out. I especially like the Chamber Tree and its possibillities to create truly specialized ships.

      Great concept!
    12. Top 4ce

      Top 4ce Force or Ace?

      Jul 25, 2013
      My thoughts as well.

      #12 Top 4ce, May 16, 2017
      Last edited: May 16, 2017
      • Funny Funny x 2
      • Useful Useful x 1
    13. A_Uchiha

      Aug 7, 2015
      Looks good. im a little on the fence for the whole only allowing one active reactor at once. I like what siserith was saying. but nonetheless i like where this is heading. shows alot of potential. i wont know exactly how i will feel about it untill i can play around with it , but i still give this two thumbs up.
      • Agree Agree x 1
    14. troll82

      Apr 9, 2017
      well thx for making it way more complicated then it is now. For some players it might be appealing having this kind of system in here, personally for me leave it by the old, way easier to setup and controll
      • Agree Agree x 2
    15. gamebox3000

      Jun 26, 2013
      Just because your used to it doesn't make it easy for everyone, I can't count the number of people who I've seen turn this game down because of the current power system.
      • Agree Agree x 6
    16. Valiant70

      Valiant70 That crazy cyborg

      Oct 27, 2013
      I believe I see how the U.S.S. Enterprise and other Star-Trek styled ships could be made to function reasonably well within this system, and that's a good sign. Systems are compact enough, the nacelles have a purpose, etc. Granted the saucer still wouldn't be ideal but it wouldn't be as bad as it would be in the current system.

      How do you plan to do this, or do you know yet? Does this mean chambers will affect weapons ship-wide? Or can chambers be connected to a single weapon? I would prefer the latter as it allows more design freedom.

      I'm still rather concerned about the mass of interior spaces and decorations, but hopefully crew will solve that.
      You mean you'll build the jump drive into the ship core? Some small ships like shuttles don't really need jump drives. Including them in the ship core seems very silly.

      I really like the sound of this, but watch it with the graphics. I don't want a face full of lag when I hit the sensors.

      I think the new way of killing ships is more logical. Damaging random systems to make the thing blow up is too Hollywood. I prefer to have individual systems blow up for their own reasons rather than the whole ship vaporizing for the sake of drama.

      I would like to see one of two effects from overheating:
      1. The ship doesn't explode, although the reactor might explode and take part of the ship with it. Everything just ceases to function and the ship becomes dead in space. It can be salvaged later.
      2. The ship "blows up" into several chunks of physical wreckage that can be salvaged later, but cannot be rebooted.
      • Agree Agree x 3
      • Like Like x 1
    17. troll82

      Apr 9, 2017
      for me its the problem of making small ships function as good as they do now. ill never get the same size ship work as good with the new system.
      • Agree Agree x 2
    18. dannsair2

      Dec 24, 2014
      this seams good to me. but one suggestion with the idea of chambers I would like they idea that if you should be able to invest tech points into have a secondary reactor online.
      • Agree Agree x 3
    19. jontyfreack

      jontyfreack Pipe-God-Emperor of starmade

      Nov 29, 2013
      you might want to read that bit again
      • Like Like x 1
    20. Valiant70

      Valiant70 That crazy cyborg

      Oct 27, 2013
      I think it will be difficult to cram that much stuff in and still have power to run it without your stabilizers being way out on hokey-looking, far-too-long nacelle things.
      • Agree Agree x 1