29-09-2010, 03:31 PM
Bonjour, voici quelques remarques/questions/opinions:
1. D'accord avec Sephi-Chan sur le "tu vas vraiment en chier".
2. L'algo A* est plus adaptée à une représentation matricielle du terrain.
3. Je n'ai pas compris le principe de la fragmentation. Comment cela marcherait-il?
- On lance l'algo avec un maillage moins dense du terrain pour trouver des points intermédiaires? (je dis ça au hasard: ça ne me paraît pas réaliste)
- On utilise une représentation vectorielle (avec les routes par exemples) pour limiter le nombre de nœuds?
- On coupe des branches de l'algo en fonction de certains seuils (du genre, on laisse tomber si on s'éloigne trop de la destination)?
- A quoi correspond le premier déplacement de 20 cases? A un point choisi par le joueur? Un peu contraignant, non?
4. Un calcul coté client peu paraître séduisant au niveau de la charge CPU mais je préfère le calcul coté serveur:
- C'est plus dans l'esprit d'un client léger vers lequel tu t'orientes.
- Ça évite le transfert de la map vers le client (qui ne doit peut-être pas tout connaître).
- C'est plus simple car moins d'aller-retours client-serveur (requête de la map + check du path).
- Ça permet de faire des choses genre:
1. Calcul d'un path pour le joueur A.
2. Le joueur A se déconnecte.
3. Un joueur B crée un obstacle sur ce path avant que A n'arrive à destination.
4. Le serveur peut recalculer un nouveau path même si A est déconnecté.
- Ca n'économise pas la création de process coté serveur puisque de toute manière, il en faudra un pour les calculs temps-réel.
5. Si tu charges le serveur de ces calculs, il reste beaucoup de questions de design. Il n'est en effet pas réaliste d'intégrer ces calculs dans la création de page: trop couteux. Alors, qui doit s'en charger?
- Le process temps-réel? S'il est schédulé à la minute, il n'aura pas forcément le temps, à moins d'un multiplexage temporel de l'algo (à chaque cycle, on ne réalise qu'un nombre fixé d'itérations), mais ça complique beaucoup les choses!
- Un ou plusieurs threads asynchrones (suivant le nombre de CPU)? C'est plus réaliste. Ça nécessite juste la gestion de file d'attente de requête de trajectoire. Les problèmes d'accès concurrent devraient être limités si tu ne communiques que par la BDD.
- Un thread par requête: ca permet à un joueur de ne pas avoir à attendre le calcul des requêtes précédentes mais attention aux problèmes mémoire car idéalement, chaque thread doit travailler avec un snapshot du terrain. Donc si tu charges tout en mémoire, que tu as 20 requêtes simultanées et 100 octets en moyenne par cellule, tu arrives à 2 GO. Ce qui ne tient pas avec un système 32 bits sous Windows. Ou alors, il faut utiliser des process différents. Mais bon, je préfère la solution précédente.
6. Ne pas oublier que si tu vises 100 joueurs simultanés, par exemple, avec un update par minute, ça te fait à peine plus d'une demi-seconde pour répondre à chacun... rien d'insurmontable mais il ne faut perdre ça de vue pendant tes devs...
1. D'accord avec Sephi-Chan sur le "tu vas vraiment en chier".
2. L'algo A* est plus adaptée à une représentation matricielle du terrain.
3. Je n'ai pas compris le principe de la fragmentation. Comment cela marcherait-il?
- On lance l'algo avec un maillage moins dense du terrain pour trouver des points intermédiaires? (je dis ça au hasard: ça ne me paraît pas réaliste)
- On utilise une représentation vectorielle (avec les routes par exemples) pour limiter le nombre de nœuds?
- On coupe des branches de l'algo en fonction de certains seuils (du genre, on laisse tomber si on s'éloigne trop de la destination)?
- A quoi correspond le premier déplacement de 20 cases? A un point choisi par le joueur? Un peu contraignant, non?
4. Un calcul coté client peu paraître séduisant au niveau de la charge CPU mais je préfère le calcul coté serveur:
- C'est plus dans l'esprit d'un client léger vers lequel tu t'orientes.
- Ça évite le transfert de la map vers le client (qui ne doit peut-être pas tout connaître).
- C'est plus simple car moins d'aller-retours client-serveur (requête de la map + check du path).
- Ça permet de faire des choses genre:
1. Calcul d'un path pour le joueur A.
2. Le joueur A se déconnecte.
3. Un joueur B crée un obstacle sur ce path avant que A n'arrive à destination.
4. Le serveur peut recalculer un nouveau path même si A est déconnecté.
- Ca n'économise pas la création de process coté serveur puisque de toute manière, il en faudra un pour les calculs temps-réel.
5. Si tu charges le serveur de ces calculs, il reste beaucoup de questions de design. Il n'est en effet pas réaliste d'intégrer ces calculs dans la création de page: trop couteux. Alors, qui doit s'en charger?
- Le process temps-réel? S'il est schédulé à la minute, il n'aura pas forcément le temps, à moins d'un multiplexage temporel de l'algo (à chaque cycle, on ne réalise qu'un nombre fixé d'itérations), mais ça complique beaucoup les choses!
- Un ou plusieurs threads asynchrones (suivant le nombre de CPU)? C'est plus réaliste. Ça nécessite juste la gestion de file d'attente de requête de trajectoire. Les problèmes d'accès concurrent devraient être limités si tu ne communiques que par la BDD.
- Un thread par requête: ca permet à un joueur de ne pas avoir à attendre le calcul des requêtes précédentes mais attention aux problèmes mémoire car idéalement, chaque thread doit travailler avec un snapshot du terrain. Donc si tu charges tout en mémoire, que tu as 20 requêtes simultanées et 100 octets en moyenne par cellule, tu arrives à 2 GO. Ce qui ne tient pas avec un système 32 bits sous Windows. Ou alors, il faut utiliser des process différents. Mais bon, je préfère la solution précédente.
6. Ne pas oublier que si tu vises 100 joueurs simultanés, par exemple, avec un update par minute, ça te fait à peine plus d'une demi-seconde pour répondre à chacun... rien d'insurmontable mais il ne faut perdre ça de vue pendant tes devs...