Discussion :

[ac_wingless]

Et tu as effectivement mis le doigt dessus sans le vouloir: c'est irréaliste.
On est bien d'accord: c'est pourquoi je veux recadrer cette discussion autour de son titre :le jeu par Cloud computing ne passe pas par ces histoires de video compressée, mais par la gestion complète des ordres GPU par un serveur. Il y avait bien d'autres choses que Onlive à la Games Convention Online. La phrase citée de raptor s'applique aussi bien au "Direct3D 10.1 Command Remoting" qu'à Onlive.

- Il faut installer le jeu en local avant d'y jouer
oui, comme il faut installer un browser. C'est simplement un problème de standard. DXGI 1.1 est un pas dans cette direction, il n'est pas bien difficile d'imaginer un "browser de jeu DXGI1.1" sur lequel n'importe quel jeu pourrait s'exécuter.

- plus possible aux éditeurs de s'assurer de l'absence de piratage (le seul truc qui les motive, eux, pour info)
au contraire, ça résoud complètement ce problème.

- besoin d'upgrade hardware régulier côté client puisque -au delà de la partie 3D- il faudra bien faire tourner le reste en local.
Besoins minimaux hors GPU. Pour vous donner une idée, dans un système réel similaire dans son principe bien que basé sur du P2P, on dépense 474W dans les GPUs, 4W dans l'équivalent CPU (en fait un système propriétaire bien moins puissant qu'un CPU, mais largement capable d'étouffer un GPU), et presque 1W dans la partie de FPGA qui s'occupe de la liaison ETH. Cela veut dire que le coté client ne paie que pour la qualité du graphisme qu'il veut avoir en local, pas pour le reste. Le "reste en local", c'est presque rien, peut-être 5W avec des Atom.

- des besoins en bande passante totalement irréalistes pour des connexions WAN (ou alors on parle des 0.00001% de la population qui ont un accès Gigabit chez eux, et encore).
Absolument pas. Le débit passant sur le PCIe est pratiquement nul en dehors des cas que j'explique en détail au dessus (VB, IB, textures, qui sont dès aujourd'hui gérés par les MMOs en termes de débit).

Pour en revenir à l'argument du "vécu" du joueur, il est évident, mais d'une part il saute complètement si les jeux sont modifiés (mon argument ci-dessus, où Turbine a changé son principe de MMO à latence de FPS pour un MMO à latence du genre WoW, et rencontré le succès), et d'autre part et surtout, la qualité de la perception locale s'est considérablement améliorée ces dix dernières années. En particulier, pour adapter localement et en temps REEL (je parle même pas de 50 ms, mais plutôt de la latence de PCIe) le rendu calculé par le serveur, il suffit de mettre à jour exactement 64 ou 128 octets au travers du bus PCIe pour une expérience utilisateur parfaite. Il y a déjà des outils CAO collaboratifs qui permettent des mouvements instantanés en local, ce n'est qu'une question de temps que ça arrive dans le domaine du jeu. Le flux remontant permet au serveur de lisser le résultat et d'assurer une perception cohérente sur l'horizon 300 ms, avec un retour instantané sur tous les mouvements locaux se combinant naturellement à l'affichage (caméra, déplacement, etc.) et suffisamment rapide (de type MMO) pour tout ce qui ne relève pas de la jouabilité de FPS (IHM).
Je pense que vous confondez la perception locale du joueur et la cohérence en multijoueur. Dans le cadre multijoueur, calculer les ordres GPU sur un serveur ou en local ne change pas le problème de cohérence inter-joueur: l'argument est neutre.

Par ailleurs, vous parlez sans arrêt de "rendu sur le serveur"... vous avez bien compris que le rendu est fait sur le client? Seuls les ordres de rendu sont faits sur le serveur. Pensez en termes de fichier PIX... On est bien d'accord que dérouler un PIX par internet n'est pas bien difficile, n'est-ce pas? Alors quelle est la différence entre ça et ce que propose Microsoft dans Windows 7?

[nouknouk]

- Il faut installer le jeu en local avant d'y jouer
oui, comme il faut installer un browser. C'est simplement un problème de standard.

