Large scale events - Checklist
Last updated
Was this helpful?
Last updated
Was this helpful?
Before kicking off your live event, there are a number of key steps to follow to ensure delivery of a seamlessly executed experience. We have compiled a checklist of items to help projects navigate this, covering a range of topics from setting up the right permissions, to ensuring your event has sufficient streaming capacity.
For your real event, you will want to ensure that both your event and world are set to public, in order for members of the public to be able to authenticate and join. You can see how to do this here:
Before the event however, you may want to test with a limited group of external stakeholders. The best way to test this without making your event or world public is by using access groups on your test world.
Ensure the world has public stream client access disabled.
Create a new access group, and add the relevant external user emails.
Grant them the relevant in-game roles that you want to test.
Once this is completed, you can send them a link to the connect page for the world (top right of the above image). The link is usually of the format:
{your-domain-name}.m2worlds.io/dashboard/connect/{example-lc-id-312712}
External users will be able to join the world via that link, while general members of the public will not be able to access your test world.
We recommend testing setting your event and world to public at least once before the event day to check all the required permissions are set up correctly.
In order to test how your world runs at scale, we recommend deploying your world with a target number of bots that can simulate real players to help projects check performance before going live.
Scale testing with bots is a crucial part of your project development process - many bugs/issues may not present unless stress-tested at sufficient scale. A rough guideline may be as follow:
Expected Max: < 250 -> Test: 1,000
Expected Max: ~ 1000 -> Test: 2,000
Expected Max: 1500 - 2500 -> Test: 5,000
Expected Max: >2500 -> Test: 10,000
We highly recommend projects scale test at regular intervals throughout the project development life cycle.
Performance testing can help you identify:
Framerate issues on certain event triggers at scale (e.g. drops in fps when spawning certain collectibles)
Collision issues within your level that are hard to identify when testing with limited players (e.g. players falling through floors, walking through walls, escaping the map)
Issues with custom avatars/MML objects loading and rendering at scale.
Unexpected crashes during your playtest
For any crashes encountered during performance testing, we recommend sending a report (a prompt will appear upon crashing) and raising a request in your support channel, at which point your assigned support engineer will be able to assist.
For testing performance at scale, projects can:
Self-deploy bots into their test world via the dashboard: you are able to deploy up to 2000 bots for worlds set to the "Large" scale settings. We recommend doing this to stress test your deployment.
Run a playtest with real users: if you're interested in ways to appropriate scale test your world, or need support in doing so, please reach out to your M² support engineer or account manager.
If you are planning on running tests with thousands of bots, please notify your support engineer ahead of time, as these tests can be costly if left running for extended periods of time
This should be done at a regular cadence, but can be done at the project's discretion. We recommend running scale tests with many bots/real users towards the end of your project development cycle.
For more detailed performance analysis, please reach out to your support engineer.
Platform provided support for Moderation will be deprecated in the future. Please check back to this page to be notified of when this supported functionality has been removed.
For your event, you may wish to moderation the language/text from your event's text and voice logs.
Our platform provides some out of the box profanity filtering for chat messages. Additionally, M² can provide internal tooling to support projects with moderating in real time, as well as systems for automatically muting/banning of users based on our custom ruleset.
To set this up, please reach out to your project's support engineer. You will also need to arrange for an M² representative to monitor your chat logs in order to support dynamic muting/banning during the event.
This should be tested as part of final rehearsals, ~ 1 week before the event. If you have specific moderation rules you want to set up, reach out to your support engineer ahead of time so this can be set up.
In order to support streaming for users, you must ensure that:
There is sufficient streaming capacity for the event
If you are expecting a turnout of >200 users:
Due to limits on streaming capacity, you will need to coordinate your event time and capacity expectations with M². Please reach out to your account manager to check that there will be no contention on the network with other events at your scheduled time.
Alternatively, you can mandate that users only use native downloaded clients to bypass streaming capacity limits.
If you are expecting a turnout in excess of 1,000 users, your technical account manager can coordinate the reservation of capacity with M²'s pixel streaming provider.
Please note - reserved capacity is only available to those on our Premium Support tier.
You are on a streaming-supported release version.
For reserving streaming capacity, Nvidia streaming requires 4 weeks notice for reservations.
For upgrading to your final release version, this should be done as soon as feasibly possible (for example, when you choose to update your project version depends on the frequency of our releases).
For some events, you may want to enable queuing for your world in order to manage the load of many hundreds of users trying to join your experience at once.
To enable queuing for your event, ensure this is set up before your world is launched. You can find more details on our queuing system here:
This should be tested as part of final rehearsals, ~ 1 week before the event.
Some events may want to constrain access to users from specific regions, e.g. EU only attendees.
M²'s pixel streaming provider covers most countries; however there are some gaps - to ensure that your target audience can attend via pixel streaming, please refer to:
If you wish to geo-lock your event to a particular location, please reach out to your project's support engineer before the event day to set this up.
This should be tested as part of final rehearsals, ~ 1 week before the event. This is especially the case if you need to test with users outside your geo-locked location.
As part of an advanced M² support package, we offer a War Room service where members of the M² engineering support team will be made available during your event.
Our engineering support team will support in the live running of the event, overseeing any technical issues that may arise, and answering ad hoc questions you may have during the course of the event.
Issues with player fidelity and functionality at different player LOD levels, and when transitioning between those levels. For more information on player LOD levels see .
Before performance testing please make sure that your bots are able to exercise the behaviours you're implementing within your world. For details on how to setup bots, and configuring custom behaviors for them see .
When performance testing, you're looking to validate that your world performs as expected when under load. For client performance analysis we recommend using traditional Unreal performance analysis tools like along side a download client. You can also get some high-level server performance details from world dashboard section:
If your project version is too old to support streaming, you will need to upgrade your project to a newer release. You can follow our guide on upgrading .
To find more details about War Rooms, please read more .
