I was going to post this in wossisface’s wishlist, then realised it’s better off separated. This has also been brought up a few times:
- What type of automation do you think is viable for Boundless?
- Boundless Automated!
- An easy switch
- Home Automation in Boundless
I think a lot of those are quite grand in nature, but my thoughts are that even my simple thoughts on this would still be absolutely hellish to code.
SWITCHES + AUTOMATION
So, I genuinely think that switches, and things that can be affected by switches would be a good thing, but almost one-hundred percent would be completely hellish to code.
What’s worse, that they would be even more hellish to implement into the current UX/UI whereby it would be easy for people to understand how to do it, and what level/abilities they’d need to do it.
I don’t think, though, that it’s totally out of the realms of possibility, though.
Speaking of UX/UI, I’ll mention that I’ve tried to get on with Space Engineers, and it’s frankly a ■■■■■■■ mess. It’d literally be easier to learn JSON (which is bizarely easy - and I’m ■■■■ damned stupid!) and do switches that way, than to do things the way SE does things, but they do have pretty curves and half-bevel/slopes.
Anyway, I dye cress, and I’m not advocating JSON as the route.
Create two(ish) things:
Literally, a block with an on/off switch on it. Perhaps allow it to be different colours dependent on materials used, I dunno.
A version of an existing block with the ability to assign a label that allows it to be referenced to change its state from
Start the automation at this simple level, and perhaps put a lot of caveats around it:
Restricting it to gleamclub would perhaps drive up more GC subs, and also give a really cool benefits for joinging.
Special Skill Only
Ensuring that on top of GC that one needs to spend 5 (10?!) points on a new, special, skill to be able to do any of this.
STATEs Can Only Be Forged
Making it so that
STATEblocks must be forged, and at a high cost (materials, time, etc) will ensure that this doesn’t get abused, and drive the game engine crazy.
Limit Per Settlement
Create a limit of
STATEblocks per settlement, again for the sanity of the game engine (probs), will hopefully limit abuse, and encourage creativity.
Simply put, any automation creates some medium to heavy negative prestige that is proportionate to your prestige level, and land owner (overall), to prevent people using this as pay to win, and to encourage usage only for those that really want some auto light-switches. Also, could help lessen the strain on the engine some more.
[maybe]Connected / Max Distance
Perhaps also either make it so SWITCH and STATE blocks must be connected (and powered?) by wossitcalled thingies, or perhaps have a maximum distance for any wireless communications.
So, if the game introduces it with two very simple blocks that have clear 1/0 options:
- A door
No, not gleam.
If it works, and it takes off, then future updates can expand it (hell, even introduce multiple switch options -
if 1 turn on label1 - or something?) but don’t get too deep at the off. What matters is the code be as simple as possible, and scalable, and won’t hurt other ■■■■.
So the upshot of the first implementation of this would be that if you activate the switch, then the STATE that it’s linked to will change state. A lantern will turn on/off, or a door or trapdoor will open/close.
I genuinely think if it’s kept that simple, then we, the people will find our own ways to make it complicated … and that’s just fine.
I mean, a few of us have made switches, anyway … but … it’s a bit inelegant, isn’t it.
I do just think that a way to control lanterns (not gleam), and doors/trapdoors, with a switch, would be an awesome place to start with “Boundless ‘automation’.”
In the future, once it’s been ironed out, then, yeah, perhaps the more advanced automation ideas can come in. Like if there was proper pooling of liquid you could have a scenario that when liquid reaches the top of a forged “liquid level door” then the door opens. Or simply, liquid hits door, door opens.
Imagine the levels of creativity we could reach with this.
It could perhaps also save some of the elements that some players find “boring” … I’m not exactly sure what, but eventually perhaps some machines have simple functions, and this could work out for them. For example, ‘vending machines’ … Years down the line, in its maturity, perhaps it could allow users to create an on/off for a stove, then when someone puts money in a thingy, the stove lights up (with materials gathered by the owner) and cooks some glass from the silty and sand inside it. It would save mindless machineering by the owner. Sure, the buyer has to wait for an in game notification that their glass is ready, but … still … someone has had less to do.
Anyway, as always, just a suggestion, and as I said at the start (and within) a probably very silly one due to the annoyingness of the coding it (and the UX/UI of it) would probably require.
As such, since it’s a suggestion, and not a literal “this is how the game should be”, I will unsubscribe from all notifications on this, as I’m literally just suggesting it, not wishing to have an open discussion.
In the even that it’s even remotely thought about for inclusion, I absolutely revert any/all rights to the dev team (as I’m sure is written in to the “suggestion terms” anyway) but would also happily consult via PM if required.