[How to balance Factories for PVP]

Additional note:

If in the future factories are made to always consume resources, then the old (current) behavior could be enabled with a god mode cheat like in Beseige

[Gravity manipulator part]

Don't VTOL thrusters already fulfill this?

Or do you mean you want a general remote force actuator, like an omnidirectional tractor beam, and the fact it uses 'force' has nothing to do with 'gravity'?

[single hollow block]

I've needed this recently!

[Island maker]

Speaking of which, it would be cool if planets had oceans. I'm surprised I never heard this idea before

[How to balance Factories for PVP]

I imagine it has long waited in the back of many our minds, when will our machines get to combat one another for dominance over a planet?

When can we use our hard earned weapons against other players?

Will Factories ever NOT be broken in a PVP environment?

 

Here I propose a constraint that might make Factories viable in PVP. We have to put a leash on it.

Obviously in any PVP battle, drone size and block count limits should apply.

So what happens when factories effectively circumvent the block count limit?

We have to add a leash on factories (when in PVP at least). Factories need to pay for their creations with some kind of resource, but not just time. What if factories built stuff out of the actual resources we harvest in the game???

Imagine every single block in the game has a recipe, in red/yellow/blue materials.

In full combat PVP with factories, you have to include resource tanks on your drone. These resource tanks contain the material that the Factories use (Stetium, Rogium, Marium). Resource tanks may not be attached on a branch off of a factory. You cannot factory create resource tanks in these kinds of PVP matches.

Now here are some ideas on how to leverage this core idea in different possible ways:

In easy mode autonomous or synchronous PVP: At the beginning of each match, all resource tanks are filled for free. You don't get to keep the resources after the match ends though.

In hard mode synchronous and manual live PVP: Resource tanks regenerate! They draw upon your resource balance available in game! This creates hardcore end-game content and a reason to harvest resources in PVE even after unlocking all the tech tree nodes!

In ultra-hard mode autonomous or synchronous PVP: Resource tanks are not filled automatically at the beginning of the match. When the match starts, your drone has to go into the world and harvest resources from the ground itself before it can use a factory! You also get to keep any resources you harvested and have leftover if you win the match!

 

 

[All my thoughts on sensors/logic, in a single coherent picture.]

It's just my two cents, but here you go

On 12/12/2018 at 11:26 AM, Lurkily said:

First, the basics. I think logic should be local. That is to say, parts should require a connection to see a signal. Even the lack of such a connection is information that can be of great value to an engineer, activating a missile's flight or indicating to the brain that something critical is destroyed, and I think wireless logic with wireless connectors present is a meaningless 'gimme' that circumvents a logistical problem that could be quite rewarding to overcome via design. 

I'm not on board. If you've ever debugged real world physical circuits and logic gates before, you know that missing connections and spaghetti of wires does not help. Regarding detection of critical destruction, I've found drone-detecting sensors to be useful for this.

On 12/12/2018 at 11:26 AM, Lurkily said:

Speaking of connectors; I think wireless connectors should go to a pair of units, transmitter and receiver, each with the option for a whitelist or blacklist of signals that are permitted or forbidden. Receivers should act like a simple button, relaying signals that pass their whitelist/blacklist. Connectors currently block signals, but with control over the direction signals travel and the type of signals traveling, I don't think that separation is necessary.  

I'm in favor of whitelist and blacklist signals. This would allow better more fine control over state/signal propagation, but without all the spaghetti mess of manually wiring stuff. In other words, pervasive signal propagation should be the default, but restricting what signals can propagate should be an option.

I don't know if receiver/transmitter pairs are necessary though. I think whitelist on logic splitters and blacklist on logic connectors would suffice.

On 12/12/2018 at 11:26 AM, Lurkily said:

Sensors. I would like sensors to have ranges that can be added. A directional sensor might have one range and one tolerance, or five ranges and no tolerances, and it shouldn't have to be filled sideways to adjust the tolerance. Instead, add and adjust ranges as you see fit, and anything you don't set is a tolerance. 

This is difficult to understand. Are you saying, for example, you would like to configure directional sensors so they can detect thirds, fourths, fifths, or any other arbitrary split of radial ranges? I think I could see use in this. Actually I know I could. I'm on board in principle.

