Advanced Worlds & Optimization

The hard part of a bigger map is not adding more. It is keeping the next change possible.

A doorway needs widening. A spawn needs another exit. A rule needs resetting. If every correction means rebuilding a beautiful room, decoration has started running the project.

This guide takes Switchyard, our small two-team arena, from a tested blockout to a maintainable world. You will make a reusable wall bay, compare its cost before repeating it, add one isolated event exercise, and prepare a release candidate you can actually check.

Before you begin

Start with a saved arena that already completes a match. Finish Your First Playable Map and Designing Better Battles, or bring an equivalent layout with tested spawns, routes, equipment, and endings. You should be comfortable with transforms, duplication, snapping, and the difference between editing and playing.

Evidence boundary: the capabilities below are documented in dated BigBox materials and firsthand builder transcripts. We have not launched the game to verify its current build. The construction, performance-testing, and release methods are recommendations; they are not engine guarantees. Follow the tool labels and warnings in your installed version.

Your outcomes:

• One reusable construction module with a tested seam and opening.
• A repeatable way to compare detail cost without guessing a universal object limit.
• A small event that distinguishes a trigger, selection, condition, and action.
• A saved release candidate with a practical regression checklist.

1. Build a kit before building a district

A kit is a small family of pieces you can combine predictably. For Switchyard, use three variants: a solid wall bay, a doorway bay, and a low cover bay. Keep the same floor reference and outer width. That makes a late doorway change a local correction rather than a different construction system.

Multi-selection and joint transforms are demonstrated in the early developer walkthrough at 16:00–16:58.^[6] OlafGolaf's Swiss TV Station build shows a more useful lesson at 11:27–12:59: select a facade, group it, discover a missing piece, regroup, duplicate, then correct alignment.^[5] A group is a convenience, not proof that every intended object was selected.

Exercise: make one wall bay worth repeating

1. Work beside the arena, away from live spawn objects and rule-critical objects.
2. Place a simple solid wall and two modest trim pieces. Keep trim out of the walking opening.
3. Make a doorway variant using the same outer dimensions. Check the opening in play, not only in builder flight.
4. Multi-select the intended parts and use the available grouping workflow. Move the group a short distance: does anything stay behind?
5. Duplicate one bay. Join the two bays and check the seam from both sides, above, and at player height.
6. Change the second bay's orientation and recheck alignment. Do not solve a seam by adding more overlapping trim.
7. Save your working map before repeating the bay around the arena.

Snapping helps precision, but Olaf's demonstration shows that different elevations and imperfect base geometry can still produce misalignment.^[5] Keep a reference bay nearby until the whole kit behaves consistently.

Diagram: build once, inspect twice

WALL BAY                 DOOR BAY               TWO-BAY TEST
+--+-------------+--+    +--+----+   +----+--+   [ WALL ]|[ DOOR ]
|T | solid wall  |T |    |T |    |   |    |T |           ^
+--+-------------+--+    +--+----+   +----+--+        inspect seam
===================== floor reference =========================
T = restrained trim     opening tested at normal player height

Text alternative: a wall bay and doorway bay share an outer width and floor reference. The doorway has a real opening between solid sides. A two-bay assembly exposes the seam that must be inspected before further duplication. This is a conceptual kit, not a fixed game dimension.

2. Separate a placed group from a saved group

Grouping inside a map and retaining that assembly for another map are different capabilities. BigBox's July 15, 2024 change list added the ability to save buildable groups and place them in other maps.^[10] The July 30 notes then fixed large saved groups that could not spawn.^[11]

If your Builder exposes saved groups, save the tested bay there and try placing it in a separate scratch map. Compare it with your reference: expected parts, placement, orientation, textures, opening, and collision. Keep a written kit name and revision so you know which version you are reusing.

Do not assume saved groups are live-linked prefabs. The inspected sources establish saving and placement, not automatic updates to every existing copy.^[10] If you revise the doorway, inspect the copies already placed in the arena. Until you have demonstrated otherwise, treat them as separate assemblies that need checking.

Likewise, the Rules Library transfers rulesets between maps; it is not the same thing as saving geometry.^[7] Keep a short note connecting your map revision, kit revision, and ruleset. That note is your release bookkeeping, not a hidden editor feature.

This workflow uses the in-game builder. It does not require a third-party designer or promise that external geometry can be imported.

3. Spend detail where players can use it

At a junction, players need to see the route, recognize cover, and identify a threat. A cluster of pipes that hides the doorway is not richer art. It is lost information.

