Zone Object proposition

[Soybeen]

Developers have always struggled with compartmentalizing areas of their places into “zones”, i.e. regions that mark the boundary of some special place, or area.

Whether or not a Part/Player is within such a zone determines the possibility of certain game behavior. These inclusive and exclusive zones often mark spawn areas (for players, or assets), areas where players may build (such as property and parcels of land), areas where players may engage in combat, areas of relevant information to iterate over (to avoid magnitude checking irrelevant areas), etc…

Assuming the hypothetical function workspace:IsPartWithinZone(zone,part), or something similar, Developers would be able to easily make these determinations.

Here is a hypothetical representation of three low-resolution zones surrounding a small island.

• The Red Zone marks a protected spawn area where nobody may build.
• The Green Zone is nested completely within the Red Zone. Combat is not allowed in this zone. It is also amorphously shaped.
• The Yellow Zone is nested only partially within the Red Zone. This zone has been claimed by a Player to enforce exclusive building rights.

It is obvious that these zones are very broad and inaccurate containers due to their chunky rectangular nature. A dedicated Zone object which could be expanded with something like the Terrain Grow tool would allow the islands to be more accurately bordered.

The greater challenge of creating custom zones is noticed when zones are not shaped like spheres or cubes. These oddly shaped zones are typically composed of multiple regions that must be independently scanned to determine contents of the whole.

Amorphously shaped zones are not common on Roblox because despite the straightforwardness of their utility, they are not simple to create.

Some custom solutions to this problem that developers are currently using include Region3 checks, Part:GetTouchingParts()/.Touched checks, and the Magnitude property of Vector3’s to determine distance, or combinations of more than one of these at a time.

This does not address the potential diversity of functions for scanning those zones, nor does it address how programmers are creating custom nested zones, and their scanning functions.

Dedicated zone objects would be useful in Studio for determining such things as which areas to populate with certain assets, e.g. code that generates only rocks in Red Zones and only trees in all Green Zones. This is a use-case that I run into frequently, as the placement of assets is painstaking for large Places, and there is often too much variation in the terrain to allow reliable placement of assets based on x/y/z limits.

The creation of a resizeable Zone object with a property such as ZoneId (or BrickColor for better visual understanding), and their ability to include nested zones would afford developers much more flexibility over their Places, and there would be great utility in amorphously shaped Zones which could be drawn onto the map with accuracy.

[cxmeels]

@Soybeen

workspace:IsPartWithinZone(zone,part)

In relation to this, you’re after: workspace:FindPartsInRegion3(Region3, InstanceToIgnore = nil, MaxParts = 20).

Although some sort of official “ZoneService” would be great. This is actually something I’m in the process of making in the form of a plugin, with accompanying ModuleScripts.

[Soybeen]

Yes, but of course that is for regions, I was just proposing how that same concept might apply to a zone.

Let me know if you end up creating a plugin capable of streamlining this process, as I would be your first buyer.

[cxmeels]

Will do. It’s in the works now, as I was making it for a friend’s game, but planned on releasing it publicly, as I know it’s something people request a lot.

[stravant]

This can entirely be done with a plugin. In fact, it’s likely better done with a plugin because then if the “amorphous zone” behavior isn’t quite what you want you can tweak it.

I would suggest this as a built-in plugin instead of a core engine feature.

[Soybeen]

My only thought is that these proposed Zone objects would not only be used for the purpose of developing the map, but during runtime they would be generated/manipulated on the fly, so if it were a plugin, it would also have to give you a module, which seems abstract. Plugins are also inherently less accessible.

Maybe you’re right and my specific use cases are too small to justify an entirely new object, however, just looking across the top games, Zones of inclusion/exclusion are pretty common.

[EgoMoose]

I don’t understand why you can’t do this with current features? A simple non-robust example would be to write a class that checks a number of region3 and combines the results thus treating it as a singular zone.

[Soybeen]

The difficulty comes from mapping the zones over a plot of land that isn’t easy to fill with just rectangles or just spheres. Imagine a 3D snake with four heads and wildly disproportionate body, now try to map it accurately with Region3 and the difficulty becomes evident

This is an issue when zoning sections of cave networks for example and alternative strategies must be employed.

I also don’t like using parts as invisible barricades or markers, and if zones were constructed with a series of perimeter nodes (attachment-based) in some capacity then this would also allow for very robust control over the zone boundaries while keeping the work environment clean pre-runtime.

