Maxis a dû travailler pendant 6 mois pour rendre SimCity jouable hors-ligne

Maxis a dû travailler pendant 6 mois pour rendre SimCity jouable hors-ligne

La faute à Java

97

Maxis a dû travailler pendant 6 mois pour rendre SimCity jouable hors-ligne

Par Kevin Hottot

Le 15 janvier 2014 à 11h45
Société numérique
2 min

Ce n'est plus qu'une question de semaines avant que SimCity devienne entièrement jouable hors-ligne. Si à première vue il ne semble pas très compliqué de couper l'accès d'un jeu à Internet, les travaux sont bien plus importants qu'il n'y parait. C'est en tout cas ce qu'ont voulu expliquer les équipes de Maxis.

SimCity DLC Nissan

 

Six mois et demi : voilà le temps qu'ont passé les équipes de Maxis pour permettre au mode hors-ligne de SimCity de voir le jour. Cela peut paraître énorme pour simplement couper les tuyaux entre un jeu vidéo et des serveurs, mais pour que le titre fonctionne de la même manière en ligne et hors-ligne, les travaux à entreprendre sont bien plus importants qu'il n'y paraît.

 

Dans le cas de SimCity, les modules régissant les communications entre le jeu et les serveurs étaient codés en Java. Deux tâches attendaient alors les équipes du studio : modifier ces modules afin qu'ils génèrent localement l'ensemble des données requises, comme les statistiques des villes voisines d'une même région, puis les réécrire en C++ afin de faciliter leur exécution. 

 

« Toutes les simulations au niveau régional doivent désormais être faites localement. Les algorithmes qui gouvernent les échanges entre les villes ont dû être retravaillés de façon à rendre les échanges entre les villes plus réactifs. Cela a requis des optimisations majeures pour permettre à la simulation de fonctionner ainsi. Nous avons l'obligation de rendre ce jeu fonctionnel sur tout type de machines. Nous ne voulons pas que quelqu'un qui a apprécié le multijoueurs trouve le mode solo mal optimisé », explique Simon Fox, Lead Engineer du mode solo de SimCity, sur le blog officiel du jeu.

 

Tout cela aura réclamé six mois et demi de travail, et nous devrions en voir les fruits dans seulement quelques semaines si tout se passe comme prévu du côté de chez Maxis. Nous ne manquerons évidemment pas de suivre tout cela d'assez près, d'autant qu'il sera assez intéressant de savoir quel impact aura ce mode hors ligne sur les performances du jeu avec une configuration modeste. En effet, la connexion permanente ayant été notamment imposée afin de permettre le fonctionnement du titre sur des machines peu performantes, il faudra veiller à ce que personne ne se retrouve sur le carreau.

Commentaires (97)


Jean_Peuplus
Le 15/01/2014 à 11h50



Nous avons l’obligation de rendre ce jeu fonctionnel sur tout type de machines.





Marche pas sur mon Amstrad CPC 6128


Dirty Troll
Le 15/01/2014 à 11h51

Ils n’auraient pas eu besoin de faire marche arrière si ils avaient dev leur jeu en corrélation avec ce que la communauté autour de ce jeu veut.



D’ailleurs il aurait été dispo en hors ligne dés le départ, il serait à coup sur dans ma bibliothèque (enfin quoi que, Origin………….)


after_burner
Le 15/01/2014 à 11h51

Ça me semble pas étonnant. Si il y avait beaucoup d’aspect gérés par les serveurs, remanier le code pour pouvoir s’en passer demander certainement du temps.



Le problème c’est que 6mois et demi plus tard, cet effort risque d’être anecdotique dans la tête des joueurs qui ont sans doutes d’autres titres en vus. C’est dès le départ qu’il fallait y penser…


babelouest
Le 15/01/2014 à 11h52

Ce plus permettra-t-il de compenser les inconvénients de ce jeu ? Je pense bien entendu en particulier à son étendue, bridée d’office même là où des machines puissantes pourraient le gérer.



En tout cas, si la modification a été implantée correctement, elle devrait attirer ceux qui ne veulent pas du jeu en ligne - ou qui pour des raisons techniques ne peuvent pas en profiter. Les reproches avaient été sévères et multiples, au départ. <img data-src=" />


spidy
Le 15/01/2014 à 11h52

faire le jeu hors-ligne dès le départ, ça aurait été plus intelligent <img data-src=" />



Java dans un jeu <img data-src=" /> (un vrai jeu, pas comme minecraft [/troll])



PS : je suis un pro-java mais là faut pas déconner non plus)


n1cow
Le 15/01/2014 à 11h52

Je me demande si ça a pris autant de temps au mecs qui ont fait le crack du jeu :)


dump
Le 15/01/2014 à 11h55

Conernant le cas des machines peu performante c’est bien entendu une fausse excuse de leurs part.

Chez Maxis a force de développer pour l’univer des consoles, ils ont oublié que sur PC les fans d’un titre attendent que les jeux qu’ils désirent jouer les pousses a investir dans du nouveau matos “ principe d’évolution oblige ” et ca n’est pas pour rien qu’un PC reste évolutif.


TheKillerOfComputer Abonné
Le 15/01/2014 à 12h04

Mais pourquoi exploiter le langage Java pour la programmation même partielle d’un GROS titre, quelle idée franchement… Le Python, le LUA, encore je peux comprendre, mais le Java ?



Et pourquoi ne pas avoir prévu du début un mode offline ? Encore que sur ce point, Maxis a la circonstance atténuante d’être chez Electronic Arts, et on sait que EA jubile en pourrisant la vie de joueurs par la fermeture des serveurs, donc si un jeu peut se jouer offline, ils ne pourront plus…


Starbetrayer
Le 15/01/2014 à 12h04

Rappelons que quand la communaute demandait un mode hors-ligne, il leur avait ete repondu que cela etait impossible a faire !!!



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />


Donc ils commencent à optimiser le jeu, c’est une bonne nouvelle.



Peut-être qu’une fois optimisé, les villes pourront être agrandies…


John Shaft
Le 15/01/2014 à 12h05







babelouest a écrit :



Je pense bien entendu en particulier à son étendue, bridée d’office même là où des machines puissantes pourraient le gérer.







Cela a été dit plusieurs fois par Maxis/EA est la réponse est : non, no, niet, nein, iie <img data-src=" />



malrepast
Le 15/01/2014 à 12h05



Maxis a dû travailler pendant 6 mois pour rendre SimCity jouable hors-ligne





Une telle déclaration ne serait pas aussi risible et insultante si une version tipiak parfaitement fonctionnelle et offline n’existait pas depuis plusieurs mois maintenant… <img data-src=" />


Clapitti
Le 15/01/2014 à 12h07

