My thoughts for feedback

[JWoodrell]

So after playing for a few hours here is my list of bits.

 

1) signal diodes - like a logic blocker but transfers signals  only one way through it so commands can propogate out from the core, but local command decisions dont go back to core.  To prevent having to mirror core command funcions on both sides of a current logic blocker.

 

2) rotation joint speed control - having a slider or type-able box to control rotation speed.

 

2b) end stops for joints (rotation and free) -  limit the rotation of joints  probably just a single slider to control +- from centerline, with 360 allowing continuous rotation

 

3) type-able boxes for all sliders - to allow more precise input of what you want it to do.

 

4) analog signals - having things be able to make decisions based on input numbers rather than just digital signals. 

 

5) settable rigidity for connection spars - currently spars are fairly springy leading to gummy ship syndrome.  It would be nice to be able to make them more rigid or more squishy.  The tradeoff cost being rigid beams are more “brittle” so theyre easy to break whereas squishy ones could almost function as intentional springs.

 

6) radar block - works like the detector set to enemy but returns two analog values of angle and distance.  Tune-able to three phonotypes of enemy (red blue amd green).

 

6b) detection block returns distance value starting at max range as well as current on off output

 

7) logic core - openable programming grid to setup logic gates on. I envision this coming in multiple sizes based on  the number of I/O it has and how many logic  blocks it can support internally .  I envision IO as being settable as just picking signals, or mayb fixed as x # of in, x # of out this would allow the finding of bigger and better logic blocks.  Say a 1x1 logic core can only hold say 4 logic blocks and have just 4 I/O,  1x2 would have 10 blocks, and 6 I/O, and a 4x4 core can hold  blocks and 24 blocks and 8 I/O.  Wireless logic blocks would still be external to cores (transmission equipment) and only carry one signal each.  Power draw would be linked to number of used blocks.

 

8) storage and regen in seperate modules.  Fuel reactor consumes some kind of compressed resource onboard, to require refueling, the reactor doesnt have much bulk storage, and doesnt generate enough to feed all thrusters in real time.  and fuel tanks to allow bulk consumption quickly but get refilled by reactor.  To prevent the solar panel farm things turn into now.

Power is split into panels/fusion and batteries.  It will regenerate infinitely however maybe have solar panels have lower output when underground compared to on surface.

 

9) weapon turrets toggale fixed or not, so they become fixed, or allow them to take a pair of analog inputs of range and distance, so logic could aim them.

 

10) inventory rather than item type - so you found a new type of weapon, cool story bro, but that doesnt mean you can instantly load 40 of them onto your drone.  On the simple end it could just cost gems to purchase extra copies for your inventory.  At the more complicated you could have a production plant in the mothership that requires different resources to make different  stuff and having a production que of stuff you want it to make.  This would give a reason to hunt different types ( colors?) of resource

 

11) resource drones controllable - right now they just wander around randomly and its hard to get the derpies to do their jobs.  Maybe have a follow “key” and they follow the cursor, or aimable with analogs to guide them into the resource, but they have to make it back to you for your drone to collect it, and your drone has to survive and make it back to the mothership to collect them from the planet.  Would give a good meaning to the refueling mechanic because if you ran out of fuel and couldnt make it back, you didnt gain anything from that planet run