Your First Playable Map

A good first map is not a city. It is a place where two teams can spawn, find a fight, finish a match, and want another round.

Build that first. You can put the city around it later.

In this guide, you will make Switchyard, a compact practice arena with two sheltered starting areas, a central obstacle, and a route around either side. It is deliberately plain. You need to find the mistakes while moving a wall is still easy.

Before you begin

You need access to Population: ONE's in-game Sandbox builder, a headset and controllers you can use comfortably, and enough familiarity with the game to move, climb, and glide when the chosen rules allow them. Bring a friend for the final combat test; you can do the construction and first inspection alone.

About the instructions: mechanics below are grounded in BigBox's documentation and dated firsthand tutorials, not a test of today's game build. The documented entry route is Build Games → Create Game, with templates or copyable games; labels and controller bindings may differ in your version.^[1][3] Use the tools named on your own Builder menu rather than copying an old video's button presses. The arena plans, test targets, and checklists are our design recommendations, not official requirements.

By the end, you should have:

• A saved arena with a recognizable playable footprint.
• Spawn locations for both teams, with protected exits.
• Boundaries and rules that match the intended game.
• A completed test match and a short list of actual problems to fix.

1. Open a blank map and learn four tools

BigBox's launch instructions put Build Games beside the main Play area. Inside it, Create Game offers a blank template, a starter scene, or a community game whose creator permits copying. Saved Games holds your saved and published games.^[1][3] Start with a blank grass environment for this exercise. Snow and Moon environments are also documented; you do not need a special environment to learn construction.^[1]

Use a fresh map rather than someone else's finished arena. Copyable Games are useful for study, but your first lesson should make it obvious which pieces you placed and why. Only copy a map through the creator's allowed-copy workflow.^[2]

Before building the arena, place one simple cube away from the intended play area. Practice:

1. Move: shift it sideways, then up and down.
2. Rotate: turn it and return it to a useful orientation.
3. Scale: make it longer in one direction, then restore a manageable shape.
4. Duplicate: copy it and move the copy alongside the original.

Move, rotate, scale, snapping, and builder Fly Mode are documented Sandbox tools.^[3] Duplication and alignment are demonstrated in OlafGolaf's Swiss TV Station build at 1:10–1:29 and 2:12–3:11.^[5]

Turn snapping on for a pair of aligned pieces, then off and move one freely. Learn the difference before assembling an entire floor. Do not assume snapping fixes a piece that already sits at the wrong height: Olaf's stair demonstration finds exactly that problem at 2:41–2:56.^[5]

Use Fly Mode to inspect from above and underneath; leave it to check ordinary player movement. Builder flight is a construction aid, not proof that a player can traverse your arena. Olaf explicitly turns it off to test an opening at 7:40–7:49.^[5]

Your first checkpoint: you can place, resize, copy, and align a wall without accidentally moving the floor. Remove the practice pieces when you are done with them.

2. Block out Switchyard

A blockout is the simplest version of a level that lets you test how it plays. For Switchyard, use floor pieces and plain solid shapes. BigBox documents both building objects, such as cubes and houses, and gameplay objects, such as weapons and jump pads.^[3] Leave the fancy objects alone for now.

Treat one comfortable square floor section as a module. That is a planning unit for this exercise, not a claim about the game's snap interval or real-world dimensions. Start with a footprint roughly six modules long and four modules wide. Adjust it after walking it.

Plan: Switchyard v1

                      NORTH ROUTE
       +-----------------------------------+
       |       C                 C         |
       | A1   +---+          +---+    B1    |
       | A2   | S |    X     | S |    B2    |
       |      +---+          +---+         |
       |       C                 C         |
       +-----------------------------------+
                      SOUTH ROUTE

A1/A2, B1/B2 = candidate team spawn locations
S            = solid spawn screen, not a closed room
X            = central solid obstacle
C            = separate cover block
Outer line   = intended footprint, not an automatic barrier

Text alternative: two opposing spawn pockets sit at the west and east ends. Each has a screen between it and the center. A solid obstacle breaks the middle view, while north and south routes connect the ends. Cover blocks interrupt those side routes.

Build in this order:

1. Lay a continuous floor. Avoid holes and overlapping surfaces.
2. Put a solid obstacle in the middle. Make it tall enough that standing players cannot simply see through the middle of the arena.
3. Place a screen in front of each spawn pocket. Leave an exit around both ends of each screen.
4. Add the side cover blocks. Keep space between them and the outer edge so a player is not forced into a single narrow squeeze.
5. Stand in every pocket and opening. Widen anything that feels awkward before making copies of it.

The drawing is a route plan, not a finished collision model. A narrow mark on paper may be a wall a player can climb, and a roof may become another route. Test what players can do, not only what the plan suggests.

3. Make spawns part of the layout

The early developer-led Sandbox demonstration identifies the colored player statues as team spawns and shows that they can be placed in the map at 19:38–19:56.^[6] Builder ArmsReach describes using an object's Edit function to change a spawn point's team/color.^[18] These are historical references: check the properties exposed by your current spawn object before duplicating it.

For the exercise, place two candidate spawns per team in the pockets marked A and B. That is a small-test starting arrangement, not a universal spawn count or a promise of which point the game will choose. Make sure each belongs to the intended team. Do not casually enable shared-team use: a later update added an option to make spawn points usable by all teams.^[13]

At each point, ask:

• Am I on the floor, with space around my body?
• Is the first useful route easy to recognize?
• Can I reach cover without crossing the enemy's clearest firing lane?
• If someone watches one exit, is there another way out?