Use a simple hierarchy:

• Silhouette: the large shape that identifies the area.
• Route information: openings, climb faces, landing areas, and useful cover.
• Surface character: texture and restrained trim that make the place feel intentional.

Do not give all three equal visual weight. Reserve the strongest landmark for a place players need to remember. Keep repeated bays quiet enough that the important opening still stands out.

BigBox documented skybox and lighting presets in February 2025.^[14] If you change them, repeat the readability check under the new lighting. A weapon, doorway, or opponent that was obvious before may blend into the background afterward. Presets are a documented capability; a particular preset being competitively readable is something your own test must establish.

Walk both directions through the south dogleg. Look toward the perches from ground level. Ask a new player to point out the next route without coaching. If the answer requires explaining your art, simplify the art.

4. Treat the budget as a constraint, not a performance certificate

A firsthand launch build report describes a map detail budget and observes its use while constructing a level.^[4] It does not provide a universal conversion from one object to one unit of cost. Do not budget a world by counting props as if every prop were equal.

Use the budget display and publication warnings actually present in your build. This guide deliberately gives no exact current cap, per-shape cost table, or guaranteed safe percentage: none was verified in the current game.

Run a small comparison before stamping your kit everywhere:

Compare candidates in otherwise equivalent scratch saves. If the display rounds small changes away, compare an equal batch of each candidate rather than declaring a zero-cost part. Do not infer a hidden exact formula from a rounded display.

Choose the least elaborate version that does the job. Reserve capacity for the things playtests uncover: another screen, an objective adjustment, a repaired route. Filling the display before testing leaves you choosing between a broken encounter and deleting finished art.

Budget and runtime comfort are separate checks. Being allowed to save or publish does not establish that a crowded fight feels smooth on the devices your players use. The opposite also matters: an uncomfortable test does not prove geometry is the cause. Rules, activity, device conditions, or connection can change the experience.

5. Optimize by a repeatable journey

Do not wander randomly, delete something, and announce an improvement. Use a route you can repeat:

1. Start in the west spawn pocket.
2. Cross the south dogleg while looking back toward the center.
3. Climb to the north perch using the match's movement rules.
4. Look across the arena and descend toward the central landing.
5. Repeat from the east side.

Keep the device, rules, approximate player activity, and route comparable. Record where you noticed stutter, visual clutter, or navigation difficulty. If you have a reliable measurement tool, record what it actually measured; otherwise call the result a comfort observation, not an FPS benchmark.

At the first reproducible problem, test one hypothesis. For example: replace decorative repetition along the dogleg while preserving its solid cover and route width. Replay the journey. If nothing changes, do not call the removal a performance win merely because fewer objects remain.

Optimization loop

SAVE BASELINE -> REPRODUCE A PROBLEM -> CHANGE ONE THING
       ^                                      |
       |                                      v
   KEEP OR REVERT <- COMPARE SAME ROUTE <- SAVE CANDIDATE

Text alternative: preserve a baseline, reproduce a specific issue, make one controlled change, save the candidate, compare the same journey, and either retain or revert the edit. The loop measures observations rather than promising a particular speedup.

Repeat the combat test after optimization. A faster-feeling arena that lost a spawn screen is not an improved release.

Study captured complexity without guessing its intent

Open BAMBOO by GODS_PITDEVIL in the archive with its hidden layers visible. The captured model contains about 2.6 million world triangles, 779 roof pieces, 112 false pieces, two boundary volumes, three kill zones, 23 triggers, and two playfield volumes. Those extraction counts describe the recorded geometry only: they do not identify the creator's intent or prove a performance problem. Use the map as an inspection exercise—follow one repeatable journey, toggle one hidden layer at a time, and write down the first specific problem before proposing a change.

6. Add one event you can explain

Advanced rules are real, but they are not an unrestricted programming environment. BigBox describes an editor with events, conditions, functions, variables, roles, and buffs, explicitly saying it is not a full visual programming interface.^[7] Start with an observable result before designing an elaborate mode.

The documented entry is Play → Edit Rules → enable Advanced Editor, which exposes the Event Editor.^[7] Do the following exercise in a separate scratch map, not by stripping rules out of your working deathmatch arena.

Exercise: a route instruction ring

This adapts BigBox's official Hello World, Parts 1–2. The new message is ours; the mechanism is theirs.^[7]

