I don't have experience either. But as I remember: some database types don't support decimals, but all of them supports float. And float for our calculations should be enough to store all data. Python can easily show the values by
"%.3f" % value (float value would be showed as 3-decimal digits number stored as string).
Another workaround is to use integer instead (as it is done in Widelands model for soldiers - their HP is stored like that).
Django says it can, but actually you're right I should use float or int. Maybe int then? But then what do you do? You have a function for changing the value back to the original? Maybe float is easier
But where you want to use decimals instead of floats?
huhhhh, I have no idea what I'm doing on this. Never made a lot of "low-level" stuff before tbh. Neither a lot of math, at best some geometry stuff. It seems float will fit perfectly for that job, I'll use that
About the tread:
That is a good idea!
Ok, I'll do that tomorrow then
Database models for ranking games and ladder
Perfectly on topic on my current problems!
Recently I was thinking how to solve the models for games and players. The problem was split into two parts:
- Game models
- Ranking values models
Here's what I have for now for my first test. A lot of stuff are missing but I'm looking for functionality first
class Game(models.Model): #Same idea as you :P
user = models.ForeignKey(User, related_name='game')
start_date = models.DateTimeField(default=0)
game_type = models.CharField(max_length=255)
game_map = models.CharField(max_length=255)
players = models.CharField(max_length=255)
result = models.CharField(max_length=255)
submitter = models.CharField(max_length=255)
class Rating(models.Model): #what you call participant model?
player = models.CharField(max_length=255)
rating = models.DecimalField(max_digits=5, decimal_places=2)
standard_deviation = models.DecimalField(max_digits=4, decimal_places=2)
volatility = models.DecimalField(max_digits=5, decimal_places=2)
For Game models we need lots of data, but the data can be also split into two parts: specific game data & players (and teams) data. Plus we want to support not only 2-players games, but every possible Widelands game too. That makes the system more complicated.
For that we need at least two models: game model and participant model. Game model will contain data like map, win conditions, timestamps, and so on. Participant model will create many-to-many relation between game model and registered user model, plus it should contain data like which team the player was playing with, how many interruptions were on that player side (future use?) and so on.
So if I understand correctly:
Specific game :
- win conditions,
- ==> rel to "registred user"
- rel to "participant"
Which data do you want to put in registered user?
And for coding stuff, arbiter can have access to django admin page, where on a game model form can be several inlines of participants and it will be quite easy to add any records or edit them.
Why didn't I think about that? The first thing I did was a page for the arbiter to enter data...
For rank models I was thinking about one that will contain join to the registered user
Huh, yes didn't realized I was gonna need another table for the score. Yes I guess we can't recalculate everything everytime someone looks at the scores. Even more so as the score won't be updated every minute.
rank values (two integers and two floats for beginning),
rank number. rating score. Standard deviation. Volatility???
update time (when rank record was created) and if it is an active one. Why the last "active"? Because if we create that, we can easily store data about previous rank values and then we can see whole history of the player.
Why not say that it's inactive after a certain standard deviation? Mhhh although yeah, we might need to store the user's history. Is that what you wanted to put inside regitred user?
And why I am thinking about integer values for ranking? Because then we can easily support simpliest win/lose rank too.
I'm not sure I understand that part
I understand that you may have another view on the problem, so I am open for your point of view .
No no, all good ideas! Just not sure I understand exactly on all of them