à quand PCi hors ligne hein? je vous l’demande.



Se connecter à internet pour consulter un site et poster des commentaires, et comment on fait dans le train ? hein ? <img data-src=" /> <img data-src=" />


Seyhan
Le 15/01/2014 à 12h08

Je l’avais bêta testé, ça m’avait plu.

Ils ont demandé une connexion permanente, j’ai pas acheté.

Ils reviennent sur leur décision, peut être que moi aussi (mais origin <img data-src=" /> )


gogo77
Le 15/01/2014 à 12h09







spidy a écrit :



faire le jeu hors-ligne dès le départ, ça aurait été plus intelligent <img data-src=" />



Java dans un jeu <img data-src=" /> (un vrai jeu, pas comme minecraft [/troll])



PS : je suis un pro-java mais là faut pas déconner non plus)







On parle de code côté serveur. Le Java est extrêmement courant pour créer des services hautement sollicités. Ça n’a rien à voir avec un client codé en Java.



Edit : En tout cas j’espère que ce mode offline va permettre aux moders de s’éclater sur ce titre (même si officiellement EA ne veut permettre que peut de choses moi j’attends de voir ce qui existera dans les faits)



Pyroa
Le 15/01/2014 à 12h09







John Shaft a écrit :



Cela a été dit plusieurs fois par Maxis/EA est la réponse est : non, no, niet, nein, iie <img data-src=" />







Ouais comme le mode hors-ligne !



Aller attendons 6 mois et je parie qu’ils vont y venir



knos
Le 15/01/2014 à 12h14







malrepast a écrit :



Une telle déclaration ne serait pas aussi risible et insultante si une version tipiak parfaitement fonctionnelle et offline n’existait pas depuis plusieurs mois maintenant… <img data-src=" />







En même temps ils ont dis 6 mois. Mais pas à combien ni combien d’heure semaine. C’est peu être un gus pendant ses pause café <img data-src=" />



Naneday
Le 15/01/2014 à 12h14

Mode Hors Ligne ( Une connexion internet est requise pour ce mode)

<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />


spidy
Le 15/01/2014 à 12h21







gogo77 a écrit :



On parle de code côté serveur. Le Java est extrêmement courant pour créer des services hautement sollicités. Ça n’a rien à voir avec un client codé en Java.



Edit : En tout cas j’espère que ce mode offline va permettre aux moders de s’éclater sur ce titre (même si officiellement EA ne veut permettre que peut de choses moi j’attends de voir ce qui existera dans les faits)





Justement, là une partie du code (comms avec les serveurs) est en Java et ils doivent réécrire en C++ pour des questions de perfs (calculs en local et non juste gérer des requêtes/réponses).



dans ta logique le code coté serveur - qui ne devrait plus faire grand chose - doit être réécrit en C++ pour être plus performant. <img data-src=" />



pour le code coté serveur, je ne connais pas le % d’applis professionnelles écrient en Java mais ça doit être minimum 40-50%.



malrepast
Le 15/01/2014 à 12h27







knos a écrit :



En même temps ils ont dis 6 mois. Mais pas à combien ni combien d’heure semaine. C’est peu être un gus pendant ses pause café <img data-src=" />







<img data-src=" />









spidy a écrit :



Justement, là une partie du code (comms avec les serveurs) est en Java et ils doivent réécrire en C++ pour des questions de perfs (calculs en local et non juste gérer des requêtes/réponses).



dans ta logique le code coté serveur - qui ne devrait plus faire grand chose - doit être réécrit en C++ pour être plus performant. <img data-src=" />



pour le code coté serveur, je ne connais pas le % d’applis professionnelles écrient en Java mais ça doit être minimum 40-50%.





En même temps ils n’allaient pas faire un copier/coller du code java dans un jeu probablement écrit à 90% en C++, ça aurait en plus nécessité l’installation de java sur la machine.



stardrawer
Le 15/01/2014 à 12h29

Est-ce qu’un jour ce jeu sera bon ?


fitfat
Le 15/01/2014 à 12h31

Est-ce que ça signifie qu’il sera possible de créer un serveur Sim City perso ?


HarmattanBlow
Le 15/01/2014 à 12h32







spidy a écrit :



Justement, là une partie du code (comms avec les serveurs) est en Java et ils doivent réécrire en C++ pour des questions de perfs (calculs en local et non juste gérer des requêtes/réponses).





Effectivement le nouveau code doit en plus simuler des joueurs virtuels mais surtout il vient s’ajouter à au jeu lui-même qui met déjà à genoux certains PC.



Clapitti
Le 15/01/2014 à 12h34







spidy a écrit :



Justement, là une partie du code (comms avec les serveurs) est en Java et ils doivent réécrire en C++ pour des questions de perfs (calculs en local et non juste gérer des requêtes/réponses).



dans ta logique le code coté serveur - qui ne devrait plus faire grand chose - doit être réécrit en C++ pour être plus performant. <img data-src=" />



pour le code coté serveur, je ne connais pas le % d’applis professionnelles écrient en Java mais ça doit être minimum 40-50%.







Et donc en quoi c’est <img data-src=" /> qu’ils utilisent java pour la partie serveur ?



XMalek
Le 15/01/2014 à 12h36

Comms avec les serveurs en java et ça s’étonne d’avoir des ENORMES problèmes de perf lors des releases ?

Sérieusement ils embauchent quoi comme codeurs dans le jeu vidéo de nos jours ? (j’ai quitté ce domaine parce que ç a payait au lance pierre mais coder des points aussi critiques en java ? Alors comment dire…)


mightmagic
Le 15/01/2014 à 12h37

Peut être que la prochaine fois avant de coder n’importe quoi juste pour mettre un DRM parce que les joueurs sont des pirates, ils penseront avant tout au jue.

Leur moteur de simu est assez raté et le jeu est plombé par pleins de tares.

Ce n’est pas sim city societies mais ça n’en reste pas moins un jeu raté.



“En effet, la connexion permanente ayant été notamment imposée afin de permettre le fonctionnement du titre sur des machines peu performantes, il faudra veiller à ce que personne ne se retrouve sur le carreau.”

La mythomanie aura toujours droit à la lumière chez EA.



Comment justifier un DRM contraignant pour lutter contre le piratage en disant que c’est pour les petites configs.








zogG a écrit :



Et donc en quoi c’est <img data-src=" /> qu’ils utilisent java pour la partie serveur ?





Parce qu’ils savaient très bien que le communauté demanderai un mode hors-ligne. Ils auraient donc du prendre la techno adaptée dès le début.



NEVdD
Le 15/01/2014 à 12h39

6 mois sans préciser les effectifs on peut supposer que ça revient à 100 hommes jours, en fait une broutille pour un projet.


