Judge the content by the visitor's task
A familiar game can attract attention, but attraction and explaining a product are different objectives. Before comparing development options, write down what a guest should do and remember. Then test whether an existing experience actually delivers that outcome.
Existing content can reduce the amount of new creative and development work. It still needs compatibility checks, permitted use, configuration, staff preparation and a full trial. Custom content offers control over the intended interaction, but introduces design decisions and approval work that the client must participate in.
Compare three procurement routes
| Route | What can make it useful | What to verify |
|---|---|---|
| Existing experience | The activity already matches the event goal | Public-use rights, supported hardware, languages, session length and reset |
| Configurable experience | An established mechanism can accept agreed branding or content changes | Which elements are truly editable and who performs the adaptation |
| Custom development | The product, story or interaction requires a specific design | Prototype, scope, source assets, review stages and ongoing support |
A configurable product sits between the other choices only if its actual editing options fit the brief. Adding a logo outside the headset does not make the in-headset story a custom brand experience. Ask to see where the visitor encounters the intended message.
Check event-use rights before preparing stations
Ask the content provider to confirm the permitted event use, dates, territory, station count and any public display or recording requirement. Keep this confirmation linked to the exact title or version. An ordinary purchase receipt alone does not answer every question about an event deployment.
Valve's Steam PC Café Program is an official route for operating participating games and VR experiences in public venues. Its setup documentation describes different account and licence arrangements. This is a platform-specific example; confirm the applicable route and available content for your event rather than assuming every store title is included.
For commissioned content, also agree third-party assets, music, fonts and the rights to edit or reuse the result. The contract should identify what is delivered and what remains dependent on another platform or licence. These are procurement questions for the actual project, not automatic ownership rules.
Worked example: an event attraction or a product explanation
Imagine a hypothetical exhibitor launching a new industrial tool. One proposal offers an existing VR challenge unrelated to the tool. Another adapts a configurable scene with approved product images. A third builds a short interaction in which the guest uses a simplified virtual version of the tool.
If the objective is to provide a brief attraction alongside staff-led product conversations, the existing challenge may be enough after its operation and rights are verified. If the objective is to demonstrate the tool's distinctive action, the unrelated game cannot meet it just by adding brand graphics to the stand.
Before choosing the custom route, build a small prototype of that one action. Ask product specialists whether it communicates accurately and first-time participants whether they understand what to do. If the action requires extensive explanation, revise the concept before creating a large environment. This example is not a report of a client project.
Evaluate event operation in either route
Trial the complete session: launch, instructions, controls, experience, exit and reset. Check whether staff can return to a known starting point and whether online accounts or updates interrupt opening. Include the intended spectator view and a way to assist someone who stops early.
For existing content, ask whether tutorials, menus or long introductions can be managed through supported settings. For custom content, specify the event opening sequence and operator controls explicitly. Do not assume that development of the visitor scene includes a usable staff interface.
Plan reuse without assuming zero preparation
List the expected future venues, languages, devices and content changes. A reusable core may be valuable, but a different headset, brand campaign or operating system can require review. Separate the right to reuse from the practical ability to deploy and support the application.
Compare the first event and the likely repeat events using the same scope headings: content, adaptation, licences, hardware, preparation and operation. Avoid a simple “development divided by event count” calculation that leaves future maintenance and event delivery out.
Decision checklist
Does the actual experience deliver the visitor outcome?
Are event-use rights and supported platforms confirmed?
Which branding, language and interaction changes are possible?
Has the full session and reset been demonstrated?
Are approval, support, handover and reuse responsibilities recorded?
Common mistakes are selecting a popular title before defining the message, assuming all content can be rebranded and treating custom development as automatically better. Share the goal and candidate content with interactive installation planning, together with the proposed VR equipment.