Also I think people don't understand what tolerance is. I think the graphic is very very misleading. The tolerance isn't a dead section of the circle, it is the amount of slack the directional sense has.

On 12/12/2018 at 11:26 AM, Lurkily said:

Self awareness is a big thing. Trackers will help a lot, if sensors can seek a specific tracker, not the nearest or average center. Things like a GPS setting for the directional sensor (your current rotation around the planet, with Nimbatus being 0/360) would also help. 

Position trackers are recently released and can be turned on and off by signals

On 12/12/2018 at 11:26 AM, Lurkily said:

Awareness in general will also help. My complex creations often stumble on simple things like not being able to position themselves well, hooking on terrain that slips through sensor fans, unexpected input leaving hinges in unexpected positions, etc. 

The previous adjustable ranges will help. I think permitting detector sensors to have even a narrow angle, so they're a fan instead of a line, would help with sensor criteria 'dodging' sensors. More criteria for sensors to operate on will also help. 

Proximity sensors are now released

On 12/12/2018 at 11:26 AM, Lurkily said:

Altitude should be a general purpose distance sensor, with units that aren't changed by planet size. Instead, when used for altitude, they should have the option to have a specific starting value. (Altitude of the core, surface, hopper, Nimbatus level, and whatever in between marks are appropriate. ) It should be able to measure distance to any sensor criteria that makes sense. 

Dynamic sensor control.  Sensors can be as powerful as a keyboard in controlling complex behaviors. I'd like to see the ability to adjust the range of a sensor dynamically, the same way dynamic thrusters can be adjusted.  That way, fine dynamic control can be achieved without math parts, without dozens of ranges, without tons of logic. 

To me it sounds complex, but good if the complexity is tolerable

On 12/12/2018 at 11:26 AM, Lurkily said:

Processors. Think of them as a box that can contain a few logic parts. My opinion is that every 1x1 footprint of a processor should contain a 2x2 footprint of sensors or logic. This means you could use them to put very compact directional sensors on a hinge, or put a whole raft of complex logic in a larger processor. 

The reason is twofold. Obviously, it makes streamlined construction easier. But it also reduces part count for logic. Sumo is far too dependent on brute force - smart drones are weaker drones. I'd like to see that mitigated to reward intelligent design and intelligent done behavior more in asynchronous multiplayer. By limiting the available size of professors, or by damaging the parts it contains when the processor is damaged, you also aren't totally eliminating the threat posed by logic damage. 

So if I understand correctly, you want to discount complex logic?

I share the goal. There are lots of different ways to solve that goal though. In the following thread, I mention two new gates that if introduced would allow for all possible "2 inputs and 1 output" logic to each get their own gate.

Another possible idea is a 2x2 tile that accepts 4 inputs, produces 1 output, and is basically a configurable 4 input truth table. This would extremely help condense complex logic. The configuration UI might be difficult to design though.

[Built in sensor negations]

Similar to how the directional sensor and altimeter have two possible states and two possible outputs, it would be convenient if distance sensors, proximity sensors, speed sensors, and temperature sensors all came with their negatives states as built in configurable outputs. This would spare us a "not gate" quite frequently.

[Hydraulic block]

One major difficulty with this is the fact it heavily implies connecting parts in a non-tree structure. e.g. connecting two disparate branches of parts instead always branching out from parts. This would probably require significant rework of the underlying code. However, such an underlying capability would be useful for loads of more things than just pistons.

Overall I'm very in favor. I wouldn't get my expectations too high too soon though

[Input Controlled Logic Splitter]

I would like a logic splitter that can have the splitting functionality turned on and off according to a signal.

Right now there is a lot of suffering with conflicting logic on factory spawned creations.

I would like to have an element created by the factory send a signal back to the factory, but for that signal to be disconnected after the factory-produced machine decouples from the factory itself.

An alternate solution would be to add a "Split logic on decouple" checkbox to the factory

[Improvements to Logic and and input schemes]

To expand on Advanced Logic Gates:

• 2 Inputs: Nonimplication
  • https://en.wikipedia.org/wiki/Material_nonimplication
  • https://en.wikipedia.org/wiki/Converse_nonimplication.
  • The above links are the same thing, but with inputs flipped (since inputs are not commutable in this operation).
  • "A but not B"
  • "A and not B"