Donc tu as la solution pour développer un client de jeu global capable de servir de moteur de base pour n'importe quel jeu qui sera distribué, seules quelques règles de jeu étant déployées à chaque fois ? Une sorte de Saint Graal du gameMaker, quoi

Et sinon, s'il faut à chaque fois installer ou télécharger une partie majeure spécifique à chaque jeu, il est où l'intérêt pour le joueur comparé à une solution comme Steam ?

:le jeu par Cloud computing ne passe pas par ces histoires de video compressée, mais par la gestion complète des ordres GPU par un serveur.

Je ne comprends pas ce que tu veux faire, pour moi il n'y a que deux solutions concernant le rendu (je parle de transformer des primitives graphiques glVertex, glCeci, glCela en une image composée de pixels de couleurs):

1/ Le rendu est effectué côté serveur. Il va transformer des primitives (ie. des appels à une bibliothèque quelconque openGL, DirectMachin ou autre) en une image qui sera destinée à être affichée sur l'écran du client. L'image est donc générée côté serveur et il faut que le client l'affiche. Il faudra donc bien à un moment où à un autre transférer l'image du client vers le serveur. Et quel autre moyen que de la vidéo ? A partir de là, deux solutions:

- solution 1: de la vidéo non compressée (admettons en 720p @ 50Hz, loin de ce que nous propose déjà une PS3 par exemple), c'est 1280x720x3x50 = 1Gbits/sec de débit nécessaire

- solution 2: de la vidéo compressée. Au delà du fait que la qualité sera forcément moins bonne qu'un rendu en local qui sera par définition non compressé, il reste un problème de taille: on n'encode pas de la vidéo comme ça, et surtout la compression se fait en fonction des images précédentes et suivantes ce qui introduit une latence (typiquement, les équipements actuels low-latency sont entre 100ms pour du MPEG2 à 300ms pour du MPEG4) => latence inacceptable pour un jeu.

2/ Le rendu est effectué côté client: Dans ce cas on perd tout l'intérêt du cloud puisqu'il ne va mutualiser que la portion congrue de la puissance nécessaire à faire tourner le jeu. Le joueur devra toujours changer régulièrement de carte graphique s'il veut espérer jouer dans de bonnes conditions. Il est où l'intérêt ?

De plus, le serveur devra attendre les input du joueur avant de dérouler la logique de jeu qui amènera à renvoyer les "ordres de rendu". Bref, on garde le même problème de latence (un aller/retour entre le client et le serveur) mais on se rajoute des soucis sur le dos. Pourquoi faire simple quand on peut faire plus compliqué ?

