This is a patch release and contains bug fixes, performance improvements, and usability improvements.
Through a few mechanisms, we’ve improved the Beamable initialization times by roughly a factor of 2, and content resolve times by multiple orders of magnitude. When Beamable initializes, there are 4 general networking steps that need to occur;
In Beamable 1.0.0, those 4 steps were happening in sequence. Now, in this patch release, the last 3 steps all begin at the same time, and execute in parallel. In high latency network conditions, this is a major speed improvement. Additionally, Beamable switched the internal representation of access token expiration from a date string, to a numeric-based timestamp. The numeric representation prevents the need to do any date parsing, which saves about a quarter of a second in initialization speeds on a Google Pixel 4A. Additionally, games with lots of content can take advantage of the Content Baking feature, which is now supported on all platforms. In 1.0.1, the content manifest is baked alongside the content objects and included as a resource in builds.
There were several UI glitches in the Microservice Manager UI/UX that have been fixed, including some broken icons, broken text wrapping, and inconsistent texts between windows. Critically, the ResolveAll() function that was used for Content downloading has been fixed. Previously, the implementation of ResolveAll() would trigger a stack overflow under certain conditions. The method would actively try to run up to 50 content downloads in parallel. As soon as one download finished, the method would start a new download. However, the new download was represented as a recursive call from the original download’s Promise success callback. Depending on network conditions, it was possible for one chain of method execution to reach the stack frame limit and trigger a fatal crash. Our new solution uses a batch mechanism internally instead of a rolling recursive mechanism. Instead of using callback recursion to schedule all the downloads, the new method creates a data structure to represent the downloads and enumerates it over time. Lastly, there was a bug in the micro-storage feature where document Ids weren’t being set correctly when using the mongo driver’s replacement functions.
Apple has changed how they entrust the player’s device id to developers. You can read about it here. Beamable is not creating a workaround for this behavioral update starting in iOS 14.5. However, if a Beamable customer wants to change the internal deviceId that will be reported to the Beamable backend, they can use the updates in 1.0.1. Please reference this code to override the deviceId. In general, you can unregister the standard IDeviceIdResolver implementation, and register your own custom implementation.
A few community members on the Beamable Discord brought up some great points about our package. We’ve changed our internal usage of the AssetDatabase.FindAssets function to use fully qualified class names. This should limit the cases where Beamable accidentally loads types of assets defined in customer projects. We’ve also configured all of our assembly definition files to “overrideReferences” which should stop them from automatically referencing every assembly in a customer’s project.
The full changelog history can be found on our Github, here…