search

maandree / cnt

Coop Network Tetris, a university project.
maandree.github.com/cnt
4 stars 1 forks source link

Player ID (color) assignment #31

Closed aiqueneldar closed 12 years ago

aiqueneldar commented 12 years ago

Needs to be implemented so that ConnectionNetworking can use it. I saw that Matte has started an example. We can use that if nothing else.

Functionality needs to be reachable by ConnectionNetworking and have one method for returning a unique unused ID.

Assigning Matte this for the time being.

maandree commented 12 years ago

Didn't we say the Player ID should just be counted up from 0, and that the GUI handles the colour mapping?

aiqueneldar commented 12 years ago

No, I have always said that player ID is used as a unique value that is in a range that supports being converted to colors as that was the main idea with the interaction way. But I wanted it in int so that other interaction ways are capable, for example CUI without colors.

If you (refereing to Matte and Peyman) doesn't want that, then we can change it

maandree commented 12 years ago

I though we agreed we should change that is it as a GUI issue, and it would make it easier for low/non colour UI:s.

I think it should be changed because of that but also:

Letting the ID counted up from 0 will allow 2³² players (but can be unlimited). Using colours as ID will not even allow 2²⁴ as many colour cannot be used. When the players are many enough the colours will look almost identical (slightly above the difference a normal human eye can distinguish), and to some player identical; it will not matter if some actual have the same colour. Letting the UI map the colours will make it easier to create your own way the colours are chooses, even due, it may be good if every player sees the same colours.

aiqueneldar commented 12 years ago

Ok, we can change it then to use IDs from 0 and up. As long as Peyman doesn't dissagree.

maandree commented 12 years ago

Should Block store the Player or just the Player's ID?

aiqueneldar commented 12 years ago

If we use Multiton shouldn't player ID be enough?

maandree commented 12 years ago

ID is enough even if we do not use multiton, but since only UI:s knows the colour it may be more natural to store the player.

maandree commented 12 years ago

Multiton may not be the best idea as the new instance are create by that client, and the key is only the ID while the constructor need more information: name, IP address, and a, possible empty, list of DNS names.

aiqueneldar commented 12 years ago

I say add another constructor that can create an empty player object with only ID that can be filled in later with a player joined. I liked the idea with multiton

maandree commented 12 years ago

The solution I'm using right now is:

Constructor for creating new instance. Getter for existing instances both ID and UUID. Automatic mapping of deserialised instances using readResolve().

UUID is needed for the friend list.

Basically it is like multiton except instance can only be create using a constructor and there are two maps.