Ideally, we should be able to tell people:
- Put the InitSDK node on all your map's Level Blueprint's BeginPlay (or in your map's GameMode OnBeginPlay in C++) and it should "just work TM".
- This node should also configure BeamPIE magically so that no additional setup is required.
Another few things about our initialization flow:
- Today, you can enable and disable our systems (or delay their initialization) as the main way to customize this process.
- This is a bit of an all or nothing approach and doesn't seem flexible enough.
So...
- We should also modify our BeamRuntimeSubsystem lifecycle hooks to work a little different:
- Library-like: At each point in the lifecycle, the user should get an object that exposes the list of managed subsystems over which they can call any operations and append their handle to an array. That point will wait for those operations and collect/report errors accordingly. This will also allow users to attach diagnostic at the callsite for debugging purposes.
- By default, this object will also expose controls for our default implementations of these systems initializations:
- "You can set which stats you want to automatically fetch here"
- "You can set which item scopes you want to automatically fetch here"
- "you can disable automatic stats initialization"
- etc...
- The flow would be: earliest possible callback get a configuration API you can call to set up various toggles and things about how you want us to initialize the SDK for you.
- The reasonable defaults:
- All our subsystems will implement and expose a "default per-lifecycle point operation" that you can call as the equivalent of "please enable this system as you would in the default path".
- Our default setup uses the same system our customer --- its just the fallback implementation of their customization system.
There's some implementation questions still, but... this seems like a much more flexible and straightforward approach to initialization. Also, because this will be integrated with BeamPIE --- it'll greatly reduce onboarding friction to use it.
Ideally, we should be able to tell people:
Another few things about our initialization flow:
So...
There's some implementation questions still, but... this seems like a much more flexible and straightforward approach to initialization. Also, because this will be integrated with BeamPIE --- it'll greatly reduce onboarding friction to use it.