Do not decide that spawns are fair after one successful appearance. BigBox changed respawn logic to a weighted selection of valid points in May 2024; testing a single point does not establish the behavior of the whole set.^[9]

4. Set boundaries deliberately

There are two separate questions: where the game considers the play area to be, and what physically prevents a player from leaving it.

The early Sandbox demonstration shows Zone Bounds being resized to define the zone area at 19:03–19:38.^[6] A firsthand launch review separately describes invisible walls as boundary-making objects.^[4] Do not treat those as interchangeable tools. A visible outline in editing is not evidence that a player will collide with it.

Keep this first arena on reliable ground. Fit the zone area to the intended match, then test the perimeter in play. If you add an invisible boundary object available in your build, make its position understandable with visible scenery or a wall: an unexplained invisible stop feels like a bug.

Inspect above the arena as well as around it. Climb the screens. Try to reach the outside from their tops. If you can leave the intended fighting space, either make that route a deliberate part of the level or change the geometry and boundary setup. Do not surround an untested escape route with lethal objects and call the problem solved.

Zone-height advice from old videos can be outdated. BigBox added zone/respawn height overrides using the zone-bounds buildable in March 2025.^[15] This exercise does not rely on an old fixed-height rule.

5. Pick one ruleset, then write down what it does

Choose Team Deathmatch for the first version. BigBox's Advanced Editor tutorial explicitly starts from a TDM map, but you do not need to enable advanced logic for this exercise.^[7]

Open the Play tab and Edit Rules, the route documented by BigBox.^[7] Keep the basic setup simple. Before testing, record the settings actually shown in your game:

The table is a design brief, not a list of guaranteed field labels. BigBox documents score-based wins and time-based endings in its rules guide; exact behavior depends on the ruleset and round configuration.^[7]

Use a small, understandable weapon selection rather than a wall of every weapon. Gameplay weapons are documented building objects, and the Edit function can adjust weapon rarity.^[3][18] Match the two sides' choices and rarity for the first comparison. Do not let a stronger starting weapon disguise a bad route.

Save before testing. BigBox's official tutorial saves a map and tests from the Sandbox Play panel.^[7]

Study a captured arena

Open BATTLEFIELD PAINTBALL by GODS_PITDEVIL in the archive and inspect it from normal player height. The capture records two large spawn clusters at the same height, one boundary volume, and one playfield volume. Its captured rules use opposing halves, elimination on death, 125% player speed, 90% gravity, and no fall damage. Those facts do not prove the layout is balanced; use them to ask how spawn separation, movement rules, and the playable boundary reinforce one another.

For your own blockout, keep the brief smaller:

6. Run three tests in order

Test A: the construction walk

Without combat, walk the full floor, both routes, every spawn pocket, and the perimeter. Look for seams, snag points, head clearance, and places you only reached because builder flight was on. Check the arena from normal player height, not just the overhead view.

Test B: the movement challenge

Try to climb over your route separators and glide from every accessible high point under the chosen match rules. Note where those paths land. If a route bypasses all the cover, that is a layout issue to investigate, not evidence that climbing is wrong.

Test C: the complete match

Play with your friend. Finish a match rather than stopping after the first kill. Confirm:

• Both teams appear in usable positions.
• Death and respawn work repeatedly.
• Weapons and ammunition behave as intended.
• Neither side is stuck watching a spawn exit.
• The score or timer produces the expected ending.
• The next test starts cleanly rather than inheriting a confusing state.

Swap sides for another round. A skilled player winning is not the same thing as a stronger starting side.

Write one sentence per failure: where, what happened, and what to change. “East team was shot while stepping out of the north exit; move that cover block to break the angle” is useful. “Spawns bad” is not.

7. Save, reopen, then share

Saving and publishing are separate steps. BigBox documents saving throughout construction, accessing saved maps, and publishing when ready; the firsthand launch review describes creations as private until published.^[2][3][4]

Give your working save a recognizable name. After your first full match, save again, leave the editing session when convenient, and reopen the saved map. Confirm the floor, spawns, rules, and last fix are still there. That read-back is more valuable than assuming a save click worked.

For a first test, use the game's available friend/room workflow. Official launch materials confirm collaborative building; they do not make every collaborator's save equivalent to an owner-controlled release.^[2] Agree who owns the working version before anyone starts editing.

When the arena works, use the game's publish flow and inspect the resulting listing. Search by title or author, both supported by the documented Game Explorer.^[3] Have another player load it. Do not promise automatic placement in a featured playlist: publication and curation are different outcomes.

Troubleshooting

First-map checklist

• □ I can move, rotate, scale, duplicate, and align a piece.
• □ The floor and perimeter have been tested without builder flight.
• □ Both teams have correctly configured spawn candidates and more than one useful exit.
• □ I checked climb and glide routes under the actual match rules.
• □ Equipment opportunities are comparable on both sides.
• □ We finished a match, swapped sides, and repeated deaths.
• □ I saved, reopened, and confirmed the latest changes.
• □ If published, another player can find and load the intended version.

Next: make the fights better

You now have something worth improving: a map that runs a whole game. In Designing Better Battles, we will turn Switchyard's simple loop into a more deliberate arena, with measured routes, contestable height, and feedback you can act on.

For reference study, browse the public map archive. Treat a browser view as a way to inspect a layout, not a substitute for testing movement, collision, spawns, or rules in Population: ONE.