Shyruko
Le 15/01/2014 à 12h46

Tant qu’on pourra pas exploiter pleinement la carte en mode solo (je peux comprendre qu’en muilti l’interaction est “utile”) ce jeux restera n’aura que peu d’attrait pour pas mal d’acheteurs déçus


Nithril
Le 15/01/2014 à 12h52







TheKillerOfComputer a écrit :



Mais pourquoi exploiter le langage Java pour la programmation même partielle d’un GROS titre, quelle idée franchement… Le Python, le LUA, encore je peux comprendre, mais le Java ?



Et pourquoi ne pas avoir prévu du début un mode offline ? Encore que sur ce point, Maxis a la circonstance atténuante d’être chez Electronic Arts, et on sait que EA jubile en pourrisant la vie de joueurs par la fermeture des serveurs, donc si un jeu peut se jouer offline, ils ne pourront plus…







Car Java fait du sens coté serveur.



Nithril
Le 15/01/2014 à 12h53







ActionFighter a écrit :



Parce qu’ils savaient très bien que le communauté demanderai un mode hors-ligne. Ils auraient donc du prendre la techno adaptée dès le début.







Visiblement non ils ne savaient pas très bien. A moins que tu sois dans leurs secrets? <img data-src=" />



spidy
Le 15/01/2014 à 12h57







zogG a écrit :



Et donc en quoi c’est <img data-src=" /> qu’ils utilisent java pour la partie serveur ?





j’ai jamais dit ça justement, java coté serveur ça me choque pas du tout.



Jos Abonné
Le 15/01/2014 à 12h57







ActionFighter a écrit :



Parce qu’ils savaient très bien que le communauté demanderai un mode hors-ligne. Ils auraient donc du prendre la techno adaptée dès le début.





Il n’y avait pas que le java qui posait problème. Le jeu n’a pas été pensé du tout pour du hors-ligne et ils s’imaginaient que ça resterait comme ça.

Sinon c’est évident qu’ils auraient faire des choix techniques différents, et pas seulement pour le langage de programmation



Nithril
Le 15/01/2014 à 12h57







XMalek a écrit :



Comms avec les serveurs en java et ça s’étonne d’avoir des ENORMES problèmes de perf lors des releases ?

Sérieusement ils embauchent quoi comme codeurs dans le jeu vidéo de nos jours ? (j’ai quitté ce domaine parce que ç a payait au lance pierre mais coder des points aussi critiques en java ? Alors comment dire…)







la JVM est lente c’est connu. Elle va d’ailleurs bientôt disparaitre <img data-src=" />



djbudge2
Le 15/01/2014 à 13h00

S’ils ont codé des modules en Java, ça veut dire que Sim City nécessitait une JVM, non? JVM qui était sans doute installée par le jeu.

Combien de PCs de joueurs ont une JVM pas à jour maintenant? Y a même peut-être des PCs de joueur avec Java Web Start autorisé dans les navigateurs. Hérétique!! Fournisseurs de failles!!


Lyron
Le 15/01/2014 à 13h03

Je trouve les commentaires un peu rageux… “Ils avaient qu’à le faire au début !”. Je trouve qu’ils font quand même preuve de rétrospection et sont au final pas mal à l’écoute du joueur (en même temps vu comment ils s’en sont pris plein la tronche). Qu’ils aient perdu du fric à cause de cette erreur, ça regarde qu’eux.

Question technologie, le java était justifié pour le code serveur. C’est évidemment plus le cas pour le mode hors ligne. Ils auraient pu faire du quick and dirty en mettant un serveur local java embarqué dans le jeu.


Nithril
Le 15/01/2014 à 13h04







djbudge2 a écrit :



S’ils ont codé des modules en Java, ça veut dire que Sim City nécessitait une JVM, non? JVM qui était sans doute installée par le jeu.

Combien de PCs de joueurs ont une JVM pas à jour maintenant? Y a même peut-être des PCs de joueur avec Java Web Start autorisé dans les navigateurs. Hérétique!! Fournisseurs de failles!!







Il y a plein de façon d’intégrer une JVM sans nécessiter d’installation d’un JavaSE.



D’ailleurs encore faut il que le client utilise effectivement du Java



gogo77
Le 15/01/2014 à 13h06







spidy a écrit :



Justement, là une partie du code (comms avec les serveurs) est en Java et ils doivent réécrire en C++ pour des questions de perfs (calculs en local et non juste gérer des requêtes/réponses).



dans ta logique le code coté serveur - qui ne devrait plus faire grand chose - doit être réécrit en C++ pour être plus performant. <img data-src=" />



pour le code coté serveur, je ne connais pas le % d’applis professionnelles écrient en Java mais ça doit être minimum 40-50%.









Après avoir relu l’article, j’avais effectivement mal compris. Pour moi c’était en Java uniquement côté serveur et leur travail a été de réécrire ce qui se faisait sur les serveurs localement en C++ pour reproduire le comportement du jeu sans nécessiter une connexion internet. Le Java dans les jeux vidéos est tellement peut courant et pas franchement adapté que ça ne m’était même pas venu à l’idée qu’il puisse y avoir une partie cliente utilisant ce langage ^^



Bref, j’espère juste qu’ils vont faire quelque chose qui tourne correctement et que ça apportera son lot de libertés côté customisation du jeu.



spidy
Le 15/01/2014 à 13h10







Nithril a écrit :



la JVM est lente c’est connu. Elle va d’ailleurs bientôt disparaitre <img data-src=" />





ouais franchement je comprends pas pourquoi oracle garde ça <img data-src=" />







djbudge2 a écrit :



S’ils ont codé des modules en Java, ça veut dire que Sim City nécessitait une JVM, non? JVM qui était sans doute installée par le jeu.

Combien de PCs de joueurs ont une JVM pas à jour maintenant? Y a même peut-être des PCs de joueur avec Java Web Start autorisé dans les navigateurs. Hérétique!! Fournisseurs de failles!!





en parlant de ça, tous les jeux vidéo installent automatiquement VC++ redistribultable ou VC# redistrubutable donc ça ou un jre, c’est pareil pour moi quand je vois que j’ai trouzemilles versions différentes dans ajouter/supprimer.



TZDZ
Le 15/01/2014 à 13h14







Lyron a écrit :



Je trouve les commentaires un peu rageux… “Ils avaient qu’à le faire au début !”. Je trouve qu’ils font quand même preuve de rétrospection et sont au final pas mal à l’écoute du joueur (en même temps vu comment ils s’en sont pris plein la tronche).





Personnellement, ce qui me gène (je n’ai bien sûr pas acheté le jeu dès que j’ai vu les premiers commentaires à son propos + origin) c’est la communication sans aucun respect pour les joueurs.



