"Display friends on song select rankings when present."
Did I read that right
Because if I did, I'm going to squeal like a girl
Did I read that right
Because if I did, I'm going to squeal like a girl
Exactly. If you really want to see who your friends are, just remember who they are. They're already highlighted on the list and any friend beyond rank 40 won't show anyway.wmfchris wrote:
The problem is your "friends" may not want to show his/her score and this could end up with people watching random players' score by making friends with him/her. If the relationship is mutual and he/she is willing to disclose his/her score, you can simply ask him/her for the score/replay.
You need an index per-user per-beatmap ordered by score. As this information is obviously not stored in a single table, it means duplicating a lot of data, which all needs to be updated on a regular basis. Making this an efficient lookup is one of the most challenging query types for a database. It of course can be done, but requires a lot of optimisation, consideration and storage space.mmstick wrote:
I don't see how this would be intensive to implement, plenty of other games do this. One way would be to store all scores on a server, only keeping the highest score a user makes and the client simply grabs the data from the website database in real-time (similar to embedding a frame of a webpage). Another way would be for the clients to individually ask other clients for their highest local scores to sync with and promptly attempt to sync with friends clients when a new high score is obtained.
This is kind of confusing to me. Whatever confusing must be hard, right?peppy wrote:
I am hoping to address this in a round-about way in the future. For now, due to my previously mentioned reasons, it is not possible.You need an index per-user per-beatmap ordered by score. As this information is obviously not stored in a single table, it means duplicating a lot of data, which all needs to be updated on a regular basis. Making this an efficient lookup is one of the most challenging query types for a database. It of course can be done, but requires a lot of optimisation, consideration and storage space.mmstick wrote:
I don't see how this would be intensive to implement, plenty of other games do this. One way would be to store all scores on a server, only keeping the highest score a user makes and the client simply grabs the data from the website database in real-time (similar to embedding a frame of a webpage). Another way would be for the clients to individually ask other clients for their highest local scores to sync with and promptly attempt to sync with friends clients when a new high score is obtained.
Your solutions may sound simple to you, but aren't actually feasible due to over-simplication (suggestion 1) or incorrect approach (suggestion 2).
As would Iloseri wrote:
I'd hunt your weak scores downKaoru wrote:
If I had stars I would add them to this. I'd know which of my friends I had highscores and which I wanted to beat this way.
peppy wrote:
I am hoping to address this in a round-about way in the future. For now, due to my previously mentioned reasons, it is not possible.You need an index per-user per-beatmap ordered by score. As this information is obviously not stored in a single table, it means duplicating a lot of data, which all needs to be updated on a regular basis. Making this an efficient lookup is one of the most challenging query types for a database. It of course can be done, but requires a lot of optimisation, consideration and storage space.mmstick wrote:
I don't see how this would be intensive to implement, plenty of other games do this. One way would be to store all scores on a server, only keeping the highest score a user makes and the client simply grabs the data from the website database in real-time (similar to embedding a frame of a webpage). Another way would be for the clients to individually ask other clients for their highest local scores to sync with and promptly attempt to sync with friends clients when a new high score is obtained.
Your solutions may sound simple to you, but aren't actually feasible due to over-simplication (suggestion 1) or incorrect approach (suggestion 2).