This site requires JavaScript, please enable it in your browser!
Greenfoot back
nccb
nccb wrote ...

2012/1/14

High Scores!

1
2
darkmist255 darkmist255

2012/1/31

#
I was thinking of something along that idea as well. Multiplayer over LAN or WAN has intrigued me recently.
Builderboy2005 Builderboy2005

2012/1/31

#
It would be difficult, but it sounds like it actually would be possible O.O Can't wait for Greenfoot 2.0 so we can get to experimenting! Definitely only Turn based games though :P As Nccb said, constant accessing of the Highscores network would definitely put a great strain on the network.
nccb nccb

2012/1/31

#
Before you all get too excited, the system doesn't really support that kind of interaction very well. Firstly, there's currently no API call to fetch the data for a specific other user, only for all users (though it wouldn't be hard to add -- I'll think about this). Secondly, each player would only be able to participate in a limited number of games at once. There is a limited-capacity piece of storage per user (per scenario), so a user would have to store the ids of users they are currently in a game with, and the associated state, within their personal storage space. Thirdly, because you can't write to their state, and they can't write to yours, you'd have to store your turns in your space, and their turns in their space, and build up the game state from there. Fourthly, this will be additionally problematic because there isn't really any guarantee against race hazards, in the case where both users are online at once. Overall: I'm just not sure it's feasible to do lots of small multiplayer games with this system. One big game might be more doable (!), but the network overhead is then potentially a problem. I did consider this multiplayer use case, but to do it properly you'd need to permit a high or unlimited amount of storage (if each player can play one game with each other player, suddenly the max storage is proportional to N^2, where N is the number of users -- with the scheme I've chosen, it's N), and you'd need more complex access rights and the whole thing started to look like a mess. So hence we have a simple scheme, mainly tailored to high-score tables, and, alas, not towards multiplayer games. For the kinds of things you guys are imagining, you might just have to code and host your own server + applets. Look into sockets programming if you're interested in doing things like that, but I'm afraid Greenfoot isn't likely to be able to support your commendable plans.
Builderboy2005 Builderboy2005

2012/1/31

#
Ah yeah, the inability to access specific users would indeed make multiplayer more difficult. Either way though, I'm simply looking forward to the highscore and save game ability of the new system ^^
Duta Duta

2012/2/1

#
I've been doing quite a bit of sockets programming of late, so I'm not too worried about this lack of functionality :) Still, it'll be a good update and I'm looking forward to it!
DonaldDuck DonaldDuck

2012/3/11

#
nccb wrote...
At the moment, it's one score int, 10 general-purpose ints, and 5 strings of up to 50 characters per user, per scenario.
Would it be possible to also allocate space for about 10 GreenfootImage and also 10 boolean type storage? Or arrays of either?
    int saveScore = 0, saveHP = 100, saveCount = 100, saveLevel = 0;
    String saveWorld = "empty";
    GreenfootImage[] saveImage = new GreenfootImage[6];
    boolean[] purchaseData = new boolean[items];
I have to save a 626 character string and these other values. I could make do with a string containing "true false example.png" etc. But I'm sure there are many other users who would also benefit from these storage types.
mjrb4 mjrb4

2012/3/12

#
Storing ints and strings is one thing, images is another entirely! That would really chew up space and bandwidth much more than is sensible - it won't happen I'm afraid. And that's before we get to size limits and that sort of restriction... In terms of booleans, you can emulate this storage either by using strings, or if space is an issue by bit fiddling an int. You'll have to find a way around it with the current limitations I'm afraid - while they may flex slightly in time I can't see us changing them that much!
DonaldDuck DonaldDuck

2012/3/12

#
Ah, I see. I didn't consider the amount of storage space it would require.
Duta Duta

2012/3/12

#
If you look at an alternative method of storing an image (storing the RGB values of each pixel) it begins to be obvious why so much space is required: Imagine an 1000x1000 image -> For each pixel in that you need to store the RGB values -> that's 1,000,000 RGB values. This is obviously pretty similar to how a bitmap (.bmp) file stores an image (and also the reason why .bmp's take up so much more space than the same image in a .jpg form for instance), but still you get the idea :p
You need to login to post a reply.
1
2