# Mapwright: Full Blog Content for LLMs

Generated: 2026-10-25T19:14:22.839Z
Source: https://mapwright.app
License: cite with attribution and a link to the source URL.

This file concatenates every Mapwright blog post in clean markdown so that
language models and answer engines can ingest the full corpus in a single
fetch. Per-post canonical URLs appear under each title.

----

# The UEFN Creator's Field Guide to In-Game Economies

Source: https://mapwright.app/blog/uefn-economy-guide
Author: The Mapwright Team
Date: 2026-04-26
Tags: UEFN, Game Design, Economy, Monetization, Verse

> A practical, math-grounded walkthrough of designing UEFN economies that hold up over thousands of sessions: faucets, sinks, dual-currency models, anti-inflation tactics, and how to pressure-test it all before you publish.
## Why most UEFN economies break in week two

The thing that kills creator maps isn't bad combat or weak art. It's an economy that feels great in playtest with five people and collapses the second a thousand strangers play it for an hour. By session three, the top players have hoarded so much currency that nothing in your shop matters. By day five, new players see the gap, bounce off, and the map's retention curve quietly flatlines.

Economies break for boring, reproducible reasons: the **faucet rate** outpaces the **sink rate**, the **time-to-progress curve** flattens too fast, or the **secondary currency** never finds a real role and becomes inert. The good news is that all three are measurable, and all three can be tuned before launch if you treat your economy as a system instead of a vibe.

This guide walks through the model we use when we build for UEFN: how to lay out faucets and sinks with real numbers, how to layer currencies so each one earns its keep, how to detect inflation before it strangles your map, and how to validate the whole thing in the Mapwright simulator before live players ever touch it.

## The core loop, stated as math

A UEFN economy is just a directed graph of resources. Players perform an **action**, the action **emits** a resource into their wallet, and the wallet **drains** when the player exchanges that resource for an upgrade, cosmetic, consumable, or unlock. Tighten that into one sentence:

> A healthy economy emits resources at a rate that lets a median player feel meaningful progress every session, while draining those resources fast enough that the wallet never trivializes the next decision.

Two numbers control everything: the **emission rate** (`E`, currency per minute of play) and the **drain rate** (`D`, currency per minute that the player chooses to spend). When `E > D` for too long, you have inflation. When `D > E`, you have a frustration spiral. The interesting design space is the gap between them and how it changes with player tenure.

Concretely, a session-one player should see something like `E ≈ 1.2 × D_short`, where `D_short` is the price of the cheapest meaningful upgrade. By session ten, that ratio should be closer to `1.05 × D_long`, with `D_long` being a long-arc goal like a prestige tier or a top-shelf cosmetic. The exact numbers depend on your mode, but the *shape* matters: emission and drain should converge as players advance, not diverge.

## Faucets: where currency comes from

A **faucet** (also called a source) is any rule that mints currency into a player's wallet. Most maps over-rely on one or two faucets, which is what causes the median-vs-top-player divergence. The fix is to spread emission across faucet types that fire at different cadences and require different inputs.

Useful faucet categories:

- **Activity faucets** reward in-the-moment actions: completing a round, scoring a goal, surviving a wave. They emit fast and reward skill or focus. These dominate session-one earnings and should make up roughly 50–65% of total emission for a new player.
- **Progress faucets** reward longer arcs: clearing a chapter, hitting a leaderboard tier, finishing a daily set. They emit slower but in chunkier amounts, and they're the lever you use to pull medium-tenure players forward.
- **Cadence faucets** reward presence: a daily login bonus, a returning-session multiplier, a weekly streak. They flatten the gap between casual and core players, and they're disproportionately important for D7 retention.
- **Social faucets** reward bringing or keeping other people in the map: a small bonus for a full party, a referral assist, a team-objective payout. They cost you almost nothing to add and do real work for organic discovery.

A common mistake is to make faucets purely additive. The result is that a no-life player earns 10x what a casual player earns and the economy bifurcates. Better is to give each faucet a **soft cap** per session so that the eighth round of the day pays a fraction of the first. Players still feel the reward, but the per-minute emission for a marathon session compresses toward the median.

## Sinks: where currency goes to die

A **sink** is any rule that removes currency from the economy. Sinks are the unsexy half of the design and they are almost always under-built. If you only have one sink (an upgrade store), every player will eventually max out, the store will go inert, and you've created a wallet with nothing to do.

Layer your sinks so that wallet pressure stays alive across the whole tenure curve:

- **Functional sinks** unlock or improve player capability: weapons, gear, abilities, vehicle skins that affect handling. These dominate early spend and tie directly into the moment-to-moment loop.
- **Cosmetic sinks** are pure self-expression: skins, emotes, name colors, banner trails. They don't gate gameplay so they don't risk pay-to-win perception, but they're the workhorse of long-tenure spend because they never run out of new variants to ship.
- **Consumable sinks** drain currency permanently and on a per-attempt basis: a one-shot revive, a temporary multiplier, a gambling-adjacent loot pull. Consumables are the strongest lever you have against hoarding, and they should make up at least 20–30% of total drain for active players.
- **Service sinks** charge currency for resets, retries, or convenience: re-rolling a build, fast-forwarding a cooldown, paying for an off-cycle round. They're the safety valve when emission unexpectedly outpaces functional and cosmetic spend.

Two design rules for sinks that are easy to miss:

1. **The cheapest meaningful sink should always be roughly one session of play away.** If a new player sees no purchase that feels reachable in their first 15 minutes, the wallet stops being motivating and becomes a number on the screen.
2. **The most expensive sink should be visible but not yet purchasable.** Aspirational items keep mid-tenure players engaged in a way that "everything is buyable today" never can. The aspirational item is the lighthouse, not the dock.

## Dual-currency design done right

Most polished UEFN maps run on at least two currencies, and good ones use that split deliberately. The classic pattern is a **soft currency** earned through play and a **hard currency** that's either rare, gated, or buyable. Each currency should have a clear *job*.

A model that works well in practice:

- **Soft currency** funds the moment-to-moment loop. It's high-emission, high-drain, and most of the player's session-to-session decision-making lives here. Functional upgrades, consumables, and service sinks should accept soft currency.
- **Hard currency** funds identity and aspiration. It's low-emission, slow-drain, and reserved for cosmetics, prestige, and gated unlocks. Players should always feel slightly short of a hard-currency goal, because the gap is where motivation lives.

Where this goes wrong: when soft and hard currency become **freely convertible** at a static exchange rate. The instant a player can grind soft currency into hard currency, the hard tier collapses into a tax on time and the entire identity layer flattens. If you want a conversion path, make it one-way (hard buys soft, never the reverse), gated (a weekly cap on conversions), or expensive enough that it's a last resort, not a strategy.

A second subtle failure: hard currency that's *only* purchasable. That signals pay-to-win to a Fortnite audience that is unusually allergic to it. Always emit a small drip of hard currency through play (a chapter completion, a top-3 weekly leaderboard, a rare drop) so the player knows it's earnable, even if most of it gets purchased.

## Inflation: the silent map killer

Inflation in a UEFN economy looks like this: the median wallet balance grows session over session faster than the most expensive sink. After a while, the most expensive sink isn't expensive anymore. After a little longer, every sink feels trivial and the player has nothing left to want.

Three signals that inflation is starting:

1. **Median wallet trending up across sessions** when it should plateau. Healthy wallets oscillate around a steady-state value as players earn and spend in roughly equal measure. A monotonic upward trend means emission is outpacing drain.
2. **Top-decile players completing the cosmetic tier in under a week.** If the players who play most are also the players with nothing left to buy, your cosmetic ladder is too short or too cheap relative to your faucet rates.
3. **Returning-session spend dropping while session count rises.** A returning player who used to spend on every login and now spends on one in five is telling you the wallet has lost its narrative pull.

Anti-inflation tactics, in roughly the order you should reach for them:

- **Tighten the soft cap on activity faucets.** This is the cheapest and least disruptive lever because it only affects marathon players.
- **Add a recurring sink.** A weekly seasonal bundle, a cosmetic rotation, or a consumable players want to top up creates ongoing drain without changing the pricing of existing items.
- **Introduce a rare drop with a hard-currency unlock.** This puts the burn back on hard currency without requiring a price increase elsewhere.
- **Re-price the top of the catalog.** This is a last resort because it feels punitive to existing holders. If you do it, only re-price *new* items and keep historical purchases stable.

What to almost never do: a global currency wipe or a retroactive price increase. Both feel like theft to players, and both will show up immediately in your D1 retention as a step function down.

## The pacing curve: making session N feel different from session 1

A flat economy is a boring economy. A player whose tenth session feels exactly like their first will churn around session twelve, because there's no narrative of progress. The pacing curve is the deliberate shape of how quickly currency, capability, and aspirations grow over tenure.

Think of pacing in three bands:

- **Sessions 1–3 (onboarding)**: Emission is generous, sinks are abundant and cheap, and the player should be making a meaningful purchase every session. Goal: install the loop and prove the wallet matters.
- **Sessions 4–12 (early mastery)**: Emission tightens, sinks get more expensive and more diverse, and the player starts to choose between competing purchases. Goal: introduce trade-offs and reveal the second-tier cosmetics.
- **Sessions 13+ (mastery)**: Emission flattens, sinks lean into prestige and identity, and aspirational purchases dominate. Goal: keep the lighthouse visible without ever quite letting the player reach the last island.

A useful rule of thumb: by session 12, a median player should have unlocked roughly 60–70% of the functional catalog and 20–30% of the cosmetic catalog. The remaining 70–80% of cosmetic depth is what carries them past session 30.

## Dailies, weeklies, and the shape of attention

Dailies and weeklies are not really economy mechanics. They are **attention mechanics** that route currency. The currency they emit is a side effect of the real job, which is to give the player a reason to come back tomorrow.

What makes a daily set work:

- **Three to five tasks, completable in 15–25 minutes.** More than that and the daily becomes a chore; fewer and it doesn't feel like a session.
- **One easy, one medium, one stretch.** The easy one guarantees the dopamine hit, the medium one makes the session feel substantive, and the stretch one creates a pull toward your skill systems.
- **A small bonus for completing the full set.** A modest "all clear" payout converts a satisfying session into a habitual one.

Weeklies should pay roughly 4–6x a single daily and almost always emit a small amount of hard currency. They are also the right place to introduce **seasonal narrative**: a weekly that ties into a current event, a limited-time mode, or a story beat keeps the map feeling alive without requiring permanent content additions.

A pattern to avoid: weeklies that can be 100% completed by a single high-skill burst on day one. The point of a weekly is to spread engagement across the week, so structure tasks that require *different sessions* (for example, "play five different rounds" or "complete on three different days") rather than a single grind.

## Pressure-testing the economy before you publish

The hardest thing about economy design is that you can't really feel it from a single playtest. Five friends playing for 20 minutes will not surface the inflation you'd see at session 50 with a thousand players. The only way to find those failures cheaply is to simulate.

A useful simulation does three things:

1. **Generates synthetic player profiles** along the tenure curve: a session-one player, a session-five, a session-twenty, with realistic differences in skill, time-on-task, and purchase preferences.
2. **Replays your faucet and sink rules** against those profiles for hundreds of synthetic sessions, tracking the wallet trajectory, the sink-completion curve, and the time-to-aspirational metric.
3. **Surfaces the failure modes** as plots: a divergent emission curve, a flattening sink curve, a gap between top-decile and median that grows past 3x.