• 2 Inputs: Conditional/Implication
  • https://en.wikipedia.org/wiki/Material_conditional
  • https://en.wikipedia.org/wiki/Converse_implication
  • The above links are the same thing, but with the inputs flipped (since the inputs are not commutable in this operation)
  • "A if B"
  • "not B without A

If we added the above gates, then we would only need a single gate for every possible 2 input truth table. This is the core material motivation in my eyes

I run into the need for these operations all the time, but I'm stuck using two gates, usually in the "A and not B" format

Here is a picture depicting the behavior of the new gates on the right:

https://imgur.com/a/pnFdl04

[New Area Hazards (Racing and Catch)]

Here are some more thoughts I'll add then:

• The reason that VTOL is overwhelmingly the best at Catch isn't because it automatically aims, but because it can change directions almost instantly
  • You can tell this if you try to make a drone that goes extremely fast in one direction and tries to turn towards the target instead of using VTOLs. Full drone turning can't compete with the instant direction adaptation of VTOLs
  • I personally don't think VTOL is overpowered and needs to be nerfed or anything. Just to be extra clear. Rather than saying "we should nerf VTOL because it does this map too well" I would say "We should create new maps where VTOL isn't automatically the best solution"
• The idea you mention of the map changing over time is awesome. Especially if with barriers.
  • How to create a map that is VTOL-nerfed is basically to reduce the number of waypoints that can be reached by following a straight line. That is the simplest way to boil down the issue

Thanks for your ears! or your eyes, as it were

[New Area Hazards (Racing and Catch)]

Pretext:

Right now we have 2 damaging hazard types in racing (and catch)

1. Walls. You can think of this as damage proportional to your perpendicular velocity component. Or "damage by speed".
2. Shock areas. As far as I can tell this is "damage over time".

There is a problem with the "damage over time" approach though. There is a counterplay to damage over time areas by going over them extremely fast, rather than trying to avoid them at all.

In "Catch" it seems like there is more incentive for redundancy and raw speed than careful navigation. There is nothing wrong with a challenge in redundancy and speed, but there isn't a challenge truly dedicated to careful navigation in that regard yet.

In the racing maps, leaderboard-grade speeds fly over shock-areas so fast that they are totally inconsequential, making the Phoenix and Tournament maps practically as featured as Hydrus but with with less difficult turns. Example of shock areas made totally inconsequential by speed: https://youtu.be/MCeprgLvRqg?t=284

Feature Suggestion:

• New race/catch hazard area: Spikes/blade area. This type of area does "damage over distance", in contrast with "damage over time". The more distance you go through it, the more damage you take, up to very high damage. If you come to a standstill inside it, there is no damage over time. (But it will still take damage to navigate out once you get moving again.) The damage is low enough that escaping laterally (in races) should be feasible, but the damage should be high enough that pressing forward recklessly will be very punishing.
  • With only "damage over time" hazards, solving the map can be reduced to solving only one variable: speed.
  • With "damage over distance" hazards, the challenge again becomes to solve two variables, speed and hazard perception/reaction.
• New race/catch hazard area: Barrier. This is "damage by speed", just like walls, except...... cutting into the roadway itself, making an impassable lane.
  • It could be done in any way, but I imagine this like any other hazard: Center lane, Left Lane, Right Lane
  • This is again to prevent race maps from being reduced to solving raw speed alone. Think about what makes the Hydrus Highway more difficult to solve than the Sagittarius Drag Strip. It's the very tight turns that are very very difficult to control at high speeds. Roadblocks may have the same damage mechanism as raw walls, but the drone design challenge to avoid roadblocks is very different from the challenge to avoid walls.
  • This again makes the maps a challenge in solving hazard perception/reaction, not just speed and simple waypoint following.
  • This already exists in the Catch tournament! Which is good! You can see that drones get caught on it very often, and even smash one another into it. This enriches the arena very much. Maybe there could be even more catch maps, including one with more barriers?
• (Do not modify any existing maps, for obvious reasons. The above new area types would be good for new maps though. Particularly I would personally imagine these as higher difficulty hazards than what exists right now. Belonging to future, higher difficulty maps.)