> For the complete documentation index, see [llms.txt](https://mindcodeinteractive.gitbook.io/easy-build-system/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mindcodeinteractive.gitbook.io/easy-build-system/learning/beginner-guides/building-area-guide.md). # Building Area Guide This guide walks you through creating and configuring a [Building Area](/easy-build-system/reference/building-area.md). *** ### Understand How Areas Work Without any [Building Areas](/easy-build-system/reference/building-area.md) in your scene, players can build anywhere. The moment you add one, the system switches to a whitelist.\ Only zones you've defined allow building. Everything outside is blocked by default. Each area carries a list of [Building Rules](#add-building-rules) that validate what happens inside it.\ Rules run in order, and the first one that fails blocks the action.\ This lets you stack restrictions like "only walls here, and only below height 10". Areas can overlap. When they do, the one with the highest priority wins. ### Create the Building Area Go to: `Tools > MCI > Easy Build System > Components > Create Building Area...` Or right-click in the Hierarchy: `MCI > Easy Build System > Components > Create Building Area...` The tool creates a root GameObject named "Building Area" with the component attached.\ It also frames the new object in the Scene view. Move it to where the buildable zone should sit. Then adjust its size to cover the area you want. ### Configure the Area Three things matter: what it covers, how strict it is, and how it ranks against others. **Shape** decides the zone geometry. * **Bounds** is a box volume. Good for rectangular zones like rooms, plots, or lots. * **Sphere** is a radius. Good for circular zones like territory around a flag or NPC. Pick based on what your zone naturally is. For Bounds, edit the Area Bounds vector to match your zone dimensions in world units. \ For Sphere, set the Area Sphere Radius. The gizmo updates live in the Scene view to see the result. **Inclusion Mode** decides how strict the area is about what counts as "inside": * **Partial** means any overlap counts. The part can stick out a bit. * **Full** means the entire part must be contained. No overhang allowed. Use Partial for relaxed gameplay, Full for tight architectural rules. **Area Type** is a label for your own organization.\ Use it to tag zones like `BuildableZone` or `SafeZone` so scripts can find them.\ It doesn't affect runtime behavior on its own. **Area Priority** (0 to 100) decides who wins when areas overlap. Higher number wins.\ The default 0 is fine for a single area. It matters as soon as you start nesting zones.
### Add Building Rules Rules are what give an area its actual restrictions.\ An area with no rules just means "building is allowed here".\ That's useful as a whitelist gate, but rarely enough on its own. Click **Add Rule** to attach one. Two built-in rules cover most needs: * **Height Restriction Rule** limits where players can build along the Y axis.\ You configure separate Y ranges for placement, destruction, and adjustment.\ Useful for "no building above the rooftops" or "underground only" zones. * **Category Restriction Rule** limits which parts are allowed by their Category.\ Each mode (placement, destruction, adjustment) has its own allowed list.\ Useful for themed zones like "decorations only" or "no defensive structures". You can add as many rules as you want, even multiples of the same type.\ Rules evaluate top to bottom, and the first failure blocks the action.\ Order matters when rules overlap, so put the cheapest checks first.
### Test & Debug Enter Play Mode and try placing a part inside the area. It should succeed if all rules pass. Try outside the area, or in a way that violates a rule. It should be blocked. If placement is unexpectedly blocked, turn on **Show Logs** on the part's conditions.\ The Common Condition is the most useful one to enable.\ The Console will tell you exactly which rule rejected the action and why. The area's **Debug Settings** section controls how the zone is drawn in the editor.\ The **Debug Draw Flags** field picks where the gizmo appears.\ Turn on Game View temporarily during playtests to see the zone live in your build.
### Practical Examples **Layered permissions with overlapping areas.**\ A large "General" zone at priority 1 covers most of the map with loose rules.\ A smaller "Restricted" zone at priority 10 sits inside it with stricter rules.\ The smaller zone wins where they overlap. You get nested control without duplicating rules. **No-build zones via empty allow lists.**\ Add an area with a Category Restriction Rule.\ Leave the allowed lists empty for the modes you want to block.\ Nothing matches an empty list, so everything gets rejected.\ This is the cleanest way to mark a zone as completely unbuildable. **Mode-specific rules.**\ Placement, destruction, and adjustment each have their own allowed list.\ A common pattern is "destruction allowed everywhere, placement restricted to certain zones". Players can clean up old builds without being able to add new ones freely. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://mindcodeinteractive.gitbook.io/easy-build-system/learning/beginner-guides/building-area-guide.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.