Greenfoot 2.2.0 beta

Hey just noticed adding tags from the edit option on a scenario on the gallery isn't working. And I ran into a problem when I had an abstract class that has some constructor, say public Upper(int num). And a class that extends Upper, but before including the super's constructor call inside the subclass's constructor, I compiled and it basically doesn't finish compiling nor throw errors. P.S. Totally excited about 2.2.0 !

@DonaldDuck: I can see a use for getPosition. I wasn't clear enough about the username method, PlayerData.getDataFor(String userName). Under what circumstances would you have a username that you wanted information about? Let's say I'm playing as nccb, when/why would I want to get the data specifically for DonaldDuck? I'm not having a go or anything, but I just want to find a compelling use-case before adding the method. @bourne: I can't reproduce the abstract class issue, but I wonder if it might be related to error highlighting. Could you send us the code (if you can put it in a state to reproduce the problem), and/or check your debug log (look in Greenfoot->About for location) for any exceptions?

@nccb: I was thinking mostly for a slightly easier way to communicate with specific users, making multiplayer functionality easier. Alternatively, an 'answer key' for example could be stored in the owner's data strings and in this way, the solution to a game could be changed without updating the scenario.

You're going to run into privacy leakage issues if different users can read each other's PlayerData though. It's a corner case, but a clever enough social engineer might manage to harvest user's addresses, credit cards, etc. Unlikely though.. and the sort of person who's likely to yield sensitive info to an online game is equally likely to yield that data in a public online forum too. But still, it bears thought.

@tkiesel I don't think this is a problem (unless we're overlooking something, then I'd like to hear about it). We have thought about it quite carefully. All that a scenario can receive from a player is the user name and the image. Not more (and indeed far less) than is already visible on the web page. The scenario can then add some data (11 ints and 10 strings), for example to store the high score, or your current level, or any other data that the program wants to associate with the player or the game, but it cannot retrieve any other data from any other user. Other players of the game can only retrieve the users' names and images and the game data (as far as the game permits it). Other code (other scenarios) cannot access the data from other scenarios at all. For example, if I make a scenario that stores data, your scenario cannot access it. There is no mechanism to specify the database or table or file or container of any kind that the data is stored into. You just get space exclusively for your scenario, and nothing else. Michael

Also let me point out that this API is not meant for multiplayer, and as such, I don't think specific methods and functionality that are specifically for multiplayer should be added unless some sort of turn based multiplayer is actually supported officially.

Well-multiplayer is possible in Greenfoot-try using a ServerSocket and a Socket. That is all you need to get started...provided you know the other person's IP address.

Builderboy2005 is right. This functionality is not really intended for multiplayer, so we're not really looking to support that. To properly support peer-to-peer real-time multiplayer on gallery applets (which it seems lots of you want!), we would have to build a socket forwarder on the gallery server that relayed communications around. That's technically feasible, but that's not what is going in to 2.2.0. We might twiddle the API a little bit, but broadly this storage is for high-scores and per-user storage -- interaction is just not really possible, because it's not what the system was designed for.

@mik: I wasn't talking about data being available across Scenarios. I just meant that if you can display Strings associated with this scenario and accounts other than the person currently logged in, then it would be possible to do a Scenario along the lines of..... "Enter your full name: " ______________ "Enter your home address: " ___________ "Enter your credit card number and expiration date: " ___________ ----------- | Submit | ----------- Followed by a display of the username and those three Strings for each user who pressed the Submit button. As I said above, it's not a real issue in terms of code, just a matter of how sneaky someone would want to be in their social engineering. (I chose a completely non-sneaky example above just because I don't feel like giving any malicious actors any ideas.) It's entirely possible that I've missed the boat and that only an int is exposed. I haven't gotten the 2.2.0 beta to mess around with it yet. I can say I'm excited about the possibility of making Scenarios that can recognize that the player is the author by username and expose some self-coded debug functionality! I think my students can make great use of that! :)