Known Issues

Gateway's challenge system is designed around static, design-time definitions. All challenges must be defined upfront in a Data Asset before the game runs. There is currently no mechanism to create, modify, or inject challenge definitions at runtime — meaning challenges driven by a live backend, a rotating schedule, or any form of procedural generation are not possible with the current architecture.

This affects use cases including but not limited to:

This is a known gap and runtime challenge support is planned for a future release. If this feature is critical to your project, please factor it into your integration decision before purchasing.

The GatewaySavingProvider covers the expected saving needs for most projects out of the box, but it is not designed to be significantly restructured. The debounced saving strategy, the slot system, and the underlying save game class are all functional as-is, but deviating far from this setup — such as replacing the persistence backend entirely, integrating a third-party save system, or changing the fundamental save flow — is likely to require non-trivial work and may not be well-supported by the current architecture.

Minor customization through subclassing is possible, but if your project has specialized or complex saving requirements, evaluate the fit carefully before building on top of it.

When debugging a multiplayer session in PIE with more than one player, all players will read from and write to the same save slot by default. This means player data can collide and overwrite between clients, making it difficult to accurately test per-player progression in a local multiplayer session.

The current workaround is to manually call SwitchSlot — or use the SwitchSlot console command — early in initialization to assign each player a distinct slot name during testing.

A more ergonomic solution — where a debug build automatically separates save slots per player when multiple clients are detected — is a planned future improvement. For now, manual slot separation is required for reliable multiplayer save testing in PIE.

If you encounter a bug or limitation not listed here, please reach out so it can be tracked and addressed. Known issues will be documented on this page as they are identified, along with workarounds where available.