Logo Platform
logo amplifiers simplified

Ship Designer: Module Editor for Customizing Ship Modules

Space BattlesShip DesignResearch

Reply
8 years ago
Nov 22, 2016, 7:25:40 PM

Idea/Ultimate Goals:  (This is a modification concept, not a redesign)


The concept for this idea is to accomplish the following goals:

  • Introduce a Module Editor for creating custom modules and thus greatly expand ship design possibilities.
  • Make researching resource-based modules more worthwhile and keep them competitive by making them scale better, maintaining their usefulness and relevance throughout the eras.
  • Clean up the Ship Designer interface and thus make the Ship Designer more intuitive and easier to use as a knock-on effect.


To accomplish the above goals, the idea is to propose to the Dev's that they add a module editor to the ship designer, to use for customizing ship modules instead of the current system where you have this huge list of ship modules, all of the same type, where the only difference between many of these modules (other than stats) is their resource variant.  Where instead of the huge list, you could snap-in and snap-out resources as needed that add the unique modifiers associated with the resource to the base module type, creating the resource-based variants in the process.


Issues With The Current System:


Currently, when you research a new resource-based material (Titanium, Adamantium, Orilchalcix etc.) or substance (Hyperium, Antimatter, Quadrinix etc.).  You can obviously use that resource in your ship designs and use their module counterparts to boost your ships stats.  You have planets that have this resource that is mined, continuously filling your stockpile up to a maximum of 999.  Any more you mine (which you can't stop), simply gets wasted/thrown away.  The problem comes in once you research the next tier of resources.  You have these new elements that are stronger and more powerful, so naturally you are going to use these as much as possible.  So, what do you do with the old resources to which you now have tons of.  Right now, not much other than diplomatic trade and a couple special support based modules.  Other than that, they become pretty much, completely useless.  Constantly accruing, and nothing to do with them.  Why?


Well the problem hits when you hit the next level/era because of 2 things.  One, you have these new resources that are considerably more powerful/useful than the previous, but you may have a limited supply, so you may not be able to use too much of them in your new builds for the moment.  So you might think, hey, then why don't you mix and match with the older resources as well, then there's no problem right?  Wrong, and that's where the second problem becomes glaringly apparent.  Unfortunately, this is where we get into the issue of scaling.  See, right now, as your tech/eras advance, so do your basic white weapon/shield modules (as they should).  The base stats of these basic white weapons and shields become stronger and more powerful, but your old resource-based modules such as titanium and hyperium, do not.  Which means that even your most basic white weapon/shield modules become even more powerful than the earlier resource-based weapons/shields rendering the older resources completely obsolete and useless as a result for anything other than a couple special support based modules.  Example:


 


As you can see by the above example, the tier 3 basic module is now more powerful than the older resource based variant, rendering the older resource useless.  And even if you consider the Hyperium Tier 2 variant, that one actually has the exact same stats as the basic tier 3 variant.  So why would you bother to use the Hyperium resource variant, when all it does at that point is increase the cost in resources and provide zero benefit over the basic white module.  All of these factors result in you now having tons and tons of constantly accruing resources that you literally can't do anything useful with.  



Often times, making you wonder why you bothered wasting turns researching them for such relatively short periods of usefulness.  This is where I think a module editor would be the perfect way to fix this problem and would literally give us everything we want and more.


Approach Proposal:


Instead of having researched a resource, then the Dev's having to create special individual listings for each and every weapon/shield module etc and specific stats for each these "basic" modules and various "resource-based" variants.  


(As you can see, in the later era's, the options box starts getting overfilled with all the different variants of the same modules.)


All they would have to make are the basic white modules and stats and scale them through the eras like they already do (this would in turn save the Dev's considerable work).  This way, apart from support modules, you would only have to select the basic white module types to attach to your ship:


(Similar to how it looks earlier in the game.  Fewer listings for the same "type" of module.  Drastically cleaning up the Design Interface)


Then add 2 interactable slots to each module while it's attached to the ship (whether it's a weapon or shield) to which we can attach resources to (whether you double up on one resource, or use one of each of 2 resources to make hybrid modules), and make the resources themselves, modifier based instead of actual individual modules.  They modify and boost the base characteristics of whatever module they're attached to.  That way, you could create your resource based weapons/shields, like you already can.  But it means you could also make hybrid weapons, like torpedoes with adamantium housings and antimatter warheads.  And on top of that, it makes all older resources useful again, because now that resources simply boost/modify the base characteristics of whatever module they're attached to, it means that all older resources will now properly scale with everything else naturally, giving them back their relevance in the later eras.  Don't have enough antimatter?  Fine, I've got plenty of Hyperium, I'll use that instead and still get a boost.  Just a smaller boost.  Or they could have a secondary effect/property that's unique to that resource, such as increased armor penetration or increased accuracy or critical hit chance etc that could keep older researched resources competitive in the later eras without breaking game balance.  Greatly expanding ship design possibilities in the process.


This would also open the door for adding more module types without having to worry about further bogging down the current system with tons of additional listings.  Such as new weapons like pulse wave blasters or defensive systems like point defense systems for defending against fighters and missiles.


Supporting Examples:

  • With the current system, adding just the above 2 examples of new ship module "types" would require a total of 14 new individual module listings in the ship designer.  One for each basic white listing, then an additional 6 individual listings each to account for all of the resource variants as well.  Resulting in 7 listings each, 14 listings total.  That's a lot of listings for just 2 new module types.  Where as the Module Editor would only require the 2 white module listings, and then those modules could be turned into the resource-based variants via the module editor.  So you'd still have access to all the resource variants you already have, but also have even more possibilities due to the ability to make hybrid variants via the editor, in effect multiplying your possible options.  All from just 2 listings.  That's a big difference.


  • On that same note, lets use just 1 of the above new module types as an example.  If you were to use the module editor, resource modifier-based approach proposed, and you were able to snap-in and snap-out 2 resource types.  Including all variations of: no resources attached, one blank + one filled, doubled up, and one of each of 2, the total number of module resource combinations (only counting the 6 resource types we know of currently in game) skyrockets to a total of 49 possible combinations.  That's 49 possible module configurations all from just 1 module type listing.  Now scale that across all offensive and defensive modules and you now have a truly mind boggling number of possible ship design configurations.  


The result?  Drastically more ship design combinations.  Considerably fewer item listings bogging down the design interface.  Resource usefulness scales a lot better through the eras "naturally" without requiring developer intervention.  And opens the door for the Dev's to add new module "types" to the ship designer (whether now or via future DLC) without having to worry about further bogging down the design interface with tons of new unnecessary separate listings.  All from a relatively small modification to the current system.  That's a lot of bang for your buck.


They can still have support modules require a very specific resource, like they currently do with support modules and I would like that, but I do think for the most part, that a module editor/resource modifier based system is the best option for weapon/defense modules overall.  


Over the short term, it would take more work by the Dev's to implement this modification to the current system, but over the long term it would save them a ton of work and open the door for them to add more unique resources and/or module types later (if they so chose to), without bogging the ship design interface down with tons of unnecessary module listings.  It would literally fix every issue currently present with resources and scaling and expand ship design possibilities by a massive amount, yet simplifying it at the same time.  It's worth considering at the very least.

Updated a day ago.
0Send private message

Out of Vision

The OUT OF VISION status is given by the dev team to ideas that are not compatible with their vision of the game or technically not feasible.

The-Cat-o-Nine-Tales

DEV The-Cat-o-Nine-Tales

status updated 5 years ago

While being able to customize your modules is an interesting idea with many possibilities, ultimately this could not make it into ES2. The level of micromanagement this would lead to did not fit well into the general design of ES2.

Comments

Reply
Copied to clipboard!
?

Click here to login

Reply
Comment