Script-locked object properties and descendants

Feature Requests Engine Features
#1

Private / Script-locked object properties and descendants

Currently in Roblox, it is quite easy to make the mistake that is accidentally modifying an object’s properties (such as a part or a weld’s CFrame, reparenting / destroying an object or changing a property that other scripts may rely on).

In some game engines, object properties are restricted or set to private and can only be modified by the object itself or any script/code that is present within the object.

The existence of such a system allows for developing games that are more secure and “correct” and where errors or bugs are easier to find.

It also prevents one game object from directly modifying the state of another object.

Example

When a system like this is utilized, if the developer wishes to code a sword that deals damage to a zombie for instance,
a BindableEvent or BindableFunction must be used instead, present inside of the zombie that will invoke the zombie’s script to subtract it’s own health points.

Some descendants inside a model or actor may be configured to be exempt from being private/locked to make communication between objects and scripts through values or attributes possible in case the developer wishes to use something else than BindableEvents or BindableFunctions.

Security

On top of this, if a game utilizes free models or 3rd party scripts, finding problems such as a random script modifying game objects or altering them in ways that break other scripts shall be way easier to identify while also providing more protection against malicious code.

Script-locked objects do not only protect variables from outsider modification but can also protect the object from having descendants added or destroyed without permission, further preventing random things from breaking or causing bugs.

This feature essentially also protects the developer from themselves and their own mistakes since scripts will throw an error if they modify an object that is private / locked.

Closure

And finally, this feature is entirely optional, therefor developers who aren’t comfortable with it don’t have to use it.
It can be enabled or disabled on a per-object basis and is not on / off for the entire place/experience.

It’s more like a flag or a property (perhaps service) that can only be switched on in Studio.

If Roblox is able to address this and consider this feature it could greatly help with building organized, structured and robust experiences with as little bugs and potential flaws and errors as possible.

1 Like
#2

This sounds a lot like the recent Script Capabilities, but maybe it’s not quite 1-1 as it’s more feature-based instead of granular to Instance properties:

#3

It is far different from that, I did however reply with a suggestion on that thread.
But no, this is an entirely new feature.

The general idea of this feature is that you can lock an model’s properties and descendants so that only one script can edit them.

This prevents accidental overwriting / object destruction.

I sometimes find myself accidentally changing an object property or adding/removing an descendant and not knowing which script does that.

With this feature, a zombie can only change it’s own health points, if it wants to deal damage to the player, the player character will need it’s own health script that has to be invoked with a BindableEvent.

The idea is inspired by how other game engines handle objects and by languages like C++ and C# which let’s you set variables to “protected” or “private”, isolating it to only itself.

#4

I’m not sure how one would accidentally change an object’s property, much less doing such enough to warrant a feature request about it. Typically, a game would be comprised of systems which are responsible for handling specific aspects of the game. For example, a game might have a zombie system which would be responsible for doing things like spawning, damaging, attacking, etc. As a result, there would be no justifiable need to manually modify a zombie’s model or humanoid, as that would be handled by the corresponding controller/system