Lurkily

Not sure. I'm not feeling this one, but I'm not sure why. Part of it may be that it's not emergent; most of the weapons with complex behavior are emergent from simple combinations. You can make a carpet-bomber for instance, but it's basically a grenade launcher with accuracy downgrades, and multi-fire/RoF upgrades. You can make an acid sprayer, but it's just the particle gun with heavy and bouncy particles. In this, it feels like though you build it from the smaller guns, it's not an emergent property of them. It's a whole new gun, and the four guns are part of a recipe. I'm not sure. I'm tired. I'll sleep on it and look at this again.

Brief question. Which tech? Most of the enemies currently just shoot guns at you, and a lot of the planetary enemies are not technological. Is this for sumo?

I'd like a sensor for distance. Distance to the nearest terrain, distance to the nearest enemy, nearest ore, distance to Nimbatus, distance to the dropoff site. I'd also REALLY like to be able to get the distance to a specific block - either another paired distance sensor, or just a block you specifically select in the construction menu, whichever. EDIT: Merged these topics. I thought I had seen more of them, but it must have come up in the discussion of other ideas. But while I have them both open, I might as well. As ManTheMister said, something that works like an altimeter, but tuned to selectable targets (Such as drone core, planet core, and other already extant targets) would be fantastic; and could even serve to obsolete the altimeter. I meant to merge mine into yours; it looks like I did the reverse. Sorry about that.

I'd like to be able to pair certain sensors so they each detect whatever relative to their paired block. For instance, two directional sensors would always point to each other. Two speedometers would detect each block's speed relative to the other. (Read the delta between their speed instead of the speed alone.) Altimeters would read zero when they're both at the same altitude, but if one was ten meters higher, one would read -10 meters, and the other would read +10 meters. The only thing I can't see this working for might be things like detectors, which are just on and off. Any interaction needed can be done with logic. A pairing like this would make it possible to have separated drone parts act with coordination, and would bring a new level of self-awareness to drone control. You would be able to logically begin and end processes when parts are aligned (jaws are fully closed, stop closing buzzsaw jaws)

I guess what I'm getting at is that design strategy seems very focused on giving players very basic means by which to make weapons with complex behavior. They don't give you an acid sprayer, but they do give you a particle weapon, and also spread upgrades, sticky particle upgrades, and high-gravity particles, so voila, acid sprayer. I think it might be more successful to consider what upgrades can be made available to make a grenade launcher into a cluster bomb - allowing the player to craft complex behavior from the simple weapons - rather than adding new weapons that start with pre-scripted complex behaviors.

That's the idea; less about making it easy, and more about not losing your progress in the mission and having to replay it if you're able to continue, but lost a critical part. I find replaying missions frustrating.

So I can get not wanting to be able to rebuild your drone from the ground up; that doesn't seem to be a part of the design philosophy here. But what about mounting something on the Nimbatus itself that could rebuild missing parts? Get under the Nimbatus, and into a specific region, and stay there, and it can begin rebuilding parts. The end result wouldn't be a kind of invulnerability, and you would have to retain some maneuvering to be able to get back to altitude in order to take advantage of it. But it would also mean that losing a couple of critical parts or logic isn't the end of your mission.

If it causes issues, you could always make micro-drones fully rigid, since in this example, they're going to be limited by part size, and relatively small - small constructs are typically stable to begin with, so making the micro-drones more absolutely rigid shouldn't betray a player's expectations. These are more things that would be assisted by the 'truth table' suggestion; a detailed logic table in a single part would make intelligent sub-drones more likely.

That's the one. It's about literature, but I think that particular article refers to the design of a setting, so I think it has application to game design, as well.

I have thoughts on this. There's another suggestion up about manufactories with a decoupler that acts as a sub-drone core. The manufactory will rebuild everything within it, including that core, once it's destroyed. What if every sub-part to that sub-core was scaled down in size? Miniaturize the parts, so that you can create missile-size drones that can act intelligently, and still fit within whatever size limit you place on the manufacturing part.

Brandon Sanderson - the author of a number of fantastic books - spoke once on magic in fiction. He said that it's not what magic can do, that's interesting -- the limitations are what make magic interesting. I think we have to keep that in mind here. Nimbatus is to a large degree fun because of the engineering and logistics required. This isn't a supervillain game where you just sweep in, scorch entire planetary surfaces, and move out; it's the engineering limitations and overcoming them that's fun, and their performance in the game is the reward system.

I got a notification and took a second look. I see that I was unclear in one particular. On energy use; have the shield generator draw the power - X power to X hp regenerated in shield parts, and limit the GENERATOR'S ability to draw. This has the specific result that if widespread damage is done to shields, the recovery, which is limited, will have to be divided between the various shield parts that can be repaired. It will make widespread damage more crippling to its function.

My thoughts on this is that this would be a part which would exert an upward force proportional to the forward velocity of the wing. This would vary depending on air resistance, with higher resistance or lower altitudes (denser atmospheres) presenting more lift. Activation should also enable it to apply CW or CCW torque proportional to your forward speed. It should be a block that has a wing-shape drawn over it (To show you which way is 'forward' for the wing), with moving flaps. (To show its activation.)

