Heu, non, justement, l'échange de données en temps réel entre plusieurs joueurs, c'est assez chiant en PHP. Après, tout dépend de la quantité de données et de l'aspect véritablement "temps réel" que tu recherches.
Regarde les ressources concernant Quake III et son moteur, ou Ogre 3D. Je pense qu'il doit y avoir tout ce qu'il faut au sujet de comment ces moteurs ont démarré et se sont développés.
PHP n'est pas étudié pour du temps réel car il s'agit, de base, d'un langage de template. Couplé à Apache, c'est d'autant plus flagrant (et d'autant d'autant plus sur les mutualisés où tu n'auras pas la main sur la configuration): c'est une stack construite sur le fait qu'une page web est demandée, puis servie, et terminé, la connexion s'arrête, le taff est fait.
Pour faire tu véritable temps réel, il faudrait que la connexion au serveur puisse persister, que le serveur puisse ainsi envoyer des données côté client, et que le serveur ait une notion d'évènement (ou d'attente passive) qui lui permette d'envoyer les données nécessaires au client connecté lorsque ces données sont disponibles sur le serveur. Et je ne compte pas le fait que le client puisse remonter des données par moment au serveur si nécessaire.
Ces opérations sont totalement transparentes sur un moteur de jeu classique (AAA), c'est pour cela que pour des jeux de ce genre, c'est la solution la plus adaptée. Sans compter que je doute de la scalabilité d'un tel mécanisme (à 3-4 joueurs, soit e qu'un jeu AAA encaisse sans aucun problème, cela peut passer mais quand on fleurte avec la centaine de connecté en même temps, je commence à douter des performances d'un machin web "temps réel"... pour un vrai jeu j'entends hein, pas juste un truc bidon envoyant 3 données toutes les 2H pour juste montrer qu'on peut avoir 100 connectés en même temps)
PS: C'est un Mantis, ça tournes sur PHP, tu peux l'installer sur ton propre serveur si tu veux
Regarde les ressources concernant Quake III et son moteur, ou Ogre 3D. Je pense qu'il doit y avoir tout ce qu'il faut au sujet de comment ces moteurs ont démarré et se sont développés.
PHP n'est pas étudié pour du temps réel car il s'agit, de base, d'un langage de template. Couplé à Apache, c'est d'autant plus flagrant (et d'autant d'autant plus sur les mutualisés où tu n'auras pas la main sur la configuration): c'est une stack construite sur le fait qu'une page web est demandée, puis servie, et terminé, la connexion s'arrête, le taff est fait.
Pour faire tu véritable temps réel, il faudrait que la connexion au serveur puisse persister, que le serveur puisse ainsi envoyer des données côté client, et que le serveur ait une notion d'évènement (ou d'attente passive) qui lui permette d'envoyer les données nécessaires au client connecté lorsque ces données sont disponibles sur le serveur. Et je ne compte pas le fait que le client puisse remonter des données par moment au serveur si nécessaire.
Ces opérations sont totalement transparentes sur un moteur de jeu classique (AAA), c'est pour cela que pour des jeux de ce genre, c'est la solution la plus adaptée. Sans compter que je doute de la scalabilité d'un tel mécanisme (à 3-4 joueurs, soit e qu'un jeu AAA encaisse sans aucun problème, cela peut passer mais quand on fleurte avec la centaine de connecté en même temps, je commence à douter des performances d'un machin web "temps réel"... pour un vrai jeu j'entends hein, pas juste un truc bidon envoyant 3 données toutes les 2H pour juste montrer qu'on peut avoir 100 connectés en même temps)
PS: C'est un Mantis, ça tournes sur PHP, tu peux l'installer sur ton propre serveur si tu veux