Jump to content

Security System (Element or RDMS Right)


SGCamera_Beta

Recommended Posts

I added this to the Upvote site, but I will also post it here for discussion:
 

Players logging off on other people's constructs is a problem, for numerous reasons. Players that log off on someone else's construct should be "kicked off" the construct.

When a character logs out of the game on a construct that they do not have permissions for (defined either by a construct-wide RDMS right similar to Board Construct, or by applying Use rights on a "Security System" element), their character should be moved outside the build area of the construct and their physics should be de-parented.

There should be a way for the player to know their right status on a construct before logging off to avoid confusion.

When not in the safe zone, the security system could become lethal instead.

Link to comment
Share on other sites

On 1/8/2021 at 8:06 AM, SGCam said:

I added this to the Upvote site, but I will also post it here for discussion:
 

Players logging off on other people's constructs is a problem, for numerous reasons. Players that log off on someone else's construct should be "kicked off" the construct.

When a character logs out of the game on a construct that they do not have permissions for (defined either by a construct-wide RDMS right similar to Board Construct, or by applying Use rights on a "Security System" element), their character should be moved outside the build area of the construct and their physics should be de-parented.

There should be a way for the player to know their right status on a construct before logging off to avoid confusion.

When not in the safe zone, the security system could become lethal instead.

What happens when you are transporting someone and they drop connection / crash the game though? I wouldn't want to add RDMS every time someone needs a lift.

I would far rather they added some sort of "security server" element that you can install on your ship which will detect any player "docked" to the specific construct at any time and allow players to kick them off. On the flip side, subvert gameplay that is created by letting players "hide" on enemy ships is something that has come about because of people being able to hide / stowaway on other players ships - and I believe in expanding gameplay rather than limiting it on principle. So on that I would far rather the devs took this as an opportunity to expand the said gameplay rather than remove it completely - albeit with the ability to give the players who own the construct some way / method to counterplay against it. Maybe through skills how long you can stay on a construct undetected etc. 

Link to comment
Share on other sites

14 hours ago, Volkier said:

What happens when you are transporting someone and they drop connection / crash the game though? I wouldn't want to add RDMS every time someone needs a lift.

If it was implemented as an element, then you could just turn the element off when you don't want it to operate.

14 hours ago, Volkier said:

I would far rather they added some sort of "security server" element that you can install on your ship which will detect any player "docked" to the specific construct at any time and allow players to kick them off. On the flip side, subvert gameplay that is created by letting players "hide" on enemy ships is something that has come about because of people being able to hide / stowaway on other players ships - and I believe in expanding gameplay rather than limiting it on principle. So on that I would far rather the devs took this as an opportunity to expand the said gameplay rather than remove it completely - albeit with the ability to give the players who own the construct some way / method to counterplay against it. Maybe through skills how long you can stay on a construct undetected etc. 

I had this idea because of that specific gameplay.  The number one problem is that there is no way to detect if someone is logged off on your construct, and even if you did know they were there you have no way to remove them.  My suggestion is the simplest implementation to solve both of those problems, however I do agree it potentially detracts from emergent gameplay. 

 

If another solution resolved both problems such that as the construct owner if I could spend some time working to find and remove players from my construct, then I would be all for it.  Personally the most annoying thing is that characters totally disappearing from the world is very unrealistic, and the fact that people can use it to their advantage and there is no counter-play makes for a frustrating game mechanic.

Link to comment
Share on other sites

On 1/13/2021 at 7:09 AM, SGCam said:

If it was implemented as an element, then you could just turn the element off when you don't want it to operate.

I had this idea because of that specific gameplay.  The number one problem is that there is no way to detect if someone is logged off on your construct, and even if you did know they were there you have no way to remove them.  My suggestion is the simplest implementation to solve both of those problems, however I do agree it potentially detracts from emergent gameplay. 

 

If another solution resolved both problems such that as the construct owner if I could spend some time working to find and remove players from my construct, then I would be all for it.  Personally the most annoying thing is that characters totally disappearing from the world is very unrealistic, and the fact that people can use it to their advantage and there is no counter-play makes for a frustrating game mechanic.

 

 

Yeah I agree with you. The issue I have is that there are a LOT of things that there is currently no counterplay to, and I would far rather see if the planned updates would include the said counterplay rather than the adding or removing mechanics which are posing a temporary problem rather than a permanent one. The reasons being:

- Just like in real life - it is far more difficult to get the powers that be to reverse a bad decision after it has been implimented than getting the said decision to be implimented in the first place
- If such a mechanic is a temporary measure that will be reversed in the future, someone would need to put in the time right now to work on implementing it, fixing the bugs, fixing the bugs with other impacted systems and then un-implimenting it, fixing new bugs, and fixing new bugs with newly impacted systems as a result. 

And to me, removing aspects of emergent gameplay is a bad decision - even if there is currently no counter. On the flip side, realising what gameplay has emerged and expanding on it would in in contrast a good decision in this instance. In short and to circle back to the point - absolutely agree that there should be a counter against stowaways and spies, but it needs to be a worked in system that expands on that aspect of gameplay for everyone involved. Implementing it as an element is this a great way to do this as it can be later expanded upon.
Completely disagree with removing stowaway ability for the same reason and principle I disagree with removing any gameplay that has emerged due to player creatively using the tools and systems given to them within the game to achieve results that were not planned. It would be a damn boring game if every player interaction was curated and scripted.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...