Discovery moments are shown after a player checks in at a stop. They can be used to reveal story information, provide instructions, display a sponsor offer, show an image, explain what to do next, celebrate arrival, or add flavor to the location. In customized and created Hunts, Discovery content is one of the most important ways to make a stop feel intentional rather than just a point on a map. Discovery content is a powerful place to make the stop feel rewarding. It can tell players what they unlocked, what they should notice at the location, how to redeem an offer, or why that stop matters to the story or event.

Some Hunts may include locations with age restrictions, such as venues that are 18+ or 21+. If a Hunt uses one of those locations, the app may prevent players who do not meet the requirement from launching or continuing the Hunt. Creators and customizers should pay attention to age badges and availability warnings when choosing Official Hunt Sponsor locations, especially when sharing a Hunt with families, students, employees, or mixed-age groups. Age restrictions are enforced to protect players, creators, sponsors, and the app. If your group includes younger players, avoid age-restricted sponsor locations or design an alternate route using private locations, arrival-only stops, or family-friendly checkpoints.

Some Official Hunt Sponsor locations have specific Hunt participation hours that can be different from their normal business hours. If a Hunt depends on a sponsor location and the player tries to launch or play when that location is not available for Hunt participation, the app may block the Hunt or warn the player. This protects the player experience and helps avoid sending people to places that cannot currently support the stop, QR scan, offer, or check-in. A location’s Hunt participation hours may not match its ordinary business hours. For example, a venue could be open to the public but not participating in Hunts during certain times, or it could have rules that prevent gameplay late at night.

A Hunt may be unavailable for several reasons. It may not be published yet, it may be outside your selected play area, it may require an active creator plan, it may have reached its player limit, or one of its required locations may be closed for Hunt participation. Some Hunts also include age-restricted locations, so players who do not meet those requirements may be blocked. If you are joining a private Hunt, confirm the code is correct and ask the creator whether the Hunt is active and has available player slots. The fastest fix is to identify which rule is blocking you: location, age, hours, player capacity, inactive plan, unpublished status, or an incorrect code. If you are a player, ask the host to verify the Hunt is published, active, and still has room for new players.

Yes. Some Hunts are designed for team play. A team may have one navigator who controls the main progression while other players follow along. During certain moments, non-navigator players may see a waiting message until the navigator unlocks the next clue, completes a check-in, or triggers the next story moment. Team play works best when everyone stays together, follows the same route, and communicates before answering puzzles or scanning stop QR codes. Team play works best when the group agrees who is navigating before the Hunt starts. If the Hunt uses AR, puzzles, or location check-ins, have the navigator read prompts out loud so the rest of the team understands what is happening and can help solve clues.

A Hunt QR code lets players join the overall Hunt. It is the QR version of the join code and is usually used on invitations, event materials, or a Printable QR poster. A stop QR code is different: it is used during gameplay to confirm that players have reached a specific stop. If a stop uses a Scan code checkpoint, players must scan that stop’s QR code before the Hunt will unlock the next step. When printing or posting QR materials, label them clearly so players know whether they are scanning to join the Hunt or scanning to check in at a specific stop. Mixing up join QR codes and stop QR codes is one of the easiest ways to confuse players during an event.

A join code is the private access code for a Hunt. It usually looks like HUNT-XXXXXX. Anyone with the code can join the Hunt if it is active, published, not full, and otherwise available to that player. For private Hunts, the join code is how the creator or customizer invites specific players without making the Hunt public in the catalog. Keep the code private if you only want a limited group to play. Do not post a private join code publicly unless you want anyone with the code to be able to join, subject to capacity and eligibility rules. For parties, trainings, or customer events, it is usually better to share the code only with invited players.

Go to Profile, choose Join a Hunt by Code, and enter the code someone shared with you. You can also scan a Hunt QR code from a poster, invitation, printed page, or another player’s screen. Private Hunts are not listed in the public catalog, so the join code or QR code is the access key. If the code does not work, check the spelling, confirm the Hunt is published, and make sure the creator has available player capacity. If the code does not work, check for typos, missing hyphens, expired access, full player capacity, or a Hunt that has not been published yet. The person who created or customized the Hunt may need to open the share screen again and send you the current code or QR.

To start a Hunt, choose an available public Hunt from the catalog or join a private Hunt using a join code or QR code. The app will then guide you step by step through the experience. Depending on the Hunt, you may read story content, solve puzzles, travel to locations, check in by QR code, answer location-based questions, confirm arrival, view discovery content, or interact with AR objects. Some Hunts may only be available during certain hours or to players who meet age requirements. Before starting, check whether the Hunt is public, private, sponsored, location-based, or age-restricted. If you are joining a private event, make sure you have the exact join code and that the host has published the Hunt and has enough available player slots.

Not immediately. Hints should help players recover when they are stuck, not skip the experience. A good approach is to make the first hint subtle, the second hint more specific, and the last hint nearly direct. For example, a first hint might mention a sign color, while a final hint might say the business type or exact area to check. This keeps the Hunt moving while preserving the satisfaction of solving. A good hint ladder lets players choose how much help they want. The first hint can nudge, the second can narrow, and the final hint can make the answer or QR location very clear.

One to three hints is usually enough. Start with a gentle hint that nudges players in the right direction, then make later hints more direct. If the app asks for one hint per line, put each hint on its own line. Good hints prevent frustration without making the clue meaningless. For public or larger-group Hunts, include enough hints that people who do not know the area can still finish. If your Hunt is for a party or public audience, err on the side of more help. If it is for puzzle enthusiasts, you can make the first hint subtle and later hints more direct.

A good QR checkpoint hint tells players exactly where to look once they are at the stop. Examples include: “Look near the front register,” “Ask the host stand for the Hunt sign,” “Check the poster by the entrance,” or “Find the green Hunt card near the counter.” The checkpoint hint should reduce friction, especially if staff are busy or the QR code is not immediately visible. QR hints should be more direct than location clues because players have already solved the destination. The goal is to prevent awkward searching, not to create another difficult puzzle unless that is intentional.

A good location clue gives enough information to find the place while still feeling like part of the game. For example: “Find the place where stories line the shelves and the next chapter waits near the corner.” This clue suggests a bookstore without simply saying the name. You can make clues easier or harder depending on your audience, the size of the area, and whether players are expected to walk, drive, or stay inside one venue. Good location clues often combine direction and theme. For example, a bookstore clue might mention stories, shelves, chapters, or local landmarks rather than only saying the business name.

It depends on the type of Hunt. For a casual party, pub crawl, or family event, including the business name may be perfectly fine because the goal is a smooth route. For a mystery, puzzle, or challenge-based Hunt, it is usually more fun to hide the name behind a clue. You can also use a progressive hint strategy: the clue is playful, the first hint narrows it down, and the final hint makes it obvious if players are stuck. For casual events, using the name can reduce friction. For puzzle Hunts, hiding the name can make the experience more engaging, but only if the clue still gives players enough information to solve it without getting frustrated.

Avoid clues that send players into unsafe, private, restricted, employee-only, high-traffic, or confusing areas. Do not make players cross dangerous roads unnecessarily, enter places where they are not welcome, disturb staff, search through merchandise, or access anything not intended for the public. Also avoid clues that depend on details that may change, such as a temporary sign, daily menu item, parked car, or object that might be moved. Also avoid clues that require players to trespass, distract staff, block entrances, enter employee-only areas, or search in ways that could make a business uncomfortable. Safety and courtesy matter more than cleverness.

A good location clue is solvable, fun, and fair. It should give players enough information to identify the destination without simply becoming a GPS instruction. Good clues can reference a landmark, theme, sign, product, color, local history, inside joke, object, view, or wordplay. The best clues make players feel clever when they solve them, but they should not be so vague that players wander around frustrated. The best clues create a small moment of discovery. They should point toward the answer through landmarks, themes, signs, history, inside jokes, or visual details while still being fair to someone who is not the creator.

The location clue helps players figure out where to go. It points them toward the stop. The checkpoint hint helps them after they arrive, usually by telling them where to find the QR code, what detail to observe, or where to look for the answer. A location clue should solve the destination; a checkpoint hint should solve the exact check-in action. Keeping these separate makes the experience much clearer for players. A common mistake is using one clue to do both jobs. First get players to the right place, then use checkpoint hints to help them find the exact code, object, or answer once they are there.

Mock At Destination is a testing feature that appears while Testing Mode is on. It simulates the player arriving at the next stop, so you can test check-ins, clue progression, discovery content, and the overall flow from your couch or desk. This is for creators and customizers during testing only. It should not be left on when real players are invited, because it would undermine the real-world movement and arrival experience. This is useful for validating the flow from stop to stop without driving or walking the route. Because it simulates arrival, remember that it will not prove that GPS accuracy, QR placement, signage, or real-world clue wording works at the actual location.

Yes. Testing Mode is strongly recommended while you are building or editing a customized Hunt. It allows you to test the flow without physically traveling to every stop, which is especially helpful when checking clue order, discovery content, checkpoint behavior, and player instructions. Turn Testing Mode off before you invite real players so they experience the actual location-based version of the Hunt. Testing Mode is one of the best ways to catch obvious mistakes early, such as missing clues, wrong checkpoint settings, or confusing discovery text. It should not be treated as a substitute for a real-world walkthrough when the event depends on exact physical placement or QR posters.