I'd like to see shields actually generate blocks that don't interact with drone parts. They would just shade the area, rather than being a concretely visible part, and make shields something you can dig a hole into rather than just a region that detonates projectiles. This would make shields something you could actually dig a hole into, and they would benefit from overlap. Shields could use energy to regenerate any shield block that is adjacent to an undamaged block, or to the shield generator itself. This means that if an AOE attack hits it, the outer damage can't be repaired until the blocks around the damaged section are fully repaired. In the meantime, the region will be vulnerable to further damage to or destruction of shield parts. Limit their ability to draw power from your drone, and you would also limit their ability to recover from heavy damage. As a result, AoE wouldn't be an immediate threat to a pristine and undamaged ship with shields, but it would still be the weapon of choice to chew up shielded ships. Shields under AoE attack would try to shrink the damaged area, but repeated AOE hits would just push that recovery back again, and further damage parts that haven't been regenerated yet. I'm kind of aware that this is a pretty big departure from the current design philosophy behind shields, but I thought I'd put my two cents in. The shield structure from Wayward Terran Frontier inspired a bit of this.

The bomb Sounds like the cluster bullets upgrade. You could also manufacture this with TNT and some relatively simple logic. (When separated from an input (by decoupling) wait X seconds, decouple TNT parts with engines, which are toggled by the output that decouples them.) There is also a suggestion for a manufactory-style part that can rebuild child parts, so you could make your cluster bomb something that gets rebuilt, if that's implemented. There is a toggle logic part that can help you keep thrusters on - when you hit the input, it'll toggle an output that you can use to trigger thrusters. The digger ray sounds like it's better suited to upgrades than a new weapon. One dev expressed some hesitance at the idea that weapons might gather resources, though. There is a suggestion up to have a 'do not damage ore' upgrade to weapons, though, which might begin to approach what you want from this idea -- it sounds like you want to be able to get at ore easily without damaging it.

I mean, if you want to include a cheat mode, that would be a good way to do it, make it something you have to research, unlock, and engineer. Just make it inaccessible until you deactivate any element that might have you competing with a drone with such parts - sumo or any arena challenges or any high score ladders.

Honestly, it takes a little more time to build the drone, but I don't think it makes mitigates the overpowering effect it has on gameplay. Not by itself.

This happens to me, too, and is relatively common, I've seen it on multiple planets. Distance from the core isn't a factor, I think.

That is indeed an issue; a triple laser will not exactly target the mouse with the center beam, almost as if it uses the quad-beam offset for its targeting.

Power hammer. damage and heavy knockback on contact. Impalement spikes that capture an enemy. (With an articulated arm, I can jam them into another melee weapon!) Paired blocks that activate a laser weapon between the two blocks. A mace that converts the delta between its vector and whatever it hits into better damage than simple collision. Lastly, a swordbreaker; basically a spike that immediately destroys weapon parts on contact.

I'm throwing a dart here, but Kevin, you're aware that you can attach parts to things other than the drone core? There's no limit to the size of the drones you can build. Expanding the build circle could be useful for slightly larger drones that, anchored to the core, are stable, but I think looking at other solutions for large, stable drones may be more productive.

The reason I suggest using the decoupler as a small drone core is so that you can't go in with an itty-bitty drone, and just manufacture thousands of little sub-drones to swamp the entire planet as a one-size-fits-all strategy. With the exception of retrieval missions (and even those, if you have smart enough recovery drones that you dispatch first) this could easily become a dominant strategy. For example, if your sub-drone had a manufacturing part that made a copy of itself, you might swarm the map with an infinity of drones. By making the decoupling point a drone core, you can hold back rebuild ONLY when the drone core (thus the entire sub-drone) is completely defunct or destroyed. By limiting the number of cores, you can limit the number of autonomous elements available to the player, as well, if that suits development goals. By limiting the number of sub-parts, you also limit the player's capacity to make drones that build drones that build drones, as well as limiting their ability to just make their main drone manufacture itself, giving it a regenerative capacity.

A decoupler block that doubles as a drone core; the decoupler can only have a certain number of child parts. You need energy, fuel, a number of thrusters, some logic, and guns or drills, whatever tools. A limit of 10-20 child parts, with more parts available for bigger sub-cores. You can limit the number of cores usable on a single drone, and not rebuild them until the core is destroyed/ self-destructs, and/or put a time-limit on them so you can't flood the map with drones.

I do think it would add some of the greater than/less than logic that has been missing. Aside from directional sensors and speed sensors, hinges can benefit from that. A lot of my suggestions have been poking and prodding at different ways to approach this, to find a method that's compatible with your development plans.

What about ranges for outputs on any analog parts? Start a directional sensor or hinge off with no outputs at all (Or a set of reasonable, commonly useful defaults) and let the user set outputs for each range of values? Thus, if I wanted a drone that reacted intelligently to being flipped on its back, I could add a third range to a directional sensor, and use 10-110 as tilt right, 111-249 to aggressively flip over, and 250-350 to tilt left. This would maintain the current system of having stimuli and output, but also permit a single sensor to have as many output potentials as a user is willing to configure. At the same time, the default configurations can be adjusted easily by a novice.