What would it take to have 100 full persistent boards in a server? We want this because
If I'm collaborating with someone on a project, we could easily have 100 pages of calculations or working notes.
If I'm teaching a class, it would be cool to have the material spread out over a large landscape as suggested in this image:
This is the thought behind "loci" (https://metauni.org/posts/loci/loci). However, the technical foundations of metauni aren't sufficient yet to support that. I estimated here (https://github.com/metauni/metaboard/issues/19) that a board full of text costs about 200Mb. That's more than we would typically write on a blackboard full of math, so let's say 150Mb. So we can handle 10 full persistent boards (in one experiment this used 1900Mb) but not 100.
There are several technical obstacles:
(a) Board loading and saving has to be fast and asynchronous (i.e. not blocking world load, and not taking too long at world end).
(b) Memory usage: we can't have all the parts for all the boards in the world at once.
(c) DataStore limits: we probably can't store 100 full persistent boards with a single DataStore key, as the limit is 4M characters (https://developer.roblox.com/en-us/articles/Data-store).
(b) We either adopt global content streaming (https://developer.roblox.com/en-us/articles/content-streaming) or bake our own. It should be relatively straightforward to parent the Curves folder to ReplicatedStorage on the client if the board is a sufficient distance from the player (with the possibility of overriding this manually if necessary, if people want to sky-write with their boards or use them for some other purposes where long-distance reading is necessary. We can give the boards a special appearance so that when you see a board far away that is "cloudy gray/black" you know it is being blanked out until you get closer).
(c) Using one key per board will be slow, although experiments might overturn this intuition (based on my experience with persistent Weiqi boards many months ago). However maybe we can cluster boards in some arbitrary way and have one key per 10 boards, or something like that. Or we can switch to a solution based on AWS, although this will only be feasible for private servers that cost money (since somebody has to foot the AWS bill). I think eventually we will outgrow the DataStore solution anyway, so maybe there are free servers with caps on the number of boards that are persistent (the cap being determined by DataStore speed and storage limits) and paid private servers with no limits.
What would it take to have 100 full persistent boards in a server? We want this because
This is the thought behind "loci" (https://metauni.org/posts/loci/loci). However, the technical foundations of metauni aren't sufficient yet to support that. I estimated here (https://github.com/metauni/metaboard/issues/19) that a board full of text costs about
200Mb
. That's more than we would typically write on a blackboard full of math, so let's say150Mb
. So we can handle 10 full persistent boards (in one experiment this used1900Mb
) but not 100.There are several technical obstacles:
(a) Board loading and saving has to be fast and asynchronous (i.e. not blocking world load, and not taking too long at world end). (b) Memory usage: we can't have all the parts for all the boards in the world at once. (c) DataStore limits: we probably can't store 100 full persistent boards with a single DataStore key, as the limit is 4M characters (https://developer.roblox.com/en-us/articles/Data-store).
However these seem not too difficult to overcome:
(a) with @BenSBk's asynchronous loading and saving this should be OK, provided the cold start problem (https://github.com/metauni/metaboard/issues/22) is fixed.
(b) We either adopt global content streaming (https://developer.roblox.com/en-us/articles/content-streaming) or bake our own. It should be relatively straightforward to parent the
Curves
folder toReplicatedStorage
on the client if the board is a sufficient distance from the player (with the possibility of overriding this manually if necessary, if people want to sky-write with their boards or use them for some other purposes where long-distance reading is necessary. We can give the boards a special appearance so that when you see a board far away that is "cloudy gray/black" you know it is being blanked out until you get closer).(c) Using one key per board will be slow, although experiments might overturn this intuition (based on my experience with persistent Weiqi boards many months ago). However maybe we can cluster boards in some arbitrary way and have one key per 10 boards, or something like that. Or we can switch to a solution based on AWS, although this will only be feasible for private servers that cost money (since somebody has to foot the AWS bill). I think eventually we will outgrow the DataStore solution anyway, so maybe there are free servers with caps on the number of boards that are persistent (the cap being determined by DataStore speed and storage limits) and paid private servers with no limits.