Save & get join code saves your customized Hunt and takes you directly to the Share your hunt screen. From there, you can copy the join code, share the code with players, show the Hunt QR code, or create a printable QR poster. This is the step that makes your private customized Hunt easy to invite others into. Before sharing widely, you should test the experience and make sure Testing Mode is turned off for real players. After you reach the share screen, review the join code, QR code, poster options, and test-play option. Even though the Hunt is shareable, it is still wise to test before sending the code to your full group.

You cannot rewrite the main story structure of the base Hunt in Customize mode. The broader sequence, theme, and core story stay intact. Also, if you choose an Official Hunt Sponsor location, you cannot edit that sponsor’s official details, offer content, participation hours, age restrictions, or other sponsor-controlled availability rules. You can choose to use the sponsor location or pick another location, but official sponsor information is controlled by The Hunt and the sponsor setup. This is by design so the base Hunt remains coherent and sponsor information remains accurate. If you need to change the story itself, add new steps, create alternate paths, or control advanced media and AR, use Create Hunts instead of Customize Hunts.

In a customized Hunt, you can edit the stop-level experience. This includes the location, checkpoint type, QR or question-based check-in behavior, accepted answers, optional fuzzy matching, wrong-answer messaging, hints, discovery text, discovery images, and active windows. You can also create your own private locations or choose from existing locations. The goal is to let you make the Hunt work for your route and event without rebuilding the entire story. For each stop, think through the player’s real experience: how they will know where to go, how they will prove they arrived, what they will see after check-in, and whether the stop should only be active during certain dates or times.

Go to Profile, choose Customize Hunts, tap New, pick a base Hunt, and give your customized version a name. Then use the Customize Hunt editor to review each stop, choose or create locations, select checkpoint types, write location clues, add checkpoint hints, configure questions if needed, and add discovery content. When you are ready, tap Save & get join code. The app will take you to the share screen where you can copy the code, share it, or display the Hunt QR code. A good setup process is: choose the base Hunt, name your version, pick or create each location, select checkpoint types, write location clues, add checkpoint hints, test the route, then share the code only when you are comfortable that players will understand what to do.

No. Customized Hunts are private. Only people with your join code or Hunt QR code can join. A customized Hunt does not appear in the public catalog, and it is not discoverable by other users browsing the app. This makes Customize a good fit for private parties, friend groups, company events, or any experience intended for a specific invited audience. Private means the Hunt is controlled by the join code or QR code. Keep that code within the intended group, and remember that anyone who receives it may be able to join until the player limit or availability rules prevent additional players.

Customize is the simpler path: you start with an existing Hunt and personalize the locations, check-ins, and stop details while the story structure stays the same. Create is the full builder: you can start from scratch or clone a template, then edit the Hunt’s title, description, cover image, story steps, content, puzzles, stops, choices, branches, AR, audio, images, and publishing settings. Customize is best for adapting an experience quickly; Create is best for building an original experience. Choose Customize when the story framework already works and you mostly need different places. Choose Create when you want to change the structure, add original content, build puzzles, add branches, use AR, or design something that could eventually be submitted for public review.

Customize Hunts is best for people who want a polished Hunt framework without building every step themselves. It works well for birthdays, bachelorette parties, date nights, pub crawls, family activities, campus events, team outings, customer events, training routes, and small group experiences. Use Customize when the main story or template already fits your goal and you mainly need to swap in your own places, instructions, checkpoints, and local details. It is especially useful when you have a real-world route in mind but do not want to write a complete game from zero. A host can turn familiar places into a polished private experience by changing the locations and checkpoint content while relying on the template’s built-in structure.

Customize a Hunt lets you take an existing Hunt and make a private version of it for your own event, group, or route. The underlying story structure stays the same, but you can change the practical stop-level experience: locations, checkpoint types, location clues, checkpoint hints, questions, accepted answers, discovery content, images, and active windows. It is designed to be faster and easier than building a completely original Hunt from scratch. Customize is intentionally streamlined so you do not need to understand every advanced creator tool. Start with a strong base Hunt, then focus on matching the stops to your event and making each clue and checkpoint clear enough for your specific players.

No. AI narration calls are not used for creator-built or customized Hunts. The text, narration, audio, images, and other media players experience are based on what you provide in the builder. This means you should proofread your narration, upload any audio you want players to hear, and make sure your text is clear. Official admin-created Hunts may have separate settings, but creator and customized Hunts do not rely on AI narration generation. Plan creator Hunts as human-authored experiences. Use your own text, recorded audio, uploaded files, and approved assets, then proofread and test them carefully because the app will show players what you provide.

Yes. You should test every created Hunt before inviting players. Use Test-play your hunt to experience it like a player, and use Testing Mode with Mock At Destination to move through location-based stops without physically traveling. Creator test plays do not consume outside player slots. A good test should confirm that every step appears correctly, every puzzle works, every location is accurate, and every branch goes where expected. Test as both the creator and, when possible, as a real invited player. Creator testing checks the build; player testing helps confirm that join codes, player slots, permissions, GPS, QR scanning, and device-specific behavior work as expected.

Yes. The builder is designed to auto-save your work as you type and edit. You may also see manual Save, Save changes, Saved, Saving, or Not saved indicators depending on where you are in the app and what you are editing. Auto-save helps protect your work, while manual save controls give you confidence before leaving a screen, publishing, or sharing. When in doubt, tap Save or Save changes before exiting. Auto-save helps protect your work while manual save gives you confidence before leaving a screen or testing. Watch the saved/not-saved indicator, and avoid closing the app immediately after a major edit until the app confirms the changes are saved.

Only you can see your draft. Draft Hunts are not public, not joinable, not shown in the public catalog, and not available to players by code. Draft status lets you safely build, test, and revise without accidentally inviting players into an incomplete experience. When your Hunt is complete and passes validation, you can publish it privately to make it joinable by code or QR. Draft status is useful because it gives you a safe workspace. Do not assume players can join until you publish privately and reach the share screen with a live code or QR.

Start from scratch gives you a blank Hunt so you can build every part of the experience yourself. You add the title, description, category, cover image, and steps. You decide where players go, what they read, what puzzles they solve, what they scan or answer, what media appears, and whether the Hunt uses branches or AR. This option is best when you already have your own concept or need a highly custom route. A blank Hunt gives you maximum control but also more responsibility. Before adding many details, outline the step order on paper or in notes so you know where the intro, locations, puzzles, choices, finale, and any branches will go.

Start from a template creates your own editable copy of a curated Hunt structure. Templates can save a lot of time because they may already include a theme, story flow, step order, example locations, puzzles, cover image, and recommended structure. After cloning a template, you can edit the title, description, images, content, puzzles, stops, locations, branches, and other details. A template is a starting point, not a locked experience. A template is not just a visual theme; it can include a working sequence of steps, stops, default text, images, and gameplay logic. Treat the cloned template as your editable copy, then rename it and replace any placeholder content before publishing.

Go to Profile, choose Create Hunts, tap New, and select either Start from a template or Start from scratch. A template gives you a cloned structure that you can fully edit, while scratch starts with a blank Hunt. Build the Hunt by adding and editing steps, locations, clues, puzzles, media, and validation details. Test it thoroughly, publish it privately when it is ready, and then use the Share screen to invite players by code or QR. For your first full build, starting from a template is usually faster than starting from scratch because it gives you a working structure to study and edit. Once you understand how steps, stops, checkpoints, and publishing work, starting from scratch becomes easier.

Create Hunts is best for users who want to build an original experience rather than simply adapt an existing one. It can be used for scavenger hunts, themed parties, brand activations, campus games, employee trainings, museum or city tours, classroom activities, onboarding routes, escape-room style experiences, choose-your-own-adventure stories, or private events with more custom structure. Use Create when you want control over the full story, step sequence, puzzles, branches, media, and gameplay. Creator Access can support many use cases beyond entertainment, including orientation events, educational lessons, staff training, destination tours, corporate activations, and guided experiences. The more public or complex the use case, the more important testing and clear instructions become.

Create Hunts gives you access to the full Hunt builder. You can start from a blank canvas or clone a template, then build and edit the complete experience. This includes Hunt basics, cover image, story/content steps, puzzles, stops, locations, clues, choices, branches, AR assets, audio, images, text timing, discovery content, active windows, validation, private publishing, sharing, QR posters, and optional submission for public catalog review. Create Hunts is the right tool when you want control over the full player journey. It is more powerful than Customize, so plan your structure before building: what the player sees first, where they go, what they solve, what happens if they choose differently, and how the Hunt ends.

Yes. In the full creator builder, you can move, reorder, and delete steps. Reordering is powerful, but it can affect puzzles, branches, stop order, and player flow. After changing step order, always test the Hunt and confirm that every step points to the right next step, every branch still resolves, every stop appears in the intended sequence, and no player can get stuck or skip required content accidentally. After reordering, re-test the Hunt because moving a step can affect branch destinations, puzzle overrides, stop sequence, and story continuity. A Hunt can look fine in the editor but still feel confusing if the step order no longer matches the narrative.

Track A is the main path of your Hunt. Think of it as the default storyline or route that most players follow. When you add choices or branch overrides, players may temporarily move into alternate tracks such as B or C. Those alternate tracks can rejoin Track A later or end separately. This system lets you keep the main Hunt organized while still creating optional detours, alternate scenes, different outcomes, or choose-your-own-adventure style structure. Track labels help you keep the structure organized while building. Players do not need to understand the internal labels, but you should use them to make sure branches rejoin correctly and endings happen where you expect.

