Lurkily

Does this maintain an altitude, or does it just crush it against the Nimbatus? I normally just have my satellites push straight up against the nimbatus, and trust a wide configuration to keep their thrust pointed at the mothership. That is when I use them at all. I tend to avoid energy/fuel satellites. They feel too cheaty, and I expect them to go away in the future, so I'm doing my best to do without them.

Struts would really be little more than the struts we already have, though, only more of them. Apparently, things were able to be freely connected in previous builds and caused some issues. I'm sure any issue could be mitigated, but I favor a different solution that sidesteps the problem. My favored idea right now is to have a second layer that is used to construct a 'chassis' or 'skeleton'. These pieces would not have physics interactions with other blocks, and would 'fuse' together. The entire chassis would be fully rigid as long as the parts were adjacent, giving you a rigid body to anchor all your parts to. A drawback to this system would be that if chassis parts were ever exposed, damage dealt to that part would also damage every ship part attached to it. This would include adjacent chassis pieces, meaning that damage to your chassis could propagate through large portions of your ship, diminishing as it propagates to more remote sections. If a part of the chassis were ever broken loose, they would also be heavy enough to deal physics damage to other parts of the ship as it maneuvers. My thought is that chassis parts should be more mass-efficient the larger they are. So large pieces may be heavier, but they're lighter than a lot of small pieces of the same size. Thus you incentivize working with the design constraints of large or oddly shaped chassis parts. Though each section should only be selectable as a whole, they should be treated as groups of 1x1 blocks. Thus you can connect parts to nearby sections of a chassis piece instead of the center, and damage to a chassis piece propogates in the same way, regardless of whether you use big or small pieces. Each individual block of a chassis piece should also be destructable. This opens up the potential to 'break a ship's back'. Chassis pieces, being heavy, might cause physics damage as you maneuver if they became separated into parts. It provides a rigidity solution without simply interconnecting things more. All connections are still parent-child, as they are now, without having to worry too much about introducing circular, self-reinforcing, or computationally expensive physics loops. It provides logistical challenges in building efficiently, and it provides a weakness which, if exposed to damage, could threaten large parts of a ship.

I'm thinking more along the line of modular weapon builds. Open up a weapon mod interface, and you have a build area the shape of a weapon graphic. (semi-conical for a laser, a hemisphere for an emitter, etc.) In this area, you can fit tetromino-shaped pieces with different functions.(Range/projectile lifetime, fire rate, damage, weapon mods.) Maybe a unique, immobile piece in each weapon to determine ammo/weapon type. (Long-beam bio laser, or plasma bullet gun.) If you want to increase a weapon's size, you can increase the area to cram components into the weapon, along with increasing energy draw, mass, etc. Each weapon can expand in different directions, on a different scale. Emitters can go from 1x1 to 2x2. Guns can go to 2x1, then 4x2, 8x3, etc. Lasers increase in a straight line - 1x1, 2x1, 3x1, 4x1, etc. So far we don't have a lot of engineering challenges; I'd like to see the potential for unusual shapes and scales of components, and weapons that can scale up but only in certain dimensions might help fulfill that a little.

I'd be interested in seeing a weapon design much like a drone design - damage blocks and range blocks and special blocks for homing or cluster, etc. a weapon 'core' for basic attributes; rarity, tier, type, ammo. It would be nifty if you could make enormous ships built entirely around a massive weapon that you designed yourself.

Directional sensors point either to your cursor or to gravity at all times. If that pointer (the small black circle) is within either of the red sections, the corresponding key is pressed. This can be used to make self-stabilizing drones, by wiring the drone to turn itself when it's tilted too much. Alternately, you can use it to make mouse-piloted drones, by moving the drone in a direction when the cursor is that direction, or always turning the drone to face the mouse cursor, to target weapons and to direct thrust as you maneuver. To make a gravity-based sensor that stabilizes your drone, just plop one down in your design. One output should be the key you use to tilt the drone right and the other left. Dump it into the test area, and the drone should always face up. Or down, if you have them backward.