Furthermore, this could potentially be used to allow for more articulate custom navmeshes if a point grid of X resolution could be mapped onto the zone, and that utility speaks for itself.

[EgoMoose]

I’m still a little confused tbh.

Are you looking for essentially a way to define custom geometry?

Your attachment example is not as simple as you may be envisioning it. How do we properly define the boundaries of our “zone” with attachments. Convexity and concavity play a huge role in this.

[Soybeen]

Very custom geometry, yes, and easily defineable. If what I am proposing is already possible, but not easily defineable, then it’s not very attractive or useful to me as a developer.

[Soybeen]

Well, if I had to propose one way, the attachments would line up with the voxel grid and be painted on with a tool.

This doesn’t seem like the best solution when conceptualizing zones as objects, so it might be best to instead have a zone service, and a manipulation tool like the Terrain plugin.

The technical challenges are not in my ballpark, but it certainly seems feasible.

[EgoMoose]

No i mean like uhh… Lets just look at a 2d top down example. Say i have these attachments:

I could connect them numerous ways:

It gets even more complex in 3d as you can imagine and the only way to ensure you generate a good result without assumptions that would limit how you build your zones would be to use a toolset as robust as blender.

Although possible, i think that’s a herculean amount of effort required to build something we can get by with by doing the decomposition ourselves…

I’d suggest looking into rotated region 3 modules (ive made one myself) or collision detection algorithms. Then you can build your own system around that.

[Soybeen]

Well, I would ask you how the Terrain Grow and Erode tools work, and base the determinations off of how those already paint upon voxels.

The attachment ( or some other node ) perimeter is a non-significant part of the proposed concept, if its challenge is too great I probably wouldn’t miss it too badly.

[EgoMoose]

I suspect that could be an option, but again that’s a limitation. You’re filling with certain shapes that tmk can’t be rotated (I’m sure that can be adjusted though) otherwise you have to do it by hand. I think back to your cave example, why not just decompose the caves into parts/cylinders/balls. Otherwise you’re going to have to fill them all in by hand?

[Soybeen]

A Zone Paint tool would make that virtually painless, even with a few dozen caves.
Or at least, far more painless than decomposing them into not-so-precise spheres.

Zone mapping by hand would be just as important as generating them live, as many areas devs would like to zone are pre-determined

[EgoMoose]

Ah, well i guess we’ll just have to disagree. We clearly have different views on this and neither of us will be able to convince the other.

That’s okay though! If enough ppl support this from a convenience standpoint then Roblox should implement it regardless of if it can already be done.

[Soybeen]

Maybe you are seeing a bigger picture that I am not seeing. I’m definitely not as well versed as you in these areas, so I’ll leave off this thread with what I’ve suggested without trying to go too deep into the complexity of its implementation.

That said I still stand by the potential usefulness of a tool like this, and think it would be a great addition to Studio.

[EncodedLua (Juniper)]

While I’m on this topic I figured I’d weigh in my 2 cents. I’ve used @EgoMoose’s rotated Region3 module and it’s a lifesaver - super easy to use and allows for differently shaped regions, would highly recommend.

However, one thing I’ve noticed is that simply using :GetTouchingParts() and empty Touched handlers works on average 4-10x faster than the :CastPart() function in the rotated Region3 module (done on an empty baseplate with 1 zone). This might be a bad idea because I’ve heard large amounts of Touched events aren’t the best to use performance-wise, but as of now, those are the 2 best ways to make zones the fastest.

[Soybeen]

Yep, while EgoMoose’s module serves to this end nicely, there is a ton of room for improvement on Roblox’s part to provide the tools necessary to create good ‘custom geometry’ out of the box. His module highlights a shortcoming in the Roblox engine, and the capacity of dev creativity to overcome those shortcomings.

Though, with respect to Ego’s creation, I am not too excited about the hooplah of placing spheres and bricks and having to study a third party module for any length of time to achieve something that would do brilliantly as a Studio feature.

The Terrain tools and voxel grid bring us a little closer to the custom geometry required for Zones, but yet even with Terrain, there isn’t a highly intuitive way to distinguish geometry from its surroundings, scan it, or manipulate it. You can’t even transfer segments of Terrain between places in a supported way- it requires a plugin.

The Voxel grid is there, and offers more than enough precision for the bulk of tasks. We should be leveraging it for more than just Terrain. The idea for Zones stems from this, but in-between the lines there lies a greater feature request for the power to define and manipulate custom geometry with far more ergonomic tools than we currently have.