10-07-2013, 11:42 PM
(Modification du message : 11-07-2013, 09:52 AM par Sephi-Chan.)
Coucou,
Ces derniers temps j'ai découvert un bug sur mon algorithme de match making (en réalité, une implémentation très naïve qui convenait pour mes essais mais inutilisable en vrai).
Le jeu se joue en parties d'un format donné (par exemple 3 équipes de 4 joueurs, noté 3x4). A tout instant, un joueur peut inviter d'autres joueurs à jouer avec lui à une partie d'un format donné (par exemple : moi A, j'invite B, C et D pour une partie en 3x4). Une fois que tous les joueurs invités ont répondu favorable à la recherche, elle est enregistrée dans le système.
Le but est ensuite de créer des parties qui regroupent les différentes recherches. Ici, le système tentera de créer autant de parties possible pour le format 3x4. Bien sûr, s'il n'y a qu'une seule recherche pour ce format, ça ne suffit pas. L'autre point important : il ne faut pas que les parties aient de joueurs en commun.
Je cherche donc à établir un bon algorithme pour faire ça et je viens vers vous pour vos suggestions.
Voici la structure de données de base que je propose :
Et en sortie, je souhaiterai (mais je suis ouvert à d'autres propositions) avoir une structure de données telle que :
Voilà ! A vos suggestions !
Ces derniers temps j'ai découvert un bug sur mon algorithme de match making (en réalité, une implémentation très naïve qui convenait pour mes essais mais inutilisable en vrai).
Le jeu se joue en parties d'un format donné (par exemple 3 équipes de 4 joueurs, noté 3x4). A tout instant, un joueur peut inviter d'autres joueurs à jouer avec lui à une partie d'un format donné (par exemple : moi A, j'invite B, C et D pour une partie en 3x4). Une fois que tous les joueurs invités ont répondu favorable à la recherche, elle est enregistrée dans le système.
Le but est ensuite de créer des parties qui regroupent les différentes recherches. Ici, le système tentera de créer autant de parties possible pour le format 3x4. Bien sûr, s'il n'y a qu'une seule recherche pour ce format, ça ne suffit pas. L'autre point important : il ne faut pas que les parties aient de joueurs en commun.
Je cherche donc à établir un bon algorithme pour faire ça et je viens vers vous pour vos suggestions.
Voici la structure de données de base que je propose :
{
// On associe un format à toutes les recherches pour celui-ci.
"2x3" : [ { name: "A", players: [ 1, 2, 3 ] }, { name: "B", players: [ 3, 4, 5 ] }, { name: "C", players: [ 4, 5, 6 ] } ],
"3x4" : [ { name: "D", players: [ 1, 2, 3, 4 ] } ]
}
Et en sortie, je souhaiterai (mais je suis ouvert à d'autres propositions) avoir une structure de données telle que :
{
// L'équipe B n'a pas été gardée car elle contenait un joueur en commun avec
// l'équipe A (qui est prioritaire car inscrite la première).
// Il y a un tableau pour chaque partie que le système peut créer pour le
// format 2x3 avec les équipes qu'on lui a donné (ici 1 seule partie peut
// être formée, avec les équipes A et C).
"2x3" : [ [ { name: "A", players: [ 1, 2, 3 ] }, { name: "C", players: [ 4, 5, 5 ] } ] ],
// Ici. Hélas il n'y a pas assez d'équipes pour former la moindre partie.
// Il aurait fallu au moins 3 équipes sans joueurs en commun.
"3x4" : [ { name: "D", players: [ 1, 2, 3, 4 ] } ]
}
Voilà ! A vos suggestions !