Si on reprend les déclarations les unes après les autres ça oscille entre mensonges et incompétence. Pour moi ça suffit largement pour boycotter un éditeur. En plus on a le choix, niveau vidéo ludique en ce moment…



spamator
Le 15/01/2014 à 13h14

Ca leur fait les pieds.

Ce jeu attire toujours les foules ?


von-block
Le 15/01/2014 à 13h15

Tout est maintenant en place pour la fermeture définitive des serveurs et l’abandon du jeu.


Toorist
Le 15/01/2014 à 13h17







XMalek a écrit :



Comms avec les serveurs en java et ça s’étonne d’avoir des ENORMES problèmes de perf lors des releases ?

Sérieusement ils embauchent quoi comme codeurs dans le jeu vidéo de nos jours ? (j’ai quitté ce domaine parce que ç a payait au lance pierre mais coder des points aussi critiques en java ? Alors comment dire…)





En fait je vois pas le problème :/

Java c’est pas performant et ca consomme quand on est en “local”, là c’était (dixit Kevin) juste pour la communication avec les serveur. Ce que Java fait plutôt bien et sans dégradation des perf.









ActionFighter a écrit :



Parce qu’ils savaient très bien que le communauté demanderai un mode hors-ligne. Ils auraient donc du prendre la techno adaptée dès le début.







La on est d’accord, même si le choix de Java était pas une connerie en soi, leur analyse en aval était mauvaise et ils n’ont pas envisagé de pouvoir passer en offline alors qu’ils savaient pertinemment qu’ils étaient à contre courant des attentes de la communauté.



Clapitti
Le 15/01/2014 à 13h17







spidy a écrit :



j’ai jamais dit ça justement, java coté serveur ça me choque pas du tout.







du coup je piges pas trop ça :







spidy a écrit :



Java dans un jeu <img data-src=" /> (un vrai jeu, pas comme minecraft [/troll])



PS : je suis un pro-java mais là faut pas déconner non plus)








damaki Abonné
Le 15/01/2014 à 13h19

6 mois de travail à une personne. En fait 6 mois de QA, vu la qualité désastreuse des premières releases de SimCity.

Au sujet de la taille des villes, ça reste comique que les villes soient plus grande dans SimCity 4 et que les régions existent déjà. Et c’est pas tout à fait pareil, mais on peut s’échanger les régions par mail, pour faire un mode multi asynchrone ;)


Lyron
Le 15/01/2014 à 13h20







TZDZ a écrit :



Personnellement, ce qui me gène (je n’ai bien sûr pas acheté le jeu dès que j’ai vu les premiers commentaires à son propos + origin) c’est la communication sans aucun respect pour les joueurs.



Si on reprend les déclarations les unes après les autres ça oscille entre mensonges et incompétence. Pour moi ça suffit largement pour boycotter un éditeur. En plus on a le choix, niveau vidéo ludique en ce moment…







Oui c’est sûr que pour un jeu moins populaire ça fait aucun doute. Mais Sim City c’est quand même culte… Donc personnellement étant un grand fan depuis le tout premier opus j’ai fini par l’acheter, mais seulement le mois dernier ! Ca m’a clairement freiné tout ce raffut en effet. Mais je trouve que le jeu reste bon. S’il évolue dans le bon sens, alors le reste menfou !



thibsert
Le 15/01/2014 à 13h21

Une solution rapide et facile, aurait été de faire tourner le serveur en local sur la même machine que le client. Ils auraient sans doute pu pondre ça en une semaine, au prix de perfs dégueulasses et de quelques Go d’espace disque en plus.



Je trouve ça plutôt positif qu’ils aient pris le temps de trouver une solution convenable, plutôt que de coller une rustine qui serait resté là ad vitam eternam.


Nithril
Le 15/01/2014 à 13h24







Toorist a écrit :



En fait je vois pas le problème :/

Java c’est pas performant et ca consomme quand on est en “local”, là c’était (dixit Kevin) juste pour la communication avec les serveur. Ce que Java fait plutôt bien et sans dégradation des perf.



La on est d’accord, même si le choix de Java était pas une connerie en soi, leur analyse en aval était mauvaise et ils n’ont pas envisagé de pouvoir passer en offline alors qu’ils savaient pertinemment qu’ils étaient à contre courant des attentes de la communauté.







Java pas performant c’est une légende urbaine. <img data-src=" />



Starbetrayer
Le 15/01/2014 à 13h25







von-block a écrit :



Tout est maintenant en place pour la fermeture définitive des serveurs et l’abandon du jeu.







+1, il faut reduire les couts









Nithril a écrit :



Visiblement non ils ne savaient pas très bien. A moins que tu sois dans leurs secrets? <img data-src=" />





Je sais bien que les devs sont de gros autistes asociaux, mais de là à ne pas avoir lu quelque part le retour de la communauté après l’annonce d’un jeu online only <img data-src=" />







Jos a écrit :



Il n’y avait pas que le java qui posait problème. Le jeu n’a pas été pensé du tout pour du hors-ligne et ils s’imaginaient que ça resterait comme ça.

Sinon c’est évident qu’ils auraient faire des choix techniques différents, et pas seulement pour le langage de programmation











Toorist a écrit :



En fait je vois pas le problème :/

Java c’est pas performant et ca consomme quand on est en “local”, là c’était (dixit Kevin) juste pour la communication avec les serveur. Ce que Java fait plutôt bien et sans dégradation des perf.



La on est d’accord, même si le choix de Java était pas une connerie en soi, leur analyse en aval était mauvaise et ils n’ont pas envisagé de pouvoir passer en offline alors qu’ils savaient pertinemment qu’ils étaient à contre courant des attentes de la communauté.





<img data-src=" />



On est d’accord, le problème n’est pas Java, c’est la volonté de verrouiller le mode hors-ligne dès le développement, dans le choix des technos.



Et là, ils retournent leur veste, parce que s’ils peuvent gratter les quelques péons qui jouent en tipiak, ce sera toujours ça de pris.



damaki Abonné
Le 15/01/2014 à 13h35







Starbetrayer a écrit :



+1, il faut reduire les couts





Réduire les coûts, ça veut dire arnaquer les joueurs en langage EA.



XMalek
Le 15/01/2014 à 13h36







Toorist a écrit :



En fait je vois pas le problème :/

Java c’est pas performant et ca consomme quand on est en “local”, là c’était (dixit Kevin) juste pour la communication avec les serveur. Ce que Java fait plutôt bien et sans dégradation des perf.







Juste Deux truc :

garbage collector et optimisations bas niveaux du compilateur.

