+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Le jeu sur internet, langages et intérêts (/showthread.php?tid=7612)
Le jeu sur internet, langages et intérêts - L'Omniscient - 28-03-2016
Bonjour,
Bon alors, d'abord, je tiens à dire que je ne suis pas doué dans les termes, donc ne m'en voulez pas si je nomme mal les choses.
Jouant en ce moment à des jeux en ligne de Blizzard, dont l'interface d'accueil est intégralement en ligne, je me demandais, quels sont les langages qu'ils utilisent ? Je me suis aussi demandé, quelles sont les majeures différences en terme de potentiel entre un jeu par navigateur et un jeu vidéo (je ne sais pas très bien comment différencier les nomenclatures).
Le jeu web fonctionne avec des langages côté serveur, côté client...
Mais un jeu vidéo en ligne, comment ça fonctionne exactement ? On enregistre les données sur l'ordinateur du joueur pour que l'ordinateur puisse lire plus facilement de nombreuses informations ? Et en terme de sécurité, comment ça marche ? Peut-on modifier des fichiers de jeux vidéos si on s'y connait ? Et enfin, s'il n'est pas possible de modifier des éléments d'un jeu vidéo enregistré sur son PC, comment se fait-il qu'il n'existe pas de langage sécurisé côté client, qui fonctionne un peu de manière similaire à un fichier de jeu vidéo ? (qui s'enregistrerait sur l'ordinateur par exemple)
D'autre part, en réfléchissant aux différences entre un jeu web et un jeu vidéo, on peut facilement relever la différence en terme de puissance, bien que je pense n'avoir jamais avoir vu de jeu qui utilisait le potentiel des langages de programmation pour navigateurs à son maximum (mis à part peut-être des jeux de studios de production comme Dark Orbit où ils vont assez loin en terme de ressemblance avec un jeu vidéo je trouve -je suis loin d'avoir testé beaucoup de jeux par navigateur, je précise-). Mais quand on regarde le site web de Dark Soul III par exemple (qui fait buguer mon ordi, mais c'est une autre histoire), on voit quand même qu'il y a pas mal de potentiel avec la programmation sur navigateur. Finalement, comme on en parlait dans un autre sujet, la grosse différence c'est dans l'animation, les langages de programmation pour navigateur ne permettent pas encore d'aller très loin à ce niveau là. Par contre, en terme de jouabilité, il y a autant de potentiel sur un jeu par navigateur que sur un jeu vidéo, l'animation en moins (après tout, en terme de calculs, on peut faire autant de choses non?)
Maintenant, là où je trouve que le jeu par navigateur est quand même assez fort, c'est dans sa simplicité d'accès. Pas d'installation, pas d'ouverture de programme, on se coupe pas du reste de son environnement informatique (en un clic on va voir ses mails, on ferme le jeu, beaucoup moins de dépendance en terme de temps). Je me suis demandé si cette simplicité d'accès pouvait rallonger la durée de vie d'un jeu ? Personnellement, tous les jeux vidéos auxquels j'ai joué, j'ai fini par ne plus y jouer, principalement parce qu'on était auparavant dépendant des CD ROMS, et qu'il fallait les trouver, les insérer, etc. Aujourd'hui ce n'est plus le cas, mais c'est vrai que je m'empêche quand même de jouer à certains jeux car le temps de mise en route implique de s'y consacrer un minimum de temps (le temps de lancer une partie, ça peut aller de 5 à 10 minutes, donc potentiellement au moins le double / triple pour "rentabiliser" le temps de démarrage). Par exemple, j'ai récemment acheter Dungeon Keeper 2 dont je n'ai pas fini la campagne, et je l'ai lâché pour un autre jeu, car s'investir sur 2 jeux à la fois, c'est difficile, ne serait-ce qu'à cause de ce temps de chargement des jeux (si on a deux / trois heures de disponible en rentrant du boulot pour se détendre, alterner entre deux jeux en temps de chargement, ça prend bien 20 minutes, comptez avec ça les possibles bugs de votre ordinateur, le temps que doit prendre l'ordinateur pour passer d'un jeu à l'autre, et tout ce dont j'ai déjà parlé ci-dessus).
Autre point sur lequel le jeu web me paraissait intéressant, mais que le jeu vidéo récupère de plus en plus : le social, la connectivité avec les autres joueurs. Un tchat, facebook, les mails... Tout ça, ce sont des éléments qui sont très présents dans les différents sites internet, mais quand on voit par exemple Battle Net, l'interface multijoueurs de Blizzard, avec l'omniprésence d'éléments sociaux, et en plus très dynamiques et animés, ça me paraît plus performant que sur un navigateur (bon, Facebook y arrive très bien, mais je ne sais pas quelles technologies ils utilisent, et faut avouer que ya tellement d'éléments que ça rame et c'est parfois plus chiant qu'autre chose). Après, je n'ai peut-être pas encore les clés pour avoir des échanges fluides entre client et serveur. Mais quand je vois l'AJAX par exemple, il y a quand même un temps de traitement avant la récupération des données pour les renvoyer au client non ? Personnellement, sur un code avec 4 requêtes SQL, j'ai 1 à 3 secondes de délais selon le navigateur, en ayant supprimé et allégé tout ce que je pouvais, alors qu'une telle action sur un jeu vidéo serait immédiate. Est-ce qu'il existe des langages de développement, technologies ou frameworks pour navigateur qui permettent d'échanger plus rapidement en le client et le serveur ?
Et en terme de jeux vidéos multijoueurs, comment ça se passe ? Quels sont les langes de programmation utilisés ?
Voilà, je vous ai fais part de mes questions, de mes réflexions, j'attends vos avis, vos réponses, et tout ce que vous voulez ! Je le redis, je ne suis pas du tout dans le monde de la programmation ou du jeu, donc je ne connais pas du tout les termes, et je ne m'y connais pas non plus vraiment en terme de technique. Donc si je dis des absurdités, ne soyez pas agressifs comme peuvent l'être certains utilisateurs d'OC par exemple, dites moi simplement que je me trompe
RE: Le jeu sur internet, langages et intérêts - MadMass - 28-03-2016
Hmm je ne vois pas d'exemple de jeu Blizzard dont l'interface d'accueil serait intégralement en ligne, tu pourrais en donner un ? Tous les jeux blizzard que j'ai touché étaient 100% client lourd.
RE: Le jeu sur internet, langages et intérêts - L'Omniscient - 28-03-2016
Starcraft 2 et Heroes of the Storms par exemple.
Pour les deux jeux, il y a un tchat accessible à tout moment et le choix entre partie solo et partie multijoueurs se fait en un clic, et nécessite exactement le même temps de chargement (il y a la recherche des joueurs en plus bien sûr). Alors qu'avant, sur Warcraft III par exemple, il fallait se connecter à Battle Net pour accéder au multijoueur.
RE: Le jeu sur internet, langages et intérêts - MadMass - 28-03-2016
Ah dans ce sens là, ok. Ben je sais pas précisément quelles technos ils utilisent mais ça doit probablement être basé sur des moteurs maison en C++ des deux côtés ^^
Ce sont des programmes exécutables, des trucs lourds quoi, compilés, et même s'ils utilisent un langage de script interprété par dessus pour tout ce qui est interface, ça repose quand même sur un moteur derrière qui est du bon gros code bien lourd et bien complexe. Derrière c'est une connexion en TCP ou UDP selon les besoins (sûrement en TCP pour les menus et en UDP pour le jeu lui-même), mêlé à des requêtes HTTP pour les trucs un peu statiques (les messages de maintenance sur WoW ça passait par http de mémoire).
Du coup non ils n'enregistrent rien de sensible sur l'ordinateur du joueur, y'a que les fichiers techniques du jeu (programmes compilés, ressources graphiques...), tout est côté serveur, et la connexion au serveur est permanente. Bien évidemment on peut modifier le jeu côté client avec plus ou moins de difficulté, mais derrière le serveur vérifie les données qu'il reçoit et détecte les incohérences qui apparaissent en cas de triche par exemple.
C'est sûr que l'avantage des jeux de ce type c'est que c'est des "vrais" jeux, qui exploitent pleinement le matériel notamment, et puisqu'ils sont installés côté client on économise le chargement des données... Le premier qui veut faire un wow-like dans un navigateur il va pouvoir s'accrocher rien que au niveau du buffering des données. Forcément l'inconvénient c'est qu'il faut installer, bon... Dans WoW ils ont réussi à gérer suffisamment bien les ressources pour que le jeu soit jouable sans être totalement téléchargé, il télécharge en live les éléments les plus proches du joueur en priorité et ça marche plutôt pas mal, même si ça induit du lag. Et parfois un beau mur bleu pour te dire de faire une pause parce que le bout de map derrière n'a pas été chargé encore. Mais c'est surtout un palliatif au fait que sur WoW, beaucoup de joueurs + jeu très lourd impliquait de passer la journée à télécharger la MaJ sans jouer y'a 10 ans, du coup ça réduit un peu le côté frustrant. Techniquement c'est beau mais tellement dur à mettre en place que je ne crois pas avoir vu quiconque s'y risquer à part eux...
L'un des avantage du jeu web, ceci dit, c'est de pouvoir jouer au boulot. Alors que jouer à WoW ou heroes of the storm au bureau discrétos, bon courage.
RE: Le jeu sur internet, langages et intérêts - Thêta Tau Tau - 28-03-2016
En fait un jeu "bureau" multijoueur ou un jeu par navigateur fonctionnent de manière similaire, avec un serveur et un client.
La différence principale c'est que dans un jeu web, le client tourne sur un navigateur et est donc soumis à certains standards, alors que dans un jeu bureau, on est libre quant au choix de la technologie. Par exemple le seul langage de programmation possible dans un navigateur est le javascript, alors qu'on peux faire un client dans n'importe quel langage pour un jeu bureau.
Après si on prends en compte les plugins (unity web player par exemple), on peux avoir une technologie non standart dans le navigateur, du coup il n'y a quasiment plus de différences entre les jeux web et les jeux bureau, mais on perd une partie de l'intérêt du web puisqu'on oblige l'utilisateur à installer le plugin.
Parce que ouais, l'avantage du jeu web, c'est l'accessibilité : on peux jouer à un jeu web sans rien installer, depuis n'importe quel ordinateur.
Ca c'était pour le côté technologie, après du côté gameplay, il y peut aussi y avoir quelques différences, par exemple les jeux de gestion par navigateur se jouent souvent en "mutlitache" (on fait autre chose en même temps).
RE: Le jeu sur internet, langages et intérêts - Patatruc - 29-03-2016
(28-03-2016, 04:54 AM)LOmniscient a écrit : Peut-on modifier des fichiers de jeux vidéos si on s'y connait ?
Oui, comme pour tout autre type de programme exécutable, mais ça demande des compétences plus pointues que bidouiller le DOM ou du code Javascript dans un navigateur.
Citation :D'autre part, en réfléchissant aux différences entre un jeu web et un jeu vidéo, on peut facilement relever la différence en terme de puissance
C'est vrai actuellement, mais l'écart pourrait être considérablement réduit quand le projet WebAssembly sera finalisé. Peut-être d'ici un ou deux ans ? Ca semble aller très vite.
Citation :Est-ce qu'il existe des langages de développement, technologies ou frameworks pour navigateur qui permettent d'échanger plus rapidement en le client et le serveur ?
Dans un jeu en temps réel par navigateur, on ne passerait pas par AJAX mais par des WebSockets.
RE: Le jeu sur internet, langages et intérêts - Xenos - 29-03-2016
Comme Theta TauTau l'a dit: le jeu web n'a pas la maitrise du navigateur (et doit donc respecter les normes HTML et autres) alors qu'un jeu vidéo classique a la maitrise sur le "navigateur" (aka, le code client du jeu) et par conséquence, sur le contexte du joueur (il est sur console? PC? quels paramètres peut-il régler?)
Dans les deux cas, tout ce qui est chez le client est falsifiable (raison pour laquelle certains jeux sont crackés limite avant leur sortie). Donc, niveau triche, c'est au serveur de tout vérifier, que ce soit un jeu bureau ou web (certains jeux bureau font quand même confiance au client pour des raisons de perfs: les concepteurs préfèrent un jeu fluide chez 100% de joueurs dont 5% de tricheurs qu'un jeu fluide chez seulement 5% de joueurs avec 0% de tricheur).
Pour l'aspect "facilité d'accès", je ne suis pas tant d'accord que cela: les jeux bureau Plug & Play, ça existe. Et tu peux très bien faire un téléchargeur de 2Mo qui va télécharger les données du jeu à la volée et au besoin (voire en arrière-plan). Pour moi, la facilité d'accès, tu l'as uniquement si tu restes sur du HTML standard, car tu as un jeu accessible sur tous les supports, dans tous contextes (ce qu'un jeu classique ne permet pas facilement, ne serait-ce que si son gameplay n'est pas adapté).
En revanche, je suis d'accord sur le "cout" d'ouverture d'un jeu classique. Mais il faut en faire une force: on jongle entre jeux web, donc autant ne pas trop chercher l'immersion et se concentrer sur l'ergonomie. A l'inverse, sur un jeu classique, il faut miser sur l'immersion car elle ne sera pas "cassée" par un saut dans la boite mail.
RE: Le jeu sur internet, langages et intérêts - Thêta Tau Tau - 29-03-2016
(29-03-2016, 02:34 PM)Xenos a écrit : Pour l'aspect "facilité d'accès", je ne suis pas tant d'accord que cela: les jeux bureau Plug & Play, ça existe. Et tu peux très bien faire un téléchargeur de 2Mo qui va télécharger les données du jeu à la volée et au besoin (voire en arrière-plan).
Je suis d'accord, une installation n'est pas une énorme barrière, mais quand on voit que, par exemple, si le temps de chargement d'un site passe de 2 à 4 secondes, le taux de rebond explose, ou encore qu'on perd plein de joueurs quand on demande une validation de mail à l'inscription, il faut se dire que même une petite barrière peut avoir son importance.
RE: Le jeu sur internet, langages et intérêts - L'Omniscient - 29-03-2016
C'est génial de vous lire, ça enrichit tellement ma vision des choses !
Whaaa, WebAssembly ça fait rêver ! :o Selon vous, quand on veut vraiment s'investir dans des projets de jeu sur ordinateur à long terme (sans prendre en compte des jeux à énormes animations), est-ce qu'il est important d'apprendre le C et ses dérivés ou le développement web a-t-il un vrai avenir dans le jeu vidéo ?
D'ailleurs, en lisant quelques infos sur WebAssembly, je lis que ça envisage de devenir le langage binaire du web. Ca veut dire que des langages assembleurs (si c'est bien comme ça qu'on les appelle) vont être réalisés à partir de ce langage binaire ?
Merci pour WebSockets, je n'avais jamais vu ça :o Je vais me renseigner. C'est peut-être la résolution à mes problèmes ! Le délai de récupération des données est immédiat ? C'est sécurisé (contrairement au JS) ?
RE: Le jeu sur internet, langages et intérêts - Patatruc - 29-03-2016
(29-03-2016, 06:48 PM)LOmniscient a écrit : D'ailleurs, en lisant quelques infos sur WebAssembly, je lis que ça envisage de devenir le langage binaire du web. Ca veut dire que des langages assembleurs (si c'est bien comme ça qu'on les appelle) vont être réalisés à partir de ce langage binaire ?
En gros, c'est un langage de bas niveau pouvant faire vaguement penser à de l'assembleur, en effet (en plus lisible). Il n'y a pas grand-chose de très détaillé en Français sur le sujet. En Anglais, voici une très bonne présentation avec des exemples de code : https://auth0.com/blog/2015/10/14/7-things-you-should-know-about-web-assembly/
Potentiellement, un programme compilé en Webassembly pourrait être écrit à terme dans n'importe quel langage. Actuellement il est restreint au C++ mais l'ambition est de l'ouvrir à d'autres langages... c'est très ambitieux, à un tel point qu'il y a une inquiétude sur javascript à long terme, comme le montre cette interview de Brendan Eich. En tout cas, ça pourrait signer la fin du quasi-monopole de Javascript sur les clients Web, .
Citation :Merci pour WebSockets, je n'avais jamais vu ça :o Je vais me renseigner. C'est peut-être la résolution à mes problèmes ! Le délai de récupération des données est immédiat ? C'est sécurisé (contrairement au JS) ?
A la base ça repose sur TCP donc oui c'est rapide, ce n'est conditionné que par le ping et le débit du client (et du serveur). Pour que ce soit sécurisé il faut utiliser un Websocket sécurisé (protocole wss, équivalent du https pour http).