FileKit is one of the "secret sauces" Pley uses to make your games ultra-accessible. It is essentially a file streaming service but with ease of use in mind. No more worrying about versioning, compression, file duplications in memory and CDNs. All of this is handled by FileKit automatically for you.
In WebGL, the browser doesn't allow the game to access the file system. When you are trying to load or write a file to a disc the compiler emulates a virtual file system in memory. Consequently, the entirety of your game assets would be stored in memory, and to top it off, whenever your game would request an asset it would create a new copy of said asset as if "loading it into memory".
Combine this with the browser's enforcing a limit of 2GB RAM per tab and you can imagine how this is a big issue.
The solution to the above problem is to partition your game.
There are two ways to handle assets and content in a game. The first one is Game A's method; you bundle all your assets and all your content and they get downloaded when the player loads your game. Whenever you update any of your game content or assets, the user has to download the entire game every time.
In the second method, Game B's method; you divide your game's content and assets into multiple partitions (or bundles). You upload your base game (bare minimum content, assets and code) on the main server (where players download your game) and then you upload the rest to a secondary server that your game downloads when the user starts using the content.
You can see the second method used a lot in MMO (Massively Multiplayer Online) games. You download a small section of the game (likely the starter area) and as you go through that content, the game keeps downloading the rest of the content progressively to serve it as you need it.
Our current target is to launch (a fully interactive experience, not an in-game progress bar) any game within 30 seconds or less.
As you can guess, the second method is what we recommend when publishing your games on Pley. Since Pley is web-based, loading times and performance are very important.
The second method allows the player to access the game faster (since they only download a smaller size content vs the entire game's catalog). It also helps with game performance (by loading only the necessary content in memory) and this something FileKit helps with immensely!
FileKit works really great with Unity's Addressables. Given you can use Addressables in one of two ways, FileKit behaves differently based on this:
If you are keeping your content local (using
StreamingAssetsfolder) and loading your content/assets only when you need them, FileKit will detect this, host your assets on our CDN free of charge, auto-version it for you and compress it using Brotli. It will then remap all your asset loading code to FileKit to load them from our CDN and decompress them when needed automatically. This provides you with faster loading times of assets and less memory footprint.
If you are keeping your content on a CDN (be it Unity's or another), FileKit will detect this and not modify anything and keeps your references intact.
We echo Unity's sentiment in trying to avoid using the Resources Folder as much as possible due to its issues. Instead, we recommend that you use FileKit directly.
You can still use FileKit directly without resorting to neither Addressables nor the Resources folder. You can load a file directly by using
FileKit.ReadFile and providing the path and name of the file you want to load.
// SDK must be initialized first before using FileKit.
// When the level is loaded, load the player's image.
private void OnMainLevelLoaded()
// A call back triggered when FileKit is done with loading the image, assign it to the correct UI element
private void DisplayAvatarIcon(Result result, byte data, int dataLength)
myimage.sprite = (Sprite) data;
Paths provided to FileKit.ReadFile
You might have noticed above that we provided the method
ReadFilewith the path
StreamingAssets/. This is a special feature of
ReadFile, whatever path is given,
ReadFilewill understand that this path is inside the Assets folder of your project and will look for the file there. You don't have to use any special path resolution tricks to find what you want.
FileKit Error handling
Sometimes when you're reading a file, you may encounter errors while doing that. We provided the
Resultenum to help you find out what the exact error is and resolve it. The three main issues you can encounter with FileKit are:
Result.FlkFileNotFound: This is when you're trying to load a file that does not exist. We recommend you double check the path and the filename you're reading.
Result.FlkFileTooBig: This happens when you're trying to load a file bigger than 4 TB.
Result.FlkBufferTooSmall: This happens when you're providing a smaller buffer than the information passed. Providing a larger buffer will resolve the issue.
Updated 3 months ago