Print one Access Portal, stick it to your wall, and your floor starts earning. Guests scan it, pay for their own session, and you take half of every entry — on their headset or one of yours. Build the park from your phone out of a catalog of attractions other people keep adding to. No ticket booth, no imaging afternoon, no capital.
Every guest funds their own session. You are paid a share of what they spend walking in — on their headset or one of yours, it costs you nothing to run.
The companion app is an operator's new best friend: every park you run in one place, a catalog of attractions to choose from and full control over all the headsets on your floor. No laptop, no installations, no back office.
24
My New ParkVirtual park
2
Boost VC IndoorVirtual park
0
Winslow GreenBainbridge Island, WA
59
Fair Worlds TestSeattle, WA
0
Keystone YardPlacerville, CA
0
New PlaceSacramento County, CA
Entry is a whole number of Plays that you set, and it is then pinned — no minimums, no subscription required, and no meter. Every guest who walks through is worth exactly the same to you whether they sprint out in four minutes or close the place down, because one entry buys the whole local day. That is a number you can quote a birthday party on and forecast a Saturday with, rather than find out about on Sunday.
Ten guests, ten identical charges. Your cost per head is a number you chose, so every ticket you sell has a margin you already know.
The guest who lingers costs triple the one who rushes. You find out what Saturday cost on Sunday.
A Play splits three ways and you are the first cut. Half of what is left after the app store goes to you; the developers whose attractions actually ran that session split the rest with us. Nobody is paid out of your balance — the guest funded all of it.
A guest's Play → 50% to you, then the rest to the developers who built the ride
Want something nobody else has? The developers building these are in the DreamPark Discord — ask for the attraction your park needs, or find what shipped this month before it reaches anyone else's floor. Find a developer →
Buying DreamPoints is for the sessions you fund yourself. Subscribe on the web and none of your money goes to an app store's 30% cut — then the plan discounts it again, and the discount deepens every step up. A busy operator's DreamPoints cost a third less than face value.
Every step up is strictly cheaper per point, so no tier is ever beaten by stacking smaller ones — and at the top a point costs 0.667¢ instead of a penny. Unused points roll over, points already credited are yours whatever happens to the plan, and you can cancel any month.
What a Play is worth, what you earn on one, what you can and cannot cash out, and what an Access Portal costs. Short answers, and the page that proves each one.
The single unit everything on the platform is priced in. Under the hood a Play is a flat 100 DreamPoints — fixed, permanent, and never shown to a guest — and a DreamPoint is worth about 1¢, so a Play carries about a dollar of face value wherever you see it. At a consumer park one Play is one guest, one park, one local day, with unlimited re-entry inside it. At your park you set the number of Plays and the session window yourself. Guests buy their own Plays in the app; you buy Plays only for the sessions you are funding.
Plays you paid for never expire — not at the end of the month, not when a plan renews, not if you cancel. That covers everything bought in a plan, a top-up pack or an in-app purchase. The only balance with a clock on it is promotional credit we gave you (placement incentives, beta credit, orbs), which may lapse after 18 months of a completely inactive account. And when something bills, promotional credit is spent first — so the Plays you actually paid for are always the last to drain.
They roll over and stay yours. A subscription resets what is included each month; it does not reset your balance. A quiet February simply leaves you with a bigger cushion for spring break — there is no use-it-or-lose-it month on this platform.
Roughly 35¢ for every Play a guest spends at your door. A guest arriving on their own headset at a five-Play entry earns you about $1.75; one taking a rental at ten Plays earns about $3.50. The split is nested rather than one flat percentage: the app store takes its cut off the top, you take 50% of what is left, and developers take 50% of what remains after that. So the exact figure moves a little with how the guest paid — a Play bought on the web carries more through the split than one bought inside an app, and a promotional free play carries almost nothing, because we collected almost nothing. You earn on guests who arrive by scanning a placed Access Portal.
No — and that is deliberate rather than a policy we might relax. Plays you bought are closed-loop credit for using DreamPark: never redeemable for money, never transferable to another account. That is the line that keeps the currency out of money-transmitter and stored-value regulation, which is what lets us run it at 1¢ a point with no fees on top. Buy roughly what you expect to need, and let the rollover carry the rest. What your park earns is a different balance and a different question — that one is a revenue share, and it does pay out.
As a revenue share — the same rail, and the same rate, a developer is paid on. Earnings accrue as DreamPoints and convert at 1 DreamPoint = 1¢. This is the half of the answer above that is not closed-loop, and the difference is where the balance came from rather than what it looks like: Plays you bought are credit you spend here, while DreamPoints your park earned from guest entries are your share of money we actually collected on your behalf. The two are tracked separately on your account for exactly that reason, and only the earned side is payable. The payout schedule, minimum and method are not published yet — when they are, they will be in your operator terms and on this page, not in a support thread.
It is the printed code a guest scans to get into your park — your physical front door, and the thing that makes a park earn. $25, once, ordered on the web rather than in the app, because the App Store requires physical goods to be bought outside it. You place it where guests arrive and anchor it once, so we know where in the world that door is; from then on every guest who comes in through it is attributed to you. A guest who gets in another way still plays — you just do not earn on that session. One Portal per door, so a venue running two entrances can tell them apart.
If the guest paid in Plays: nothing at all. That is the rule the whole model rests on — exactly one party funds any given session, never both — so a guest spending their own Plays at your door covers that session outright, headset included, and your cost for it is $0. You spend Plays only when you are the one selling entry: taking cash or a booking at your own door, off-platform, where you keep the spread. There is no footprint tier, no per-minute meter and no per-attraction rate any more — entry is a flat number of Plays that you set.
No. This is the part operators usually double-check, so plainly: the price is flat. It does not meter, it does not surge, and it does not vary with how long a particular guest lingers. You set a whole number of Plays and a session window, and that is the price for guest one and guest nine hundred alike. At a consumer park a single Play covers the whole local day with unlimited re-entry, which is the opposite of a meter. The number per head is one you chose, which is what makes it possible to price a ticket or quote a birthday party without guessing.
Yes — one balance, on your account, and that is a deliberate change from the per-park pots we used to run. A park is somewhere that earns now, not a jar you have to keep topped up, so there is nothing to strand at a park you close and nothing to blend across parks priced differently. Plays sit on the account; a guest-funded entry settles against the guest; and what your parks bring in is reported per park and per Access Portal, so you can still tell which door is doing the work.
No. There is nothing to buy in advance, so there is nothing to write off. Nothing is charged and nothing is earned until a session actually runs. That is the whole difference from tickets: the money follows something that happened rather than a bet on a Saturday placed weeks earlier.
Your account carries one balance, counted in Plays — no currency figure to interpret and no per-park estimate to reconcile. It also moves slowly, because guest-funded sessions never touch it: it drains only for the things you are genuinely buying, like selling entry yourself at your own door, or a rented fleet's weekly charge. So you top up when that one number looks short against the weekend you have booked, not when an invoice surprises you.
The guest keeps playing. A session already underway is allowed to run you a little below zero rather than ending someone's birthday party at the till, and it is flagged unfunded on your dashboard so you can top up. Unfunded sessions still pay developers, so leaving them to pile up is not free — but no guest ever sees an error because of it, and a headset is never blocked at the door. A guest paying with their own Plays is unaffected either way: that session was never drawing on your balance.
Because the app stores take up to 30% of anything bought inside an app, and they take it before the money reaches you. Buy here and none of that happens: the full amount lands in your balance, and subscribing discounts it a further 10–33% on top, with the discount deepening as the plan gets bigger. It is the same haircut that decides what a guest's Play is worth to you — one bought on the web carries more through the split than one bought in-app.
Never — and on a guest-funded session you do not pay them at all. A guest's Play is split once, in order: the app store takes its cut off the top, you take 50% of what is left, and developers take 50% of what remains, divided by where your guests actually spent their time. DreamPark keeps the rest. You do not sign title deals, negotiate rates or chase invoices — and because the developer share follows playtime, every developer on the platform has a reason to make the thing standing in your park better.
They convert at full face value: 1 ticket = 500 DreamPoints, which is 5 Plays, credited as purchased Plays that never expire. Flat pricing quietly made that worth more than it was: at the consumer rate of one Play per guest per day, a ticket that used to buy a single session now covers five.
No — bring your own and manage them through ArborXR, ManageXR or our MDM, whichever you already run. More to the point, your guests increasingly bring their own, and that is the best session on the platform for everybody: they pay their Plays, you earn your share, and the hardware costs you nothing. Renting is for operators who would rather not own depreciating hardware: units arrive configured and enrolled, cost 15 Plays per headset per week, and scale down the moment you stop needing them. Renting does require an active plan, because a recurring fleet needs a recurring balance behind it. A rented headset in a session the guest paid for costs you nothing on top — exactly one party funds any session, never both.
Your fleet is marked delinquent and you get a grace period of three days to top up, during which everything keeps working normally. Past that, the rented units are remotely locked until the balance is settled — rented hardware only, never your own, and never mid-session. Paying clears it.
No minimum spend, no term, no per-park licence fee. Plans are monthly and cancel any month; Plays you already bought stay in the account after you cancel. The fleet is the only commitment, and it is week to week. An Access Portal is a one-off $25 purchase, not a subscription.
Yes, and it is the fastest way to reach us. Operators compare what actually draws a crowd, developers take requests for the attractions they build next, and new titles, jams and events are announced there before anywhere else.
Create an account, place your first attractions, set your price, and open. You know what every guest costs before the first one walks in.