A Choice step lets players choose between two paths. This is how you create a visible decision point in the story, such as choosing between two missions, two suspects, two routes, two challenges, or two roles. Choice steps can send players into different branches that later rejoin the main path or lead to different endings. Use Choice steps when the player’s decision should feel meaningful. Choice steps make the Hunt feel personal because players decide where the story goes. Keep the options clear, and make sure each branch has enough content to feel intentional rather than accidental.

A Stop step sends players to a real-world location. It can include a location clue, an exact location, a checkpoint requirement, hints, discovery text, images, active windows, and sometimes QR code or question-based verification. Stop steps are the core of the physical Hunt experience. Use them when players need to travel to a place, find something at that place, check in, and then unlock the next part of the Hunt. Stop steps are where real-world logistics matter most. Make sure the location pin, active window, checkpoint type, clue, hints, and discovery content all match what players will actually experience on-site.

A Puzzle step asks players to solve something before continuing. This could be a riddle, trivia question, observation challenge, code, clue, image puzzle, training question, or location-based prompt. Puzzle steps can include accepted answers, hints, correct and incorrect messages, images, audio, text timing, AR experiences, and optional branching behavior. Use Puzzle steps when you want players to think, collaborate, notice details, or earn the next part of the Hunt. Puzzle steps work best when the answer is discoverable from the content you provide or from something players can observe. Avoid puzzles that require outside knowledge unless the Hunt clearly tells players where to find the information.

A Content step is used for narration, dialogue, instructions, story setup, training information, event guidance, or transition text. Intro and finale moments are usually Content steps. You can use Content steps to tell players what is happening, introduce a character or narrator, explain the rules, create atmosphere, or connect one stop to the next. A strong Content step is clear, short enough to read comfortably on a phone, and directly useful to the player. Use Content steps to create pacing between action moments. They are good for intros, transitions, instructions, story reveals, character dialogue, sponsor introductions, training explanations, and finales.

The main step types are Content, Puzzle, Stop, and Choice. Content is for narration or information. Puzzle is for questions, riddles, or challenges. Stop is for real-world locations and check-ins. Choice is for branching the story into different paths. These four concepts give you enough flexibility to build simple private routes, training flows, guided tours, scavenger hunts, puzzle games, and choose-your-own-adventure style experiences. If you are unsure which type to choose, ask what the player is doing at that moment. Reading or listening is Content, solving is Puzzle, traveling or checking in is Stop, and choosing a path is Choice.

Steps are the building blocks of a Hunt. Each step tells the app what the player sees, solves, visits, chooses, scans, collects, or unlocks next. A complete Hunt is a sequence of steps arranged into a main path and, if you choose, alternate branches. Good step design is what makes the Hunt feel like a real experience instead of a simple list of places. A good Hunt feels simple to the player even though it may have many steps behind the scenes. Each step should have one clear job: tell, ask, send, or branch.

Use Scan code when you control the location or can place a poster or card. Use Question when the player must observe something at the stop but a QR code is not practical. Use Arrival only for outdoor, public, or open locations where GPS arrival is enough. Use No checkpoint when verification is not important. The best checkpoint is the one that gives players a smooth experience while still protecting the integrity of the Hunt. Many Hunts use a mix of checkpoint types. For example, a party route might use arrival-only for outdoor landmarks, QR for a venue where you control signage, and question check-ins for places where players must observe something.

No checkpoint means players can continue without proving they are at the location. This can be useful for a story beat, optional waypoint, transition step, remote clue, or low-stakes moment where verification does not matter. Use it carefully. If the stop is important to the route or gameplay, a QR scan, question, or arrival-only checkpoint usually creates a better experience. No checkpoint can be useful for story beats, optional pauses, or instructions that should not slow players down. Use it carefully because players may be able to advance without actually going to the place.

Arrival only means the player checks in by being near the location. This is best for parks, public landmarks, outdoor spaces, walking tours, campuses, or other places where QR placement is impractical. It is easier for players, but less precise than scanning a QR code or answering a question. Test arrival-only stops on location because GPS accuracy can vary by device, weather, buildings, and environment. Arrival-only check-ins are convenient, but GPS can be imperfect, especially indoors, near tall buildings, or in crowded commercial areas. Use a reasonable arrival radius and test at the real stop.

Question means players must answer a question to check in or continue. This is useful when you cannot place a QR code but still want players to prove they found the location or observed something specific. The answer might come from a sign, mural, menu, statue, plaque, window display, object, training material, or clue. Add accepted answer variations so players are not blocked by minor wording differences. Question check-ins are often the best choice when you cannot post a QR code but want players to prove they noticed something real. Add accepted answer variations so minor wording differences do not block players unfairly.

Scan code means players must scan the stop’s QR code to check in and continue. This is best when you can place a QR poster, card, sign, table tent, sticker, handout, or printed clue at the location. It gives the strongest proof that players found the intended place. Make sure the QR code is easy to find, large enough to scan, printed clearly, and placed somewhere safe and appropriate. For QR stops, place the code somewhere obvious enough to find but not so obvious that it ruins the clue. Test the printed code with the same kind of phone players will use and make sure lighting, size, and placement are reliable.

Checkpoint options may include Scan code, Question, Arrival only, and in some customization flows, No checkpoint. Scan code requires a stop QR code. Question requires the player to answer a prompt correctly. Arrival only relies on the player being near the location. No checkpoint allows the Hunt to continue without verification. Choose the checkpoint type based on how much proof you need and what is practical at the stop. The best checkpoint type depends on the stop environment. QR codes are precise, questions are flexible, arrival is convenient, and no checkpoint is useful only when verification does not matter.

A checkpoint is how The Hunt confirms that a player has reached, completed, or interacted with a stop. The checkpoint can require scanning a QR code, answering a question, being near the location, or sometimes no verification at all. Checkpoints help make the Hunt feel real and prevent players from skipping ahead without actually visiting or completing the intended location moment. Checkpoints are optional design choices, but they strongly affect how controlled the experience feels. A tight checkpoint confirms the right place or answer; a loose checkpoint makes the Hunt easier but less verifiable.

The warning appears because sponsor locations may have rules that affect whether players can launch or complete the Hunt. These can include Hunt participation hours, open or closed status, age restrictions such as 18+ or 21+, and other availability rules. If a player tries to play outside those rules, the Hunt may be unavailable to some or all players. The warning helps creators and customizers understand this before publishing or sharing. The warning exists so creators do not accidentally invite players into a Hunt that cannot run at the selected time. It is better to see the restriction while building than to have players blocked during the event.

No. Official Hunt Sponsor location details are controlled by The Hunt and the sponsor setup. You can choose whether to use that location, but you cannot edit its official address, participation hours, age restrictions, offer details, or sponsor-controlled discovery information. This protects sponsor accuracy and prevents creators from accidentally misrepresenting a participating location. If the sponsor location does not fit your Hunt, choose or create a different location. Those fields are locked because they belong to the official sponsor record. If the sponsor’s information appears wrong, the correct fix is to update the official location record through the appropriate admin process, not to override it in a private Hunt.

An Official Hunt Sponsor location is a participating location managed through The Hunt. Sponsor locations may include official address information, participation hours, open or closed status, age restrictions, arrival radius, offers, discovery content, and other rules. When you select an Official Hunt Sponsor location, the app may show a confirmation card so you understand how that location can affect player availability. Sponsor locations are usually best when you want players to visit participating businesses or venues without having to set up all the details yourself. Always review their participation hours and restrictions before building a route around them.

Yes. You can create your own private location by adding a name, optional description, address or coordinates, map pin, and photos where supported. This is useful for homes, parks, offices, classrooms, event venues, campus spots, landmarks, or temporary places that are not Official Hunt Sponsor locations. Make the name and description clear enough that you can recognize the stop later while editing. When creating a private location, use a clear name you and your players will recognize. Add enough description, address, photos, or map accuracy so you can tell later which real-world place the location represents.

You can choose a location by searching for an existing location, selecting an Official Hunt Sponsor location, using your current location, dropping a pin on the map, picking an exact spot on the map, entering coordinates, or creating a new private location. For best results, use the most accurate location possible and test it in the real world. Small GPS errors can matter if the stop uses arrival-based check-in. Choose locations that are safe, accessible, appropriate for your players, and practical at the time the Hunt will be played. If the exact entrance or meeting point matters, use the map pin and checkpoint hints to remove ambiguity.

A Stop is a real-world place players visit during a Hunt. It can be a business, park, landmark, building, campus location, museum exhibit, event space, trail marker, or custom point on the map. A Stop usually includes a location clue that helps players find it, plus a checkpoint that confirms they arrived or completed the task. Stops can also include discovery content shown after check-in. A strong Stop gives players a clear reason to go somewhere and a satisfying thing to do when they arrive. Think of it as a combination of destination, clue, proof of arrival, and reward.

If you leave text scroll duration blank, the app may use the audio length or a default duration, depending on the step configuration. This can work well for simple steps, but for polished story moments you may want to set the duration yourself. Set a custom duration when the text is long, when pacing matters, when the audio is not the same length as the text, or when you want the player experience to feel more controlled. Leaving it blank is fine for simple steps, but set it manually when timing matters, such as a dramatic reveal, a training explanation, or a piece of narration that should match audio pacing.