Yes, I'm aware that shields aren't yet terribly effective against some things, though bracing them in heavier blocks can help. That's why my focus was on what they might be in the future; the promise to look at solutions to the rigidity problem, alone, would be enough to redefine their effectiveness. I did try zippering a ship's spine together today - a 2x7 spine of solar panels, zippered together. Big ships still look like a bag of loose legos, but they're not splitting or separating at least. A design that's less long and more of a brick would probably be even more rigid, as my ship was pretty skinny. I've done similar things by connecting every block to either the core, or the closest block to the core possible, and I still think that's ideal, (and already leads to what you call 'stitching',) but using this to also 'tether' sections of the ship will help.

Parts that overlap will wig out, and sometimes very close parts with a slight rotation or parts attached to something far away will begin freaking out, especially if there are no other parts behind them for support. Firing most weapons introduces a recoil. Lasers shouldn't have recoil, but if you're seeing this only while firing AND turning, it's obviously doing something to the physics. Rigidity is one of the things that it's been mentioned will be addressed in the future, and I'm hoping this will be aided by that.

I have also noticed performance lags when playing for a very long time. (6+ hours - I have left the game running in the background to test world-destroyers, a relatively slow process.) My assumption was the same - that there's a memory leak or some other slow build-up of inefficiency somewhere.

What you're trying to say, is to connect every other part, so the rigidity of one chain reinforces the rigidity of the other chain? This may also work with diagonal or zig-zagging chains 'zippered' together. Thanks for this. I'll play around with that. As for out-tanking shields . . . in the current build, parts seem to regen damage - I've never seen a bit of damage that was 'the straw that broke the camel's back'. If I come out of a fight without damage, I'm golden. I assume this will change, though, and if so, shields being able to avoid damage entirely might be able to out-tank any armor.

But wouldn't it be ideal to use unique keys for what needs to be unique, and shared keys for what doesn't? The game doesn't really need either one. The only reason they exist is to make up for the limits of the interface and/or the user's patience.

I honestly hate these devices. They're a laziness/complexity tax. A punishment on people who are running out of keys, or who just don't want to assign the same six functions to twenty-four new keys on four identical drones with the struggle of keeping them unique. I propose that blocks with inputs and outputs get a checkbox. "Copies get unique inputs/outputs." Thus if I copy a drone with lots of logic involving every letter of a qwerty keyboard, the copy will have all that logic, only it'll use Q1, W1, E1, R1, T1, Y1, and etc. It would take the effect of splitting out of physical blocks, and put it in the inputs/outputs where it belongs. Because let's face it, the only time it's ever beneficial to use a splitter block is when you're running out of keys, or when it's just too much work to assign that many unique keys. A lot of push has gone on for strings as inputs/outputs, which would solve the first issue, and I firmly believe (in almost any game) that the last issue is something the interface should address, not the player.

So I've been playing a while. I've been reading the forum. I've been thinking. I think the best way to handle logic is to take it into a seperate interface. Make a 'computer' block. Within a 'computer' interface, permit the user to connect a number of logic blocks so that fairly complex logic can be contained in a fairly compact computer. Larger computers (or more resource-hungry computers) can handle more blocks. The drone brain can be fairly simple, permitting three or four innate blocks that always function until destruction This would create a system in which logic blocks don't dominate and bloat an autonomous drone, but also serve as a much more critical weak point than they otherwise would. It would also create an opportunity for a self-organizing hierarchy of how logic blocks are connected in an interface not cluttered by ship parts, where a player could click on a thruster activation, and highlight all the logic that is involved in activating it.

