Re: [glob2-devel] Beta 4 Continued Plan

[Leo Wandersleb]

Hi

> have read and downloaded the page "Beta 4" on our wiki, and infact, most 
> of those things are now done. The only thing really left to do is the 

nice :) looking forward to test it. do we have some secondary server for that? 
something online 22/6 with low bandwidth or so?

> ladder system, so we need to agree on an actual system for a ladder. In 
> particular, there are tons of problems posed by rating any arbitrary game.
>
> Take a look at http://en.wikipedia.org/wiki/Elo_rating_system and its 
> spinoffs to see potential candidates for rating systems. If we want to 
> be able to rate an arbitrary games, we are going to need to modify one 
> these for our own purposes.

elo is right what i had in mind. (as i said before i really want to keep record 
of all that the score is based on so we can adjust our formulas later.)

we will have exactly the same problems like fide has in this point
* inflation (people leave the system with less points than with what they 
entered leaving behind those who harvested them. top players will not be 
comparable over time)
* deflation (the inverse)
* groups decoupling from the rest (2 friends each with score 100 could play 
until one has score 0 and the other 200 while outside that group the top player 
has score 180)
* being sensitive enough (people will be frustrated if winning a game is not 
reflected by an increas in their score)
* but not too much (people will be frustrated if their score flips rather 
arbitrary between top of the field and bottom line. they will also refuse to 
play against people that can cost them many points while they have little chance 
of winning anything much.)

plus we want to have
* games with more players involved
* unbalanced maps
* maybe switching alliances (although we have predefined alliances now i would 
love to see if switching alliances can be modelled, too)

I would love to try and model suiting formulas. Can start the instant we know 
what data we will log.

Main problem will be to find a good estimate of the games outcome but we will be 
able to tell the quality of our system from the changes of single players 
scores. a good system should, after some games played, keep a player on the same 
score - his strength. if we evaluate a new formula based on the data collected 
we will quickly see if it can improve the strength-estimate.

> I am currently working on an administration system for the YOG routers, 
> the hot-pluggable servers that do the basic task of routing for a games. 

the thing so secondary yog servers can register with the main yog server to 
route games involving the own IP/arbitrary IPs?

> After this, I'm going to work on ciphers for our game data, so that the 
> password is encrypted when sent, and its encrypted on the players-end. 

on the server passwords should not be stored at all. only the hash should be 
stored.
on the client, storing the hash of the password or anything that could be used 
to identify with the yog server is insecure.
even more insecure would be to store the encrypted password with the source 
telling how to decrypt it.
sure yet more insecure is to do like now and store it plain text ;)

> I'm considering using an ellipctical curve based private key encryption, 
> using the blowfish cypher, and sticking with the sha1 as our hash.

so i hope you got some library in mind and are not about to implement any of 
these yourself.
do you plan to have a key pair per server distributing the public keys? this way 
you could really point-to-point protect data like the credentials. :) it would 
be fine with me to not take that effort (and make the "insecure"-font +3pt) but 
if it's fun to you, go ahead.

> After that, I will continue with some improvements given on our wishlist.

http://globulation2.org/wiki/Wishlist

greetings, leo