Text speed or text scroll duration controls how long the on-screen text takes to appear or scroll for the player. This matters when you have narration, longer story text, or audio that should stay synchronized with the visual text. If the duration is too fast, players may miss important details. If it is too slow, the Hunt can feel dragged out. Use a duration that matches how long a normal player needs to read the step comfortably. Text duration is especially important when narration is long or when players are walking. If the text scrolls too fast, players may miss instructions; if it is too slow, the Hunt can feel sluggish.

Yes. Puzzle steps can include supporting media such as an image or audio where the builder allows it. Use images when players need to inspect visual details, mood, symbols, maps, signs, or clues. Use audio when narration, instructions, music, sound effects, or a spoken clue improves the experience. Always test media on a phone screen and in real conditions so players can see and hear what they need. Media can make a puzzle much stronger, but it also creates another thing to test. Confirm that the image is readable on a phone and that any audio is clear in the environment where players will likely listen.

Puzzle hints are shown when players need help, usually after wrong answers or when they choose to ask for help depending on the Hunt settings. Hints should move from subtle to specific. If a puzzle relies on a sign, image, audio, AR object, or location detail, your hints should point players back to the relevant evidence. The goal is for teams to finish the puzzle with help, not abandon the Hunt. Hints should be written in the order players will receive them. Start broad and become more specific so players can still feel like they solved the puzzle even after asking for help.

Use the correct-answer message to reward the player and set up the next moment. It can be as simple as “That’s it. The next clue is waiting,” or more thematic, like “The vault clicks open. A new trail appears.” This is a good place to reinforce the story, congratulate the team, or explain what happens next. Keep it brief enough that players do not lose momentum. Correct-answer messages are a good place to add delight. Use them to confirm the win, advance the story, give a small reward, or set up the next step so the player feels momentum.

Use the wrong-answer message to help players try again without making them feel punished. A good message might say, “Not quite. Look closer at the sign near the entrance,” or “Almost. Check the second line on the poster.” Avoid sarcastic or vague messages like “Wrong” unless the tone of your Hunt intentionally supports it. The best wrong-answer messages keep the energy up and guide players toward the intended observation or logic. Wrong-answer messages should keep the tone encouraging. Avoid making players feel stupid; instead, point them back to the observation, clue, or hint that will help them recover.

Fuzzy matching allows small typos, spacing issues, or minor spelling differences to still count as correct. This is helpful because players often type answers while walking, standing outside, or talking with teammates. Fuzzy matching should make the experience more forgiving, but it is still smart to add obvious accepted answers yourself. If the answer is a specific name, phrase, or code, test it carefully to make sure the matching feels fair. Fuzzy matching is helpful, but it should not replace good accepted-answer setup. If two very different answers could be close in spelling, use careful wording and test the puzzle to make sure incorrect answers are not accepted accidentally.

Capitalization should not be used as a trick. Players should not be punished for typing “bookbug,” “Bookbug,” or “BOOKBUG” if the answer is otherwise correct. Even when the app handles capitalization forgivingly, you should still test your puzzle answers and add common variations. The goal is to reward understanding, not make players guess the exact formatting you had in mind. Even when capitalization does not matter, clarity still does. If the answer is a code, phrase, or name where exact formatting matters, explain that expectation in the clue or instructions.

Accepted answers are alternate versions of the correct answer that should still count. For example, if the correct answer is “Bookbug,” you may also want to accept “Book Bug,” “this is a bookstore,” or “Bookbug and this is a bookstore,” depending on the clue. Adding accepted answers is one of the best ways to prevent players from getting stuck because they typed a reasonable variation instead of your exact wording. Think like a player when adding accepted answers. Include common misspellings, abbreviations, punctuation differences, plural and singular forms, and versions with or without spaces when those differences should not matter.

A Puzzle step asks the player to enter an answer before the Hunt continues. The builder lets you define the correct answer and, where supported, extra accepted answers. When the player submits an answer, the app compares it to the accepted answer list and either unlocks the next step, shows a correct message, gives a wrong-answer message, reveals hints, or sends the player to a branch depending on your settings. When designing a puzzle, decide whether the goal is fun, verification, story progression, or a real challenge. The answer settings should match that goal so players are not blocked by formatting instead of thinking.

Branches are powerful but easy to break if they are not tested. Make sure every branch points to a real step, every route can continue or end cleanly, and players cannot get stuck in a dead end by accident. Watch out for references that only make sense on one path, QR codes that are only available to one branch, and step numbers that change after reordering. Always test every branch, not just the main path. The main risks are dead ends, loops, skipped required stops, and story moments that no longer make sense. Use testing to play every possible route, not just the route you expect most players to take.

Use Choice steps for visible decisions and Branch Overrides for hidden outcome-based decisions. A Choice step lets players knowingly choose a path, while a Puzzle Branch Override can send them to different paths based on performance. Design each branch as a short, intentional sequence with its own tone, reward, challenge, or consequence. Then either bring players back to the main path or give each branch a satisfying ending. A good choose-your-own-adventure Hunt usually starts simple: one main path, one or two meaningful choices, and branches that rejoin cleanly. Once that works, you can add more complex alternate routes.

Goto Step tells the app which step should come next. Instead of following the normal sequence, the player is sent to the specific step number you choose. For example, a correct answer could go to Step 12 while a wrong answer goes to Step 20. When using Goto Step, make sure the destination step exists, makes sense in context, and eventually leads to a valid continuation or ending. The destination should be a real step number in your Hunt. After setting a Goto Step, test the path from the puzzle to that destination and from that destination back into the rest of the Hunt.

Use “On wrong answer → go to…” when a wrong answer should create a detour, second-chance path, easier explanation, penalty path, alternate clue, or different story consequence. It can make the Hunt feel more like a real game because failure does not simply stop the experience. Be careful not to make wrong-answer paths too punishing unless that is clearly part of the design. This can be fun when failure should still move the Hunt forward instead of simply stopping the player. Keep wrong-answer branches constructive so players stay engaged rather than feeling punished.

Use “On correct answer → go to…” when solving the puzzle should send players somewhere other than the default next step. For example, a correct answer might unlock a shortcut, reveal a secret room, send players to a bonus clue, award a better ending, or move the team into a special story branch. This is a powerful tool for making players feel that solving the puzzle changed the experience. Use this for shortcuts, bonus content, hidden scenes, reward branches, or moments where solving the puzzle should clearly change the player’s experience. Always confirm the destination step exists and is in the right place.

If you leave Branch Override blank, the puzzle usually continues using the normal next-step behavior. That means players proceed to the next step in the current sequence after completing the puzzle. Leaving it blank is the right choice for most simple puzzles. Use overrides only when the puzzle outcome should change the path, unlock a bonus scene, create a detour, or send players to a different branch. Leaving it blank is safest when you want a normal linear Hunt. Add overrides only when you intentionally want the puzzle result to change where the player goes next.

Branch Override lets a Puzzle step send players to a different step based on whether they answer correctly or incorrectly. Normally, a correct answer continues to the next step after the current block. With an override, you can set an optional Goto Step that sends players somewhere else, such as an alternate path placed later in the Hunt. This lets puzzle outcomes affect the story, not just unlock the next screen. This is a powerful way to make puzzle success or failure affect the story. A correct answer might unlock a reward path, while an incorrect answer might send players to a detour, explanation, easier puzzle, or alternate ending.

Yes. Branches can rejoin the main path later, or they can lead to different endings. Rejoining is useful when you want players to experience a short detour but still finish the same Hunt. Separate endings are useful when choices or puzzle outcomes should matter more. When designing branches, decide whether each branch is a temporary side path, a meaningful alternate route, or a true alternate ending. Rejoining is useful when you want different choices to feel meaningful without creating completely separate Hunts. Make sure the rejoin step makes sense for players coming from either branch.

A story branch is an alternate path through the Hunt. For example, one team might choose the “brave” path while another chooses the “clever” path. Each branch can include its own content, puzzles, stops, discovery moments, or ending. Branches are how you create choose-your-own-adventure style Hunts where different players can have different experiences while still being part of the same overall Hunt. Branches can be short or complex. For most creators, short branches that rejoin the main story are easier to manage than long separate paths with many unique steps.

A decision point is a moment where players choose what path to take. In the builder, this is usually handled with a Choice step. Decision points make the Hunt feel more interactive because players are not just following a fixed route; they are affecting the story. A decision might be based on strategy, personality, role, team vote, suspicion, risk, or preference. Decision points are what make a Hunt feel less linear. Use them when the choice should feel meaningful, such as choosing a route, a character response, a strategy, a team challenge, or a story direction.

In team play, the non-navigator waiting message is shown to players who are not currently controlling the main action. It lets them know that the navigator is working through the next clue, AR moment, puzzle, or unlock. A good waiting message keeps teammates engaged and prevents them from thinking the app is frozen. Keep it short, reassuring, and consistent with the tone of the Hunt. This is especially important in team play because only one person may be actively scanning or collecting. The waiting message reassures everyone else that the app has not frozen and that the team will continue once the navigator finishes.

Usually no. The recommended setting is to keep AR messages on because they help players understand scanning, placement, surface detection, and collection. AR can be unfamiliar to some users, and short instructions reduce confusion. Only turn messages off if the experience is extremely simple, has been tested thoroughly, and the on-screen guidance would interfere with the intended effect. Turning messages off can make the experience feel cleaner, but it also removes guidance that prevents support questions. For most creators, leaving them on is the safer choice.