The splitter makes small logical groups copy-pasteable, but only at the cost of including a new block for every block you copy-paste. And by definition, if you must copy-paste it then you need a lot, meaning a lot of additional splitter blocks. Splitters are better done without, if you have the patience and the keyboard for it. I don't even know what the logic connector does. Re-connect logic from brain-connected things behind a splitter? Why would I want to?

Hives and gun emplacements read as terrain. I agree that this is not useful in many cases. It's useful for effectively moving on a planet surface, and maintaining a suitable distance from hives, though. I would prefer they read as both terrain, and enemy.

I did the same (Cheat Engine) to try and get suitable weapons for autonomous drones. (Because towers are unsuitable to autonomy.)

It's a common scheme in hack-and-slashers to have a tier and a rarity paired so that several factors, each of varying effectiveness, determine a weapon's usefulness. The goal is not to have 'correct' answers to a strategic question of what weapons are 'good'. Higher tier isn't always better, and higher rarity isn't always better. Any question that has a correct answer or a dominant strategy is not a strategic choice - it's just a correct choice and an incorrect choice. In Nimbatus, it can be hard to notice the image variations that show a weapon is of a higher tier; but there are variant images for each weapon that can make a weapon more powerful, despite being the same rarity and having the same (or irrelevant) modifications. The lasers and shotguns are probably the easiest to notice this with. I do agree more work needs to go into it, but remember that we're playing a tech demo, in essence. I think the main purpose of this demo is to prove to people that they can make it work.

I'd like to see a future update that would provide wireless transmission of energy, with effectiveness dropping off with range. In combination with blocks that 'pair' (suggested elsewhere, blocks that would indicate the direction and range of the paired block) you would be able to create a satellite that followed you, that you'd have to return to occasionally to refill your batteries.

There are a lot of dampening forces that should be present, but even now you can see reactions that reinforce each other - for instance, very long struts attached to a motorized hinge turn a little wiggle into an insane dance until the whole assembly explodes. Circular interactions have the same potential. It may be easy to address - one hopes any potential problem would be - but a dev's time is usually better spent by simply eliminating circular physics interactions. They still exist, of course. Parts still bump into each other, and one strut's wobble inciting a wobble in the next strut is probably why hinges with long struts tear themselves apart; the self-reinforcing wobble with a longer lever overcomes any dampening involved. But if you can eliminate a possible source of jankiness, it's my opinion that you should. It's not worth a programmer's time to fix what the game doesn't neeed. Less time spent fixing that means more time making awesome weapons and planetary ecologies, and etc. It's not my place to tell them where to spend their time, of course. But I strove for a solution that minimized the amount of coding, fixing, and balancing involved. Pure rigidity eliminates a lot of physics calculations, and a parent-child structure to the connections ensures that every physics interaction through connections has an endpoint.

Keep in mind that what we're handling isn't even an alpha, but something serving the purpose of a tech demo. Expect balance and gameplay goals to arise that aren't currently present. Not to say you shouldn't have suggestions for both, just not to assume that what you're seeing now is supposed to represent a desired balance or gameplay.

If the player decides to do that, it's their fault. It is better to give players the freedom to make interconnects rather than preventing it just in case someone makes a million of them and makes the game crash. Besiege lets you build massive creations in 3D with a large number of interconnects. doing the same in 2D should be easier.I can't comment much because I haven't played Besiege, but it seems to cause a problem here, in this engine. Saying that 'players shouldn't do things that kill their CPU' doesn't absolve the developer of a responsibility to design software that is sustainable by available consumer hardware. Besiege really lets you connect every piece to every other piece? That's insane. For 100 pieces, that's 4,950 connections, each of which need to influence the physics of every block, and do that all over again in every frame of gameplay. (The formula for the number of connections should be X/2 * (X-1), X being the number of blocks.) Usually you do it by forbidding circular interactions where possible, favoring parent-child interactions. Physics can be unpredictable; circular interactions might be self-reinforcing until a minor wiggle becomes an instability that tears a structure apart. It's possible to code well enough to avoid that, but usually a developer gets more use out of their time just trying to eliminate the circular interaction so that self-reinforcing loops can't occur. Thrusters not directly connected to the core wobble, parts often clip into each other when they sway. Janky physics is not a good way to make a game challenging. Giving players the freedom to make big and complex designs will also lead to more YouTube videos of people showing off their creations. The game will get a lot of free publicity I think that you think you're disagreeing with me, but my proposal was intended to permit players to make enormous ships without looking like a sack of legos. The skeletal structure introduces a weak point that must be protected by shields and armor. This is the mass challenge and vulnerability I spoke of. I wasn't talking about the wobble as a build challenge. The weakness is the fact that if the skeleton is damaged, everything attached to that segment is also damaged. The build challenge I spoke of is the fact that, because larger skeletal pieces are more mass-efficient, it's useful to build a ship around larger skeletal pieces, which will influence the shape of your ship. I absolutely want to permit the player large and rigid ships. That's the whole point of the rigid skeletons.

