A/B testing on dev builds?

[aRottenKomquat]

After seeing the hugely mixed reaction to the new reactor proposal, I got to wondering if Schine has the resources and manpower to consider A/B testing. Basically when you have something this new and this game-changing that can be addressed a few different ways, partially implement ALL the ways. Yes they'll be buggy and incomplete, but if they're coded up just enough to get the basic idea across, players can tinker with each way and then provide feedback on which ones they liked, which they don't, and help figure out what works and what doesn't before Schine spends a ton of effort fully developing the feature.

Maybe this would be a good task for future Councils, too. Organize events based around A/B testing and help gather feedback for Schine.

Such a scheme could be really helpful in the future when they start devoting a ton of time to game balance.

 

[NeonSturm]

But this needs to be outside the "dev build" branch, maybe an "experimental or modification branch" (else peoples might get a false idea).

The code is a lot of work, but not hard work:
system.parts = { part, part, part } // the config file would replace system with [SystemName] and part with [PartName]
system.slaves = { slave1, slave2, slave3, … }
systemPair.master = system.getMaster( system1, system2 ) // systemPair is about pipes
systemPair.slave = system.getSlave( system1, system2 )

getMaster
   ( sys1, sys2 ) // variables
   {
   if( sys1.doesSlave( sys2 )) return sys1
   if( sys2.doesSlave( sys1 )) return sys2
   }
getSlave
   ( sys1, sys2 ) // variables
   {
   if( sys1.doesSlave( sys2 )) return sys2
   if( sys2.doesSlave( sys1 )) return sys1
   }

/* similar code for groupPair.getSystem (defining block type) and groupPair.getPart (less defining block type) when 2 groups touch
 * the defining block type is the primary one of a chamber-system. A group checks for unaware neighbours if it found the defining neighbour.
 * a block group are all blocks of the same type which are touching, or all blocks of a shape which are touching.
 */
/* to be … continued
 * continue … to be
 */

1. what connects to what
2. which shapes are required
   
3. group of blocks (similar touching, complete shape) touching another group
4. variables pros/cons of a part pushed to the system (BlockBehaviourConfig.xml has buffs/debuffs, shine has done this work already).
5. …

But I think it's more useful / easier if shine just release one ship which looks like they want it to look.