Improve the "Player Spawner" device for non-BR scenarios

The Problem

The official documentation for the Player Spawner device states the following:

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.

What!!?

For non-BR islands, the following problems arise:

  • 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.

:family: 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

:tokyo_tower: 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

:package: 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

Thanks!

(post deleted by author)

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.