This is exactly what Mapwright's economy simulator does. You declare your faucets, sinks, prices, and caps in your project, generate synthetic sessions, and read the resulting curves before you ship a single change. When the curves are wrong, you iterate on the rules, not on the live audience.

A practical workflow we recommend:

- Define the faucet table, sink table, and pacing bands in your project file.
- Run a 1,000-session simulation across three player archetypes.
- Look first at the **median wallet trajectory** across sessions 1, 5, 12, and 20. If it's monotonically rising past session 10, tighten emission.
- Then look at the **sink completion curve**. If the top decile clears the cosmetic catalog by session 8, the catalog is too short or too cheap.
- Finally look at the **time-to-first-purchase** for your session-one profile. If it's longer than 12 minutes, your cheapest sink is too expensive or your activity faucet is too slow.

Iterate until the curves look right at the simulator level, *then* ship to a closed playtest, *then* ship public. Every loop you save in the simulator saves a hundred loops in the live data.

## A short checklist before publish

- [ ] Soft and hard currency each have a clearly stated job.
- [ ] At least four faucet types are emitting, with soft caps on the activity faucet.
- [ ] At least three sink categories are present (functional, cosmetic, consumable at minimum).
- [ ] The cheapest meaningful sink is reachable in 12–15 minutes for a session-one player.
- [ ] The most expensive sink is visible but takes 15+ sessions of focused play to reach.
- [ ] Median wallet trajectory across simulated sessions plateaus, not climbs.
- [ ] Top-decile sink completion is below 60% by session 8.
- [ ] Daily and weekly tasks are structured to spread engagement across days, not bursts.
- [ ] Hard currency is earnable in small amounts through play, not gated entirely behind purchase.

If you can tick those nine boxes and your simulator curves look healthy, you have an economy that will hold up past week two. Everything else in your map (combat, art, narrative, mechanics) gets to do its job without an inflation problem strangling it from underneath.

The economy is the spine. Build it deliberately and the rest of the map gets to breathe.

## Related reading

