Alors déjà je comprend pas ce que tu entends pas requêtes, si il s'agit de demander au serveur si il y a du nouveau, tu fais fausse route, enfin disons que c'est pas la meilleure solution. Je te conseille pour çà d'utiliser des socket ainsi ce sera instantanée (enfin avec le temps de transmission quand même!).
Pour la vue FPS et le bord de l'écran, je n'ai pas de solution, si ce n'est dire que si la dernière position de souris était proche du bord ben on continue de tourner. Pour ce qui est du contrôle de la souris j'ai pas compris l'idée et la supposition sur shockwave. Pour moi shockwave c'est ShockWave Flash et çà m'étonnerai qu'on puisse controller la souris quand l'utilisateur demande de la sortir de la zone flash...
Pour les déplacements de perso, je ne vois pas trop la question, pour moi dés que l'on reçois sur le socket le perso X a bougé ben, tu récupères l'objet en question (indexé dans une table ou via l'arborescence de la scène 3d comme tu veux) et on lui dit de bouger. Évidement il faut juste lui donner la destination (et éventuellement les points de passage), et faire une méthode pour déplacer entre chaque point de façon continue. Il est envisageable d'implémenter un moteur de prédiction de mouvement dans le cas ou le temps de mise à jour est trop long et ou on préfère la fluidité de mouvement à l'exactitude de ce dernier.
Pour le chargement, alors là c'est une grande question, déjà les textures et autre doivent être chargé dynamiquement dans la bibliothèque, ainsi je pense que le navigateur peut les mettre en cache. Un pack texture à télécharger peut être proposé à tes joueurs en cas de problème serveur (serveur pas assez performant, pas assez de bande passante). Sinon il est évident qu'il ne faut pas tout charger, certaines choses tellement fréquente peuvent être chargé au début mais sinon il faut juste déterminer un périmètre au delà du champs de vision à précharger, on peut aussi faire une estimation plus complexe avec le vecteur vitesse de la camera. Si c'est possible tu ordonnes le chargement en fonction de l'importance. Et si une texture est critique tu stoppes la fenêtre avec une barre de chargement.
Pour ce qui est du sol à déplacer, déjà tu le charge pas complètement, mais de plus dans sandy (je pense que c'est la même dans papervision) les objets trop éloigné ne sont pas affiché. Donc çà ne ramera pas à cause de çà (du moins ils ont déjà pensé à ce problème). Sans compter que les objet éloigné sont approximé en termes d'affichage.
Pour la montée normalement il doit y avoir un trucs spécifique pour faire le sol, faut regarder dans les tutos mais je pense pas que ce soit compliqué de ce point de vue.
Pour les collisions, tu dois installer en plus un moteur physique et apprendre à t'en servir. Perso pour mon trucs de téléportation j'ai juste fait 3 classes qui se chargent de représenter les collisions et d'envoyer les évènements dés qu'elles s'appercoivent qu'une de leurs instance et dans la zone d'une autre et çà grâce à un timer.
Bon ceci étant je crois que pour certaine chose tu te fais des illusion, enfin du moins je préfère te dire de faire gaffe. Je veux parler de vouloir détecter un coup d'épé par exemple, çà laisse entendre que tu veux des personnage assez réaliste pour être affiché en grand, donc quelques chose qui sorte des primitives habituel, quelques choses qui devra être modéliser avec un logiciel comme blender ou 3ds.
Le trucs c'est que c'est très lourd ces trucs là, c'est possible pour un personnage voir plusieurs, mais de là à penser un monde complet avec des perso réaliste, je ne sais pas si c'est faisable. Tu risque d'avoir des problèmes de lags énormes.
Un moteur comme sandy ou papervision, c'est pas la même chose qu'un moteur 3d normal, il faut en avoir conscience. Enfin je me trompe peut être...
Ouai en fait j'ai tord mais bon faut pas s'attendre à une qualité extrême je pense:
http://www.qigames.com/game.php?id=alienslayer
Attention faut cliquer sur le play et de laienslayer et non de la pub pour wizard...
Pour la vue FPS et le bord de l'écran, je n'ai pas de solution, si ce n'est dire que si la dernière position de souris était proche du bord ben on continue de tourner. Pour ce qui est du contrôle de la souris j'ai pas compris l'idée et la supposition sur shockwave. Pour moi shockwave c'est ShockWave Flash et çà m'étonnerai qu'on puisse controller la souris quand l'utilisateur demande de la sortir de la zone flash...
Pour les déplacements de perso, je ne vois pas trop la question, pour moi dés que l'on reçois sur le socket le perso X a bougé ben, tu récupères l'objet en question (indexé dans une table ou via l'arborescence de la scène 3d comme tu veux) et on lui dit de bouger. Évidement il faut juste lui donner la destination (et éventuellement les points de passage), et faire une méthode pour déplacer entre chaque point de façon continue. Il est envisageable d'implémenter un moteur de prédiction de mouvement dans le cas ou le temps de mise à jour est trop long et ou on préfère la fluidité de mouvement à l'exactitude de ce dernier.
Pour le chargement, alors là c'est une grande question, déjà les textures et autre doivent être chargé dynamiquement dans la bibliothèque, ainsi je pense que le navigateur peut les mettre en cache. Un pack texture à télécharger peut être proposé à tes joueurs en cas de problème serveur (serveur pas assez performant, pas assez de bande passante). Sinon il est évident qu'il ne faut pas tout charger, certaines choses tellement fréquente peuvent être chargé au début mais sinon il faut juste déterminer un périmètre au delà du champs de vision à précharger, on peut aussi faire une estimation plus complexe avec le vecteur vitesse de la camera. Si c'est possible tu ordonnes le chargement en fonction de l'importance. Et si une texture est critique tu stoppes la fenêtre avec une barre de chargement.
Pour ce qui est du sol à déplacer, déjà tu le charge pas complètement, mais de plus dans sandy (je pense que c'est la même dans papervision) les objets trop éloigné ne sont pas affiché. Donc çà ne ramera pas à cause de çà (du moins ils ont déjà pensé à ce problème). Sans compter que les objet éloigné sont approximé en termes d'affichage.
Pour la montée normalement il doit y avoir un trucs spécifique pour faire le sol, faut regarder dans les tutos mais je pense pas que ce soit compliqué de ce point de vue.
Pour les collisions, tu dois installer en plus un moteur physique et apprendre à t'en servir. Perso pour mon trucs de téléportation j'ai juste fait 3 classes qui se chargent de représenter les collisions et d'envoyer les évènements dés qu'elles s'appercoivent qu'une de leurs instance et dans la zone d'une autre et çà grâce à un timer.
Bon ceci étant je crois que pour certaine chose tu te fais des illusion, enfin du moins je préfère te dire de faire gaffe. Je veux parler de vouloir détecter un coup d'épé par exemple, çà laisse entendre que tu veux des personnage assez réaliste pour être affiché en grand, donc quelques chose qui sorte des primitives habituel, quelques choses qui devra être modéliser avec un logiciel comme blender ou 3ds.
Le trucs c'est que c'est très lourd ces trucs là, c'est possible pour un personnage voir plusieurs, mais de là à penser un monde complet avec des perso réaliste, je ne sais pas si c'est faisable. Tu risque d'avoir des problèmes de lags énormes.
Un moteur comme sandy ou papervision, c'est pas la même chose qu'un moteur 3d normal, il faut en avoir conscience. Enfin je me trompe peut être...
Ouai en fait j'ai tord mais bon faut pas s'attendre à une qualité extrême je pense:
http://www.qigames.com/game.php?id=alienslayer
Attention faut cliquer sur le play et de laienslayer et non de la pub pour wizard...