JeuWeb - Crée ton jeu par navigateur
Browser Quest - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Général (https://jeuweb.org/forumdisplay.php?fid=36)
+--- Forum : Des jeux (https://jeuweb.org/forumdisplay.php?fid=59)
+--- Sujet : Browser Quest (/showthread.php?tid=6057)

Pages : 1 2 3 4 5 6


RE: Browser Quest - Angelblade - 02-04-2012

L'avenir quoi


RE: Browser Quest - Maks - 02-04-2012

Personnellement je pense que Ajax et les Websockets peuvent cohabiter. Ajax ne nécessite pas de serveur et est plus simple à mettre en place (surtout si tu utilises Jquery ou une fonction maison comme moi).

Quentin > Tu as déjà essayé de combiner Node.js et les web workers ?


RE: Browser Quest - niahoo - 03-04-2012

(02-04-2012, 11:18 PM)quentin01 a écrit : Bien moins rapide même, le JS executé à l'aide de Node.JS selon les benchmarks va carrément bien plus vite que du PHP en CLI. De plus, le PHP comme le dit Maks est synchrone, or si plusieurs clients se connectent, PHP les bloque.

Si plusieurs clients se connectent, ils doivent pouvoir s'exécuter dans un thread Apache simultanément.

Non le seul problème avec php c'est son support pour les websockets mais c'est possible. et si tu prends un autre serveur qu'apache ça doit rouler.

Mais bon c'est se faire chier pour rien.



RE: Browser Quest - Amrac - 03-04-2012

Si j'ai bien compris Niahoo, les websocket & PHP n'utilisent pas apache lorsqu'ils sont ensemble.

C'est un CLI php qui tourne en fond, et qui est donc bloqué sur 1 thread.


RE: Browser Quest - niahoo - 03-04-2012

Exact je n'étais pas allé assez loin dans mes lectures d'exemples. Et ben ça craint d'autant plus, perso j'utiliserais pas un truc du style


RE: Browser Quest - quentin01 - 03-04-2012

Oui effectivement c'est un PHP en CLI qui tourne et non une page web comme ça fournit par Apache. Donc oui c'est mono-threadé Wink Après bon, si il faut utiliser PHP pour ça, faut coder soit même toute la partie Serveur qui recoit l'en-tête de départ, alloue un nouveau thread pour chaque client, etc. Autant utiliser Node.JS qui est fait pour ça et qui le fait très bien.

Concernant Ajax, c'est utile dans le cas où il faut recharger une partie d'une page, des données sur une page à intervalle peu rapprochés. Dans les autres cas, je pense que mettre en place un système avec Node.JS vaut mieux. ( Si c'est possible, donc si la personne a un serveur ).

@Maks : Non, en fait je me suis jamais bien intéressé aux WebWorkers, j'en ai pas l'utilisation vu que je ne code pas des trucs qui demandent beaucoup de calculs côtés clients. Par contre il m'est arrivé de faire de la délégation à des sous processus avec Node.JS ( possible aussi de faire du clustering dans le même genre ).


RE: Browser Quest - Argorate - 03-04-2012

(02-04-2012, 11:18 PM)quentin01 a écrit : Bien moins rapide même, le JS executé à l'aide de Node.JS selon les benchmarks va carrément bien plus vite que du PHP en CLI. De plus, le PHP comme le dit Maks est synchrone, or si plusieurs clients se connectent, PHP les bloque, il faudrait donc utiliser une extension permettant de multithreadé PHP, il n'est donc pas fait pour ça. Alors que le JS est lui fait pour ça, asynchrone et réellement fait pour être multithreadé.

Après je ne sais pas quoi dire de plus, c'est assez simple à comprendre. C'est la même architecture qu'un logiciel qui se connecte à un serveur. Le client s'y connecte à l'aide des sockets, et ils s'envoient mutuellement des sockets pour se dire ce qui se passe.

Concernant Node.JS en lui même et les websockets, tu as parlé d'Ajax et j'aimerais dire en quoi les websockets sont plus performantes. Une requête AJAX c'est une requête HTTP comprenant donc l'en-tête à envoyer, l'en-tête reçu et le contenu, or dans le cadre de petites informations ( donc de petit contenu ), les en-têtes HTTP sont majoritaire dans les échanges, les éviter économise beaucoup de bande passantes ( surtout qu'une requête HTTP passe par Apache, qui doit executer du PHP ... ). Les websockets sont un dérivé du protocole TCP mais utilisant une en-tête HTTP au départ, par la suite aucune en-tête n'est utilisé. C'est donc économe en bande passante, de plus, ça évite de passer par Apache ou d'executer un nouveau code à chaque fois puisque là le code du serveur est toujours en route en background sur le serveur. Cette solution est donc économe en bande passantes mais aussi en performances au niveau de l'execution du code.

Oué, pour le coup des header j'étais au courant, mais j'avais pas pensé a l'histoire d’asynchrone c'est vrai...

Du coup, n'ayant connu et utilisé qu'apache avec php, comment ça marche un serveur en JS? Comment on configure ça? Il reste une partie du code en php où c'est vrai que JS? (parce que du coup adieu l'OO)?

Sinon, autre chose que tu as dis qui m'intrigue, c'est que tu dis que le jeu reste en permanence en route sur le serveur, donc pas de perte de temps a recharger des données communes, c'est vachement énorme! du coup je comprends pourquoi le temps réel est possible avec autant de gain!

Merci pour les explications Wink


RE: Browser Quest - niahoo - 03-04-2012

Avec node JS il n'y a plus de PHP du tout, c'est un autre environnement tout simplement. Si node JS t'intéresse, il y a pas mal de tutos sur internet. une recherche rapide me donne ça http://www.nodebeginner.org/ il m'a l'air assez complet mais je ne connais ni Node.js ni la date de ce tuto.

et non pas adieu l'OO, enfin pas forcément. JS est un langage qui utilise majoritairement des objets, ils ne sont simplement pas organisés comme dans la pluspart des autres langages (des classes, des classes héritées) mais fonctionnent par prototype. Beaucoup de librairies essaient de simuler ce sytème de classes, y compris Backbone, hélas, en utilisant des 'new Machin()' partout et c'est dommage. JS est plus simple.


RE: Browser Quest - quentin01 - 03-04-2012

niahoo a déjà répondu pour le full JS mais je pourrais aussi rajouter qu'en fait Node.JS et un programme en C qui utilise le moteur V8 executant le javascript, lui rajoutant des APIs de base pour la gestion du réseau, de plus Node.JS met aussi en place une solution efficace pour l'héritage de classe.

Après c'est normal que le jeu reste lancé en permanence sur le serveur, c'est un peu le principe des relations clients -> serveurs, faut bien un serveur lancé en permanence. Et donc oui c'est plus performant à tout point de vue.

Et de rien pour les explications, si tu as d'autres questions je pourrais y répondre Wink


RE: Browser Quest - Argorate - 03-04-2012

Du coup adieu le php pour faire du temps réel donc? ^^
Pour l'OO, c'était dans le sens qu'on ne peut plus réellement déclarer de classe a proprement parlé, JS c'est du prototype pas renflement de l'objet même si comme tu dis, on peut le simuler plus ou moins.

Tout les hébergeurs permette de faire tourner node JS? comment ça marche niveau technique et déploiement?