de plus tant que la mémoire est géré de manière automatisée (même si tu peux désactiver le bousin en partie) cela coute cher et cela coute TRES cher (des millions voir des millards de cycle par secondes sur des programmes en charge max cpu).







Nithril a écrit :



Java pas performant c’est une légende urbaine. <img data-src=" />







Cela dépend ce que tu fais mais pour des applications critiques (ie c’est le cas ici c’est un programme qui gère des millions de personnes connectés en même temps) java est moins performant. Par contre java est clairement moins gourmand en temps jour/homme pour obtenir le même résultat.



spidy
Le 15/01/2014 à 13h44







zogG a écrit :



du coup je piges pas trop ça :









spidy a écrit :



faire le jeu hors-ligne dès le départ, ça aurait été plus intelligent <img data-src=" />



Java dans un jeu <img data-src=" /> (un vrai jeu, pas comme minecraft [/troll])



PS : je suis un pro-java mais là faut pas déconner non plus)





si tu veux : Java, dans un jeu exécuté en local.



Nithril
Le 15/01/2014 à 13h45







XMalek a écrit :



Juste Deux truc :

garbage collector et optimisations bas niveaux du compilateur.

de plus tant que la mémoire est géré de manière automatisée (même si tu peux désactiver le bousin en partie) cela coute cher et cela coute TRES cher (des millions voir des millards de cycle par secondes sur des programmes en charge max cpu).



Cela dépend ce que tu fais mais pour des applications critiques (ie c’est le cas ici c’est un programme qui gère des millions de personnes connectés en même temps) java est moins performant. Par contre java est clairement moins gourmand en temps jour/homme pour obtenir le même résultat.







Je plussois



Choub
Le 15/01/2014 à 13h46







XMalek a écrit :



Comms avec les serveurs en java et ça s’étonne d’avoir des ENORMES problèmes de perf lors des releases ?

Sérieusement ils embauchent quoi comme codeurs dans le jeu vidéo de nos jours ? (j’ai quitté ce domaine parce que ç a payait au lance pierre mais coder des points aussi critiques en java ? Alors comment dire…)





A mon avis tu connais que dalle au dev backend.



Java est probablement le système qui se scale le mieux, avec gestion du clustering dans les serveurs d’application, de la mémoire, des resources, etc..



Bref, Java côté serveur est loin d’être un mauvais choix, surtout quand ce côté serveur doit être vérifié, validé et testé automatiquement.

Et leurs soucis au lancement n’a rien à voir avec Java, mais avec leur infrastructure qui ne pouvait pas gérer cet afflux.

Preuve en est que d’autres boites se plantent aussi le jour des releases de jeux online, alors que leur backend n’est pas en java.



Bref, Java côté serveur c’est cool, côté client c’est pourri. Prendre java pour du client-side, c’est comme prendre du flash pour faire un serveur, c’est stupide, hormis d’éventuels pré-requis de compatibilité.



speedy-px
Le 15/01/2014 à 13h47

je suis le seul a avoir pensé qu’ils seraient capable de sortir le mode hors ligne en DLC payant ? <img data-src=" />


spidy
Le 15/01/2014 à 13h50







XMalek a écrit :



Cela dépend ce que tu fais mais pour des applications critiques (ie c’est le cas ici c’est un programme qui gère des millions de personnes connectés en même temps) java est moins performant. Par contre java est clairement moins gourmand en temps jour/homme pour obtenir le même résultat.





pour du calcul scientifique je veux bien mais pour des applis pros du genre site marchand ou appli backend, non. c’est pour ça que la demande en développeurs Java/JEE est si importante.



raoudoudou
Le 15/01/2014 à 13h50







von-block a écrit :



Tout est maintenant en place pour la fermeture définitive des serveurs et l’abandon du jeu.







Très bien, ça laissera un peu de champ libre à un studio talentueux, on peut rêver <img data-src=" />



Starbetrayer
Le 15/01/2014 à 13h52







speedy-px a écrit :



je suis le seul a avoir pensé qu’ils seraient capable de sortir le mode hors ligne en DLC payant ? <img data-src=" />







Ne donnes pas des idees a EA <img data-src=" />



spidy
Le 15/01/2014 à 13h53







Choub a écrit :



A mon avis tu connais que dalle au dev backend.



Java est probablement le système qui se scale le mieux, avec gestion du clustering dans les serveurs d’application, de la mémoire, des resources, etc..



Bref, Java côté serveur est loin d’être un mauvais choix, surtout quand ce côté serveur doit être vérifié, validé et testé automatiquement.

Et leurs soucis au lancement n’a rien à voir avec Java, mais avec leur infrastructure qui ne pouvait pas gérer cet afflux.

Preuve en est que d’autres boites se plantent aussi le jour des releases de jeux online, alors que leur backend n’est pas en java.



Bref, Java côté serveur c’est cool, côté client c’est pourri. Prendre java pour du client-side, c’est comme prendre du flash pour faire un serveur, c’est stupide, hormis d’éventuels pré-requis de compatibilité.





enfin ! <img data-src=" />



Enyths
Le 15/01/2014 à 13h55







XMalek a écrit :



Cela dépend ce que tu fais mais pour des applications critiques (ie c’est le cas ici c’est un programme qui gère des millions de personnes connectés en même temps) java est moins performant. Par contre java est clairement moins gourmand en temps jour/homme pour obtenir le même résultat.





Pour ça, dans l’absolu, tu prends un Mainframe avec du Cobol (et du Java sur les récents). Pour les applications critiques le plus important c’est la disponibilité et la fiabilité vient après les performances.



Choub a écrit :



A mon avis tu connais que dalle au dev backend.



Java est probablement le système qui se scale le mieux, avec gestion du clustering dans les serveurs d’application, de la mémoire, des resources, etc..



Bref, Java côté serveur est loin d’être un mauvais choix, surtout quand ce côté serveur doit être vérifié, validé et testé automatiquement.

Et leurs soucis au lancement n’a rien à voir avec Java, mais avec leur infrastructure qui ne pouvait pas gérer cet afflux.

Preuve en est que d’autres boites se plantent aussi le jour des releases de jeux online, alors que leur backend n’est pas en java.



Bref, Java côté serveur c’est cool, côté client c’est pourri. Prendre java pour du client-side, c’est comme prendre du flash pour faire un serveur, c’est stupide, hormis d’éventuels pré-requis de compatibilité.





+1



Mention très spéciale au magnifique Lotus Notes <img data-src=" />.



HarmattanBlow
Le 15/01/2014 à 14h03







XMalek a écrit :



de plus tant que la mémoire est géré de manière automatisée (même si tu peux désactiver le bousin en partie) cela coute cher et cela coute TRES cher (des millions voir des millards de cycle par secondes sur des programmes en charge max cpu).





Bof, pas vraiment.