Yes, if custom wording improves clarity or fits your Hunt’s tone. For example, a mystery Hunt might say “Search the room for the hidden mark,” while a training Hunt might say “Scan the area until the object appears.” Keep messages short because players are looking through the camera and moving their phone. Long AR text can distract from the action and make placement harder. Customize them when your Hunt has a specific voice or when the default instruction could be clearer. Keep each message short because players are already managing the camera, environment, and team conversation.

The AR HUD and hint messages are short instructions players see during AR placement and interaction. Examples include “Move your phone slowly,” “Scanning for surface,” “Hold steady,” “Locating clue,” “Look around to find it,” “Clue found,” and “Tap to collect.” These messages help players understand what the camera is doing and what they should do next. They can usually be shown or hidden individually. These messages are there because players may not know how to help their phone detect a surface. Short prompts can reduce confusion during the few seconds when the camera is scanning and the object has not appeared yet.

Adjust Pitch, Yaw, or Roll when the AR object appears in the wrong orientation during testing. For example, use Yaw if the object faces the wrong direction, Pitch if it is leaning forward or lying down, and Roll if it is tilted sideways. Make small changes and test again. Rotation issues are common because different 3D tools may export models with different default axes. If the model appears buried in the floor, lying on its side, facing away, or floating at an odd angle, rotation and scale are usually the first settings to check. Change one variable at a time so you know what fixed the issue.

Pitch, Yaw, and Roll control the starting rotation of the AR model. Pitch, or X rotation, tilts the object forward or backward. Yaw, or Y rotation, turns it left or right. Roll, or Z rotation, tilts it side to side. These settings help correct models that appear sideways, backwards, upside down, flat on the floor, or facing away from the player after placement. A simple way to remember it: yaw spins the object like turning your head left or right, pitch nods it up or down, and roll tilts it like leaning your head toward your shoulder.

Model Scale controls how large the AR object appears. A scale of 1.0 is normal size. Higher values make the object larger, and lower values make it smaller. If your object appears tiny, increase the scale; if it overwhelms the camera view, reduce it. Scale should match the object’s intended role. A collectible token may be small, while a creature, sign, portal, or clue object may need to be larger. Make scale changes gradually and test in the real context. A model that looks correct in a preview may feel too large or too small when placed in a hallway, storefront, tabletop, or outdoor area.

In the current setup, Android AR requires horizontal floor-style placement and does not offer the same level of placement specificity as iOS. That means iOS can be guided toward floor, wall, or elevated surfaces, while Android is more limited. Android AR can still work well, but creators should avoid building an AR moment that only makes sense if the object is placed on a wall or table unless there is an appropriate fallback. Design cross-platform AR with Android’s limitations in mind. If your iOS version uses wall or elevated placement, make sure Android players can still understand the clue when the object appears on a horizontal surface.

No. AR placement depends on lighting, camera movement, device capability, surface texture, available space, and the environment. Plain walls, reflective surfaces, dark rooms, crowds, moving objects, and poor lighting can make surface detection harder. Tell players to move the phone slowly, scan the area, and use a well-lit space when possible. Always test AR at the intended stop before inviting real players. AR is highly dependent on the environment. Smooth blank walls, darkness, glare, reflective floors, crowded spaces, and fast camera movement can all make surface detection less reliable.

Use Floor for objects that should sit on the ground, such as statues, boxes, creatures, signs on the floor, or large artifacts. Use Wall for objects that should appear on vertical surfaces, such as posters, symbols, plaques, or wall clues. Use Elevated Surfaces for objects intended to appear on tables, counters, shelves, or bar tops. Use Auto when you want the device to choose any suitable detected surface. Think about where the object would naturally exist in the scene. A treasure chest belongs on the floor, a poster or symbol belongs on a wall, and a small clue object may belong on a table or counter.

iOS Placement Type tells the app where the AR object should ideally appear on Apple devices. Available options may include Auto, Floor, Wall, and Elevated Surfaces. This setting helps iPhones and iPads look for the right kind of real-world surface before placing the model. It does not guarantee perfect placement in every environment, but choosing the best placement type improves the chance that the object appears where players expect. This setting helps iPhones and iPads look for the kind of surface that best matches your design. It improves the experience when used well, but real-world lighting and surfaces still affect placement.

Inspect means the AR object is primarily for viewing rather than collecting. Use Inspect when the object is decorative, informative, atmospheric, or part of a scene players need to observe. This can be useful for 3D signs, symbols, models, maps, objects with visual clues, or story artifacts. If the object contains information needed for a puzzle, make sure it is large enough and positioned well enough to inspect comfortably. Inspect is better for ambiance, exhibits, characters, artifacts, training objects, or sponsor visuals. Players can look at the object without feeling like they must find the exact tap target to proceed.

Collect means the player taps the AR object to trigger the next action, media, or progression. Use Collect when the object is meant to be found and claimed, like a hidden artifact, magical item, clue token, prize, evidence piece, or key. Make the HUD message short and clear, such as “Tap to collect,” so players understand that looking at the object is not enough; they need to interact with it. Collect is more game-like and gives players a clear action to complete. Make the collectible object visible enough to tap and use HUD text like 'Tap to collect' so players understand what is expected.

Interaction Mode controls what players do with the AR object after they find it. The main options are Collect and Inspect. Collect is more game-like because tapping the object triggers the next media or unlock. Inspect is more observational because the player views the object without necessarily collecting it. Choose the mode based on whether the AR object is part of the gameplay or mainly part of the atmosphere and storytelling. Choose the interaction based on the purpose of the object. If the object is a collectible or clue trigger, use Collect; if it is meant to be examined or enjoyed without unlocking something, use Inspect.

Yes. The AR configuration lets you enable or disable the AR object separately for iOS and Android. The recommended setting is usually to keep AR on for both device types so more players can experience it. Turn AR off for a specific device type only if you have tested and found that the asset does not work well there, or if your Hunt needs a simpler fallback for that platform. Keep both enabled unless you have tested and confirmed that one platform performs poorly. If you disable a platform, make sure the Hunt still makes sense for players on that device or provide an alternate step experience.

Use a lightweight, clean GLB under 15 MB with reasonable polygon count and optimized textures. Avoid huge image textures, unnecessary animation data, hidden objects, unsupported materials, and Draco or meshopt compression. Test the model on both iOS and Android if AR is enabled for both. Also test scale and rotation, because a model that looks correct in a 3D editor may appear too large, too small, sideways, or backwards in AR. Use reasonable texture sizes, reduce unnecessary geometry, remove hidden objects, and test the model on both iOS and Android if you plan to support both. If the object is mostly decorative, prioritize reliability over extreme detail.

The maximum AR model file size is 15 MB. Files larger than that may fail to upload, fail to load, or perform poorly for players. Smaller is usually better for mobile AR because players may be outside, on cellular data, or using older devices. Optimize the model before upload by reducing unnecessary geometry, lowering texture sizes, removing unused objects, and avoiding unsupported compression. Smaller is better when possible. Staying well under 15 MB can improve load time, reduce failures on slower connections, and make the AR moment feel smoother for players on older devices.

Use a standard, non-compressed binary glTF GLB file. Draco-compressed or meshopt-compressed models are not supported by the AR viewer. If your 3D software or optimization tool offers compression options, make sure those compression methods are turned off before export. A clean, standard GLB is more likely to load quickly and behave consistently across supported devices. Ask whoever creates the model to export a standard binary glTF/GLB without Draco or meshopt compression. If the asset was downloaded from a marketplace, check the export settings because many optimized models use compression that the AR viewer may not support.

AR objects must be uploaded as .glb files. A GLB file is a binary glTF 3D model format that can package the model, materials, and textures into one file. Use a properly exported GLB from your 3D tool and test it before sharing the Hunt. If the file format is wrong, compressed in an unsupported way, or too large, the AR viewer may not display it correctly. The .glb format is a binary version of glTF and is commonly used for 3D assets. Before uploading, open the file in a GLB viewer or test environment so you know it loads correctly outside the app.

An AR experience places a 3D object into the player’s real-world camera view. It can be used as a collectible, clue, reveal, artifact, character object, puzzle element, sponsor moment, or visual surprise. Depending on your settings, players may simply inspect the object or tap it to collect/unlock the next media or step. AR works best when it adds something memorable that could not be achieved with text alone. AR works best when it has a clear gameplay purpose: reveal a clue, show an artifact, create a surprise, let players collect something, or add atmosphere. Do not use AR just because it is available; use it when it improves the moment.

No. Audio can make a Hunt feel more polished, but text-only steps can be very effective when they are clear and well written. Use audio where it adds value: introductions, finales, character moments, immersive reveals, training explanations, or emotional story beats. Avoid adding audio just for the sake of it, especially if players are likely to be in loud places or moving quickly between stops. Audio is optional. A Hunt can be excellent with clear text, images, and checkpoints, but audio can add energy when used selectively for introductions, big reveals, character moments, or finales.

Narrator name is an optional field that identifies who is speaking or guiding the player. It might be a character, guide, host, coach, instructor, suspect, sponsor, or fictional voice. Use it when it adds clarity or personality. For example, a mystery Hunt might use “The Archivist,” while a training Hunt might use “Safety Lead.” Leave it blank if the step is general instruction and no speaker is needed. Narrator names help players understand who is speaking. They are useful for fictional characters, hosts, instructors, departments, brands, sponsors, or guides, but you can leave the field blank when no speaker label is needed.

