@ksksks, I do not know what you mean by 'the Better version'; however, I have tested the one I got with my Greenfoot 2.3.0 download and found no problems with it.

Only the owner of the scenario has access to other users UserInfo data. This does not mean that the scenario cannot be programmed to share some or all information of one user with another. My 'Private Messaging' scenario will display the names and profile pics of any user that has used the app; however restricts the sharing of the data stored (the 'score' field, the ten 'int' fields, and the five 'String' fields) to just one String field; and then, only if certain conditions exist (that communication is intended between the two users). I am the only one who can access all communications between the users because I wrote and uploaded the scenario onto the site. All in all, as far as total control, I would say that, yes, the author (or uploader) of a scenario has total access to all UserInfo data and controls what information is shared between users. The only thing the author cannot do (well, not very easily), is change what information is stored in the UserInfo data of other users. An author can program the scenario to alter the data for a user when they run the scenario while logged onto the site. Even if data is encoded, I cannot see how the key would not be accessible to the author (it would either have to be a programmed constant or it would have to be stored somewhere within the UserInfo data).

The problems created by this scenario are not checked for multiple solutions. True SuDoku puzzles will each have a unique solution; and those that do not, are not considered solvable.

There is a ball-paddle interaction glitch that needs fixing. Qualify the paddle bouncing with the y direction of the ball with each paddle.

You would only need to create the array if, and only if, you are not going to re-create the worlds when they are re-entered into. That is, if you want the worlds to be as they were when you main character left them, then you need to save the world in the array, so you can recall that same world when re-entered into. If it does not matter, and the world can create anew again, then the array is not necessary.

@askgriff, that is one way. Another would be subclassing the Level class and having an array of worlds in the Level class ('room' and 'level' fields would then be the indices of the array).