* D’abord les solutions type smart pointer sont elles aussi voraces du fait des barrières mémoires autour du compteur de références. Au-dessous d’un certain niveau de parallélisme elles coûtent même plus cher par objet qu’un GC “freeze the world” pour lequel aucune synchronisation nécessaire (le seul boulet vient de la mémoire avec le parcours du graphe mais ça reste typiquement avantageux).



* Ensuite le coût du GC doit être mis en rapport avec le coût de l’allocation/désallocation, lui aussi significatif et souvent supérieur (il faut à nouveau une barrière mémoire, une structure de données imposant plusieurs indirections, etc).



* Le pb du GC en soi n’est pas la conso CPU, c’est celui de l’interactivité, vu que les GC mettent souvent le monde en pause pendant qu’ils nettoient.



* Quant à l’usage CPU c’est avant tout le fait des compilateurs JIT pourris à comparer aux compilos C++ qui suppriment des allocations à la pelle et optimisent tout comme des chefs. Si tu veux de l’optimisation en java, et ben faut bousiller ton code et la faire à la main !









Choub a écrit :



Bref, Java côté serveur c’est cool, côté client c’est pourri.





Je suis d’accord mais toi qui connais Java, pourquoi est-ce si pourri côté client ? Dotnet n’a pas ce pb, on a des applis cool et rapides. Je n’ai jamais trouvé de réponse.



Nithril
Le 15/01/2014 à 14h09







Choub a écrit :



A mon avis tu connais que dalle au dev backend.



Java est probablement le système qui se scale le mieux, avec gestion du clustering dans les serveurs d’application, de la mémoire, des resources, etc..



Bref, Java côté serveur est loin d’être un mauvais choix, surtout quand ce côté serveur doit être vérifié, validé et testé automatiquement.

Et leurs soucis au lancement n’a rien à voir avec Java, mais avec leur infrastructure qui ne pouvait pas gérer cet afflux.

Preuve en est que d’autres boites se plantent aussi le jour des releases de jeux online, alors que leur backend n’est pas en java.



Bref, Java côté serveur c’est cool, côté client c’est pourri. Prendre java pour du client-side, c’est comme prendre du flash pour faire un serveur, c’est stupide, hormis d’éventuels pré-requis de compatibilité.







En soit ce n’est pas Java qui scale, mais tous l’écosystème conçu avec qui permet de faire des applis qui scaleront plus facilement.



Java coté client n’a rien d’une aberration, je prend pour exemple mon éditeur préféré ;)




XMalek
Le 15/01/2014 à 14h12







Choub a écrit :



A mon avis tu connais que dalle au dev backend.



Java est probablement le système qui se scale le mieux, avec gestion du clustering dans les serveurs d’application, de la mémoire, des resources, etc..







TU seras toujours moins performant en gestion mémoire optimisée que du c++, après oui tu consommeras peut être moins (théoriquement tu consommes toujours 100% de ta mémoire pour un serveur dédié et chaque bloc est déjà prédestiné, ce n’est que comme cela que tu obtiens les meilleures performances. Ta variance mémoire doit être de moins de 10% si tu veux avoir des performanances stables client ET serveur, je sais ça va faire faire des bonds aux codeurs “industriels” mais dans le jeu vidéo chaque cycle compte)







Choub a écrit :



Bref, Java côté serveur est loin d’être un mauvais choix, surtout quand ce côté serveur doit être vérifié, validé et testé automatiquement.

Et leurs soucis au lancement n’a rien à voir avec Java, mais avec leur infrastructure qui ne pouvait pas gérer cet afflux.

Preuve en est que d’autres boites se plantent aussi le jour des releases de jeux online, alors que leur backend n’est pas en java.







Tes tests tu les fais jamais en live si tu veux des performances, merci. Et leur problème c’est justement ce composant là (les statistiques) qui posait problème et qui a du être désactivé jusqu’au deuxième patch (ou troisième).







Choub a écrit :



Bref, Java côté serveur c’est cool, côté client c’est pourri. Prendre java pour du client-side, c’est comme prendre du flash pour faire un serveur, c’est stupide, hormis d’éventuels pré-requis de compatibilité.







Jamais vu une architecture correcte coté serveur en java donc peut être mais dans le JV c’est la première fois qu’on me dis qu’un composant critique est en java.



En général la répartition de performance et le montoring validation, c’est ton système de virtualisation et de répartition de charges dynamiques qui le fait . Il est “COMPLETEMENT” indépendant niveau code de tes serveurs de jeu (et il en existe de très très bon actuellement).



De plus les déboires des serveurs de simcity ont duré quoi ? un mois ? Pour seulement 1.1 millions de copies vendues ? Regarde blizzard et l’infame erreur 37 de diablo 3 (3,5M en 24H). Ca a duré deux semaines, Steam à noel ? deux jours, Nintendo ? une semaine, etc…



mkton
Le 15/01/2014 à 14h14







XMalek a écrit :



Cela dépend ce que tu fais mais pour des applications critiques (ie c’est le cas ici c’est un programme qui gère des millions de personnes connectés en même temps) java est moins performant.





Moins performant que quoi ?



Un “petit” service qui tourne sur la JVM pour gérer quelques utilisateurs :

https://blog.twitter.com/2011/twitter-search-now-3x-faster



TheKillerOfComputer Abonné
Le 15/01/2014 à 14h23







Lyron a écrit :



Je trouve les commentaires un peu rageux… “Ils avaient qu’à le faire au début !”. Je trouve qu’ils font quand même preuve de rétrospection et sont au final pas mal à l’écoute du joueur (en même temps vu comment ils s’en sont pris plein la tronche). Qu’ils aient perdu du fric à cause de cette erreur, ça regarde qu’eux.







Si c’était une société qui n’avait pas lancé le concept de Simcity, ça aurait été pardonnable car elle n’aurait peut-être pas eu l’expérience pour se poser la question. Mais on parle du créateur de la série même, et qui donc doit bien se DOUTER juste une minute qu’un tel jeu ça a toujours été, c’est, et ce sera toujours du hors-ligne. Le mode online se devait d’être accessoire pour apporter un peu de valeur ajouté s’il y avait moyen de le faire.



Soit EA a forcé Maxis, soit Maxis a fait montre d’amateurisme total en allant dans « l’ère du temps » donc les jeux connectés en permanence alors que Simcity n’avait pas besoin de ça. Surtout qu’en ce moment, ce concept est de plus en plus critiqué.



Maxis et EA n’ont donc que ce qu’ils méritent.



XMalek
Le 15/01/2014 à 14h24

doublon


XMalek
Le 15/01/2014 à 14h24







mkton a écrit :



Moins performant que quoi ?



