Greenfoot 2.2.0 beta

I think the issue with multiplayer is that there is no easy way out, no way to implement multiplayer that is simple, fast, and playable. Greenfoot was always meant for beginners, and even though advanced programmers can use it to make advanced games, I think that advanced features should never be part of the API.

Ok, a post on the multiplayer issue again: the PlayerData system was designed for high-scores and it works well at that. If you can use it to write other scenarios without wreaking havoc on the server then go for it, but we won't alter the API design to better support multiplayer. I think the API for the 2.2.0 release will be identical to the beta (with bugfixes for the implementation). As for multiplayer in general: lots of you seem quite interested in doing multiplayer games. In low-down technical terms, the only way to get multiplayer in games on the Greenfoot website is for us to build some sort of server. Java applets can only open sockets to the machine they are served from (greenfoot.org), so for applet multiplayer, we have to build something to run on greenfoot.org. At the most basic, we could have some sort of socket server that would relay messages between applets. But even this basic API would not be enough: you'd need some way of knowing who's around (i.e. a lobby system), which would probably need to be built into the server. And even then, networked games are tricky! You have to handle dropped connections and similar. Real-time multiplayer is incredibly hard, because you have to do lots of client-side prediction to compensate for the lag, and if it was UDP then you have to handle dropped packets and so on. So even if we built some sort of socket-forwarding server, I think it would be too difficult for > 99% of Greenfoot users (some of you asking here are the 1%, I know). And as ever, if you're good enough to write good netcode, you're outside of Greenfoot's target user group. We love seeing people do advanced things with Greenfoot, but ultimately it's aimed at beginners, not experts. Alternatively, we could have an additional storage mechanism that would allow games between two players (similar to PlayerData, but data per pair of users rather than per single user). So rather than worrying about sockets and messages, you just share a data structure remotely and allow updates to that. This would work more for turn-based games. You have less issues there: atomicity and contention are the main issues. To avoid polling like mad, you'd probably want push notifications of updates, though that could be managed. I am thinking about it, but it's unlikely to make it into Greenfoot, because it's only worthwhile us adding it if beginners can understand and use it (which I think is true for PlayerData). Maybe it could be done as some sort of add-on (like the gamepad support). I'll keep musing over a design, but I think the honest answer is still: unlikely.

Hi, really nice features! But I'd like to raise a few objections concerning the PlayerData class. I pretty much like the new import class dialog. So I wonder if it wouldn't be more adequate to provide the PlayerData class as a support class, which would make it possible for the user to adapt it to one's own needs. Furthermore I'd suggest renaming the new class to "UserData" (last chance if it really goes into the API!), because I think that it is not only useful for games but general purpose. Or in analogy to "MouseInfo", call it "UserInfo"? Or since it appears in the GUI as a subset of the "Preferences" maybe it could also be named "UserPreferences"... In fact, the methods are called getUserName(), getUserImage() etc. which is a bit inconsistent in my opinion. Davin, is the source code available for download? Tried to guess the file name with no success...

Rick, source is (now) available: http://greenfoot.org/download/files/source/Greenfoot-source-2.2.0.zip I personally agree with you about the UserData versus PlayerData naming but the timing is unfortunate - we just built a release candidate for Greenfoot 2.2.0 today and are testing it now. (Source code link above is the source to the release candidate). Regarding having PlayerData as an importable class, I disagree; for one thing, you don't gain much by being able to see or modify the source (it's easy enough to wrap the functionality if that's what you need to do, but you wouldn't in any case be able to change the nature of what can actually be stored and retrieved). Also, having the class inside the project would deprive us of the ability to change the implementation later (currently we can do this, because the PlayerData class is not itself uploaded as part of the scenario, but is stored in a separate jar file which we can modify post release). Finally, the class is quite complex and works differently depending on whether the scenario is running in Greenfoot or as an Applet; the complexity makes it unsuitable for inclusion with the "importable" classes which are included not just for their utility but also as examples.

Hey just an idea I had. There are account settings for notifications. Could there be a setting to give notice perhaps for when someone beats your score for a particular scenario. And it could be limited to a range for like if it was close to your score, or both being in the top 10 or whatnot. Maybe not with the same notifications as that are already present, but maybe separate. So like the High Scores notifications. I could see it as a good element for perhaps a competitive challenging scenario, or just maybe the scenario owner getting a notification that someone beat his/her score at his/her own scenario.

Even with the doc and helijcopter example I have a lot of questions about how to use Player Data. For example how do you even set the user Image or Name? there are get functions for the user names and images but no set images. Also how do you know which "user" is using your sererio on your computer or on the internet as a applet? Thanks

The Image is always that account's profile picture and the name is the account's username. So you only have accessor methods for these since they are attributes to the account and not some data for some scenario.

I'm not sure it was meant for not being used on the gallery, like a standalone application. On your computer within Greenfoot its just meant for testing at which you can change the name by going: Preferences -> Miscellaneous ->Player Name

@ttamasu: we've improved the PlayerData documentation a bit since the beta. For the username and image, the answer is dependent on where the scenario is running: Locally in the IDE: user-name is set via the dialog bourne mentions, or by pressing Ctrl-Shift-P (Cmd-Shift-P on Mac). Image is auto-generated (it draws the user-name onto a 50x50 image) Applet on greenfoot.org: user-name is set by login name, image is the chosen avatar (i.e. the same image that appears on the left-hand side in this forum). Applet elsewhere or running standalone: PlayerData is not supported. In short: the usernames and images come from people's greenfoot.org profiles, with a mechanism in the Greenfoot IDE to simulate this, for testing.

I have another ... perhaps dumb question... I was reading a comment about a prof(bpiltin@unitedisd.org) trying to add his own library collection to his students to download.... Now I was looking at Edit|Import Class... and saw how almost seamlessly you can add nice components like the scoreboard... Is it possible for a user to place some of his/her own library classes and how would you do this? If it is easy it would be a greatly enhance the functionality of Greenfoot as a learning tool. For example if I wanted to add a Vector class to import how would I do this?

Here's a copy of my post from a question in the Greenroom teachers site asking roughly the same thing: If you want to customise the importable classes and you have access to the students’ installation of Greenfoot (e.g. in the case of a networked installation), you can just drop files into the right directory. On your local machine, it’s: C:\Program Files (x86)\Greenfoot\lib\greenfoot\common or similar. Any .java file in that directory is displayed in the import browser using the corresponding .html file with the same name – be warned: this is HTML 3.2, so Javadoc output is the main suitable candidate. If you import the .java file in Greenfoot, a .png, .jpg or .jpeg file of the same name will get copied too, and made the image for that actor. If, on the other hand, you don’t have access to the Greenfoot installation, it’s true that there’s not a lot you can do right now.

No doubt, implementing multi-player games is not trivial, but is very motivating for our students. If you do it over Bluetooth, no special game server is necessary. If you use TCP, you cannot easily communicate between computers because of firewall restrictions. And indeed, in a more sophisticated game scenario, a game server is needed that handles the different users in their game rooms. A more profound discussion may be found at http://www.aplu.ch/tcpjlib. The TCP and Bluetooth framework developed by our group can be used in any Java environment, so, in principle, also with Greenfoot. Regards, Aegidius