STRESS-TEST of cloud variables. It provides five 'slots' for users to ping each other, with a timer showing how long before a response is received from a pinged user. 'Time Connected' is time since the user clicked the Green Flag. If no slots are available, you are placed into a queue. SEE NOTES BELOW for important implementation info...
* UPDATE 5 * Cloud seems much faster now, so made it do things much more quickly... :) * UPDATE 4 * Added initial cloud status test (a New Scratcher will see "ERROR: Not connected to cloud!") * UPDATE 3 * Tried to make it a bit more robust. * UPDATE 2 * User count flips between the number of users and zero so you can see without starting the project if there is someone already there (if it's not flipping, nobody is connected). * UPDATE 1 * Added audible ping alert, and connected user count. * NOTE 1* queue & slots only show connected users when running * NOTE 2* If there is nobody else currently connected, you can still ping yourself, but you can't test it out by running more than one copy with the same username, unfortunately :( So, it appears that checking & changing different cloud vars together is not very robust - it has to be done very slowly (like only once per second), or the others never see the changes... ** IMPLEMENTATION INFO ** Cloud variables are a useful innovation for Scratch 2.0, but it's really not that straightforward to make robust use of them for a multi-player game. This is because a user can change the value of a cloud variable without realising that it has already been changed by another user since the last time they got the value from the server - the data was 'stale', and the new calculation of the value for the cloud variable may be wrong (it maybe should depend on the newer value, set by second user, rather than the old value). First of all, the implementation here attempts to be more robust by using something like a mutex lock (a cloud variable that is used to check if it is ok to make changes to some other cloud data, such as the queue, or when kicking disconnected users from the connected list). But it isn't a proper mutex because of the above 'stale data' problem. So we have to check we really have it to ourselves a couple of extra times, over about a second, before we assume we can go ahead (see locking blocks inside). Secondly, the implementation here makes use of a single cloud variable for each 'connected' user (i.e. once you are out of the queue). This means only you should have control over that variable (assuming all the queuing worked correctly), and other users can read the value any time. If this does prove to be more robust, it could form the basis of a five-player online game, with a queuing system for when all five slots are taken.