Un “petit” service qui tourne sur la JVM pour gérer quelques utilisateurs :

https://blog.twitter.com/2011/twitter-search-now-3x-faster







Que du pur c++ optimisé rien que pour ton apllication à toi. Et bon les serveurs twitter c’est pas les serveurs maxis <img data-src=" /> et bon 225ms de latence ? Mon dieu je pense qu’un joueur tue quelqu’un avec une latence pareille…



youtpout978
Le 15/01/2014 à 14h29

Je ne vois pas en quoi l’utilisation de JAVA sur les serveurs est préjudiciable même pour des jeux vidéos, développez un WebService en Java est assez simple et rapide à mettre en place le gain par rapport au C++ en cout doit être assez monstrueux, assez pour s’acheter de nouveaux serveur plutôt que payer d’autre développeur ou travailler plus longtemps sur des optimisations.

Beaucoup de boite font le choix d’investir dans un serveur plutôt que dans un développeur, ça leur revient surement moins chère.


mkton
Le 15/01/2014 à 14h30







XMalek a écrit :



Que du pur c++ optimisé rien que pour ton apllication à toi. Et bon les serveurs twitter c’est pas les serveurs maxis <img data-src=" /> et bon 225ms de latence ? Mon dieu je pense qu’un joueur tue quelqu’un avec une latence pareille…







:) ouais enfin, sans savoir précisément ce qu’ils font tourner server-side et qu’ils ont du migrer, personne ne peut vraiment juger.

+1 pour les perfs de C++ en temps réel, mais Java server side pour de très grosses applications, c’est une des solutions les plus populaires et les plus outillées.



Khalev
Le 15/01/2014 à 14h38







XMalek a écrit :



Que du pur c++ optimisé rien que pour ton apllication à toi. Et bon les serveurs twitter c’est pas les serveurs maxis <img data-src=" /> et bon 225ms de latence ? Mon dieu je pense qu’un joueur tue quelqu’un avec une latence pareille…





On parle de simcity là. 225ms de latence ça serait totalement gérable.

On est pas sur CS, SC2, Lol ou autre où 1/10° de seconde peut faire la différence entre un viol et une victoire. (Ahh le bon vieux lag sur sc2 quand tu essaies de gérer les banelings qui poursuivent tes marines/zerglings et tu te retrouves avec une jolie tache vert fluo au milieu de l’écran…)



XMalek
Le 15/01/2014 à 14h42







mkton a écrit :



:) ouais enfin, sans savoir précisément ce qu’ils font tourner server-side et qu’ils ont du migrer, personne ne peut vraiment juger.

+1 pour les perfs de C++ en temps réel, mais Java server side pour de très grosses applications, c’est une des solutions les plus populaires et les plus outillées.







Oui et c’est normal, cela te coute bien moins en temps jour/homme en java qu’en c++ et la gestion des ressources (CPU/mémoire) est bien plus simple ainsi. Toujours est il que si tu recherches le 0.2% de performance manquant à tes serveurs (ce qui est le cas du jeu vidéo) java ne parait pas d’emblée une bonne solution.



fraoch
Le 15/01/2014 à 14h50







TheKillerOfComputer a écrit :



Si c’était une société qui n’avait pas lancé le concept de Simcity, ça aurait été pardonnable car elle n’aurait peut-être pas eu l’expérience pour se poser la question. Mais on parle du créateur de la série même, et qui donc doit bien se DOUTER juste une minute qu’un tel jeu ça a toujours été, c’est, et ce sera toujours du hors-ligne. Le mode online se devait d’être accessoire pour apporter un peu de valeur ajouté s’il y avait moyen de le faire.



Soit EA a forcé Maxis, soit Maxis a fait montre d’amateurisme total en allant dans « l’ère du temps » donc les jeux connectés en permanence alors que Simcity n’avait pas besoin de ça. Surtout qu’en ce moment, ce concept est de plus en plus critiqué.



Maxis et EA n’ont donc que ce qu’ils méritent.



bah moi justement, c’est bien le fait de gerer une ville et avoir des contacts avec d’autres joueurs que je trouve interessant. Et c’est ce que j ‘ai toujours voulu avoir dans un sim city, et ce , depuis le debut. Je ne trouve plus d’interet a jouer avec d’autres personnes sur ce type de jeux que contre le PC



biensur ca n’engage que moi



fraoch
Le 15/01/2014 à 14h53







XMalek a écrit :



Oui et c’est normal, cela te coute bien moins en temps jour/homme en java qu’en c++ et la gestion des ressources (CPU/mémoire) est bien plus simple ainsi. Toujours est il que si tu recherches le 0.2% de performance manquant à tes serveurs (ce qui est le cas du jeu vidéo) java ne parait pas d’emblée une bonne solution.







bah si on va plus loin dans ta reflexion, ce n’est ni java ni c++ qu’il faut mentionner

Il faut parler de différences entre langages interprétés et compilés.



En C on aura même encore de meilleurs résultats, mais ca sera moins bon qu’en assembleur … apres faut voir le rapport cout/perf



kamizol
Le 15/01/2014 à 14h55

Plus qu’à retirer Origin et puis je pourrais me laissé tenter <img data-src=" />


XMalek
Le 15/01/2014 à 15h06







fraoch a écrit :



bah si on va plus loin dans ta reflexion, ce n’est ni java ni c++ qu’il faut mentionner

Il faut parler de différences entre langages interprétés et compilés.



En C on aura même encore de meilleurs résultats, mais ca sera moins bon qu’en assembleur … apres faut voir le rapport cout/perf







C’est exactement ça.



Nithril
Le 15/01/2014 à 15h15







fraoch a écrit :



bah si on va plus loin dans ta reflexion, ce n’est ni java ni c++ qu’il faut mentionner

Il faut parler de différences entre langages interprétés et compilés.



En C on aura même encore de meilleurs résultats, mais ca sera moins bon qu’en assembleur … apres faut voir le rapport cout/perf







Ce serait vrai si la JVM faisait du pur interprété ;)



scriptograph
Le 15/01/2014 à 15h28







TheKillerOfComputer a écrit :



Mais pourquoi exploiter le langage Java pour la programmation même partielle d’un GROS titre, quelle idée franchement… Le Python, le LUA, encore je peux comprendre, mais le Java ?





Humm…

De souvenir la version était codée en Lingo donc sous Director.

En tout cas c’est le souvenir que j’ai lorsque je lançais le jeux.



fraoch
Le 15/01/2014 à 15h35







Nithril a écrit :



Ce serait vrai si la JVM faisait du pur interprété ;)







le code est compilé, mais il reste toujours une partie interpretée

sinon y aurait pas de JVM