It means the text you enter is exactly what players will see in the app. The app is not rewriting or improving it for you, so proofreading matters. Check spelling, punctuation, capitalization, tone, and clarity. Make sure the narration gives the right instructions and does not accidentally include builder notes, placeholders, unfinished sentences, or private comments. If the step is important, read it out loud before publishing. This is why proofreading matters. The app will not reinterpret your wording for players, so check spelling, punctuation, names, directions, safety instructions, and any clue wording before publishing.

Narration should usually be short, clear, and purposeful. For most story or instruction steps, aim for a length that players can comfortably listen to while standing together without losing momentum. Long narration can work for tours or training, but it should be intentional and supported by appropriate text scroll duration. If players are walking or in a noisy location, shorter narration is usually easier to follow. For most mobile experiences, shorter narration is easier to follow. If a step needs more detail, consider splitting it into multiple Content steps or pairing audio with readable text so players can catch anything they miss.

Yes, where audio upload is supported. Some builder areas may also show an Audio URL field. Audio can be used for narration, character voices, sound effects, music cues, instructions, training content, or atmospheric moments. Keep file quality high enough to understand but optimized enough for mobile use. Always test audio in the app, preferably outdoors or in the real environment where players may hear background noise. Audio can make the Hunt feel more polished, especially for narration, characters, instructions, or dramatic reveals. Test audio volume and clarity in the real environment, since restaurants, streets, and events can be noisy.

A good step image supports the specific step. It might show a clue, object, scene, map, character, symbol, sponsor detail, or visual prompt. Do not use an image just to fill space; it should help players understand, solve, or feel the moment. If the image contains information needed to solve a puzzle, make sure the important detail is large enough to see on a phone and not hidden by cropping. Step images should make the current moment easier to understand or more immersive. Avoid using busy images with tiny details unless the puzzle specifically tells players what to inspect.

A good cover image quickly communicates the theme, mood, and audience of the Hunt. It should look appealing in the app, work at smaller sizes, and not rely on tiny text that may be unreadable. For a party Hunt, choose something fun and social. For a mystery, choose something atmospheric. For training or tours, choose something clear and relevant. The cover image is often the first impression players get. A cover image is often the first impression of your Hunt. Choose something that communicates the theme quickly, looks good in a card layout, and still works when cropped or viewed on a smaller screen.

Yes. You can upload images in supported places such as cover images, step images, discovery images, puzzle images, and other media areas. Images should be clear, relevant, and easy to understand on a phone screen. Avoid using images with tiny text, cluttered details, or copyrighted content you do not have permission to use. Test images in the app because the crop and display size may differ from how they look on your computer. Use images to support the experience, not to carry critical information that may be unreadable on a small screen. After uploading, preview the Hunt on a phone to make sure cropping and text visibility are acceptable.

You should avoid sharing before the Hunt is ready. Once players have the code, they may try to join immediately. Before sharing, complete all required steps, test every checkpoint, confirm player capacity, verify locations and active windows, turn off Testing Mode, print needed QR materials, and review the experience from a player’s perspective. A few minutes of testing can prevent a bad event experience. Sharing too early is the fastest way to create support problems. Send the code only after the Hunt is saved, published, tested, capacity-checked, and any needed QR posters are ready.

Yes. Color printing is recommended, especially because some Hunt designs or puzzles may refer to poster artwork, colors, branding, or visual details. Even if the QR itself can scan in black and white, a full-color poster looks more official and may reduce confusion. Print at high contrast, avoid glossy glare when possible, and make sure the QR code is not bent, cropped, covered, or too small. Color is recommended because branding, contrast, and puzzle artwork may matter. Even if the QR code itself scans in black and white, a color poster usually looks more official and helps players trust that they are scanning the right thing.

Stop QR posters are QR posters for individual stops inside the Hunt. They are used when a stop requires a Scan code checkpoint. Each stop has its own QR code, so make sure the correct poster is placed at the correct location. The app may offer different print layouts, such as a full-page poster or smaller cut-down versions. Test every printed stop QR before players arrive. Stop QR posters should be printed, labeled, and placed carefully so each one matches the correct stop. If a stop QR is placed at the wrong location, players may unlock the wrong step or become confused.

A Printable QR poster is a branded poster that players can scan to join the entire Hunt. It is useful for parties, event check-in tables, venues, classrooms, printed invitations, sponsor locations, or anywhere players need an easy way to enter the Hunt. Print it clearly, keep the QR code large, and place it where players can scan without blocking traffic or bothering staff. Use the whole-Hunt poster anywhere players should begin: an invitation table, event entrance, classroom, venue sign, email attachment, or printed handout. Make sure the poster is displayed before the first step, not at a later checkpoint.

The Share screen is the control center for inviting players after your Hunt is saved or privately published. It shows the join code and QR code and may include buttons to copy, share, test-play, print a Hunt QR poster, print stop QR posters, submit for review, or finish with Done. Use this screen whenever you need to distribute access, print materials, test the player experience, or prepare a Hunt for an event. The Share screen is also a control center after publishing. Use it to test-play, copy the code, send the link or QR, print materials, and decide whether the Hunt is polished enough to submit for review.

No. The app is designed to run a deep validation before publishing and block incomplete or broken Hunts. This helps prevent players from receiving a Hunt with missing locations, unanswered puzzles, invalid branches, or other structural problems. You should still test carefully, because validation can confirm technical completeness but cannot guarantee that the Hunt is fun, clear, safe, or easy for your specific audience. This is one of the most important safeguards in the builder. It is better for a creator to see a fix list before publishing than for players to get stuck mid-Hunt.

Before private publishing, the app runs validation to make sure the Hunt is complete enough for players. It checks things such as whether stops have locations, puzzles have answers, and branches point to valid steps. If the Hunt uses Official Hunt Sponsor locations, you may also see reminders about participation hours and age rules. If something is missing or broken, the app should block publishing and show what needs to be fixed. Validation is meant to protect players from broken experiences. If the app flags missing answers, unresolved branches, missing locations, or incomplete steps, fix those issues before sharing the join code.

No. A private Hunt is not discoverable in the public catalog. Players must receive the join code or scan the Hunt QR code. This gives you control over who can join. If you later want The Hunt team to consider making a created Hunt public, use Submit for Review. The Hunt stays private unless it is approved for the public catalog. This protects private creators and customizers from accidentally exposing personal events, private routes, or unfinished content. Public visibility only happens through a separate review and approval process.

Publish Privately makes your Hunt joinable by code or QR code, but it does not place the Hunt in the public catalog. Private publishing is the normal way to share a Hunt with friends, family, teams, students, employees, customers, event guests, or invited players. Only people who have the join code or QR code can access it, as long as the Hunt is active and player slots are available. Private publishing is the moment your Hunt becomes usable by invited players. It is not the same as public catalog approval, so you can safely use it for testing, private parties, trainings, and small-group events.

Strong public Hunts are safe, clear, fun, polished, and easy for new players to understand. They use locations respectfully, avoid confusing dead ends, have fair puzzles, include helpful hints, and feel complete from intro to finale. Hunts with a distinctive theme, memorable story, strong local connection, or repeatable audience appeal are usually stronger candidates than one-time private party routes. The strongest submissions usually feel complete without the creator standing nearby to explain them. A public player should be able to understand the premise, follow the clues, complete the checkpoints, and enjoy the ending on their own.

Before submitting, make sure the Hunt is complete, polished, safe, original, and tested. Confirm that you have the right to use all images, audio, names, characters, artwork, locations, and other content. Check that clues are fair, checkpoint instructions are clear, branches do not break, AR works if included, and the Hunt is appropriate for the intended public audience. A Hunt that works for friends may need extra clarity for strangers. Also confirm that you have permission to use any images, audio, names, characters, logos, locations, or other materials included in the Hunt. Public review should happen after content rights and safety concerns are already addressed.

Submit your Hunt for review if you believe it could be valuable beyond your private group. This might include a strong city experience, clever puzzle Hunt, great date night, campus route, family adventure, brand activation, training concept, or creator-led story. Submission gives The Hunt team a chance to consider it for the public catalog, featured placement, or potential creator partnership opportunities. Submit only when the Hunt is something you would be proud to have strangers play. This feature is also a way to signal interest in possible featured placement or future creator partnership conversations.

No. Your Hunt remains private after submission. It will not appear in the public catalog unless The Hunt team approves it. This protects both creators and players by making sure public catalog Hunts are reviewed before broader release. Continue sharing the Hunt privately by code if you want invited players to access it while it is not public. Approval is a separate step. Until that happens, continue treating the join code as the only way people can access the Hunt.

No. Once a Hunt is submitted for review, it cannot be edited while the review is pending. This prevents the submitted version from changing during the approval process. If you need to make changes, wait for the review outcome or follow the app’s instructions if the Hunt is returned or rejected. Your Hunt remains private while it is under review. This lock protects the integrity of the review. If the submitted version could change while being evaluated, reviewers would not know which content, locations, or player experience they were approving.

No. Submitting a Hunt only asks The Hunt team to review it. Approval is not guaranteed. The team may reject a Hunt, ask for changes, or decide it is better suited as a private experience. Public Hunts need to meet a higher standard because they may be played by people who do not know the creator, the locations, the intended audience, or the story context. The team may consider quality, safety, originality, clarity, location suitability, rights to content, sponsor compatibility, and whether the Hunt is a good fit for public players. A private Hunt can still be valuable even if it is not approved for the catalog.