- New to UEFN entirely? Start with [Day One: From empty editor to a playable island](/blog/newcomer-day-one-uefn) and the [first Verse script walkthrough](/blog/newcomer-day-three-verse).
- For the language used here ([sources](/glossary#source), [sinks](/glossary#sink), [currency](/glossary#currency), [retention](/glossary#retention)), the [Mapwright glossary](/glossary) has plain-English definitions for every term.
- Pair this with our [retention engineering guide](/blog/uefn-retention-engineering) to design progression that compounds, and the [Verse performance patterns](/blog/verse-performance-patterns) so your economy code holds up under real player counts.
- Pressure-test the model before you ship in the [Mapwright economy simulator](/studio).

----

# Make Your First Fortnite Map (Part 3): Ship It and Read the Numbers

Source: https://mapwright.app/blog/teen-make-your-first-map-part-three
Author: The Mapwright Team
Date: 2026-04-25
Tags: Teen Build, Teen, First Map, Make Your First Map, Beginner, UEFN, Publishing, Discover

> Your map is built. Now publish it for real, get an island code, share it without spamming, and learn which numbers actually matter in your first week. Plus: how to set yourself up so the next map ships even faster.
## Welcome to the part nobody teaches

Tutorials almost always stop at "you have a build that works." Then the creator hits publish, gets a few players, watches the numbers do nothing dramatic, and quietly gives up.

So this third post is the one nobody writes: how to publish, how to share, and how to read the early numbers without losing your mind. If you finished [Part 1](/blog/teen-make-your-first-map-part-one) and [Part 2](/blog/teen-make-your-first-map-part-two), you have a real, playable map. The goal of today is to put it in front of strangers and learn from what they do.

## Step 1. Run a final pre-flight check

Before you push the publish button, do this checklist. Five minutes now saves a lot of patching later.

**One last clean playthrough.** Launch the local session, play one full round from spawn to win condition, no shortcuts. If anything feels broken, fix it now. If everything works, breathe.

**Set your island name and description.** In UEFN, open **Project Settings > Island Settings**. The name and description are what players see in Discover. Be specific, not generic. "Pizza Tycoon Tiny" beats "Tycoon Map." Mention your hook from part one in the description.

**Pick clear tags.** Tags shape who finds your map. Match your archetype (parkour, hide and seek, free-for-all, tycoon, zone wars) and add one or two flavor tags (theme, vibe). Avoid tag spam; Discover penalizes it.

**Decide your age rating.** UEFN forces you to declare an age rating before publish. Be honest. The wrong rating gets you removed.

**Two-factor on your Epic account.** You did this on day one of UEFN install (right?). Confirm it, because Epic blocks publish without it.

## Step 2. Build and submit

In UEFN's top toolbar, find the project menu and choose **Build & Submit**. UEFN will:

1. Cook all your assets into the format Fortnite needs.
2. Compile any Verse code.
3. Upload everything to Epic and associate it with an island.
4. Hand back an [island code](/glossary#island-code).

The first build of an island is slow. Five to fifteen minutes is normal. While it builds, write down where you plan to share the link (we will get to that in step 4).

When the build finishes, copy the island code (a 12-digit number like `1234-5678-9012`). Open Fortnite, go to the **Discover** screen, paste the code into the search box, and hit enter. Your map should load. Walk around. The version players will see is exactly this.

If anything looks wrong, go back to UEFN, fix it, and re-submit. Builds 2 through N are much faster.

## Step 3. Decide what "success" means for your first map

This is the most important step in the whole post. Most creators set themselves up to feel bad because they decide "success" is "thousands of players in the first week." Then they get fifty players in the first week, feel like a failure, and stop.

Here are realistic, healthy success metrics for a first map:

**The map is technically working.** People can find it, join it, and finish a round without it crashing or being broken. That alone is a real accomplishment.

**Your friends played it and had fun.** A handful of people had a good time on something you built. That feeling is the reason to keep going.

**At least one stranger played it.** Even one stranger discovering your map through Discover is a win. They had no relationship to you, they just found it. That is huge.

**You learned three things.** What worked? What did not? What would you do differently next time? Three concrete answers is a successful first map. The next one will be twice as good because of it.

Notice that none of these are "I made money" or "I got viral." Those are real outcomes for *some* maps eventually. They are not the goal of your first one. The goal of your first one is to *finish a project and learn*.

## Step 4. Share it without being annoying

Sharing a Fortnite map can quickly become spam. Here is how to share it without getting blocked or burning bridges.

**Friends first.** Send the code to a small group of friends with one sentence about what it is. Ask them to play one round and tell you one thing they liked and one thing they would change. This is how every map starts and how you get the first round of feedback.

**Two communities, not twelve.** Pick one Discord server you already participate in (a UEFN-creator server or a fan-of-the-archetype server, like a Zone Wars server) and one subreddit. Post your code with a *short* description, a screenshot, and a clear note about what you would like feedback on. Do not post the same thing in twenty places.

**Avoid Discord servers that are not yours.** Spamming your code in unrelated servers is the fastest way to get banned and to make a bad reputation in a small community.

**Tag a small creator, not a huge one.** A creator with 5,000 followers is far more likely to actually look at your map than a creator with 5 million. Pick one whose taste matches your archetype. Be polite, brief, and only tag once.

**Post on TikTok or YouTube Shorts with the gameplay loop.** A 15-second clip of the most exciting moment of your map, with the code in the description, is the single highest-leverage thing you can do for first-week visibility. Even a tiny video can find an audience.

## Step 5. Read your first-week numbers

After a few days, log into your creator portal and look at the analytics for your island. There is a forest of metrics. Three of them matter most for your first map.

**Sessions.** How many times has your map been launched? Sessions are the headline number. Do not panic if it is small at first. Almost no first map breaks 1,000 sessions in week one. That is normal.

**Average session length.** How many minutes does the average player spend per visit? Healthy targets vary by archetype: 12-25 minutes for round-based modes is great, longer for sandbox/tycoon modes. If your number is under three minutes, players are joining and bouncing fast. That is feedback.

**[Retention](/glossary#retention).** What percentage of players come back the next day (D1) or the next week (D7)? This is the single most important metric for [Discover](/glossary#discover) and for [engagement payouts](/glossary#engagement-payout). A first map with even a 5-10% D1 is a real result.

If your sessions are low and bounce rate is high, the most likely culprit is *onboarding*. Players join, do not understand the rules in the first 30 seconds, and leave. Fix this with billboards at spawn, a clearer name, and a sharper description. These are fast fixes that often double session length without touching gameplay.

If your sessions are healthy but retention is low, the issue is the *core loop*. The first round was fun; the second round was the same. Fix this in your *next* map by designing a deeper meta loop, not by patching this one. Ship the next map.

## Step 6. Decide what comes next

You have shipped a map. There are three healthy directions from here.

**Patch this one once.** Pick the single biggest piece of feedback (usually onboarding clarity or one balance issue) and patch it. Do not patch ten things; that is a sign you are stalling on the next map. One patch, then move on.

**Start your next map with a slightly bigger goal.** Your first map taught you the workflow. Your second map can be 25-50% more ambitious. Maybe it adds a [Verse](/glossary#verse) script (start with [Day Three](/blog/newcomer-day-three-verse)). Maybe it adds a real economy (skim our [economy field guide](/blog/uefn-economy-guide) for vocabulary).

**Connect with other creators.** The single biggest accelerator in UEFN is being around other people who are building. Find a small creator Discord, share what you are working on, ask questions, give feedback to others. Most creators are friendly; the field is still small.

## What you just accomplished

Three weekends ago, you had an idea. Today, you have a published Fortnite map with an island code, real analytics, and at least one stranger who played something you built.

That is a serious thing. Most people who say they will make a Fortnite map never do. You did. The skills you used to ship this one (picking a focused idea, blocking out a level, wiring stock devices, reading early analytics) are the same skills behind every successful map on Discover. You will get faster, your taste will sharpen, and the maps will get better.

When you are ready to push deeper, here is the recommended reading path:

- [Day Three: Your first Verse script](/blog/newcomer-day-three-verse) for your first piece of real code.
- [Verse performance patterns](/blog/verse-performance-patterns) for writing Verse that holds up under real player counts.
- [Retention engineering](/blog/uefn-retention-engineering) for the deeper "why" behind making players come back.
- [The UEFN economy field guide](/blog/uefn-economy-guide) when your map starts having currency or progression.
- The [glossary](/glossary) any time a word does not click.

Welcome to being a Fortnite creator. The first map was the hardest one. Go ship the next one.

----

# Make Your First Fortnite Map (Part 2): Build It in a Weekend

Source: https://mapwright.app/blog/teen-make-your-first-map-part-two
Author: The Mapwright Team
Date: 2026-04-24
Tags: Teen Build, Teen, First Map, Make Your First Map, Beginner, UEFN, Tutorial

> You picked your idea. Now build it. A Saturday-and-Sunday plan for shaping the level, placing the gameplay devices, and getting from blank island to playable in two days without burning out.
## The weekend plan

You did the hard part in [Part 1](/blog/teen-make-your-first-map-part-one): you picked an idea, sketched a layout, and committed to a rule that makes it memorable. Today is the build. The whole point of this post is to show you that a polished, playable map is genuinely a weekend of focused work, not a month-long grind.

We will split it into four sessions of roughly two to three hours each. Two on Saturday, two on Sunday. You can stretch this across a school week if weekends are busy. Keep the sessions discrete and finish each one before moving to the next.

Before Saturday morning, you should have UEFN installed and have walked through [Day One](/blog/newcomer-day-one-uefn). If you have not, do that first; the rest of this post assumes you can open a project, fly the camera, and place a device.

## Session 1 (Saturday morning): blockout

Blockout is the boring, ugly first pass at the geometry. No textures, no decorations, no atmosphere. Just gray boxes that show where the walls, floors, and platforms go. Every professional level designer starts with a blockout because it is the only way to feel out a layout without burning hours on art that you might delete.

Open your project. In the Content Browser, search for **Cube**. Drag a few cubes into the level. Use the scale tool (R) to stretch them into walls and floors that match your sketch. Use the move tool (W) to place them. Use the snap-to-grid (the small grid icon in the toolbar) so things line up cleanly.

Build the rough layout from your part-one sketch. Do not worry about how it looks. The questions you are answering this session are:

- Can a player physically get from spawn to the goal?
- Is anything obviously too narrow (under two meters wide is usually too tight) or too wide (over fifteen meters of empty floor feels dead)?
- Are sight lines and chokepoints where you wanted them?

Place a Player Spawner Device (you used one in Day One) at the spawn location and add a few more so you can test from different angles. Launch the session and just walk around the blockout. Does it feel right? Adjust.

By lunch, you should have an ugly, gray, walkable layout that matches your sketch. That is success for session 1. Stop. Go eat.

## Session 2 (Saturday afternoon): gameplay devices

Now you wire up the actual gameplay using stock devices. You learned the *(options, events, functions)* model in [Day Two](/blog/newcomer-day-two-devices); it is what every device in this session will use.

What you place depends on your archetype.

**Free-for-all arena.** Drop an **Item Spawner Device** for each weapon spot. Configure each spawner with the weapon you want. Place a **Score Manager Device** to track kills. Use an **End-of-Round Device** so the round ends when one player reaches a kill target. Drop a **Class Designer Device** that gives every spawning player full shields and your starting weapon.

**Hide and seek.** Place a **Class Designer** for the hider class (low health, high speed) and another for the seeker class (full health, melee weapon). Use a **Team Settings Device** to define two teams. Add a **Trigger Device** at locations the seeker can use to end the round (a "find" trigger). Use a **Round Settings Device** to set round length and team assignment.

**Parkour.** Place **Mutator Zone Devices** as kill volumes around any falls (so players who miss a jump respawn instead of being stuck below the course). Place a **Trigger Device** at the start that begins a timer, and another at the end that stops it. Add a **Billboard Device** at the end that shows the time. Optionally add a **Score Manager** that tracks completion times.

**Tycoon.** Place a **Resource Granter** at each upgrade station that gives the local player a resource over time. Each upgrade station is a **Conditional Button Device** that costs a quantity of resource and triggers an event ("upgrade level 1 unlocked"). Use **Mutator Zone Devices** to keep players inside their own plot.

**Zone wars.** Drop a **Storm Controller Device** and configure its phases. Use **Player Spawner Devices** with the team option to keep players spread out. Use a **Score Manager** to track kills.

Wire everything as we covered in [Day Two](/blog/newcomer-day-two-devices). The pattern is always the same: an event on one device triggers a function on another. Test by launching the session frequently. Wire one piece, test it, wire the next. Do not wire ten things and then try to test, because if anything is wrong you will not know which piece broke it.

By the end of Saturday, your map should be *playable*. Ugly, but playable. A friend should be able to drop in via local launch and have a real game with you.

## Session 3 (Sunday morning): make it look good

Now and only now do you do art. The reason you waited is simple: every hour of art you do before the gameplay works is an hour that might get thrown away. Now that the gameplay works, decoration is safe.

Pick a small set of meshes that match your theme and use them ruthlessly. Less variety, more repetition, looks more cohesive. The Content Browser has thousands of free Epic-supplied assets. Search by your theme word ("forest," "industrial," "sci-fi," "neon").

Replace your gray cubes with themed meshes. A wall becomes a brick wall mesh. A floor becomes wooden planks. A pillar becomes a marble column. The trick is to keep dimensions the same so your gameplay does not change. Drag a mesh in, scale it to match the cube it replaces, delete the cube. Repeat.

Add lighting. Place a **Sky Light** if your level does not have one (most templates do). Add **Point Lights** in interior spaces with colors that match your theme. Avoid all-white lighting; small color casts make a level feel intentional.

Add three or four small **prop clusters**: a stack of crates, a desk with items on it, a bench with a lamp. These cost almost nothing to place and dramatically increase how alive a space feels.

Spend no more than two hours on this. If you keep going, you will tweak forever. Stop when it looks "good enough that a screenshot would not embarrass me."

## Session 4 (Sunday afternoon): playtest and polish

Get one or two friends to drop into a local session and just play. Do not coach them. Watch what they do.

You will discover three categories of issues, in order of importance:

**Confusion.** Players do not know where to go, what to do, or how the rules work. Fix this with **Billboard Devices** that explain the rules at spawn, with **HUD Message Devices** that announce key moments, and with sight lines that pull the player's eye toward the next objective.

**Imbalance.** Someone wins way too easily, or rounds drag forever. Adjust your **Score Manager** target, your weapon set, your timer, your storm size. Iterate fast. Push small changes, re-launch, see how it feels.

**Soft bugs.** Players get stuck in a corner, or a trigger fires twice, or a respawn drops them outside the map. Fix these one at a time. Do not skip them; one stuck-in-corner moment is enough to make a player quit and never return, which torches your [retention](/glossary#retention).

By Sunday evening, you should have a map that:

- Is fully playable from spawn to round end.
- Has art that does not embarrass you in a screenshot.
- Has rules a stranger can understand within thirty seconds of joining.
- Has at least one full playthrough with friends that ended naturally (someone won, or the round ended cleanly).

That is a finished first map. It is allowed to have flaws. It does not have to be perfect. It has to be *done*. Done is the precondition for everything that comes next.

## What you should not do this weekend

A few things to actively avoid, because they are the classic time-sinks that kill weekend builds.

**Do not write Verse code yet.** Stock devices are enough for any of the five archetypes from part one. Verse is amazing, but it is for round two. (When you are ready, [Day Three](/blog/newcomer-day-three-verse) is the gentle on-ramp.)

**Do not add a leaderboard, accounts, or persistent progression.** These are large systems and they are not what makes a first map fun.

**Do not change archetypes mid-build.** If your tycoon is not coming together, ship the tycoon anyway and learn from it. Pivoting in the middle is how a weekend turns into a month.

**Do not polish art on something with broken gameplay.** If gameplay is broken, fix it first.

## Up next

[Part 3: Publishing it for real](/blog/teen-make-your-first-map-part-three) takes your finished build and walks through pushing it to Fortnite, getting an island code, sharing it with the world, and the small set of things to actually pay attention to in your first week of analytics.

If you finish before Sunday night, the [glossary](/glossary) is great prep for part 3. Especially [Discover](/glossary#discover), [Engagement Payout](/glossary#engagement-payout), and [Retention](/glossary#retention).

You are one weekend away from being a published Fortnite creator. Go build.

----

# Make Your First Fortnite Map (Part 1): Pick an Idea You Can Actually Finish

Source: https://mapwright.app/blog/teen-make-your-first-map-part-one
Author: The Mapwright Team
Date: 2026-04-23
Tags: Teen Build, Teen, First Map, Make Your First Map, Beginner, UEFN, Game Design

> You want to make a Fortnite map. The single biggest reason teen creators never ship is the idea itself. This post will help you pick something small enough to finish, fun enough to play, and shippable in a single weekend.
## Read this before you open the editor

Most people who say "I'm going to make a Fortnite map" never finish one. Not because UEFN is too hard. Not because Verse is too scary. Because the *idea* they pick is too big.

A 14-year-old can absolutely ship a Fortnite map. Lots of teens have, and some of them now make full-time money from Discover. The teens who finish always have one thing in common: they started with an idea small enough to actually complete in a weekend, learned from how it felt to ship, and *then* worked on the bigger dream.

This is part one of a three-part series. By the end, you will have published your own Fortnite map. Today's job is to pick the right first idea.

If you have not installed UEFN yet, our [Day One walkthrough](/blog/newcomer-day-one-uefn) covers that in about an hour. You do not need to do that before reading today's post; in fact, picking an idea before you install is fine. But you will install before part two.

## The most important rule: 200 by 200 meters or smaller

If you take one idea away from this post, take this one. **Your first map should fit inside a 200-meter-by-200-meter area.** That is roughly the size of one of Fortnite's smaller competitive arenas.

Why this number? Three reasons.

**You can build it in a weekend.** Two hundred meters is enough room for a real map with a real layout, but small enough that you can fully decorate it without burning out. Bigger maps take weeks.

**It performs well.** Small maps run fast on every device players use, including the older Switch and mobile builds that tank on bigger maps. Performance matters more than you think for retention.

**It plays better.** Most fun gameplay happens at close-to-medium range. Sprawling maps end up with players running in circles looking for each other, which is the opposite of fun. Tight maps mean constant action.

If your dream map is bigger than this, do not worry. You can build it. Just not as your first one. Save that idea, do this small one first, and the big one will be a hundred times better when you come back to it because you will know what works.

## Pick a mode archetype, not a vibe

The second mistake most first-time creators make is starting with a vibe ("I want it to feel like Squid Game" or "I want it to be Naruto-themed") instead of a *mode archetype*.

A [mode archetype](/glossary#mode-archetype) is the underlying shape of the gameplay. There are roughly five archetypes that work well as a first map. Pick one. Themes can come on top later.

**1. Free-for-all arena.** A small enclosed space, players spawn with weapons, last one alive wins, repeat. Examples: 1v1 build battles, gun games, sword arenas. Easiest to build and easiest for players to understand.

**2. Hide and seek (or prop hunt).** One team hides, one team seeks, on a map full of hiding spots. Requires a bit more thought about where to hide but no complex systems.

**3. Parkour course.** A linear obstacle course from start to finish. Players race the clock or each other. The fun comes from movement, not combat. Surprisingly approachable for first-timers because the gameplay is the *level itself*.

**4. Tycoon (small).** A "build up an empire" map where players collect resources to upgrade. Be careful here. Tycoons get out of hand fast. Limit yourself to three upgrade tiers and one resource for your first one.

**5. Zone wars.** A small storm closes around players who are forced to fight in a shrinking circle. Familiar to every Fortnite player and easy to ship.

Pick one of these five. We are not making a horror story map, a simulation map, a sandbox roleplay map, or a 30-player open-world battle royale on the first try. Those things are all possible later. Today's job is to ship.

## Pair an archetype with a hook

A hook is the one thing that makes your map different from the thousand others in the same archetype. Hooks do not have to be huge. The best hooks are usually small twists on a familiar idea.

If your archetype is **free-for-all arena**, your hook could be the weapon set (only crossbows, only fish, only mythics), the layout (one tiny circular room, two stories, a mirror layout), or a rule (instant kill, no shields, infinite ammo).

If your archetype is **hide and seek**, your hook could be the theme (a haunted school), the props (only Fortnite food items), or a twist (seekers can teleport, hiders have one fake clone).

If your archetype is **parkour**, your hook could be the visual gimmick (the entire course is upside down), the physics (low gravity), or the goal (collect five floating coins, not just reach the end).

If your archetype is **tycoon**, your hook is almost always the *theme* (a pizza shop, a spaceship, a tiny cottage). Pick something visually clear in three words.

If your archetype is **zone wars**, your hook is the map shape (vertical tower, ice level, all-water level). Players know zone wars; you are competing on flavor.

Write your archetype and hook on a sticky note. Out loud, your map should sound like a sentence: "Free-for-all arena where everyone only has fish weapons in a tiny circular pizzeria." That is a real map. Players can imagine it, you can build it, and Discover knows how to surface it because it slots into a familiar archetype while still feeling unique.

## Sketch the map on paper before you open UEFN

This is the unglamorous step that makes the build phase ten times easier. Grab paper. Draw the top-down outline of your 200x200 meter map. Mark:

- Where players spawn.
- Where the goal or fight happens.
- The major walls or obstacles.
- For tycoons: where each upgrade station goes.
- For parkour: the rough path from start to finish.

Spend twenty minutes on this. The sketch does not need to be pretty. It just needs to commit you to a layout. Without a sketch, you will keep re-arranging things in the editor for a week and never finish.

While you are sketching, time it: how long should one round take? For arenas and zone wars, three to five minutes is right. For parkour, two to four minutes for a skilled player. For hide and seek, four to seven minutes. For tycoons, the *first session* should feel rewarding within ten minutes, even though the loop can run much longer.

If your sketch implies rounds that last twenty minutes, your first map is too big. Cut something.

## Decide on one rule that breaks expectations

Discover loves maps that are recognizable but slightly weird. The "slightly weird" part is what makes someone tell their friend about it. So before you build, write down *one* unusual rule.

Examples of good unusual rules: "Everyone respawns with full mats." "There are no guns, only melee." "The map rotates 90 degrees every minute." "Friendly fire is on." "There's exactly one mythic somewhere on the map; whoever has it wins ties."

You only need one. Two is fine. Three is a mess. Save the others for your second map.

## What you should walk away with today

By the end of this post, you should have, written down somewhere:

1. **A sketch** of your map (top-down, on paper, twenty minutes max).
2. **One sentence** describing your map ("archetype, in a setting, with a twist").
3. **One unusual rule** that makes it memorable.
4. **A target round length** you are designing for.

That is your design brief. Tape it next to your computer. When you start building, anything that does not serve those four things gets cut. Discipline is what separates ship from never-ship.

## Up next

[Part 2: Building the level in UEFN](/blog/teen-make-your-first-map-part-two) walks you through actually constructing the map you sketched today. You will place spawns, build the layout, and have something playable by the end of the post.

[Part 3: Publishing it for real](/blog/teen-make-your-first-map-part-three) will get your island onto Fortnite Discover with an island code your friends can use, plus a small list of things to track to know if it is working.

While you wait, the [glossary](/glossary) and our [Day One UEFN walkthrough](/blog/newcomer-day-one-uefn) are great background reading. Both are written for total beginners.

You picked an idea you can actually finish. That puts you ahead of most adults trying the same thing. See you in part two.

----

# Day Three: Your First Verse Script (For People Who Have Never Coded)

Source: https://mapwright.app/blog/newcomer-day-three-verse
Author: The Mapwright Team
Date: 2026-04-22
Tags: First Steps, Newcomer, Beginner, Getting Started, Verse, UEFN, Tutorial

> A patient first walk through writing real Verse code. We will build a tiny custom device that grants a reward on a timer, with every line explained. No prior coding required.
## The first Verse script is the hardest one

Once you have written one Verse script and watched it run inside a real Fortnite session, the rest of Verse stops feeling intimidating. The hardest part is the first one. So this post is dedicated entirely to writing one small, complete, useful Verse script, with every line explained.

If you have not done [Day One](/blog/newcomer-day-one-uefn) and [Day Two](/blog/newcomer-day-two-devices) yet, do those first. They give you the editor literacy and the *(options, events, functions)* mental model you will lean on throughout this post.

What we are going to build today is a **timed reward device**. Every thirty seconds, it grants every player on the island one unit of a chosen item. It is the kind of device you find in a hub island where players want a slow trickle of resources. More importantly, it touches almost every Verse fundamental: subscriptions, timers, classes, options, and the device system.

## Step 1. Make a Verse module

Open your project in UEFN. In the top menu bar, go to **Verse > Verse Explorer**. The Verse Explorer is the panel where you create and manage Verse code.

In Verse Explorer, find your project's Verse folder. Right-click it and choose **Create new Verse File**. Name it `timed_reward`. Open it. UEFN will pop up a Visual Studio Code window with the file already loaded. (If you do not have VS Code installed, the Verse Explorer will prompt you to install it the first time.)

You will see something like this template, give or take a few lines:

```verse
using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }
using { /UnrealEngine.com/Temporary/SpatialMath }
```

Those `using` lines are *imports*. They make Epic-provided types and functions available to your code. The first one gives you device-related types. The second gives you general simulation primitives like timers. The third is for math; we will not use it today, but we will leave it.

## Step 2. Write the device class

Beneath the imports, write this:

```verse
timed_reward := class(creative_device):
    @editable
    ItemGranter : item_granter_device = item_granter_device{}

    @editable
    IntervalSeconds : float = 30.0

    OnBegin<override>()<suspends> : void =
        loop:
            Sleep(IntervalSeconds)
            ItemGranter.GrantItem()
```

That is the entire script. Let's read it line by line, because every line teaches something important.

**`timed_reward := class(creative_device):`** declares a new class called `timed_reward` that extends `creative_device`. Anything that extends `creative_device` can be placed in your level like a normal device. This is the bridge from "Verse code" to "thing in the world." See [creative_device](/glossary#creative-device) in the glossary for the broader picture.

**`@editable`** is a decoration that says "expose the next field in the editor's Details panel." Without `@editable`, a field is invisible to the editor and you can only set it from code.

**`ItemGranter : item_granter_device = item_granter_device{}`** declares a field of type `item_granter_device` and gives it a default of an empty placeholder. Because it is `@editable`, you will be able to drag any item granter device from your level into this slot in the Details panel. That is how you tell our timed reward *which* item granter to use.

**`IntervalSeconds : float = 30.0`** declares another `@editable` field, this time a floating-point number defaulting to thirty. You can change it to fifteen or sixty in the editor without touching code.

**`OnBegin<override>()<suspends> : void =`** declares the lifecycle method that runs when the device starts. `<override>` says "we are overriding the parent class's OnBegin." `<suspends>` is a Verse [effect specifier](/glossary#decides) that means "this function can pause execution." Anything that calls `Sleep` or waits on an event needs `<suspends>`. See [OnBegin](/glossary#onbegin) for more.

**`loop:`** is exactly what it sounds like: an infinite loop. Inside the loop:

- **`Sleep(IntervalSeconds)`** pauses the device for the configured number of seconds. This is non-blocking: while we are sleeping, the rest of the island runs normally.
- **`ItemGranter.GrantItem()`** calls the item granter's GrantItem function. Whatever item is configured on that granter, every applicable player gets one.

That is the entire program. Six lines of meaningful code. Save the file.

## Step 3. Build Verse code

Back in UEFN, go to **Verse > Build Verse Code**. UEFN compiles your Verse and reports any errors at the bottom of the editor. If you typed the code above exactly, you will see "Build Successful." If you see errors, they almost always come from typos: a missing colon, a wrong indent, a forgotten `using`. Verse is whitespace-sensitive, so indents matter.

After the build succeeds, your `timed_reward` class shows up in the Content Browser. Search for it. Drag one into your level.

## Step 4. Wire it to a real item granter

Place an **Item Granter Device** in your level. In its Details panel, configure which item it should grant (any consumable works for testing; wood is a classic). Then select your `timed_reward` device. In the Details panel, find the `ItemGranter` field and either drag the item granter from the Outliner into it or use the picker.

Save. Push a build. Join your island. Stand around. Every thirty seconds, your inventory ticks up by one of whatever item you configured. You just shipped a Verse-powered device.

## Why this tiny script teaches a lot

Step back from the keyboard for a minute and notice what you actually used.

You used a **class** (`timed_reward`), the unit of code organization in Verse.

You used **inheritance** (`class(creative_device)`), which is how Verse lets your code participate in the device system.

You used **typed fields** (`item_granter_device`, `float`), which is how Verse knows what kinds of things you are talking about and protects you from runtime nonsense.

You used **the editor bridge** (`@editable`), which is how Verse code becomes configurable in the visual editor instead of needing a recompile for every tweak.

You used **lifecycle hooks** (`OnBegin`), which is how your code knows when to start.

You used a **suspends function** with `Sleep`, which is your gateway into Verse's surprisingly powerful model for async behavior. Verse handles waiting, delays, and concurrency through `<suspends>` instead of callbacks or promises, which is one of the best parts of writing Verse code.

You used a **device function call** (`ItemGranter.GrantItem()`), which connects your Verse code to the (options, events, functions) world from [day two](/blog/newcomer-day-two-devices).

Almost every Verse script you ever write is a denser version of those same ingredients.

## Where to go next

You have written your first Verse script. The next steps depend on where you want to push.

If you want to deepen your **Verse fluency**, read [Verse performance patterns](/blog/verse-performance-patterns). Yes, you are still a beginner; read it anyway. The patterns it describes are not advanced, they are just *correct*, and learning them now means you never have to unlearn the wrong ones.

If you want to deepen your **design fluency**, our [retention engineering guide](/blog/uefn-retention-engineering) explains why some islands keep players coming back and others do not. Even as a newcomer, you can build with retention in mind.

If you want to start a **bigger project**, our [teen series](/blog/teen-make-your-first-map-part-one) walks through building a complete first map from a clean editor to a published island. It is written for younger creators but works equally well as a "first real project" guide for adults.

And whenever a Verse word, device, or surface confuses you, the [glossary](/glossary) is there.

Three days in, you have an editor that feels familiar, a mental model for devices, and a working Verse script. That is more than enough to start building. Go pick a small idea, ship it, and learn from what players do with it.

----

# Verse Performance Patterns: Writing UEFN Code That Doesn't Tank Your TPS

Source: https://mapwright.app/blog/verse-performance-patterns
Author: The Mapwright Team
Date: 2026-04-22
Tags: Verse, UEFN, Performance, Programming, Engineering

> Idioms, anti-patterns, and architectural choices that decide whether your Verse code hums at 30 ticks per second or chokes the moment a few players show up. Event-driven design, async discipline, and the data-flow patterns that scale.
## The performance ceiling is set by your architecture, not your loops

A common surprise for creators coming to Verse from C# or TypeScript is that the language is fast enough, the engine is fast enough, and the tick budget is generous, and yet their map still drops to single-digit frames the moment ten people join. The reason is almost never a slow function. It's an architecture that does too much work, in the wrong place, at the wrong cadence.

Verse rewards a specific style: **event-driven**, **data-oriented**, **asynchronous-first**. The idioms below are the ones we reach for when we want a UEFN map to behave the same way at one player as it does at sixteen.

## Stop polling. Subscribe.

The single biggest performance mistake in Verse code is reaching for `Sleep(0.1)` and a loop when an event already exists. A polling loop runs every tick whether anything has changed or not. An event subscription runs only when the thing you care about happens.

A polling pattern that looks innocent:

```verse
WatchPlayerHealth(Agent : agent) : void = {
    loop:
        Sleep(0.5)
        if (Player := Agent.GetFortCharacter[]):
            Health := Player.GetHealth()
            if (Health < 25.0):
                ApplyLowHealthEffect(Agent)
}
```

This burns cycles forever even when the player is at full health, and it scales linearly with the player count. The event-driven version uses `Damaged.Subscribe` and only fires when the value actually changes:

```verse
WatchPlayerHealth(Agent : agent) : void = {
    if (Player := Agent.GetFortCharacter[]):
        Player.DamagedEvent().Subscribe(OnDamaged)
}

OnDamaged(Result : damage_result) : void = {
    if (Char := damage_result.Target?, Health := Char.GetHealth(), Health < 25.0):
        ApplyLowHealthEffect(Char.GetAgent[])
}
```

The rule of thumb: **if the engine emits an event for the thing you're watching, subscribe to it.** Movement, damage, elimination, item pickup, zone enter/exit, vehicle entry, all of these have signals. Reach for `Sleep` only when you genuinely need a periodic tick (a heartbeat, a respawn timer, a wave countdown), and even then prefer the longest interval that still feels responsive.

## The cost of `spawn` and how to think about it

`spawn` is one of Verse's most powerful tools and one of its most abused. Every `spawn` allocates a coroutine, schedules it, and persists until it returns or is canceled. Spawn ten thousand of them across a session and you have ten thousand coroutines competing for tick time.

A pattern that quietly destroys performance:

```verse
OnPlayerJoined(Agent : agent) : void = {
    spawn { TrackPlayerStats(Agent) }
    spawn { TrackPlayerInventory(Agent) }
    spawn { TrackPlayerLocation(Agent) }
    spawn { TrackPlayerScore(Agent) }
    spawn { TrackPlayerCosmetics(Agent) }
    # ... ten more
}
```

Each of those is probably a polling loop in disguise. The fix is twofold: subscribe to the events instead of spawning watchers, and **batch coroutines** when you do need them. One coroutine with a `race` or `sync` block doing five things is far cheaper than five coroutines each doing one thing.

A useful mental model: a coroutine is a *task*, not a *thread*. You wouldn't spin up a thread to wait for a button press, and you shouldn't spawn a coroutine to wait for a damage event either. Reserve `spawn` for genuinely independent, long-lived asynchronous work like timed events, async network operations, or animation sequences.

## Race, sync, and the `block` you're probably not using

Verse's structured concurrency primitives (`race`, `sync`, `block`, `branch`) are how you get clean async code without ten coroutines fighting each other. The one most creators forget about is `race`, which runs multiple async operations and returns the first one that completes.

The classic use case is "wait for X, but bail out if Y happens first":

```verse
WaitForPickupOrTimeout(Pickup : item_pickup_device, Timeout : float) : logic = {
    race:
        block:
            Pickup.ItemPickedUpEvent.Await()
            return true
        block:
            Sleep(Timeout)
            return false
}
```

That single function captures what would otherwise be a tangle of state flags and polling. `sync` is its complement: run multiple async operations and wait for *all* of them. Both let you express temporal logic declaratively, which the engine can schedule far more efficiently than hand-rolled state machines.

`branch` is the one you reach for when you want fire-and-forget without blocking the parent flow. Use it sparingly, and only when the branch is genuinely independent. A branch that needs to communicate back is almost always better expressed with a `spawn` plus an explicit completion event.

## Data-oriented design: stop putting state on devices

Devices in UEFN look like nice object-oriented homes for state. They are not. Every property you read from a device incurs an engine round-trip, and many of them are surprisingly expensive. Reading transform data, fetching components, and querying device state are all measurable in a way that "it's just a getter" suggests they shouldn't be.

A pattern that surfaces in almost every map we audit:

```verse
GetPlayerTeamColor(Agent : agent) : color = {
    Devices := AllTeamColorDevices  # 16 devices, one per team
    for (Device : Devices):
        if (Device.IsAssignedToTeam[Agent]):
            return Device.GetColor()
    return DefaultColor
}
```

Called once per player per tick, this loop dominates the frame. The fix is to **build a cache once** when team assignments change and read from the cache thereafter:

```verse
var TeamColorCache : [agent]color = map{}

OnTeamAssigned(Agent : agent, Team : team) : void = {
    set TeamColorCache[Agent] = TeamColors[Team.GetTeamIndex()]
}

GetPlayerTeamColor(Agent : agent) : color = {
    if (Color := TeamColorCache[Agent]):
        return Color
    return DefaultColor
}
```

The general principle: **derive once, read often.** Anything that's expensive to compute should be computed when its inputs change and stored in a Verse-native data structure (a `map`, an `array`, a struct field). Devices are an interface to the engine, not a database. Treat them that way.

## The cost of failure

Verse's failure expressions (`if (X := ...):`, `Y[]`, `decides`) are cheap when they succeed and not free when they fail. A function declared `decides` allocates a transactional context, runs the body, and rolls back state if the body fails. That rollback is fast, but it isn't free, and code that fails-then-recovers in a tight loop is measurable.

A pattern to be aware of:

```verse
TryAddPlayerToTeam(Agent : agent, TeamId : int) : void = {
    if (Char := Agent.GetFortCharacter[], Team := AllTeams[TeamId]):
        Team.Assign(Char)
}
```

Called for every joining player, the `[TeamId]` indexing might fail, the `GetFortCharacter[]` might fail, and each failure rolls back. That's fine in normal flow. But if your code is shaped so that failures are the common case (for example, you're scanning a large array and most entries don't match), restructure so the common path is success:

```verse
# Instead of: scan everything, fail-recover-fail-recover
for (Index -> Item : Items):
    if (Item.IsActive[]):
        ProcessItem(Item)

# Prefer: filter once, iterate the active set
ActiveItems := Items.Filter(IsActiveItem)
for (Item : ActiveItems):
    ProcessItem(Item)
```

This is a small thing per call and a large thing in aggregate, especially in functions called every tick or per-player.

## Network thinking: what crosses the wire matters

UEFN is a networked engine and Verse code runs partly on the server and partly on clients. Anything that mutates replicated state crosses the network. Mutating it sixty times a second per player will saturate the connection long before it saturates the CPU.

Three rules that shape this:

1. **Batch replicated updates.** If you have ten things to change on a device, change them in one logical block. The engine coalesces tightly-grouped writes more efficiently than scattered ones.
2. **Don't replicate what doesn't need to be seen.** A score that's only used by server-side logic doesn't need to be on a replicated property. Keep it in a Verse map keyed by `agent`.
3. **Be careful with HUD and UI updates.** UI state replication is one of the heaviest paths in the engine. A debug counter that updates every tick will outweigh real gameplay logic on the network bill. Update at the slowest cadence the UX tolerates: most "real-time" displays are perfectly fine at 4–10 Hz.

## Profile, don't guess

Verse and UEFN expose enough instrumentation that you don't need to guess where time is going. The in-editor profiler will surface hot devices, hot Verse functions, and net-replication spikes. A workflow that works:

1. Build the system the obvious way first. Don't pre-optimize.
2. Run a 16-player session in the editor or on a private session.
3. Open the profiler and look for *outliers*: a function that's 5x the average, a device call that fires 100x per frame, a tick frame that's 3x the surrounding ones.
4. Optimize the outliers, not the averages. A 200ms spike every five seconds is more noticeable to players than a uniform 8ms tick.
5. Re-profile. Performance work without measurement is performance theater.

A common surprise: the slowest part of your map is rarely the part you spent the most time writing. It's almost always a quietly-added watcher loop, a forgotten `Sleep(0)` polling pattern, or a debug log that's still running in production. The profiler will find them in five minutes; reasoning won't find them in five hours.

## Checklist for a map that scales

- [ ] No polling loops where an event subscription would work.
- [ ] `spawn` count per player is bounded and small.
- [ ] All hot per-tick lookups are cached, not derived.
- [ ] Common-path code uses success-shaped flow, not failure recovery.
- [ ] Replicated state updates are batched and rate-limited.
- [ ] Profiler has been run with a realistic player count, not just a solo session.
- [ ] HUD and UI update at the slowest cadence the UX tolerates.
- [ ] No debug logs or counters left running in published builds.

If those eight items are clean, your map will hold its tick rate when it matters. The rest of the work (the Verse code that makes your design *feel* right) gets to spend its budget on gameplay, not on fighting an architecture problem.

Performance in UEFN isn't about fast functions. It's about doing less work, doing it once, and doing it only when something actually changed. Build the architecture with that in mind from day one and you almost never end up in the late-stage scramble to claw back tick time before launch.

## Related reading

- Writing your very first Verse script? [Day Three: Your first Verse script (for people who have never coded)](/blog/newcomer-day-three-verse) is the gentlest possible on-ramp.
- Definitions for [Verse](/glossary#verse), [transactional memory](/glossary#transactional-memory), [creative_device](/glossary#creative-device), [decides](/glossary#decides), and [transacts](/glossary#transacts) live in the [Mapwright glossary](/glossary).
- The patterns here protect tick rate; the [retention engineering guide](/blog/uefn-retention-engineering) and the [economy field guide](/blog/uefn-economy-guide) decide what to spend that tick rate on.
- Run high-load Verse against synthetic sessions in the [Mapwright simulator](/studio) before you ship.

----

# Day Two: Devices, Events, and the Language of UEFN Logic

Source: https://mapwright.app/blog/newcomer-day-two-devices
Author: The Mapwright Team
Date: 2026-04-21
Tags: First Steps, Newcomer, Beginner, Getting Started, UEFN, Devices, Tutorial

> The mental model that makes UEFN click: every island is just devices listening for events and reacting. Once you see the pattern, the device library stops feeling overwhelming and starts feeling like a kit.
## The thing nobody tells you on day one

Most new UEFN creators bounce off the device library because it looks endless. There are hundreds of devices. The official docs treat each one as a self-contained chapter. After an hour of scrolling, the inevitable feeling is "I will never learn all of these." That feeling is correct, and it does not matter. You do not need to learn them all.

Instead, you need to internalize one mental model. Once you have it, every device looks like a small variation on the same theme, and learning a new device takes minutes instead of an afternoon.

The model is this: **a device is a small machine. It has options that configure how it behaves, events it can emit when interesting things happen, and functions it can run when something tells it to.** That is it. Once you can see every device as the triple of *(options, events, functions)*, the library becomes a parts catalog instead of a textbook.

This post is the day-two follow-up to [Day One: From Empty Editor to a Playable Island](/blog/newcomer-day-one-uefn). If you have not done day one yet, do that first. The rest of this post assumes you have placed a Player Spawner, walked through a trigger, and pushed a build.

## The (options, events, functions) triple

Pick any device and you will find these three sections in its Details panel.

**Options** are the device's configuration. Things like "how long is the cooldown," "which team can use this," "what text does the billboard display." These are knobs you set in the editor. They do not change at runtime unless something explicitly changes them.

**Events** are the things this device can announce. A trigger device emits a "triggered" event when a player crosses it. A timer device emits "completed" when its time runs out. A button device emits "interacted" when a player presses E on it. Events are how a device says "something happened to me." Other devices (or Verse code) listen for events and react.

**Functions** are the things you can ask this device to do. The billboard has a Show function and a Hide function. A timer has Start, Pause, and Reset. An item granter has Grant. Functions are how you tell a device "do this thing now."

When you wire two devices together in the editor, you are saying "when **this device's event** fires, call **that device's function**." That is the entire idea of UEFN logic. Every island, no matter how complex, is a graph of devices passing events to each other and calling each other's functions.

## A worked example: a tiny scoring loop

Let's build the smallest possible loop that demonstrates the pattern. The loop is: a player presses a button, gets a point, and the score updates on a sign.

You will need three devices in your level:

1. A **Button Device** the player can interact with.
2. A **Score Manager Device** that tracks a numeric score.
3. A **Billboard Device** that displays text.

Wire them like this. Select the Button. In its Details panel, find the event that fires when a player interacts with it (commonly called something like "Player Interacted"). Set its target device to the Score Manager and its function to "Increment Score" (or the equivalent). Now whenever a player presses the button, the score goes up by one.

To display the score, use the Score Manager's events. It exposes events that fire when the score changes. Wire that event to the Billboard's "Set Text" function. The billboard now updates whenever the score changes.

Push a build, walk to the button, hit E. Your score goes up and the sign refreshes. You just shipped a feedback loop.

Notice that nothing in this loop required code. It is three devices, each contributing one of (options, events, functions), wired into a small machine. Nearly every gameplay system you can imagine is some variation on this pattern.

## Why events beat polling

A reasonable instinct, if you come from a programming background, is to wonder why we do not just have a "tick every frame and check the button" loop somewhere. The answer is performance and clarity.

Events are *push*. The device tells you when something happened. Polling is *pull*. You repeatedly ask "did something happen?" Push scales much better, especially with thousands of devices and players. It is also clearer to read. A wiring graph that says "button triggers score increment" is easier to reason about than "every frame, check every button to see if it was pressed."

Verse can break out of this model when you genuinely need to (more on that in [Day Three: Your first Verse script](/blog/newcomer-day-three-verse)). For now, lean hard on events. Most things you want to do already have an event for them.

## How to learn a device in five minutes

Every time you encounter a new device, run this exact playbook. It will save you hours over your first month.

**Drag it into a level.** Even if you have no idea what it does, get it into a level so you can poke at it.

**Open its Details panel and scroll the Options section.** Every option is labeled and most are documented inline. Even without reading the docs, you can tell from option names what the device is *for*. A device whose options include "Win Condition" and "Round Length" is clearly a round manager.

**Scroll to its Events section.** What does this device announce? An item granter that emits "Item Granted" is telling you it can be a *source* for other reactions. A class designer that emits "On Class Changed" is telling you you can build perks that react to class changes.

**Scroll to its Functions section.** What can other things ask this device to do? A teleporter has "Teleport Here" and "Teleport Player." Now you know it is a *destination* and a *trigger*.

**Wire the smallest possible test.** Hook one of its events into a billboard's "Show" function, with the billboard text set to something obvious like "fired!" Push a build. Trigger the event. If the billboard fires, you understand the device.

This loop generalizes. After ten devices, you will start seeing patterns. Anything called a "manager" is usually a coordinator with a lot of state. Anything called a "device" with options for "team" and "class" is usually a per-team rule applier. Anything that emits "On Player X" events is a source you can build a meta loop around.

## Common day-two mistakes (and the easy fixes)

A few patterns trip up almost every new creator. Recognize them now and you will skip a month of frustration.

**Wiring the wrong direction.** Events go *from* a device, functions are called *on* a device. If your trigger does not seem to be firing, check that you have the trigger emitting an event, not the other way around. Editor tooling makes this easy to flip by accident.

**Forgetting that devices need to be *enabled*.** Many devices have an "Enabled" option that defaults to true but can be toggled off. If a device is off, none of its events fire and none of its functions do anything. When something is mysteriously dead, check Enabled.

**Confusing a device's *visibility* with its *aliveness*.** Setting a billboard's "Show" or "Hide" affects whether players see it. It does not turn the device off. Conversely, disabling a device does not necessarily hide it. These are two separate axes.

**Putting too many devices in one level too early.** Day-two creators want to test ideas, and the right move is to keep your test island sparse. Two devices and a single wired event is a better learning environment than fifty devices in a half-built castle.

## What to read next

You now understand the *(options, events, functions)* triple, which is the deepest model in UEFN. Next steps:

- [Day Three: Your first Verse script](/blog/newcomer-day-three-verse) takes the same patient approach to your first Verse code. Verse becomes much easier to learn once you understand devices.
- Browse the [glossary](/glossary), especially the entries for [creative_device](/glossary#creative-device), [OnBegin](/glossary#onbegin), and [Verse](/glossary#verse). Those three terms will land cleanly on day three.
- When you are ready to think about *what kinds of games* this pattern lets you build, skim our [retention engineering guide](/blog/uefn-retention-engineering). Even as a newcomer, knowing what makes a Discover-friendly loop will sharpen your taste.

You have the model. Now place a few more devices, wire them up, and let your fingers learn what your head already understands.

----

# Day One in UEFN: From Empty Editor to a Playable Island

Source: https://mapwright.app/blog/newcomer-day-one-uefn
Author: The Mapwright Team
Date: 2026-04-20
Tags: First Steps, Newcomer, Beginner, Getting Started, UEFN, Tutorial

> A friendly, no-shortcut walkthrough for your first day in Unreal Editor for Fortnite. Install, open a project, place a few devices, push a build, and stand inside your own island in under an hour.
## Welcome. You are about to make a Fortnite island.

This is the post we wish we had handed to ourselves on day one. No jargon avalanche, no skipped steps, no "as you can see in the screenshot" without a screenshot. Just the path from "I downloaded UEFN" to "I am standing inside my own island in Fortnite, and a friend can join me." Most of you can finish this in under an hour.

If you are coming in totally cold, here is the shape of what you are about to learn:

1. Install the editor and sign in with the right kind of Epic account.
2. Open a starter project and learn the four panels you will actually use.
3. Place two devices and connect them so something happens when a player walks into a trigger.
4. Push a build to Fortnite and join your own island as a real player.

That is it for day one. Combat, Verse code, art polish, and economy design all come later. The only goal today is the loop of *change something, push it, see it in-game, change it again*. Once that loop is comfortable, everything else is just learning more devices.

Through the rest of this post we will lean on a few terms. If anything looks foreign, the [Mapwright glossary](/glossary) has plain-English definitions for every word in italics or backticks.

## Step 1. Install Unreal Editor for Fortnite

UEFN runs through the Epic Games Launcher. You probably already have it if you play Fortnite. If not, install it from epicgames.com and sign in with the same Epic account you play Fortnite on. Two-factor authentication needs to be enabled before Epic will let you publish anything, so turn that on now. It saves a real headache later.

In the launcher's top-row tabs you will see "Unreal Engine." Click that, then "Library," then the small "+" next to "Engine Versions" and pick the latest UEFN release. Install it. The download is large (think tens of gigabytes) so this is a great moment to grab a snack. While it installs, also check that your Fortnite client is up to date in the launcher's Fortnite tab, because UEFN and Fortnite need to be on the same major version for your builds to work.

When UEFN finishes installing, launch it. You will see a project picker. Do not start with a "blank" project for your very first session. Pick **Blank Island** from the templates instead. Blank Island gives you a tiny piece of ground to stand on with the right project settings already configured for Fortnite, which removes a class of "why does nothing work" problems that blank UE projects can have.

Name your project something memorable. You will see this name in the editor, in your file system, and on disk for years. We like the format `firstname-projectname`, like `riley-trial-island`, because it sorts well and stays unique when you have a dozen of them.

## Step 2. Learn the four panels you actually need

UEFN has a lot of panels. On day one, you only need four. Find them and ignore the rest until they become relevant.

**Viewport.** The big 3D window in the middle. This is where you fly the camera around with right-click + WASD, just like in any 3D editor. Hold right-click and roll the mouse wheel to change fly speed. If your camera is whipping across the world like a fighter jet, drop your fly speed.

**Outliner.** The list of every actor in the level (top right by default). Every device, mesh, light, and player spawner that exists in the world is in this list. When you cannot find something in the viewport, find it here, double-click it, and the camera will fly to it.

**Details.** Right below the Outliner. Whatever you have selected, this panel shows you its options. Devices in particular have entire forests of options here. You will spend a lot of time in this panel.

**Content Browser.** The dock at the bottom. Everything that exists *on disk* in your project (assets, devices, materials, blueprints, Verse files) lives here. The Content Browser has a search bar at the top. When in doubt, type what you want.

If any of those four panels are not visible, the **Window** menu in the top menu bar will let you re-enable them. Layouts can be reset under **Window > Load Layout > Default Editor Layout**.

## Step 3. Place a Player Spawner

Before you can play your island, you need at least one **player spawner**. Without one, Fortnite cannot decide where to drop you in.

In the Content Browser, search "Player Spawner Device." Drag one into the viewport. Drop it on top of the floor of Blank Island. You should see a small icon for it.

Press the **Launch Session** button at the top of the editor (it looks like a play icon and is labeled "Launch Session" or similar in the toolbar). UEFN will spin up a local Fortnite session and put you on your island. Walk around. You are now standing on something you made. We promise this feeling does not get old.

Hit Escape and choose to leave the session, which returns you to the editor.

## Step 4. Make something happen

A static piece of ground is not a game. Let's make a device react to the player.

Drag a **Trigger Device** from the Content Browser into the level. Place it somewhere visible. Then drag a **Billboard Device** into the level a few meters away. The Billboard is a simple sign that displays text to nearby players.

Now wire them. Select the Trigger. In its Details panel, find the section called **Functions** or **User Options** (it has changed names across UEFN versions; both refer to the same idea). Look for a setting called **Triggered Event** or similar. There you can pick a target device and a function on it. Pick the Billboard, and pick the Show or Display function.

What you have just done in plain English is: "When a player crosses this trigger, tell the billboard to show its text." Edit the Billboard's text in its Details panel to say "Hello, island." Launch the session again. Walk into the trigger. The billboard shows your message.

This pattern, *one device emits an event, another device reacts to it*, is the entire foundation of UEFN. Verse adds power and expression on top of this, but you can ship surprisingly fun islands using only stock devices wired together this way.

## Step 5. Push a build to Fortnite and play it for real

Local launches are great for iteration but they only run on your machine. Pushing a real build is what gets your island a real island code that real Fortnite players (or your friends in another room) can join.

In the editor's top toolbar, there is a button called **Launch Session** for local play and a separate menu, often labeled **Project**, for build-and-publish actions. Inside that menu look for **Build & Submit** (the exact label has shifted across UEFN releases; the action is the same). UEFN will:

1. Cook all your project assets into the format Fortnite needs.
2. Compile any Verse code (we have not written any yet, so there is nothing to compile).
3. Upload the build to Epic and associate it with your island.
4. Hand you back an island code.

The first build is slow. Subsequent builds are much faster because the editor caches a lot of intermediate work. While it builds, you have time to read the [Mapwright Studio overview](/studio) and decide whether you want a faster Verse iteration loop later.

When the build finishes, copy the island code, open Fortnite, go to **Discover** in the lobby, paste the code into the search bar, and join. Welcome to your own published island.

## What you should do next

Day one is intentionally narrow. The win is the loop, not the content. Here are the three best places to spend day two through five, in order:

- Read [Day Two: Devices, events, and the language of UEFN logic](/blog/newcomer-day-two-devices). It explains the device-and-event mental model in real depth, which will pay dividends every day after.
- Skim our [field guide to UEFN economies](/blog/uefn-economy-guide). You do not need an economy yet, but skimming it now plants vocabulary that will save you later when your island has currency or progression.
- Bookmark the [glossary](/glossary). Every word that confuses you on day two is probably in there with a plain-English definition.

When you are ready to write your first line of Verse, [Day Three: Your first Verse script](/blog/newcomer-day-three-verse) will walk you through it the same way this post walked you through the editor.

## A small word on patience

UEFN is one of the more capable creation environments in any consumer product, and capability comes with a learning curve. The thing that separates the creators who ship from the ones who do not is almost never raw skill. It is the willingness to make small things, finish them, and learn from each one.

You finished day one. That is not a small thing. Tomorrow, finish day two.

----

# Retention Engineering for UEFN: The Metrics That Actually Predict a Map's Future

Source: https://mapwright.app/blog/uefn-retention-engineering
Author: The Mapwright Team
Date: 2026-04-18
Tags: UEFN, Game Design, Retention, Analytics, Creator Economy

> D1, D7, and D30 retention are the only numbers that matter for whether a UEFN map compounds or evaporates. A guide to measuring them honestly, the design patterns that move them, and the traps that look like wins on day one and burn you out by month two.
## The compound-interest math of retention

Most UEFN creators look at their concurrent player count and feel things. The number is up, things are good. The number is down, things are bad. This is a deeply unhelpful way to manage a map, because concurrents tell you what happened *yesterday* without telling you what's going to happen tomorrow.

The numbers that predict tomorrow are **D1, D7, and D30 retention**: the percentage of players from a given day's cohort who come back one day, seven days, and thirty days later. They're useful for the same reason compound-interest math is useful: small differences in the rate produce massive differences in the outcome over time.

Two maps launched on the same day with the same first-day acquisition. Map A has D1=35%, D7=14%, D30=6%. Map B has D1=42%, D7=20%, D30=10%. By month three, Map B has roughly 3–4x the active players of Map A even though Map A had more first-time downloads in week one. Retention is the only metric that compounds, and it's the one that decides whether you have a hit or a flash.

## What "good" looks like for UEFN

Benchmarks vary by genre, but for the kind of session-based creator content that dominates UEFN's Discover row, the bands we use as a working baseline are:

- **D1**: 30% is the threshold of viable. 40% is good. 50%+ is exceptional and usually means the map has either a daily mechanic or genuine social pull.
- **D7**: 12% is viable. 18–22% is good. 25%+ is the territory where the map will keep growing organically.
- **D30**: 5% is viable. 8–10% is good. 12%+ is a long-tail hit, the kind of map that's still in your top-five months later.

Two important caveats. First, these numbers depend heavily on how players got to the map. Algorithmic placements in Discover bring in players with weak intent and depress D1 relative to direct shares from a creator's audience. Second, the *shape* of the curve matters as much as the absolute numbers: a map with 40% D1 falling to 8% D7 is in trouble, while a map with 32% D1 holding 14% D7 is healthier even though the first number is lower. The drop from D1 to D7 is the early signal of whether your map has a *reason to come back* baked into it.

## The mechanics that move D1

D1 is overwhelmingly a function of **first-session quality**. A player who had a satisfying, complete experience on day one is dramatically more likely to come back tomorrow. Three patterns reliably move D1:

**A complete arc inside the first session.** The player should finish *something*: a round, a chapter, a quest, an unlock. The shape of "I played, I did the thing, I saw the result" is what creates the memory the player draws on when they decide whether to come back. Open-ended sandboxes with no first-session payoff have a measurable D1 penalty.

**A visible promise for tomorrow.** Before the player leaves, they should see the thing they could come back for. A daily reward they haven't claimed yet, an unlock that's two purchases away, a leaderboard tier they're close to crossing. The visible promise is what converts the *experience* of today into the *intention* of tomorrow.

**Friction-free re-entry.** When the player does come back, they shouldn't have to re-learn the loop. A clear "continue where you left off" path, a session-resumed UI state, and a quick on-ramp into the same activity they enjoyed yesterday will all reliably move D1 by 3–7 percentage points. The number of players who churn because day-two felt like starting over is much higher than most creators realize.

What doesn't reliably move D1: the things that feel obvious. Gorgeous art, complex mechanics, deep customization. These move D7 and D30, because they're rewards for engagement that already exists. They don't manufacture engagement on day one.

## The mechanics that move D7

D7 is where **content cadence** starts to matter. A player on day seven has already decided your loop is fun. The question is whether there's enough *new* in your map to justify the eighth session.

The pattern that works most consistently is what we call **layered novelty**: a small new thing every session, a medium new thing every few sessions, and a large new thing on a weekly rhythm. Concretely:

- **Every session**: a randomized event, a rotating challenge, or a procedural variant. Even a small twist is enough to make the loop feel fresh.
- **Every 3–5 sessions**: a meaningful unlock the player has been working toward. Crossing a tier, opening a new area, hitting a milestone.
- **Every week**: a noticeable content beat. A new mode for the weekend, a seasonal event, a community challenge with a shared goal.

The week-cadence beat is the most important and the most under-built. The reason is that humans have weekly rituals, and a map with a weekly beat slots into the player's week the way a TV show used to. A player who knows that "Friday is bonus weekend" or "Tuesday a new challenge drops" has a *scheduled* return, which is dramatically stickier than a hopeful one.

What kills D7: a loop that feels identical session to session, no new visible goal between session three and session ten, and a meta-progression curve so flat that the player can't see themselves improving.

## The mechanics that move D30

D30 is where **identity and social** dominate. A player who's still around at day thirty has either built an identity inside your map (a collection, a rank, a build, a presence) or has built a social hook (friends they play with, a community they're part of). The mechanics that move D30 are the ones that strengthen one of those two pulls.

**Identity-strengthening mechanics**:

- A long, slow cosmetic progression that never quite ends. The player who's been chasing a prestige skin for three weeks is not going anywhere.
- A persistent, visible profile: title, banner, badge, lifetime stats. The more the map reflects the player's history back to them, the more invested they become.
- Earned, not bought, status. A leaderboard tier, a streak count, a hard-won unlock. Status that costs money has weak retention pull; status that costs effort has strong pull.

**Social-strengthening mechanics**:

- A party-friendly loop. Maps where playing with friends is *clearly* better than playing solo retain dramatically harder. A group bonus, a duo mode, a co-op objective will do real work.
- Asynchronous social signals. A friend's score on the leaderboard, a clan ranking, a leaderboard you can compare yourself against. Players don't need to be online together to feel they're in something together.
- A gentle community layer. A weekly community goal, a shared event, a noticeable presence from the creator. Players who feel they belong to a community of players around your map churn slower than players who feel they're playing alone.

What kills D30: catalogs that finish, identity systems that plateau, and loops that feel solitary. If a player has nothing left to chase, no identity to grow, and no social pull keeping them in your orbit, they will leave even if your loop is excellent.

## The metrics that mislead

Several numbers feel meaningful and are actively dangerous to optimize for. A short tour:

- **Total downloads** is a vanity number. Two maps with the same downloads can have completely different futures depending on retention.
- **Average session length** is misleading because it averages two distinct populations: people who bounce in 30 seconds and people who play for 90 minutes. The shape of the distribution matters more than the mean. Look at *median* session length and the *bounce rate* separately.
- **Concurrent players** is a lagging indicator at best. By the time concurrents drop, the cohort behavior that caused the drop happened a week ago.
- **Total revenue per day** is a proxy that bundles too many things. Revenue per active player and revenue per cohort are far more useful when you're trying to understand whether a change worked.

The general rule: **prefer cohort metrics over aggregate metrics**. An aggregate number tells you what the population is doing; a cohort number tells you what a *change* did. When you ship a tweak, the right way to evaluate it is to compare the cohort that joined after the tweak to the cohort that joined before. Anything else is interpretation looking for evidence.

## A retention diagnostic you can run today

If you have a live UEFN map and you want to know where your retention is bleeding, run this diagnostic before you change anything:

1. Pull D1, D7, D30 for the last six weeks of cohorts. Look at the trend, not just the latest number. A flat or rising trend is healthy; a steady decline is the most important signal you can have.
2. Compare D1 across acquisition sources. Players from Discover algorithmic placements should have lower D1 than players from creator shares; if they're roughly the same, you have either an unusually compelling first session or an unusually weak creator funnel.
3. Look at the **return-day distribution**. Of players who came back, when did they come back? A heavy spike on day one and almost nothing after means your map feels disposable. A more even distribution across the week means it's slotting into players' lives.
4. Pull the **content-engagement rate** for any new feature you've shipped in the last month. If less than 30% of active players have touched it, the feature isn't pulling weight regardless of what your gut says about it.

That diagnostic alone will tell you whether your retention problem is a *first-session* problem (D1 too low), a *novelty* problem (D1 healthy but D7 collapses), or an *identity/social* problem (D7 holds but D30 leaks). The fix for each is structurally different, and conflating them is one of the most expensive mistakes a creator can make.

## A short list of things that quietly destroy retention

Some of these are non-obvious. All of them we've seen flatten otherwise-promising maps.

- **Onboarding that's too long.** If the player isn't doing the core loop in the first two minutes, you'll lose half of them before they reach it.
- **Catalogs that finish.** If a player can complete every cosmetic and unlock in two weeks, they will leave in two and a half.
- **Daily rewards that punish absence.** A streak that resets to zero after one missed day causes lapsed players to give up entirely. Soft-decay (the streak weakens but doesn't reset) reliably out-retains hard-reset.
- **A meta-game that requires a guide.** If players need to read a wiki to understand your map, the median player will not.
- **Pay-to-progress.** A Fortnite audience is unusually allergic to it, and even subtle pay-to-progress mechanics (a paid speed boost, a paid currency sink) measurably depress D7 and D30.
- **Silence from the creator.** Maps where the creator visibly cares (notes, updates, community shoutouts) retain measurably better than identical maps from creators who go quiet after launch.

None of these will show up in a single playtest. All of them will show up in a six-week retention chart. The advantage of measuring is that you can act on them before the retention chart is the thing telling you.

## Retention is the only number that lets you plan

Concurrent players is a number you react to. Retention is a number you plan with. A map with healthy D7 and D30 will compound: every cohort you bring in adds a long tail of returning players, and your active base grows faster than your acquisition cost. A map with weak retention is a treadmill: you have to find new players forever just to stay even, and the moment you stop pushing acquisition, the active base evaporates.

The creators whose maps stay in the top of Discover for months at a time are not the ones with the most aggressive marketing. They're the ones whose retention curves let their early audience compound into a much larger long-term audience. That's it. That's the whole formula. Build a map a player wants to come back to tomorrow, give them a reason to come back next week, and give them an identity to grow over the next month. Measure all three, honestly, and act on what the numbers tell you.

The math of compounding does the rest.

## Related reading

- Just getting started? [Day One: From empty editor to a playable island](/blog/newcomer-day-one-uefn) and the [Make Your First Map weekend series](/blog/teen-make-your-first-map-part-one) are the gentlest paths into UEFN.
- The vocabulary in this post ([Discover](/glossary#discover), [retention](/glossary#retention), [session length](/glossary#session-length), [engagement payout](/glossary#engagement-payout)) is collected in the [Mapwright glossary](/glossary).
- For the systems that drive return ([sources](/glossary#source), [sinks](/glossary#sink), [currency](/glossary#currency)), the [UEFN economy field guide](/blog/uefn-economy-guide) is the deeper dive.
- For the launch motion that gives a high-retention map a shot at the algorithm, see the [Discover publishing guide](/blog/fortnite-discover-publishing).
- Pressure-test your loop with synthetic cohorts in the [Mapwright Studio](/studio) before you ship.

----

# Publishing on Fortnite: How Discover, Featured Rows, and Algorithmic Reach Actually Work

Source: https://mapwright.app/blog/fortnite-discover-publishing
Author: The Mapwright Team
Date: 2026-04-14
Tags: UEFN, Creator Economy, Publishing, Discover, Algorithm

> A grounded look at how players actually find UEFN maps: the Discover surface, the algorithmic signals that move you up and down, the role of editorial featuring, and what creators can and can't control. Plus the publishing-day playbook that consistently outperforms the launch-and-pray pattern.
## Discoverability is its own discipline

You can build the best UEFN map of the year and still see almost no players if your publishing strategy is "ship and hope." Fortnite's Discover surface is a fast-moving, signal-heavy ranking system that rewards specific behaviors and punishes others, and the difference between a map that shows up on the front row and a map that doesn't is rarely the quality of the map itself. It's the shape of the cohort that played it in the first 72 hours.

This is a guide to how the surface actually works, what we know (and don't know) about the ranking signals, and the publishing-day patterns that consistently outperform the alternatives.

## What "Discover" actually is

Discover is the primary entry point into UEFN content for most Fortnite players. It's a stack of horizontal rows, each with its own logic: some are algorithmic ("For You," "Trending"), some are categorical ("Action," "Adventure," "Party Royale"), some are editorial ("Featured," seasonal events, partner highlights), and some are persistent surface placements (top-of-screen banners, carousel rotations).

The crucial distinction for a creator is between **algorithmic placement** and **editorial placement**. Algorithmic placement is something you earn by performing well on signals the system can measure. Editorial placement is something Epic decides to give you, often based on inputs the algorithm doesn't see (production polish, brand fit, partnership context, narrative significance). They behave very differently and the strategies for getting each are almost entirely separate.

If you're a creator without an editorial relationship, your entire job is to optimize for algorithmic placement. The good news is that the algorithm is more knowable than people assume.

## The signals that move algorithmic placement

Epic does not publish the ranking model, but the signals it pays attention to are observable in aggregate. Based on what consistently moves maps up and down across thousands of cohorts, the model is almost certainly weighting some combination of:

**Click-through rate from impression.** A player sees your map's tile in a row. Do they click it? CTR is the cheapest, fastest signal in the system, and it's the gating factor for almost every other surface. A map with weak CTR will not get the impressions to prove out its retention or session-length numbers, regardless of how good those would be.

**First-session completion rate.** A player who clicks in, plays for less than 60 seconds, and bails is a strong negative signal. A player who clicks in and plays a full round is a strong positive signal. This is the signal the algorithm uses to filter out maps with great tiles and weak first sessions.

**Median session length.** Total time spent is a vanity number; the median session length is the one the system seems to weight. A map where the median session is 25 minutes will outrank a map where the median is 4 minutes even if the latter has higher concurrents, because the long-session map is producing more *engagement per impression*.

**Returning-player rate.** Recall the previous post: D1 retention is the strongest predictor of a map's long-term shape. The algorithm seems to know this and weights returning-player rate heavily. A map that gets 15% of its day-one cohort back on day two is treated very differently from one that gets 5%.

**Reporting and abandonment.** Maps that are flagged, that have unusually high quit-out rates, or that show patterns consistent with low-quality content are demoted hard and fast. This is a one-way ratchet; once a map is in the demotion bucket, climbing back out is structurally difficult.

**Cohort momentum.** New maps with growing daily-active counts get extra impressions for free. The algorithm has a clear bias toward "things that are picking up steam," which is part of why the first 72 hours of a launch matter so disproportionately.

What the algorithm almost certainly does *not* directly weight: production budget, creator follower count off-platform, marketing spend, social-media reach. These influence the algorithm only through their effect on the signals above (more shares produce more impressions, which produce CTR data, which produces ranking).

## The first 72 hours decide most of what happens

Almost every successful UEFN map can be traced back to a strong opening 72 hours. The reason is structural: the algorithm needs cohort data to evaluate a new map, the early cohorts disproportionately shape the model's view of the map, and the maps that win their first three days enter a feedback loop where success generates impressions that generate more success.

This means **publishing day is not a release event, it's an optimization window**. You're not just turning the lights on; you're producing the data that the algorithm will use to decide your map's ceiling for the next month.

A few patterns that consistently work:

**Land your launch with a concentrated push.** A diffuse trickle of players over the first week produces weak per-day cohorts that the algorithm reads as "low momentum." A concentrated push that brings in a strong wave of players in the first 24–48 hours produces the cohort-momentum signal you actually want. This usually means lining up creator shares, social posts, and any community channels you have to fire on day one or day two, not spread across the week.

**Play to your strongest acquisition source first.** If you have a creator audience, that's your strongest source: those players have the highest intent and will deliver the best D1 numbers, which seeds the algorithm with positive data. Algorithmic acquisition (random placements in Discover) brings in players with weak intent and depresses your early metrics, which is exactly what you don't want during the optimization window.

**Watch the first-session metrics like a hawk.** If you can see that first-session completion is below where you expected, fix it immediately. A patch that improves the first 60 seconds of the experience inside the first 72 hours can dramatically reshape the algorithmic curve. The same patch shipped a week later, after the algorithm has already decided what your map is, has a much smaller effect.

**Resist the urge to ship fixes that change the loop in the middle of the launch window.** This is counterintuitive but important: substantial gameplay changes in days two and three of a launch reset the cohort-comparison signals the algorithm is using and can cause your map to drop placements while the system re-evaluates. Save large changes for after the initial window stabilizes (typically around day 5–7).

## Tiles, names, and the click-through battle

Your tile is the part of your map that 100x more players will see than will ever play. CTR is the gating factor for almost everything downstream, so the tile and name are not afterthoughts; they're the most-leveraged single piece of work in the entire publishing process.

What works for tiles, in our experience:

- **One clear focal subject.** Multiple competing focal points read as visual noise at thumbnail size. Pick one and let it dominate.
- **Strong contrast and brand-distinct color.** Tiles that blend into the row's background lose impressions. Tiles with a bold, saturated, brand-distinct color stand out even when they're 80 pixels wide.
- **Faces, characters, and clear human subjects** outperform abstract or environment-only tiles, almost universally. The exception is brand-recognized environments (a familiar IP location), but unless you're working with a known IP, lead with character.
- **Tile text only when essential.** If your name communicates the mode clearly, tile text is wasted space. If your name is abstract, a one-word tile label can help. Three-word tile labels almost never help.

For names: short, memorable, and unambiguous wins. A name that immediately tells the player "this is the kind of map I want right now" will out-CTR a more clever or thematic name 9 times out of 10. Save the cleverness for the description.

## Editorial featuring: how to actually get it

Editorial featuring is the other half of discoverability and it works on completely different inputs from the algorithm. Editorial decisions are made by humans at Epic looking at the *pipeline of upcoming and recent content*, weighing things like production polish, freshness, partner relevance, and ecosystem fit. The signals that move editorial are:

- **Polish that survives a quick play.** An editor's spot-check of your map needs to land. Janky onboarding, broken systems, or visible bugs in the first three minutes will disqualify you regardless of how strong the rest is.
- **A clear pitch.** Your map should be summarizable in one sentence. "Co-op heist with a heat mechanic and a getaway phase." If the pitch takes a paragraph, the map is harder to feature because it's harder to slot into a row's narrative.
- **Timing and freshness.** Maps that align with seasonal events, ecosystem moments, or current Fortnite themes get featured more often. Plan launches around events when the calendar lets you.
- **A track record.** Creators who have shipped consistently and built a body of work are more likely to be featured because the editorial team has more confidence the next thing will land. If this is your first published map, the bar is higher; if it's your fifth competent one, the bar is meaningfully lower.
- **Direct outreach, done well.** Reaching out to Epic creator-relations channels with a clear pitch, a short clip, and a launch date well in advance puts you on the radar in a way that publishing into the void doesn't. Don't expect a response on every outreach; do expect that the cumulative effect of consistent, professional outreach builds awareness over time.

A common misconception: that featuring is the goal. It isn't. Featuring is a *boost*, not a foundation. A featured map with weak retention will burn through its boost in 48 hours and end up worse off than an unfeatured map with strong retention, because the boost cohort produces poor signals at scale and the algorithm pulls back hard. Build the foundation first; treat featuring as a multiplier on a foundation that already works.

## What creators control vs. what they don't

A useful framing: there are roughly three buckets of things in publishing on UEFN.

**Things you fully control**: the map, the tile, the name, the description, the gameplay loop, the first-session experience, the catalog depth, the publish timing, your creator audience activation. This is most of the work, and it's where the most leverage is.

**Things you influence**: the cohort that comes in (through which channels you light up), the early retention numbers (through how good the first session is), the social-share rate (through how shareable your moments are). You can move all of these, but the magnitude depends partly on factors outside your control.

**Things you don't control**: the algorithm's exact weights, what other maps launch the same day, the editorial team's roadmap, seasonal calendar shifts in player behavior, large-scale Fortnite ecosystem events that change attention. These will affect your numbers and there's not much to do about them other than time launches around the calendar and accept that some weeks are softer than others.

The trap is to let things in the third bucket dominate your mental model of why a map did or didn't perform. They matter at the margin; they don't decide the outcome. The first bucket decides 80% of the outcome and that's where every hour of effort returns the most.

## A publishing-day checklist that consistently works

- [ ] Tile and name pass a 80-pixel-thumbnail readability test.
- [ ] First 60 seconds of gameplay tested with at least three players who haven't seen the map before.
- [ ] First-session arc is concrete and completable in under 25 minutes.
- [ ] Daily reward, returning-session bonus, and streak mechanic are live on day one.
- [ ] Creator audience activation lined up to hit on day one or day two, not spread across the week.
- [ ] Social-share moments are visually distinct and clip-friendly.
- [ ] Bug-bash session done within 48 hours of publish; only critical fixes shipped during the launch window.
- [ ] Retention dashboard set up *before* launch so you're not building it under launch-day pressure.
- [ ] Plan for the post-launch week: what the first content beat is, when it ships, how you'll communicate it to returning players.

If those nine items are clean, you've done the foundational work that most launches skip. The map will get a fair shot at the algorithm, the algorithm will read the early signals correctly, and the rest of the discoverability story will follow from how good the map actually is.

Discoverability isn't a black box. It's a feedback system with knowable inputs and a strong bias toward maps that produce the right signals in their first three days. Build for that, measure what you can, and you'll find that "the algorithm" stops being a mystery and starts being a tool you can actually work with.

## Related reading

- About to publish your first map? [Make Your First Fortnite Map (Part 3): Ship It and Read the Numbers](/blog/teen-make-your-first-map-part-three) walks through the publish flow and the metrics worth watching in week one.
- New to UEFN? Start with [Day One: From empty editor to a playable island](/blog/newcomer-day-one-uefn).
- The [Mapwright glossary](/glossary) defines [Discover](/glossary#discover), [island code](/glossary#island-code), [engagement payout](/glossary#engagement-payout), and the rest of the surface vocabulary used here.
- Pair this with the [retention engineering guide](/blog/uefn-retention-engineering) and the [UEFN economy field guide](/blog/uefn-economy-guide) for the deeper systems work that decides whether a launch keeps its lift.