Mécanisme de mon projet réalisable ?

[FLX]

Bonjour tout le monde voila depuis assez longtemps que je bosse sur papier pour ce qui est de mon projet PHP.

Mais voila voyant les nombreuse possibilité je voudrais savoir :

- si il était possible de faire une map en 2D Isométrique
- de faire avancer mes personnages en temps réel.
- système de combat en temps réel

je crois que vous me suivez non ?

Voila je voudrais savoir si le PHP gère ou non ces systèmes ci-dessus merci.

[wild-D]

php c'est un langage coté serveur en plus pour stocker les donnée tu risque surement de passer par mysql;
tout seul il va de loin pas suffire; faut prévoir ce que tu utiliseras coté client (traditionnellement (x)html/css/soupoudré parfois de javascript/ajax; mais bon tu peux aussi faire du flash)

enfin
- oui
- mouai (javascript ou flah permettent de faire des animations coté client)
- bofbof; ça dépends ce que tu entends par temps réel, combien tu prévois de joueurs en simultané et tes moyens (pour le serveur).
Si tu veux du "temps réels" type terre-des-elements.net et que tu te prends un serveur ben alors oui, c'est faisable.

[FLX]

Merci bien pour ces informations

[Zamentur]

Plus précisément au sujet du temps réel:
- ajax te permettra de demander des informations au serveur à partir du client (puisque c'est un langage coté client). Mais le serveur ne pourra pas le prévenir d'une modification si le client ajax n'en fait pas la demande. Certaines techniques utilisant le protocole http 1.1 permettent de faire durer une demande pendant 1 minute afin de faire du quasi temps réel, , mais çà consomme quand même pas mal de ressource. La connexion reste néanmoins à sens unique (le client demande, le serveur répond).
- Action Script (donc Flash ou Flex) permet de faire des connections direct allant dans les 2 sens, ce qui permet d'améliorer les perf, via une connexion par socket avec php. Mais la plus part des hébergements web mutualisé n'autorise pas la connexion socket (enfin faut vérifier). AS permet aussi de faire des demande via http comme ajax donc à sens unique, et la il y a besoin de rien de spécifique pour le serveur.

[Ruz]

pour la technique ci-dessus, ca devrait etre (peut-etre pas la seule appellation): Comet
http://en.wikipedia.org/wiki/Comet_(programming)

[Sephi-Chan]

À ce propos, quelqu'un a déjà mis une architecture Comet en place ?
Car les possibilités semblent intéressantes mais je n'en ai jamais vu tourner…


Sephi-Chan

[Allwise]

Y a un framework Comet développé par une boîte française, mais je trouve plus le lien là... En tout cas ça avait l'air vachement complet, y avait tout ce qu'il faut côté client et serveur pour faire du Comet, et de la doc. Mais en fait, y avait tellement de fichiers que ça m'a découragé et que j'ai préféré vite tout fermer ^^.

La connexion reste néanmoins à sens unique (le client demande, le serveur répond).

Pas forcément. Le serveur peut très bien envoyer une réponse au client sans que celui-ci ne demande quoi que ce soit et c'est bien l'intérêt de ce procédé. Si le client devait toujours présenter ses demandes au serveur, il n'y aurait aucune utilité à faire persister les connexions pendant 1 minute... Là le but est bien de pouvoir injecter des données au client en fonction de facteurs autres que des requêtes clientes. Exemple : un joueur se connecte, on avertit tout le monde en temps réel en envoyant un message à tous les joueurs.

Outre la mise en place de l'utilisation de ce procédé qui me rebutait un peu, c'est la question de la configuration du serv et le problème de la charge qui m'a définitivement passé l'envie d'y goûter. Avec Apache par exemple je suis sûr que ça passerait pas au-delà de ~ 150 joueurs connectés sur mon serveur... Un serveur monothread (lighttpd, nginx) est probablement plus indiqué.
Facebook est un bel exemple de l'utilisation de cette technique, en voici une autre, très sympa ( tout ne marche pas tout le temps ). Côté client c'est ExtJs qui s'y colle.
http://cometdesktop.com/

Pour ma part je suis parti dans la direction du socket PHP / Flash. D'une part malgré la lenteur de PHP, je pense que ça peut passer même pour un grand nombre de joueurs, et d'autre part si ça passe pas rien ne m'empêchera de le reprogrammer dans un langage plus adapté, Python ou pourquoi pas C++.

[Zamentur]

La connexion reste néanmoins à sens unique (le client demande, le serveur répond).

Pas forcément. Le serveur peut très bien envoyer une réponse au client sans que celui-ci ne demande quoi que ce soit et c'est bien l'intérêt de ce procédé. Si le client devait toujours présenter ses demandes au serveur, il n'y aurait aucune utilité à faire persister les connexions pendant 1 minute... Là le but est bien de pouvoir injecter des données au client en fonction de facteurs autres que des requêtes clientes. Exemple : un joueur se connecte, on avertit tout le monde en temps réel en envoyant un message à tous les joueurs.

Ce que je voulais dire c'est que techniquement çà fait un aller retour, donc forcément plus couteux sur ce plan. Mais je suis d'accord en fait je me suis mal exprimé