Submit for Review sends your privately published created Hunt to The Hunt team for consideration. The team may review it for public catalog inclusion, featured placement, quality, safety, originality, location suitability, content appropriateness, and possible creator partnership opportunities. Submission does not make the Hunt public immediately. Your Hunt stays private unless and until The Hunt team approves it. Think of submission as asking The Hunt team to review your private Hunt for broader use. It is not required for private sharing, and your Hunt remains private unless the team approves it.

You can share the code with more people, but once capacity is reached, additional players may be blocked from joining. For a controlled event, it is better to match your player capacity to your expected attendance before sharing. If you are not sure how many people will join, consider adding extra capacity so late arrivals, plus-ones, or additional teams are not turned away. For a small private group, this may not matter. For a public invitation, event poster, or large text thread, assume the code may be shared beyond the original recipients and make sure capacity is high enough.

The player count shows how many outside players have joined compared with the available capacity. For example, “0 of 5 players” means no outside players have joined yet and up to five can join under the current capacity. Your own test plays should not count. This display helps you know when a Hunt is nearly full and whether you need to add more player slots before inviting more people. The first number is how many outside players have joined; the second number is the current capacity. When that number approaches the limit, consider whether more people still need to join.

You can add more player slots by purchasing a player pack when available in the app. Packs may be offered in different sizes, such as 5, 10, 25, 50, or 100 additional players. Add capacity before sharing a code with a larger audience. If a player is blocked because capacity is full, adding a pack should allow additional players to join afterward. Player packs are intended for one-time capacity needs like parties, trainings, classes, or customer events. After adding capacity, ask blocked players to try the same join code again.

When your Hunt reaches its player limit, new players may be blocked from joining until you add more capacity. Players who already joined should still be recognized as existing participants, but new invitees may see a message that the Hunt is full or unavailable. If you are hosting an event, buy enough capacity before sending invitations so guests are not turned away at the last minute. If the Hunt is for an event, buy or confirm capacity before invitations go out. It is much better to have enough slots ready than to have guests blocked when they try to join at the start of the event.

No. Customize Hunts and Created Hunts use separate player-slot pools. This means capacity for one type of Hunt does not automatically apply to the other. Check the player count shown in the appropriate section so you know how many invited players can still join that specific type of private Hunt. If you are planning a larger group, confirm the right pool has enough capacity before sharing. Check the capacity shown in each section rather than assuming one shared pool. A player pack or allotment for Created Hunts may not be the same as capacity for Customized Hunts, so both dashboards should display usage clearly.

No. Your own creator or customizer test plays do not use outside player slots. This lets you test repeatedly while building. You should take advantage of this and test the Hunt carefully before inviting people. Outside player capacity should be saved for the real players who join through your code or QR. This encourages thorough testing. You should feel comfortable testing every step, every QR code, every branch, and every puzzle without worrying that you are using up space meant for guests.

No. Rejoining the same Hunt should not double-count the same player. Once a player has joined, they should be able to return to the Hunt without using an additional slot. This is important because players may close the app, lose connection, switch devices, or come back later. The slot is tied to joining, not to every app session. This is designed to prevent accidental double-counting if a player closes the app, changes devices, loses connection, or comes back later to finish. They should return under the same account when possible.

A player slot is used when a player joins with the code, not when they finish the Hunt. This means capacity is consumed at code redemption. If you plan to invite ten people, make sure you have enough capacity before sharing the code. A player who joins and stops playing may still count because they used access to the private Hunt. Because the slot is used at join, not completion, share codes thoughtfully. Someone who joins and never plays may still consume capacity unless the app or creator workflow later provides a way to remove them.

A player slot is one outside player’s ability to join your private Hunt by code or QR. Player slots control private Hunt capacity so creators and customizers can manage how many invited players can access their Hunts. Your own test plays do not count as player slots. Player slots are especially important for events, parties, classrooms, and groups where you need enough capacity before sharing the code. Player slots help creators control how many outside players can join private Hunts. They are separate from your ability to test your own Hunt and may differ between Customize Hunts and Created Hunts.

Players who are already mid-Hunt may be allowed to finish, but new joins can be blocked while the creator or customizer plan is inactive. This protects players who already started while preventing inactive accounts from continuing to distribute new private Hunt access. If you are hosting an event, confirm your subscription is active before sending the join code. This distinction is meant to avoid disrupting players who already started while still preventing inactive plans from continuing to bring in new participants. Hosts should keep their plan active before inviting a new group.

If your subscription expires or lapses, creating and editing may lock, and new players may be unable to join your private Hunts because the creator’s plan is inactive. Your content is not deleted. Your Hunts, drafts, join codes, and work should remain associated with your account so that access can be restored when you resubscribe or restore purchases through the appropriate app store account. A lapse should not erase your work, but it can affect your ability to build, edit, publish, or accept new players. Resubscribing or restoring purchases should bring access back to the account that owns the content.

Yes. Creator Access includes the ability to customize Hunts. A Creator subscriber should not need a separate Customize subscription to use Customize features. Creator is the higher-access tier, so it includes both full Hunt creation and the simpler customization workflow. This makes sense for users who sometimes want a quick customized route and other times want to build from scratch. This prevents users from needing overlapping plans. If you already have Creator Access, you should not need a separate Customize subscription to personalize existing Hunts.

Yes. Creator Access is needed to build a full Hunt from scratch or fully edit a cloned template. Creator Access gives you the complete builder, including story steps, puzzles, stops, choices, branches, AR, audio, images, publishing, and catalog submission tools. It is the right plan if you want control over the entire experience rather than only customizing the stop-level details of an existing Hunt. Creator Access is for building original Hunts and using the full editing system. If you want to create new story steps, puzzles, choices, branches, AR moments, or full templates, Creator Access is the correct tier.

Yes. Customize access is needed to take an existing Hunt and make a private version of it with your own locations, checkpoints, clues, and stop details. Customize is designed for users who want to adapt a ready-made Hunt without using the full creator builder. If your access expires, creating and editing may lock until you resubscribe. Customize access is for hosts who want the easiest way to make a private Hunt. It gives you the ability to personalize an existing structure without needing the full complexity of the creator builder.

No. A free account can play available public Hunts and join private Hunts by code or QR. Subscriptions are for users who want to customize existing Hunts or create full Hunts of their own. Some Hunts may still have availability rules, area restrictions, age restrictions, or player-capacity limits, but basic play and joining are not the same as creator access. Playing and joining are intentionally accessible so people can experience The Hunt without becoming creators. Paid access is focused on hosting, building, customizing, and managing private experiences.

Only if the app rules, location rules, and applicable laws allow it, and only if the Hunt is appropriate for players who meet the required age. Age-restricted locations may block underage players. If your Hunt includes bars, adult venues, alcohol-related stops, or 18+/21+ locations, make those expectations clear and pay attention to sponsor age restrictions and participation hours. If you use adult or age-restricted locations, make that clear in the design and confirm that all invited players are eligible. For mixed-age groups, create a route that avoids those locations entirely.

Only use content you own, created yourself, licensed, or have clear permission to use. This applies to music, images, characters, logos, artwork, audio, photos, brand names, and story content. Private use does not automatically make copyrighted material okay, and public catalog submission requires even more care. When in doubt, use your own original content or properly licensed assets. Rights matter more if you plan to submit the Hunt for public catalog review. A private event still should avoid unauthorized copyrighted material, but public distribution creates higher risk and may prevent approval.

Avoid uploading content that is illegal, unsafe, offensive, harassing, sexually explicit, hateful, violent, private, misleading, or inappropriate for the intended audience. Also avoid personal information, copyrighted material you do not have permission to use, images of people without appropriate rights, and content that could encourage trespassing or unsafe behavior. If you plan to submit a Hunt for public review, be especially careful that all uploaded content is appropriate and rights-cleared. Also avoid content that could confuse players into risky behavior, reveal someone’s private information, or make a location look officially involved when it is not. When in doubt, keep the experience respectful, safe, and clearly within public or permitted spaces.

If players need to enter a business, interact with staff, scan a QR code inside, look for a poster, gather in a group, or use the location as part of an event, you should have permission. Official Hunt Sponsor locations are already participating locations, but private locations you create are your responsibility. Respectful coordination helps protect the player experience and prevents confusion for business owners and staff. Permission is especially important when you want players to scan something inside, ask staff for help, redeem an offer, or gather as a group. Official Hunt Sponsor locations are the safer option when you want business participation already built in.

No. Use good judgment and only send players to places that are safe, appropriate, legal, and accessible for the intended audience. Do not send players into private property, restricted areas, dangerous roads, construction zones, employee-only spaces, unsafe neighborhoods, closed businesses, or locations where they might disturb staff or customers. A good Hunt should feel adventurous and fun, not risky or intrusive. As the creator or customizer, you are responsible for choosing appropriate locations and instructions. If a clue could lead players into traffic, private property, unsafe conditions, or uncomfortable interactions, rewrite it or choose another stop.

Your account-based Hunts and purchases should be recoverable when you sign back in with the same account and restore purchases through the app store account used to buy access. If you purchased before creating an account, complete account creation or restore using the same Apple or Google account. Do not create multiple accounts unnecessarily, because purchases and Hunts are intended to stay tied to the account that claimed them. Use the same Apple, Google, or email sign-in path you used before whenever possible. If you create a new account by accident, your purchases or Hunts may appear missing because they are tied to a different account.