Yeah, it could be done, i guess, but who wants to waste money on fuel. They could make a different kind of resource for that. Making yellow the money resource, would be ok.I suspect this was more about recoloring either fuel or ore. I sort of agree. That being said, it nullifies the reward mechanic. What would you possibly be rewarded after killing a mother hive?Well, I presume there will be a balance to money and purchases, and both routes to epic weaponry can be both difficult and rewarding. I have never encountered this before. Leaving and re-entering fixed it?It does happen, and that didn't fix it for me. I got out a planet-crawler designed to eradicate the entire planet's mass, twice, and never found it. It could be an unusual circumstance happening twice, though. Are there more than one type of shields? If so, i have mixed feelings about it. Energy Shield is fine i guess but adding a Physical Shield would remove the risk of having enemies with regular weapons such as rockets and bullets. And they should no matter what, make shields use more battery when getting hit. Now you just keep it up and you are invincible against foes with energy weapons. A formula of: TotalEnergyConsumepersec + Damage taken = EnergyConsumed would be ok, meaning you use the energy to keep up the shield and lose battery charge when you take damage equal to the damage you would take. There are not, but maybe in the future. I'm not sure why staggering shield use is helpful, though, or why coloring the shields in gameplay (As opposed to in the build interface) would be useful. If it's necessary, I would just logic it. Impulse one shield's use. When one isn't active, the other's active. Use a keypress with AND gates to activate the auto-staggered activation. If the logic blocks aren't useful, just manually switch keypresses. My solution to exact shield mechanics would be to give them an internal charge. Have them draw from energy at a preset rate, so that charge can be depleted faster than they can draw from energy stores. Modulate shield coverage with the charge, down to zero coverage at 20% charge. Thus damage can be resisted fully, but coverage evaporates as more damage is applied. Shields never outgrow a careful energy solution, and more energy isnt a solution to overwhelming damage.

Keep in mind that the game isn't even in Alpha; this is a tech demo, to demonstrate that people investing in the game can rely on a viable product being released. Balance and features seem to be limited to what can demonstrate that the game can be completed, currently. By all means, keep the suggestions coming, just be aware that what you see now isn't representative of what we should expect in the final game.

Oh. That helps. Add a directional accelerometer. Reads your acceleration in the direction of the sensor, (but not backwards,) and outputs a value if it exceeds a breakpoint. So if you're being accelerated backwards, you know the enemy's pushing you out. If you're not accelerating forwards as fast as you expect, you know you're pushing on something.

You're correct, recoil doubles the recoil amount according to weapon stats. The gravity sensors also have issues. 'tilted right' seems to activate when it's turned CCW. But 'right' and 'left' are usually taken from the top side of rotation, so the sensor being tilted to the right should be a CW rotation.

Give the gravity sensor a special-case use so that while in a sumo ring, the center of the ring is considered the center of gravity. That'll let you use gravity sensors as they currently exist to help control sumobots.