This device can only spawn one player. You will need to place individual spawners for islands with multiple players. Otherwise, they will always fall from the sky and have to parachute down.
Spawning players in the sky if a spawn device was recently used is unintuitive
Requiring MANY spawn devices (max player count) to avoid sky spawns is clunky and messy
For small maps and/or small spawn areas, having to create a dedicated spawn device room to teleport players into the desired starting area is also clunky, messy, and unintuitive
The lack of volumetric spawns makes defining an area/room as a spawn area is tedious and cumbersome - one shouldn’t have to place oodles of Player Spawner devices to do so
The Spawn Player When Receiving From function is essentially impossible to use without Verse or a big logic chain - one has to manually track what spawners have been recently used to prevent the case of spawning a player in the sky
The Ask
Allow players to use the same Player Spawner device in quick succession without failing and putting them into the sky.
Scenario: Spawning → Player Collisions Are Off
Prioritize spawning players at spawn devices with less players on them
If there are no unblocked spawns, allow players to spawn and cluster atop the same device without issue
Scenario: Spawning → Player Collisions Are On
Prioritize spawning players at spawn devices with less players on them
If there are no unblocked spawns, spawn players atop each other in a stack
Scenario: Specify Volumetric Spawn Regions
Allow developers to specify that a Player Spawner should use a volume rather than a single point
Spawn players in the volume in a way that reduces player overlap as much as possible; following the above scenario philosophies
I like the idea, but I don’t think this is the direction Epic picked. Instead of making devices with many settings (or complex systems), they are moving towards building low-level Scene Graph components. The developers are expected to build their own systems that fit their specific needs by putting the components together on an entity (or more) and gluing them together with a Verse component.
Sadly, the settings of complex devices can end up with bugs when certain combinations are picked. Additionally, introducing new settings becomes a lot harder and produces even more bugs.
That is why I’m at crossroads with “where are they going to take this”?
If they will create more devices for some of these use cases or find something else?
as they release content that seems a little “temporary” if they are going with “entities with custom components”, and if they can tell more clearly which direction they are going with some of the other content.
as some devices just stack up with similar enough features to cancel another device out, but then another device has that event that you may need, becoming a spaghetti and nightmare to change, unless you make an “not broken” verse device for your specific needs. more so when you have to handle a lot of events and devices, like various spawn devices, timing, loot and so on.
sometimes it feels like features on some devices could be an own and more simple device used in a wider range, and if one had grouping, it could be easier to use. which might not be that far from using or putting component blocks onto an entity, if one could do that for an complex device with “simple/straightforward function devices” attached. until it all comes back to visual scripting.
FWIW there’s definitely a reductive middle ground that’s just “don’t spawn players in the sky - if you want two players to use the same spawner at the same time they will, but if player collisions are on, they’ll get stuck together”.
Scenario: Spawning → Player Collisions Are Off
Scenario: Spawning → Player Collisions Are On
Scenario: Specify Volumetric Spawn Regions