That is expected. Once a Hunt is submitted for review, editing is locked while The Hunt team reviews the submitted version. This prevents the content from changing during the approval process. Your Hunt stays private unless approved. If the Hunt is rejected or returned, you may be able to edit it again and resubmit depending on the review outcome and app workflow. Wait for the review result before making changes. If you realize something is wrong immediately after submitting, contact the review/admin team or wait until the Hunt is returned or rejected so you can revise it cleanly.

Make sure the latest changes are saved. Check whether the top bar says Saved or Not saved, and tap Save or Save changes if available. Close and reopen the Hunt if needed. Also confirm you are viewing the correct Hunt version, especially if you have both a template, a customized copy, and a created copy. Avoid making major changes while players are actively using a shared Hunt. If players have already joined, be cautious about major edits because they may be seeing an earlier state or may be mid-flow. For critical events, finish edits before sharing and avoid live changes unless necessary.

Android placement is more limited in the current setup and requires horizontal floor-style placement. iOS supports more specific placement choices, such as wall or elevated surfaces, but Android does not currently offer the same level of specificity here. When designing AR for both platforms, avoid depending on wall-only or table-only placement unless the experience still works with Android’s horizontal placement behavior. Design your AR moment so Android players are not disadvantaged. If wall placement is essential to the puzzle, provide alternate instructions or avoid making that AR placement the only way to continue.

Try a different iOS Placement Type, such as Floor, Wall, Elevated Surfaces, or Auto depending on where the object should appear. Improve lighting, avoid reflective or blank surfaces, and scan the area slowly. Placement is not perfect in every environment, so test the AR moment at the actual stop. If placement remains unreliable, simplify the AR goal or give players clearer placement instructions. If possible, test at the actual stop where players will use it. A model that places well in your office may behave differently in a dim bar, bright outdoor area, reflective lobby, or crowded event space.

Adjust Model Scale to change the size. Increase the scale if the object is too small and decrease it if it is too large. Adjust Pitch, Yaw, and Roll to fix the starting rotation. Yaw turns the model left or right, Pitch tilts it forward or backward, and Roll tilts it side to side. Make small changes and test on device after each adjustment. Do not change scale, pitch, yaw, and roll all at once. Make one adjustment, test it, then adjust again so you know which setting is responsible for the improvement.

Confirm the file is a supported .glb file, under 15 MB, and exported as a standard non-compressed binary glTF. Draco-compressed and meshopt-compressed models are not supported. Make sure AR is enabled for the player’s device type, then test in a well-lit area with a visible surface. Ask players to move the phone slowly while scanning. If it still fails, simplify the model and test again. If the file meets the technical requirements but still does not appear, try a simpler GLB with fewer polygons and smaller textures. This helps determine whether the problem is the specific model, the environment, or the device.

Check the exact correct answer, accepted answer variations, spelling, spacing, punctuation, and whether players might reasonably phrase the answer another way. Add common alternatives, abbreviations, plural/singular forms, and versions with or without spaces. Test the puzzle yourself with real likely answers. If the answer requires a precise code, make that clear in the clue so players know the formatting matters. Have someone else type the answer the way a normal player would. Their wording often reveals missing accepted answers, unclear clue wording, or a puzzle that expects too much precision.

The issue may be GPS accuracy, the wrong location pin, arrival radius, the wrong QR code, a checkpoint type mismatch, an expired active window, closed sponsor-location participation hours, or a question answer that is not matching. Confirm which checkpoint type the stop uses. If it is Scan code, test the exact stop QR. If it is Arrival only, check the map pin and radius. If it is Question, review accepted answers. Troubleshoot based on checkpoint type. For arrival-only, check GPS and radius; for QR, check the exact code and placement; for Question, check accepted answers; for sponsor stops, check participation hours and age restrictions.

The Hunt may still be a draft, the join code may be typed incorrectly, the Hunt may not be published privately, your player slots may be full, your subscription may be inactive, or a required location may be unavailable due to hours or age rules. Ask one player to send a screenshot of the error message, then check the Hunt’s status, capacity, plan access, sponsor-location rules, and whether the shared code matches the current Hunt. Ask one blocked player what exact message they see, because the message usually points toward the cause. Then check the Hunt status, code, capacity, subscription state, sponsor hours, age rules, and whether the player is using the correct account.

Make sure the QR code is large enough, high contrast, fully visible, and not blurry, cropped, bent, damaged, covered, or affected by glare. Test the printed QR with the same type of phone players will use. If the code is on a poster, place it at a comfortable height with good lighting. If it still does not scan, regenerate or reprint the QR poster and confirm it is the correct QR for that Hunt or stop. If the code is printed, test the exact printed version rather than only the digital preview. QR codes can fail because of low ink, glare, wrinkles, small size, bad contrast, cropping, or being placed too far away.

Check that location permission is enabled for The Hunt, then move to an area with a clearer GPS signal. Tall buildings, indoor spaces, weak signal, and device settings can affect accuracy. If you are choosing a location while building, use the map picker or coordinates to set a more exact point. If players will use arrival-only check-in, test the stop on site and adjust the location or arrival radius if needed. If GPS is unstable, move outdoors or near a window, turn Wi-Fi on, and wait a moment for the device to update. For creators, verify the actual map pin because a wrong pin can make every player appear to be in the wrong place.

First, make sure Testing Mode is turned on for that Hunt in the builder, customization screen, or admin-controlled settings if applicable. The Mock At Destination button is a testing feature, so it does not appear during normal real-player mode. If it still does not appear, close and reopen the Hunt, confirm you are testing the correct Hunt version, and make sure you are in a location-based step where mock arrival is relevant. If it still does not appear, leave the Hunt and reopen it after confirming the toggle is enabled. In admin or testing environments, also check whether any global mock-location setting is overriding the normal behavior.

Before inviting players, save the Hunt, confirm it is privately published if needed, test every step, turn off Testing Mode, verify every location, scan every QR code, test puzzle answers and accepted variations, check branches, review sponsor hours and age rules, confirm player capacity, and print any needed QR posters. Then share the join code or QR code with your invited players and be ready to help if anyone has trouble joining. Do a final creator checklist before sharing: saved status, testing mode off, private publishing complete, capacity available, QR posters printed, sponsor rules reviewed, clues tested, answers accepted, and every route playable.

Use branches when player choices or puzzle outcomes should create a genuinely different experience. Keep early branches short until you are comfortable with the builder, and make sure each branch either rejoins the main path or ends cleanly. Use Choice steps for visible player decisions and Branch Overrides for puzzle-based outcomes. Test every route from start to finish, because a single broken Goto Step can confuse the whole Hunt. Branches are most successful when each path feels intentional and the creator has tested every outcome. Use branches to add replay value, personalization, or consequences, not just extra complexity.

Use AR when it adds a memorable reveal, clue, collectible, object, or surprise that strengthens the Hunt. Keep the GLB under 15 MB, avoid unsupported compression, test scale and rotation, and use clear HUD messages. Do not rely on AR for a critical puzzle unless you have tested it in the real environment and on the device types players are likely to use. A short, reliable AR moment is better than an ambitious one that fails. Think of AR as a special effect, not the whole experience. A reliable, memorable 10-second reveal can be much better than a complex AR step that some devices struggle to load.

Use question check-ins when players can prove they found the right place by observing something real. Good question answers can come from a sign, mural, menu, plaque, statue, window, display, product, classroom item, or event object. Keep the question clear, add accepted answer variations, and avoid answers that may change unexpectedly. This checkpoint type is great when QR placement is not available but you still want meaningful verification. The strongest question check-ins use information that is stable and visible. Avoid answers that depend on temporary displays, changing menu prices, staff availability, or anything likely to disappear before players arrive.

Use arrival-only stops for outdoor landmarks, parks, campus areas, walking tours, large venues, or places where a QR poster is not practical. Arrival-only is convenient but depends on GPS accuracy, so test it at the real location. If the area is dense, indoors, or surrounded by tall buildings, consider a Question or QR checkpoint instead for more reliable verification. Arrival-only is easiest for players, but it is not always the most precise. Use it when exact proof is less important than keeping the route moving smoothly.

Use QR codes when you can place them somewhere players can easily and safely find them. The code should be large, clear, and located where scanning will not bother staff or block other customers. Add a checkpoint hint that tells players where to look. Always test the exact printed QR code before the event, and make sure each stop QR is placed at the correct stop. QR codes are best when they feel intentional and official. Use printable posters or clean signage, avoid hiding them in awkward places, and make sure staff know what they are if players may ask about them.

The most common mistake is making clues too vague or assuming players know what the creator knows. What feels obvious to you may be confusing to someone else, especially if they do not know the location, inside joke, or intended route. Test with another person whenever possible. If they pause, wander, or ask what you mean, improve the clue or add a hint. Creators often underestimate how much context players are missing. Write for someone who does not know your plan, your route, your inside joke, or your intended solution.

Start from a template or customize an existing Hunt, then focus on the parts that matter most to players: clear locations, fair clues, simple checkpoint instructions, helpful hints, and a smooth ending. Use Testing Mode first, then do one real-world test if the Hunt uses physical stops. Print any needed QR posters, confirm player capacity, turn off Testing Mode, and share the join code only when everything works. For a first event, keep the scope manageable: fewer stops, clearer clues, simple checkpoints, and one strong finale are better than an ambitious Hunt that is hard to test. You can always build more complexity after your first successful run.