mais on parle de theorie la, donc dans la theorie , meme si ca se joue a un poil de cul de nouveau né, de l’interprété sera toujours plus lent…. dans la theorie …..



Nithril
Le 15/01/2014 à 15h42







fraoch a écrit :



le code est compilé, mais il reste toujours une partie interpretée

sinon y aurait pas de JVM

mais on parle de theorie la, donc dans la theorie , meme si ca se joue a un poil de cul de nouveau né, de l’interprété sera toujours plus lent…. dans la theorie …..







Le code est compilé en bytecode, le bytecode est interprété au runtime, compilé au besoin (eg. après X appel).



Une de mes questions d’entretien préférées <img data-src=" />



Et ils n’ont pas viré leurs architectes ????

Franchement 6 mois pour ca… c’est qu’ils ont programmé avec les pieds le produit initial !


fraoch
Le 15/01/2014 à 15h56







Nithril a écrit :



Le code est compilé en bytecode, le bytecode est interprété au runtime, compilé au besoin (eg. après X appel).



Une de mes questions d’entretien préférées <img data-src=" />







hummm ok

interessant ce point de detail que je ne connaissais pas… en meme temps j’ai rien fait en java depuis des années, j’ai un peux oublié



mais quand meme (tu peux dire que je suis lourd <img data-src=" /><img data-src=" /><img data-src=" />) y a une interpretation qui peut se faire a un moment ou un autre et qui mange de la ressource ^^



BenGamin
Le 15/01/2014 à 16h00



Nous avons l’obligation de rendre ce jeu fonctionnel sur tout type de machines.



Ah bon ? Il fonctionnera sur mon PC qui a largement les spec mini avec ma debian ? <img data-src=" />


kosame
Le 15/01/2014 à 16h11

Répétez après moi :

Le java c’est tabou, on en viendra tous à bout!



semi <img data-src=" />


levhieu
Le 15/01/2014 à 16h20







XMalek a écrit :



TU seras toujours moins performant en gestion mémoire optimisée que du c++, après oui tu consommeras peut être moins (théoriquement tu consommes toujours 100% de ta mémoire pour un serveur dédié et chaque bloc est déjà prédestiné, ce n’est que comme cela que tu obtiens les meilleures performances. Ta variance mémoire doit être de moins de 10% si tu veux avoir des performanances stables client ET serveur, je sais ça va faire faire des bonds aux codeurs “industriels” mais dans le jeu vidéo chaque cycle compte)

…







Ben moi je bondis pas. Dans ma phase professionnelle «applications temps réel», la variance mémoire autorisée c’est 0%:




  1. Power-up (ou HW reset) : Phase d’initialisation : Découverte de la configuration (statique ou dans un fichier ou téléchargée …) : Calcul de la mémoire nécessaire : Allocation

  2. Si allocation OK, on passe à la phase opérationnelle, et là, plus d’allocation.



    On peut même mettre en place des tests statiques qui vérifient que personne ne fait d’allocation dynamique sans le savoir.



    Mais pour ça, faut oublier le confort de l’opérateur new sans option.



Djaron
Le 15/01/2014 à 17h26



Maxis a dû travailler pendant 6 mois pour rendre SimCity jouable hors-ligne





et les pirates avec le micro serveur local qui recupere les requetes du jeu pour tourner hors ligne, ils ont pas mis 6 mois eux, decouvrant au passage que le jeu ne faisait que du stockage via le serveur et aucun calcul déporté comme EA l’avait affirmé



du coup on se demande à quoi sont payés les codeurs chez maxis


razcrambl3r
Le 15/01/2014 à 19h37







dump a écrit :



Conernant le cas des machines peu performante c’est bien entendu une fausse excuse de leurs part.

Chez Maxis a force de développer pour l’univer des consoles, ils ont oublié que sur PC les fans d’un titre attendent que les jeux qu’ils désirent jouer les pousses a investir dans du nouveau matos “ principe d’évolution oblige ” et ca n’est pas pour rien qu’un PC reste évolutif.







+1 !! J’ai acheté mon premier PC pour Sim City 4 !!



Ewil
Le 15/01/2014 à 19h45







mkton a écrit :



:) ouais enfin, sans savoir précisément ce qu’ils font tourner server-side et qu’ils ont du migrer, personne ne peut vraiment juger.

+1 pour les perfs de C++ en temps réel, mais Java server side pour de très grosses applications, c’est une des solutions les plus populaires et les plus outillées.







Bof

Mes algo sont tous en java et servent d’IA pour voiture sans chauffeur… vu qu’on utilise des truc assez lourd (SMAR), on pourrai croire que comme tout le monde le dit “java c’est lent” et “c’est pas fait pour le critique”…



ba suffi de faire attention a comment on implémente nos algo… niveau lenteur, je suis autour des 30ms pour une boucle “acquisition capteur-&gt; pre traitement -&gt; SMA/decision -&gt; commande”

et niveau critique, quand y a personne dans la voiture….




BreizFenrir
Le 15/01/2014 à 19h49







thibsert a écrit :



Une solution rapide et facile, aurait été de faire tourner le serveur en local sur la même machine que le client. Ils auraient sans doute pu pondre ça en une semaine, au prix de perfs dégueulasses et de quelques Go d’espace disque en plus.



Je trouve ça plutôt positif qu’ils aient pris le temps de trouver une solution convenable, plutôt que de coller une rustine qui serait resté là ad vitam eternam.





+1, d’ailleurs c’est comme ça que je comprends leur justification du temps pris pour le dev.



D’ailleurs pour ceux qui tergiversent vis-à-vis de Java, rien ne laisse à penser dans le billet d’origine qu’il y avait du Java côté client.



methos1435
Le 15/01/2014 à 20h18

C’est un bon début. Mais ça n’efface pas les villes de la taille d’un timbre poste…


linkin623 Abonné
Le 15/01/2014 à 20h46







after_burner a écrit :



Ça me semble pas étonnant. Si il y avait beaucoup d’aspect gérés par les serveurs, remanier le code pour pouvoir s’en passer demander certainement du temps.



Le problème c’est que 6mois et demi plus tard, cet effort risque d’être anecdotique dans la tête des joueurs qui ont sans doutes d’autres titres en vus. C’est dès le départ qu’il fallait y penser…







<img data-src=" /> Faut le voir à l’inverse. Ils ont développé le code pour qu’il tourne sur les serveur, et jamais dans l’idée de le faire tourner sur les machines locales. Dur dur de faire de l’optimisation de code quand le jeu a été fait dans l’optique de tourner sur des machines dédiées.



Ou comment le marketing a demandé aux développeurs d’oublier la base d’un développement : optimiser son code pour le faire tourner sur la machine, pour des prétextes fumeux…



kamuisuki
Le 16/01/2014 à 07h34