Voici la solution que j'ai adopté pour ma part.
Frontend en js, qui, toutes les 100ms, envoie au serveur les déplacements du joueur, et récupère du même coup les infos des autres joueurs pour rafraîchir. Seules les infos concernant les joueurs ou éléments de décors qui doivent être affichés sont récupérées, pas celles concernant tous les éléments/joueurs de la map entière (vu que seule une partie de la map est visible à un temps donné). C'est le script côté serveur qui détermine quels éléments sont visibles par le joueur ou pas en fonction de sa position.
Côté serveur (en python), les infos relatives à tous les joueurs et éléments sont stockées dans un structure de données de type "dictionnaire" (en PHP ou autre ce serait un tableau multidimensionnel), qui est stocké en cache (avec memcache).
Le cache permet donc une pestistance, les données ne foutent pas le camp même si je redéploie l'app (vu que memcache stocke tout ça ailleurs), mais bien sûr si le serveur crash tout est perdu. Donc j'envisage une mise à jour de la bdd toutes les minutes, quelque chose comme ça.
Je serais curieux de l'avis de la communauté sur ce système, dans quelle mesure est-ce que ça vous semble "scalable", ou au contraire si ça vous semble assez barbare et inefficace. Je suis content d'éviter de trop agresser la db (car dans une ancienne version où tout était stocké dans la db, 10 requêtes par seconde par joueur ça se voyait quand même aux performances du truc, on m'arrachait pas d'ongles mais bon c'était pas intéressant). Ceci dit je ne fais que déplacer le problème en remplaçant la db par le cache. Ceci dit l'accès au cache est beaucoup plus rapide que l'accès à une bdd. Mais si le projet prend de l'ampleur, peut-être que se reposer de la sorte sur le cache deviendra inenvisageable...
J'attends avec plaisir vos remarques.
Edit : J'ai une démo à montrer mais tout d'un coup les arbres ne s'affichent plus... je balance l'URL dès que ça remarche.
Frontend en js, qui, toutes les 100ms, envoie au serveur les déplacements du joueur, et récupère du même coup les infos des autres joueurs pour rafraîchir. Seules les infos concernant les joueurs ou éléments de décors qui doivent être affichés sont récupérées, pas celles concernant tous les éléments/joueurs de la map entière (vu que seule une partie de la map est visible à un temps donné). C'est le script côté serveur qui détermine quels éléments sont visibles par le joueur ou pas en fonction de sa position.
Côté serveur (en python), les infos relatives à tous les joueurs et éléments sont stockées dans un structure de données de type "dictionnaire" (en PHP ou autre ce serait un tableau multidimensionnel), qui est stocké en cache (avec memcache).
Le cache permet donc une pestistance, les données ne foutent pas le camp même si je redéploie l'app (vu que memcache stocke tout ça ailleurs), mais bien sûr si le serveur crash tout est perdu. Donc j'envisage une mise à jour de la bdd toutes les minutes, quelque chose comme ça.
Je serais curieux de l'avis de la communauté sur ce système, dans quelle mesure est-ce que ça vous semble "scalable", ou au contraire si ça vous semble assez barbare et inefficace. Je suis content d'éviter de trop agresser la db (car dans une ancienne version où tout était stocké dans la db, 10 requêtes par seconde par joueur ça se voyait quand même aux performances du truc, on m'arrachait pas d'ongles mais bon c'était pas intéressant). Ceci dit je ne fais que déplacer le problème en remplaçant la db par le cache. Ceci dit l'accès au cache est beaucoup plus rapide que l'accès à une bdd. Mais si le projet prend de l'ampleur, peut-être que se reposer de la sorte sur le cache deviendra inenvisageable...
J'attends avec plaisir vos remarques.
Edit : J'ai une démo à montrer mais tout d'un coup les arbres ne s'affichent plus... je balance l'URL dès que ça remarche.