Je ne vois pas d'autre solution. Ou alors je n'ai pas compris ton idée géniale (que visiblement personne n'a jamais eu avant). Explique nous en détail concrètement ce qui passe dans chaque sens (client=>server et serveur=>client) et qui fait quoi (logique de jeu, calcul 3D, rendu, rasterization, ...).

Pour en revenir à l'argument du "vécu" du joueur, il est évident, mais d'une part il saute complètement si les jeux sont modifiés (mon argument ci-dessus, où Turbine a changé son principe de MMO à latence de FPS pour un MMO à latence du genre WoW

Effectivement, faire du cloud pour un jeu qui n'a pas de contraintes temps-réel fortes est possible (et encore, le MMO je doute plus que fortement). Même que je parie qu'on pourrait dès maintenant faire un monopoly online en cloud
Plus sérieusement, quelle proportion de jeux vont subsister par rapport à ce qui est actuellement vendu sur le marché si tu élimines d'emblée les FPS, les jeux en "third person camera" et plus globalement tout ceux où l'espace de jeu' n'est pas globalement constant ?

Je pense que vous confondez la perception locale du joueur et la cohérence en multijoueur.

C'est justement toi qui confonds les deux ! Il y a deux posts, tu voulais appliquer les algorithmes de prédictions dévolus au moteurs réseaux sur de la "prédiction de vidéo" !

[Mat.M]

Le rendu est effectué côté serveur. Il va transformer des primitives (ie. des appels à une bibliothèque quelconque openGL, DirectMachin ou autre) en une image qui sera destinée à être affichée sur l'écran du client. L'image est donc générée côté serveur et il faut que le client l'affiche. Il faudra donc bien à un moment où à un autre transférer l'image du client vers le serveur. Et quel autre moyen que de la vidéo ? A partir de là, deux solutions:

- solution 1: de la vidéo non compressée
- solution 2: de la vidéo compressée

Non je ne crois pas que ce soit ce dont parle ac_wingless et je crois avoir compris ce qu'il veut dire

Ce qu'il veut dire, si je pige bien, c'est que tous les calculs et toutes la logique du jeu seront effectués sur un serveur et via une sorte de protocole internet ( comme TCP/IP ) propre à Direct X des commandes GPU seront directement envoyés du serveur calculateur vers le client et le client n'aura plus qu'à les décoder.
Le client pourra décoder également toutes les instructions de rendu qui se situent entre un BeginScene et EndScene de Direct3d classique..

[deadalnix]

Perso, autant je suis convaincu par le cloud dans bien des domaines (et pour cause, je travaille dans le domaine et la demande explose).

Faire du cloud permet de réduire tout un tas de coûts : des machines moins puissantes, des système avec des configuration simples, et le tout couplé avec la virtualisation, on peut avoir juste la puissance qu'il faut coté serveur, en partageant le rab avec d'autres boites.

Mais alors pour le jeu vidéo, je suis très circonspect.

Tout d'abords on à les latences, mais avec l'augmentation des perfs réseau soit. Viens le soucis du débit mais la aussi le temps devrait régler le soucis.

Mais coté puissance de calcul . . . Pour vous donner une idée, essayez de faire tourner un serveur NX chez vous et ouvrer un vingtaine de sessions dessus pour voir.

Le cout en infrastructure va être colossal pour les éditeurs. Ils ne s'y retrouveront jamais à moins de faire du pong/tetris/pacman .

Je crois que le cloud dans le JV relève du même délire que la suppression du mode LAN dans SC2 ou bien le fait d'être obligé d'être connecté à internet pour jouer en solo a CC4.

Les décideurs sont très déstabilisé par internet et ne savent pas comment l'aborder. Ils essayent de garder le controle de ce qui est par nature incontrôlable. Ce qui est un choix digne des batailles de don quichotte contre ses moulins.

On l'a vu avec les DRM dans la musique vidéo par exemple, même avec les lois passée a grand coup de lobbing qui vont avec, ça s'est révélé inefficace. Le problème est le même ici : le cloud n'apporte rien au JV, il permet juste à l'éditeur d'avoir un plus grand controle sur son produit. C'est voué à l'échec a part pour quelques cas qui vont percer par miracle pour peu qu'un grand gourou les soutienne (je vois bien un iGame par apple par exemple).

Pour le reste, ça signifierait une baisse dans la variété de gameplay, dans la variété de jeux aussi, vu que les petits n'auront pas l'infrastructure pour faire ce genre de choses. Plus de mods (on aurait jamais connu counter strike à ce jeu la).

Qui plus est, le jeu en cloud aura toujours un train de retard vis a vis de son homologue sans cloud, qui est soumis a des contraintes moindres.

Bref, oui dans l'avenir ce sera surrement possible mais tant que ça n'apporte rien d'autre qu'un plus grand controle de l'éditeur, c'est un délire de décideur non éclairé. De plus, l'explosion des couts engendré va en faire reculer plus d'un.

[Mat.M]

Mais coté puissance de calcul . . . Pour vous donner une idée, essayez de faire tourner un serveur NX chez vous et ouvrer un vingtaine de sessions dessus pour voir.

Le cout en infrastructure va être colossal pour les éditeurs. Ils ne s'y retrouveront jamais à moins de faire du pong/tetris/pacman .

Je crois que le cloud dans le JV relève du même délire que la suppression du mode LAN dans SC2 ou bien le fait d'être obligé d'être connecté à internet pour jouer en solo a CC4.

Voilà c'est parfaitement bien dit

[unmanos]

Ouais assez d'accord pour dire que pour le jeu video ca me parrait pas tres realiste (en ce qui concerne la partie client car pour les serveurs le cloud c'est clairement l'avenir).

Meme si on arrive a avoir des temps de latence tres faible, le cout me parrait trop eleve pour maintenir un service, par example dans le cadre d'un MMO.

Eventuellement pour du casual gaming pourquoi pas... mais je reste assez dubitatif. Peut etre a tres long terme...

[DzzDDzzD]

Ouais assez d'accord pour dire que pour le jeu video ca me parrait pas tres realiste (en ce qui concerne la partie client car pour les serveurs le cloud c'est clairement l'avenir).

Meme si on arrive a avoir des temps de latence tres faible, le cout me parrait trop eleve pour maintenir un service, par example dans le cadre d'un MMO.

Eventuellement pour du casual gaming pourquoi pas... mais je reste assez dubitatif. Peut etre a tres long terme...

sans compter que pour un jeu de type FPS le temp de réponse à la rotation de la caméra ne pourra jamais etre asse rapide pour que le jeu soit jouable.


EDIT : par contre clair à mon avis que le futur se situe dans les jeux jouable en ligne sans une grosse installation ou directement dans le navigateur avec passage en mode plein ecran si demandé et idem pour les logiciels mais bon en fait ca fait un bail que ca a commencé

[oxyde356]

Ouai alors pour le jeu le cloud computing j'y crois vraiment pas. Il n'y a vraiment aucune avancé technologique vraiment visible qui réduit le temps de latence et s'il n'y a pas d'application client qui prend les actions de l'utilisateur instantanément et qui utilise un compensateur de ping et bien sans ça le jeu n'orait aucune réactivité. Donc déjà exit les FPS, ça peut peut être passé pour un RTS mais bon dite ça à un joueur de haut niveau
En somme je pense que ça se limitera a des jeux pour enfants

[deadalnix]

Il n'y a vraiment aucune avancé technologique vraiment visible qui réduit le temps de latence

Et pour cause, la vitesse de la lumière n'est pas prête de changer. Dans une fibre optique, la lumière met un peu moins de 0.2s à faire l'aller retour Europe US par exemple. C'est donc une sorte de limite qu'on ne pourra pas dépasser technologiquement.

[nouknouk]

Et pour cause, la vitesse de la lumière n'est pas prête de changer. Dans une fibre optique, la lumière met un peu moins de 0.2s à faire l'aller retour Europe US par exemple. C'est donc une sorte de limite qu'on ne pourra pas dépasser technologiquement.

Effectivement, mais ce genre de limitation pourra être dépassé dans le cadre de 'cloud' pour les jeux en multipliant les serveurs installés au plus proche du client final. Par exemple, on peut très bien imaginer que la boite qui va vouloir faire du cloud sur les jeux installera des serveurs dans chaque backbone de chaque FAI national ou supra-national (genre un pour Orange Europe, un pour Free, un pour At&T US, etc...).
A partir de là, tu as pas exemple moins de 10ms pour tout serveur situé à moins de 3000km du client final, ce qui commence à devenir acceptable même pour un jeu type FPS. Etsi ce n'est pas encore assez, rien n'empêche de multiplier les nombre de serveur pour diminuer le rayon d'action de chacun (au prix d'un surcoût non négligeable en termes d'infrastructures).

Mais finalement le problème en soit ne vient pas de la vitesse de transmission dans le tuyau, mais toutes les autres étapes qui ralentissent le schmilblick.

La compression vidéo HD par exemple prend entre 100ms et 300ms (temps de calcul + besoin d'un buffer des images à venir, ...), soit 10 à 30 fois le temps de transmission des données. Sans parler du fait qu'on ne peut quasiment pas décoder une trame qu'une fois complètement reçue.
Même principe pour plein d'autres choses, genre hétérogénéité des couches 1 à 3 dans le réseau qui implique une 'conversion' et qui demande également du temps (cf. MPLS, ATM, FR, Ethernet, ...), le routage dans le backbone du FAI, etc ...

C'est AMHA l'ensemble de ces "à côté" qui posent réellement des soucis car ce sont eux qui engendrent le plus de latence ; le temps de transmission proprement dit étant alors négligeable par rapport au reste, tout en étant surmontable en multipliant les fermes de serveurs réparties géographiquement.

Donc même si je continue à penser que le cloud est totalement irréaliste actuellement, je pense également que ça deviendra beaucoup plus faisable à moyen terme. Par exemple, le jour où tout le monde est fibré en point à point, on peut faire passer du 10Tb/s sur son lien, ce qui réduit les 'switch' entre techno réseaux et élimine le besoin de compression de la vidéo/audio.

Mais "le jour où tout le monde sera fibré en point à point", il n'arrivera pas avant 10 à 20 ans.

[deadalnix]

Oui bien sur, ces autres problèmes existent.

Je voulais juste signaler que même dans le monde des bisounours ou on aurait réussit a résoudre tous les soucis techniques, et bien ça ne marcherait toujours pas.

A moins de placer des serveurs un peu partout sur la planète pour être proche du client. Mais la, je deviens de plus en plus dubitatif sur l'intérêt de la chose et donc en reviens a mon hypothèse de départ : le cloud dans le JV, c'est un désir de la part des décideurs des boites de JV, qui va dans la ligné d'un plus grand contrôle de l'utilisateur (je ne souhaite pas entrer dans un débat sur le bienfondé de ce contrôle, il est pour moi nuisible, mais le plus important, c'est que ce soit un fait : steam, SC2 et CC4 en sont de bons exemples).

Parce qu'un fois qu'on aura dépensé des fortunes en infrastructure pour faire marcher ce genre de choses, finalement, ça rapportera quoi ? Il est ou le ROI ?

[nouknouk]

Parce qu'un fois qu'on aura dépensé des fortunes en infrastructure pour faire marcher ce genre de choses, finalement, ça rapportera quoi ? Il est ou le ROI ?

Du côté du client final, il se dit que:
- le client ferait des économies en matériel en n'ayant plus à renouveler son matos.
- la possibilité de jouer à un jeu immédiatement, sans la phase achat ou téléchargement + installation.
- la réduction des coûts pour l'éditeur se répercuterait sur le prix final payé par le client.

Ces avantages, notamment le troisième tiennent pour moi plus de l'argument 'commercial' à priori pour faire accepter le bazar plutôt que des faits établis. On ne pourra de toute façon juger que le jour où ce genre d'offre existera.

Le ROI pour les professionnels du jeux sont eux bien plus factuels et évidents:

- le coût de la distribution quasiment réduit à néant (ie. mettre à dispo une image du jeu sur x serveurs comparés à la production, l'acheminement et les coûts liés à la vente d'une boite de jeu).
- les gains en nombre de vente:
* les jeux ne pouvant pas être piratés, on peut vraisemblablement s'attendre à une hausse du nombre de joueurs qui vont acheter le produit
* l'achat étant facilité (quelques clics depuis son canapé), l'achat impulsif sera probablement plus répandu (cf. la VOD avec les FAIbox vs. les magasins de location de DVD vidéos).

le cloud dans le JV, c'est un désir de la part des décideurs des boites de JV, qui va dans la ligné d'un plus grand contrôle de l'utilisateur

De fait.

[deadalnix]

Enfin des fermes de serveurs partout dans le monde, avec des équipes pour les maintenir 7/24 dont au moins une partie sur place, c'est ça les couts de distribution d'une telle méthode.

[nouknouk]

- le coût de la distribution quasiment réduit à néant (ie. mettre à dispo une image du jeu sur x serveurs comparés à la production, l'acheminement et les coûts liés à la vente d'une boite de jeu).

Enfin des fermes de serveurs partout dans le monde, avec des équipes pour les maintenir 7/24 dont au moins une partie sur place, c'est ça les couts de distribution d'une telle méthode.

Effectivement, j'y suis allé un peu fort dans mon post. A noter qu'il faut également y ajouter le coût de renouvellement régulier du matériel (les CG notamment) pour rester à la pointe de la techno au moins pour les jeux qui en auront besoin.

Mais je pense quand même que le coût de l'infrastructure et sa maintenance sera beaucoup moins élevé que le coût de fabrication + distribution d'un produit en "boite" (coût du support physique + ce qu'il y a autour, acheminement dans des milliers de magasins, invendus récupérés par l'éditeur, produits déteriorés, marges arrières pour les grandes chaines de supermarchés, stocks [immobilisation d'actifs,entrepots, ...], marges des nombreux intermédiaires et fournisseurs, ...) .

[oxyde356]

Et pour cause, la vitesse de la lumière n'est pas prête de changer. Dans une fibre optique, la lumière met un peu moins de 0.2s à faire l'aller retour Europe US par exemple. C'est donc une sorte de limite qu'on ne pourra pas dépasser technologiquement.

lol oui biensûr au niveau du cable il n'y a pas grand chose a faire mais je ne suis pas sûr qu'il n'y est que ça à prendre en compte, il y a aussi les traitements effectués par les cartes réseaux, les routeurs, qui font perdre du temps (je ne connais pas la proportion, et dans le cas d'internet vu le nombre de routeurs traversés ce n'est peut-être pas négligeable (en tout cas vu le lag théorique que l'on devrait avoir avec un gars de los angeles et le lag réel :/). Enfin bon un professionnel qui investie dans autant de serveurs juste pour que l'utilisateur puisse utiliser ces produits (sachant que le nombre d'utilisateurs pour un serveur sera surement très petit) alors qu'avant il n'avait pas besoin de le faire ça me laisse perplexe bon on va me dire que c'est déjà arriver pour les MMORPG mais je pense qu'au niveau finance le gain était beaucoup plus visible.

[unmanos]

Du côté du client final, il se dit que:
- la possibilité de jouer à un jeu immédiatement, sans la phase achat ou téléchargement + installation.

Et d'un autre cote, vu le debit qu'il faut le telechargement d'un jeux peut se faire tres vite.

Pour le piratage c'est deja de plus en plus le cas, puisque petit a petit les jeux se jouent en ligne.

L'avantage qu'on pourrait eventuellement voir avec ce systeme c'est la quasi impossibilitee de hacker. Quand on voit ce qu'on est oblige de faire pour blinder les serveurs de ce cote la, c'est pas negligeable...

[oxyde356]

Si c'est pour porter un coup au "piratage" j'ai bien peur que le remède soit pire (financièrement) que le "mal". Et puis bon ça n'empechera pas le vol de clé d'authentification qui risque même de se répandre encore plus.

[LittleWhite]

Je viens de tout lire... et je suis plutot d'accord avec le gars qui parlait d'envoyer les ordres graphiques aux clients. ( Après avoir calculé le tout sur le serveur ).

Enfin l'idée que vous avez tous démoli. :p

Je sais une chose, c'est que OpenGL est un modèle client / serveur, donc cela se faisait déjà mais à une autre echelle. Avec OpenGL une grande partie était faites coté serveur , et puis on envoyer vraiment une petite partie chez le client.
Bon faut croire que c'est un modèle du même genre qui va être repris.

Je sais aussi autre chose, c'est qu'avec juste un dump de la mémoire on peut refaire toute une séquence graphiques. Assez facilement j'entend.

Donc, le truc, c'est que l'on va calculer l'image coté serveur ( encore heureux ).
Donc le serveur gère toute la machine du jeu ( tout l'engine ) et envoie un resultat dans le format voulu au client. Le client aura plus qu'a faire une partie de decompression ( pas video ) calcul, pour afficher la scène.
Si on veut enlever les lags on peut envoyer aux clients toute la zone visible pas le jouer ( toute la salle ) ( comme ça s'il se tourne, il n'aura pas de lag, car il a déjà les données )

En plus, avec une telle technique, on n'aura plus qu'a faire un transfert de la prochaine zone ( petit à petit ) pour changer de salle. ( L'exterieur n'est pas ultra plus compliqué , c'est souvent une skybox, et un terrain qui bouge pas beaucoup ).

Comme on a gagner de la bande passante, on peut envoyer les infos des joueurs ( choses assez dynamiques ) souvent, et surtout ça prend pas beaucoup de place sur une bande passante. Si on veut encore gagner, on peut interpoler.

Bien sur, le client n'aura plus qu'envoyer c'est commande ( 4 octet ? O_o ... pourquoi pas, un champs de flag, pour dire haut bas ... gauche droite ... ) ça prendra pas beaucoup.

Je pense que cela peut bien tourner.
Après, je vous conseillerai de lire le dernier EDGE ( magazine anglais ) celui de ce mois n°205 ) Ils parlent de onlive dedans ( il faut que je le lise :s )

Mais il mentionne aussi un truc appelée GAIKAI je sais pas ce que c'est mais ça semble aussi prometteur.

Pardon si tout ce que je viens de dire n'est pas structurée et que cela ne vous plaise pas :p

[Mat.M]

Du côté du client final, il se dit que:
- le client ferait des économies en matériel en n'ayant plus à renouveler son matos.
- la possibilité de jouer à un jeu immédiatement, sans la phase achat ou téléchargement + installation.
- la réduction des coûts pour l'éditeur se répercuterait sur le prix final payé par le client.

Oui mais tu ne pourras pas faire tes mods, utiliser le moteur du jeu ( comme par exemple avec Quake ou Half Life) faire tes propres persos niak niak je sais je suis ch..

Regarde je suis un drogué de Flight Simulator 2004 ce qui a fait le succès de ce simulateur c'est tous les avions et les scènes additives que tu peux télécharger gratuitement sur internet...
tu as les aéroports de presque partout dans le monde il y en a des milliers tout comme les avion : tu peux prendre les commandes d'un ULM ou bien d'un boeing 747 en passant par le mirage F1..

C'est pareil pour DOOM par exemple : combien de WAD de niveaux trouvait-on pour agrandir la durée de vie du jeu ?
si tout cela demain n'est accessible via internet exclusivement c.a.d. que te ne puisses pas "customiser" ton jeu ça risque de ne pas emballer grand
monde...

Et puis si tout est centralisé sur des serveurs, alors à quoi sert-il de programmer ? On va se retrouver au chomage technique alors

[nouknouk]

Je viens de tout lire... et je suis plutot d'accord avec le gars qui parlait d'envoyer les ordres graphiques aux clients. ( Après avoir calculé le tout sur le serveur ).

Le problème de cette approche est que ça demande que le rendu soit fait en partie côté client, et plus uniquement côté serveur.

Or, à partir du moment où tout le rendu n'est pas fait côté serveur, le terminal côté client devra suivre les évolutions technologiques en matière de 3D, même en admettant que le client ne nécessite qu'un faible pourcentage de la puissance de calcul totale (genre 10%, hypothèse totalement utopiste amha, même si je ne suis pas expert du domaine).

Même raisonnement (en pire) pour l'idée de compenser le lag avec du calcul local qui augmentera forcément la proportion de calcul qui devra être faite côté client (genre de 10% on passerait à 20%).

Or l'évolution de la pluissance de clacul en 3D n'étant pas linéaire mais exponentielle, ça veut dire que la fréquence de remplacement des terminaux suivra grosso modo la fréquence actuelle de renouvellement des cartes graphiques et autres consoles, et ce quel que soit le pourcentage de calcul fait côté client (à partir du moment où il est non nul).

On perd alors tout l'intérêt du cloud et l'idée du terminal léger, donc on perd le seul argument de vente (côté client final, j'entends) qui pourrait faire que le concept "prenne" auprès du grand public : "Avec le jeu en cloud, plus besoin d'acheter l'ordi/la CG/ la console dernier cri et de renouveler tous les 18 mois pour profiter des derniers jeux".

Comme on a gagner de la bande passante, on peut envoyer les infos des joueurs ( choses assez dynamiques ) souvent, et surtout ça prend pas beaucoup de place sur une bande passante. Si on veut encore gagner, on peut interpoler.

MAJ régulière de la position (et pas du rendu) des adversaires, interpolation, etc ... ça, c'est la définition du jeu 'non cloud' actuel

je vous conseillerai de lire le dernier EDGE ( magazine anglais ) celui de ce mois n°205 ) Ils parlent de onlive dedans ( il faut que je le lise :s )
Mais il mentionne aussi un truc appelée GAIKAI je sais pas ce que c'est mais ça semble aussi prometteur.

Aurais-tu des liens pour le consulter en ligne, ou éventuellement un lien pour commander le magazine depuis l'étranger ? Ca m'intéresse.

Oui mais tu ne pourras pas faire [...]

Je suis à 300% d'accord avec toi.

Mon post que tu cites n'était là que pour essayer de faire un inventaire des pour/contre qui se veuille aussi objectif que possible.

Reste que personnellement, je ne crois absolument pas en l'avènement du "cloud gaming" pour les raisons techniques que j'ai pu exposer avant, tout comme pour les raisons que tu mentionnes, d'où d'ailleurs mon emploi récurrent du conditionnel dans les parties que tu mentionnes ("il se dit que / ferait / répercuterait / ...")