1. Create a scratch map using Hangout, the blank-events starting point used in the official example.
2. Place two flight rings. Give the first TriggerID 1 using the Edit tool; leave the second at 0, as in the source example.
3. Enable the Advanced Editor, add an event, and change its trigger to Flight Ring Triggered.
4. Keep the triggering player as the selected recipient and change the action to Show Toast. Enter: “South route: cover first, then cross.”
5. Save and test. At this intermediate stage, both rings should display the message, matching the official example's unrestricted trigger.
6. Add a condition: set the left expression to Variable → Event → TriggerID, the comparator to equals, and the right expression to Value → 1. Save and test again.
7. Check the negative case: the first ring should show the toast; the second should not. Have another player check which person receives it.

The condition is the important lesson. “A ring was triggered” and “the intended ring was triggered” are different tests. BigBox's documentation also explains that available actions depend on the selected object, so inspect selection when an expected action is missing.^[7]

FLIGHT RING TRIGGERED
          |
  select triggering player
          |
  event TriggerID == 1 ?
       /         \
     yes          no
      |            |
 Show Toast     no action

Text alternative: when a flight ring triggers, select the triggering player. Compare the event's TriggerID to 1. Only a matching ring displays the route instruction; a nonmatching ring does nothing.

Do not leave a debug or instruction event in a competitive map unless it serves the actual game. Once the scratch example works, decide whether a reminder belongs in Switchyard at all. The advanced choice may be to ship without it.

7. Make custom state survive the whole match

A feature that works on the first trigger can still fail after a death, round reset, or second player joining. Write down who owns every value before adding it.

BigBox documents per-player, team, and global variable scopes; its tutorial also uses the label Individual for player-owned state.^[7] Match the scope to the job rather than treating those names as interchangeable global storage.

OlafGolaf's scoreboard tutorial makes the practical risk clear: at 6:09–10:40, an in-room counter relies on entry/exit tracking, and he warns that spawning inside the region can disrupt that assumption. At 10:55–11:06, he discusses resetting the tracking value.^[16] Use that as a reason to test lifecycle edges—not as a guarantee that a toggle-based inside/outside detector covers every possible death or teleport.

For each stateful feature, record:

Keep the logic small enough to describe without opening the editor. If a single doorway needs several unexplained counters, simplify it before adding another doorway.

8. Release the saved map, not the idea of it

Saving, publishing, and loading another player's copy are different checks. Official launch materials document save/publish and search by title or author.^[3] Build your release process around those actual steps.

First save a clearly named candidate and reopen it. Check the edited kit, the ruleset, spawn teams, equipment, and the last optimization change. Then run a full match from that saved candidate.

Use this release sheet:

Map title / working revision:
Date and installed game version, if visible:
Ruleset and movement choices:
Kit revision used:
Devices represented in testing:
Complete match and side swap:
Repeated death/respawn results:
Boundary and high-route checks:
Custom event positive and negative cases:
Second match / reset results:
Save reopened and confirmed:
Known issues and next change:

Only write what was tested. A blank device field is more honest than “Quest optimized” without a Quest test. A known issue is useful when it names a position, a consequence, and a planned correction.

If you publish, have a second player find and load the intended map. Confirm the title and latest change so you do not accidentally inspect an older copy. Do not equate publication with featured placement or a guarantee of future traffic.

Troubleshooting

Release checklist

• □ The module includes all intended pieces, and its joins and openings work in play.
• □ I tested saved-group placement rather than assuming live-linked updates.
• □ Art preserves routes, cover readability, and recognizable landmarks.
• □ I recorded the actual budget display without claiming a universal cap.
• □ Optimization preserved the playable geometry and was compared on the same journey.
• □ Any custom event has a positive case, negative case, and correct recipient.
• □ Stateful features have tested ownership and reset behavior.
• □ I reopened the save, completed a match, and checked a second match.
• □ Release notes describe real tests and known issues, not invented benchmarks.
• □ If published, another player loaded the intended version.

Your next build starts with a kit—not a bigger blank map

Keep the wall bay, the route ledger, and the release sheet. On your next project, change the experience before multiplying the scenery: a different approach to height, a new objective, or a fresh movement constraint.

Return to Designing Better Battles whenever a map looks finished but plays poorly. Return to Your First Playable Map whenever a complicated ruleset makes it hard to tell whether the basic match still works.

For layout study, browse the public map archive. Use it to ask better questions about shape and routes. Test collision, movement, rule execution, and performance inside Population: ONE before claiming they work.