Le Launcher de Bethesda a été lancé il y a plusieurs années, notamment pour accompagner le lancement de Fallout 76. Puis le jeu a été disponible sur Steam et beaucoup ont préféré la célèbre boutique à l’utilisation d’un lanceur supplémentaire, lourd de surcroît.
Mais Bethesda a décidé d’arrêter les frais. En mai, tous les jeux seront basculés vers Steam. Dans la plupart des cas, les transferts de données seront automatiques, notamment les sauvegardes. Parfois, des opérations seront à réaliser manuellement.
Le compte Bethesda.net restera requis pour les fonctions qui le demandaient, par exemple dans certains jeux pour accéder aux DLC, objets achetés, skins, mods et autres.
De plus amples détails seront fournis début avril, quand le studio commencera à communiquer plus activement sur le transfert.
Bethesda n’aborde en outre pas une question qui peut sembler évidente : pourquoi Steam, alors que sa société mère, Zenimax, a été rachetée par Microsoft pour 7,5 milliards de dollars ?
Sans doute pour des questions de disponibilité et dans une volonté de toucher autant de joueurs que possible. Après tout, de nombreux titres de Bethesda sont maintenant disponibles dans le Xbox Game Pass, mais quelques ventes supplémentaires sur Steam ne peuvent pas faire de mal.
Commentaires (31)
#1
Le lanceur était lourd ? J’aimerais bien savoir si c’était du Java ( dévelopé ou architecturé par des vieux), ou du javascript (architecturé ou développé par des jeunes).
#1.1
Tu voudrais donc savoir s’il était lourd ou lourd ?
#2
Non, il veux savoir si c’était des développeurs expérimentés sur une plateforme lourde, ou des développeurs inexpérimentés sur une plateforme légère.
#3
c’était moqueur en effet car je considère les deux comme pas sérieux. Faire passer un script pour un logiciel est un escroquerie des clients.
Faire passer un language de script pour un language de programmation de logiciel est une escroquerie technique et mon dégoût de java viens de là.
Perso, j’écris de gros scripts en perl avec des projets de près de 10 000 lignes mais à aucun moment je ne présente cela comme un équivalent d’un logiciel écrit en C, C++ ou Rust ou tout language réellement compilé.
Les scripts ont leurs avantages et peuvent convenir dans bien des cas mais ils montrent leurs limites dès qu’il sagit de projets d’envergure pour lesquels ils ne sont jamais adaptés.
#3.1
#3.2
Un langage ne définit jamais son mode d’execution, simplement sa syntaxe et sa sémantique. Il n’est écrit nul part dans la spec ECMAScript que le code ne peut pas être compilé ou qu’il doit être executé par un interpréteur.
Par exemple :
Bref, la définition de script ou pas script n’est pas si évidente que ça.
Dans tous les cas, la définition de logiciel est :
“En informatique, un logiciel est un ensemble de séquences d’instructions interprétables par une machine et d’un jeu de données nécessaires à ces opérations.”
Donc même le script le plus basique est un logiciel et il n’y a aucune escroquerie technique là dedans.
#3.3
Tu peux rajouter feu Adobe Air (runtime Flash sur Desktop), le launcher de League of Legends était codé avec ça au début
Bon pour Java c’est un peu abusé de le mettre au même niveau que les langages de script comme PERL directement interprétés puis il y a quand meme compilation en bytecode intermédiaire meme si ce n’est pas du code machine (et encore avec GraalVM ca peut l’être à présent), pareil pour le code .Net managé come du C# converti en CIL / MSIL.
#4
Si ça peut donner des idées à Ubisoft et EA…
#5
Je suis aussi assez surpris de ce choix de Steam. Quoi que, en y réfléchissant … Quelle est la part réelle de marché du magasin Windows Store ?
#5.1
Je pense que ça doit être valable pour tous les autres stores.
(le pire étant les jeux que tu achètes sur Steam mais qui t’imposent de passer quand même par un launcher externe comme, par exemple au hasard, Ubi aime bien le faire)
Je serais curieux de voir les parts de marché des launcher EA et UBI comparé à Steam mais je pense que si ces 2 là continuent encore à publier des trucs sur Steam au lieu de tout garder en exclusif sur leurs propres plateformes c’est qu’il y a une raison
Pour l’instant les parts de marché de Linux restent négligeables niveau gaming mais si ça venait à se développer fortement j’ai dans l’idée que d’autres risqueraient de revenir se pointer sur Steam qui a déjà fait un très gros boulot d’adaptation plutôt que de se faire cher à développer eux mêmes un truc en partant de zéro.
#6
#7
Désolé de la disgression, mais ça serait quoi l’use case/avantage d’exécuter du C interprété, et non compilé ?
#7.1
Ça permet de retrouver tous les avantages de l’interprété.
Le use case classique, c’est d’être facilement cross-platform.
Le code à exécuter reste le même partout et il suffit d’implémenter un interpréteur pour les plateformes qu’on veut supporter.
Un autre use case peut être de sauter la phase de compilation pour passer directement à l’exécution et donc gagner du temps de développement. C’est d’ailleurs ce qu’ils expliquent sur le lien que j’ai donné :
“For some tasks, C and its compile/ link/execute/debug process are not productive. As computer hardware becomes cheaper and faster, to be productive and cost effective, script computing in C/C++ can be an appealing solution”
Je ne rentrerai pas dans le débat “c’est nul ou c’est bien”, ce n’est pas le sujet.
#8
#8.1
Relou, ton image pète la pagination sur mobile…
#8.2
Non, c’est faux😉
#8.3
Je confirme. J’ai le souci en mode portrait.
#8.4
Est-ce qu’on peut éviter d’avoir cette conversation à chaque fois que quelqu’un poste une image ? On ne peut rien y faire tant que NXi ne fixe pas le soucis. Les gens qui postent des images n’y sont pour rien.
Edit: je rêve ou ça vient d’être fixé ?
#8.5
Bah si. Il suffit qu’ils ne postent pas d’image pour résoudre le problème.
Et écrire des commentaires à ce sujet permet à la fois :
Je trouve que c’est déjà bien comme résultat.
De toute façon avec leur développeur qui est parti en laissant ce problème, on n’est pas près de voir la correction arriver ! Il ne reste donc que l’information des lecteurs.
#8.6
Le moyen le plus efficace étant encore de nous contacter via le formulaire ou via GitHub pour nous faire part du souci et qu’on corrige lorsque c’est possible. C’est exactement la même chose que pour le signalement d’erreurs d’orthographe : les commentaires ne sont pas fait pour ça.
Et merci de laisser en dehors de tout ça un ancien membre de notre équipe qui n’y est absolument pour rien.
#9
Le rachat de Bethesda par Micro$oft m’a donné pas mal de déception…
étant amateur de Steam, cette nouvelle me rassure un peu ! (temporairement ?)
#10
#11
Et ils fixeront le souci d’autant moins vite qu’on ne le leur rappelle pas.
Donc non, a chaque fois je ferai la remarque.
Déso
#12
Et bien modère mon message, pas de problème.
Mais les 2 premiers points de mon commentaire mêmes si hors sujet sont vrais.
Et tant mieux s’il n’y est pour rien, la correction va donc arriver rapidement.
#13
Basiquement, les languages de script permettent de coder très rapidement des programmes mais ce qui fait leur souplesse constitue également leur talon d’achile. J’ai cité la compilation en exemple car l’interprétation, même sous forme de bytecode, ne remplacera jamais du code natif en terme de vitesse d’exécution. On peut cependant arger que même les processeurs x86 pratiquent l’interprétation mais c’est un autre débat.
Quand je dis “sérieux”, je pense aussi à la capacité de tel ou tel language à se préter à des projets d’envergure. C’est ma définition de logiciel. Dès lors, l’absence de typage fort rend souvent les choses complexes avec les languages de script où des problèmes d’intégration surviennent en partie à cause de cela.
Le paradigme objet aide il est vrai à l’intégration mais les grand principes de la POO ne sont pas tous bien implémentés. Java par exemple qui se pose en référence en la matière ne gère même pas l’héritage multiple. C’est risible je trouve. Ceux qui ne voient pas en quoi cela est important peuvent regarder le fonctionnement de Qt pour y voir une utilisation massive de l’héritage multiple.
Enfin, je ne considère pas comme sérieux un language pour lequel la gestion de la mémoire n’est pas accessible au programmeur. Le comportement du ramasse-miettes et la gestion globale de la mémoire de java rend impossible tout contrôle des latences des intefaces utilisateurs et c’est la raison pour laquelle je trouve qu’élever java au rang du c ou du c++ est malhonète.
La consommation de mémoire élevée est une caractéristique forte des languages interprété même si j’arrive à faire des traitement assez dingue sur des tables de données d’un milions de lignes en mémoire en perl.
Pour enfoncer le clou, la gestion du multi-tâche est devenu une caractéristique importante et j’ai été très déçu récement quand en tentant de me mettre au python, j’ai constaté qu’il n’était pas réentrant et que de ce fait, un programme python ne sais pas utiliser plus d’un coeur d’exécution.
Sur ce thème, j’ai été ému en lisant le tuto sur rust et j’ai commencé à m’y mettre car je consisère ce langage comme une base très solide pour construire de belles choses légères, rapides.
Le rust apporte un sacré coup de jeune aux languages compilés et redonne de l’intérêt à ce type de programmation. Là où j’aurai peut-être choisi perl ou python pour une api rest que j’ai commencé, j’ai chosi de la faire en rust avec la bibliothèque rocket et cela est prometteur.
#14
Au plaisir, je vais tâcher de faire au moins aussi bien
Encore une fois, l’utilisation classique de Java, c’est de le compiler via javac pour produire un bytecode et de donner ce dernier à la JVM qui va le compiler à la volée en natif.
Il en est de même pour le javascript (si il tourne dans V8 au moins et il me semble que le moteur JS de mozilla aussi).
Dans énormément de cas, la vitesse d’exécution n’est pas le problème. Faire une API ultra optimisé a l’infini, ça a peut être utile si elle doit servir des millions de requêtes à la seconde mais ça n’arrive pas si souvent que ça. Dans l’immense majorité des cas, le facteur limitant est de toute façon ailleurs (réseau, disque, parfeu par exemple) et le programme passe son temps à se tourner les pouces.
Chaque outil a ses avantages et ses inconvénients, bien sûr. Personne n’a jamais prétendu qu’un outil était parfait dans toutes les situations (et si quelqu’un l’a fait, il se trompe).
Je ne crois pas que Java ai déjà prétendu être la référence des langages objets.
Depuis Java 8, il est possible d’hériter de plusieurs interfaces.
Je ne connais pas assez Qt pour en parler mais il est tout à fait possible (et même assez simple) de faire de très belles et fluides interfaces utilisateurs en Java, par exemple sur Android. (note : je ne dis pas que toutes les applications Android ou java sont bonnes, je dis qu’il est tout à fait possible de faire des choses biens). Donc à moins d’avoir mal compris, le fait que Qt utilise massivement l’héritage multiple n’est pas une condition nécessaire à faire des choses biens.
La mémoire est toujours accessible par le programmeur. Faire un new en Java ou en C++ va bien provoquer une allocation mémoire. Déclarer une variable en javascript via bien créer une entrée dans la pile. Même en Prolog la mémoire est accessible au programmeur.
J’imagine que vous voulez juste parler de la libération de la mémoire et même dans ce cas là, ça se discute.
Est-ce que Rust est mauvais car on ne libère pas la mémoire à la main ?
Est-ce que Java est mauvais car on ne libère pas la mémoire à la main ?
Est-ce que C++ est mauvais quand on l’utilise avec une library de garbage collection ? (https://v8.dev/blog/high-performance-cpp-gc)
Bien sûr que non et je ne comprends pas du tout ce genre de remarque que je trouve très élitiste en plus d’être fausse (confusion entre le langage et l’implémentation).
La bonne manière de choisir et d’utiliser un outil, c’est d’en comprendre les tenants et les aboutissants. Si l’utilisation d’un garbage collector pose problème lors de l’exécution, alors il faut envisager de s’en passer. Si gérer la libération de la mémoire à la main pose problème, il faut envisager de laisser un outil s’en charger.
Il est possible de faire du multithread en python : https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods =>
“spawn
fork
Je n’ai pas grand chose à dire là dessus, je suis d’accord pour dire que Rust apporte des nouveautés bienvenues et que c’est un langage qui mérite de l’intérêt.
D’une manière général, je trouve votre discours trop dichotomique. Soit c’est bien, soit c’est pas bien mais il n’y a pas d’entre deux. Or l’informatique, c’est avant tout des compromis.
Et en parlant de compromis, je dirai que vous omettez une chose : le prix.
Le nerf de la guerre, c’est l’argent.
Faire de l’optimisation mémoire de poil de cul en C++, c’est une chose. Le faire en un temps raisonnable et avec un coût raisonnable, c’en est une autre.
Ensuite la maintenabilité entre en jeu. Qui peut maintenir les programmes optimisés au poil de cul ? A quel coût ?
Et donc la question ultime : est-ce que ça en vaut le coût ? (pour les pinailleurs, je sais qu’on dit “coup” mais il est littéralement question d’argent ici)
La réponse a cette dernière question est évidemment a la discrétion de chacun et c’est pourquoi dire d’un outil qu’il est mauvais de façon univoque alors qu’il répond précisément a certaines problématique est, selon moi, une erreur.
#15
Je pense qu’il y a mauvaise interprétation de ce que j’ai dit: Dans mon premier post, j’ai bien dis que les languages de scripts avaient leur intéret selon le contexte donc je m’en sert aussi.
Quand je fait un script en bash, je ne me pose pas la question de l’optimiser en en le ré-écrivant en C.
J’ai pu entendre par le passé pas mal de promoteurs de java dire que Java était supérieur au C car même le main est un objet et de continuer sur le fait que c’était le seul language purement objet.
Je n’entent plus personne qui tient ce discours depuis pas mal de temps.
Je ne vise que JAVA dans ma critique et je peux te dire que je n’ai jamais vu un autre langage créer des lags comme java quand il démarre son ramasse miette et fige les programmes de manière impromptue et non contrôlable.
Devant utiliser au quotidien des programmes écrits en java, c’est, en plus des interfaces utilisateurs pas ergonomique du tout, très pénible.
Je ne crois pas que cela soit possible en java. Peut-être que je me trompe.
Oui mais les threads sont exécutés séquentiellement sur un seul coeur. L’interpréteur Python n’étant pas ré-entrant, il est impossible de bénéficier de l’exécution simultanée des tâches. C’est ce que j’appelle le faux multi-tâche.
Encore une fois, je ne nie pas l’intérêt des scripts mais je ne trouve pas sérieux d’utiliser les languages de script, fusent-ils compilés à la volée ou non, pour des projets d’envergure.
Ce que l’on reproche très régulièrement aux gros programmes écrits en java, peu importe la version de ce dernier, c’est la consommation énnorme de mémoire et de ressources processeur pour pas grand chose. C’est pareil pour les amoureux du javascript qui voudraient s’en servir pour tout.
Le débat dans ces cas là n’est pas de grater un poil de c*l de perf mais d’arrêter de mettre les machines à genoux par des programmes basés sur des mauvais choix de languages.
Le manque de discernement est plutôt à chercher chez les promoteurs du javascript à toutes les sauces.
Perso, je n’envisage le javascript que côté client, là où il est adapté au besoin.
#16
Les applis Android sont majoritairement écrites en Java (ou en tout cas tournent dans une JVM donc avec un garbage collector) et elles ne posent généralement pas de problèmes de performances.
Peut on en conclure que le langage n’est pas en faute ?
Je voulais dire que si un outil n’est pas approprié, il faut en changer. Si utiliser Java et son garbage collector pose problème, il faut envisager d’utiliser une autre solution.
Il ne faut pas blâmer l’outil mais la manière dont on l’utilise donc.
Personne n’aurai l’idée de dire qu’un marteau est nul car on ne peut pas visser avec. Là c’est pareil.
C’est pourtant expliqué dans la première phrase de la doc… (je commence à me poser des questions sur votre bonne foi)
“spawn
Cet appel démarre un nouvel interpréteur. Si il y a plusieurs interpréteur, nécessairement, ils s’exécutent en parallèle.
On en revient au même problème : la qualité, ça se paye. Avoir des programmes correctes qui répondent bien aux besoins (souvent farfelus) de ceux qui les demandes, ça prend du temps et de l’argent.
Quand on a pas de temps ni d’argent, ça donne des résultats de mauvaise qualité et le langage n’est pas à blâmer la dedans.
Je ne peux que vous conseiller de vous intéresser de plus prêt à ce qui se fait ailleurs et les raisons qui ont poussé ces gens à faire ces choix.
Pourquoi Node a été créé alors qu’il existe déjà d’autres solutions ?
Pourquoi Typescript alors qu’il existe déjà d’autres langages typés ?
Pourquoi Go (qui se base sur l’utilisation d’un garbage collector d’ailleurs) alors qu’il existe déjà C++ ?
Pourquoi Java alors qu’il existe déjà C++ ?
Les gens qui font et utilisent ces choses ont certainement de bonnes raisons de les faire vu la taille ces projets et le succès qu’elles rencontrent.
J’ai le sentiments que vous êtes très fermé à ces nouveautés pour des raisons qui ont l’air plus idéologique ou à cause d’idées reçues que réellement techniques (sans jugement de valeur, c’est ce que je ressens en lisant votre message).
Il est parfaitement possible de faire une API Rest d’envergure tout à fait viable et performante avec Node (le combo Typescript/NestJS est d’ailleurs vachement bien)
Il est parfaitement possible de faire une interface utilisateur en java performante (voir Android)
Il est parfaitement possible de faire du multi-thread en Python
Il est parfaitement possible de faire un programme tout pourri qui rame et qui bouffe toutes les ressources en C++ ou en Rust
La faute n’en revient pas a l’outil mais à celui qui l’utilise mal.
#17
Ce n’est pas en effet les languages eux- même qu’il faut blâmer quand on cherche à les utiliser de la mauvaise manière mais comme tu le sais sûrement, ce ne sont que rarement les développeurs qui décident d’utiliser un language ou un environnement inapproprié pour le besoin mais des décideurs qui se laissent convaicre par des promoteurs comme ce fut le cas avec sun pour le java. Et sun mentait à ses clients quand il faisait la promotion de java.
Un exemple simple avec les serveurs de sms: quand orange est passé de la version c++ à la version java, il a fallu doubler le nombre de machines de production pour assurer le service. Et ce ne sont pas des nuc.
Là où tu vois de l’idéologie, il y a avant tout un certain retour d’expérience et je ne parle donc que des retours que j’ai vraiment. Sur le go je n’ai pas d’info donc je me suis bien gardé d’en faire la critique.
Sur le python, je vais creuser l’exemple que tu m’a donné mais sache que ma conclusion précédente était le fruit de pas mal d’heures de recherche sur le sujet. Je ne suis donc pas dans le dogme ou dans l’effet de mode.
Ce qui me dérange par contre est de devoir justifier constament ma position sous peine d’être accusé de troller. On vit dans un monde où personne n’a plus le droit de ne pas aimer telle ou telle chose sans se faire accuser de mal penser. Je respecte parfaitement ton droit d’aimer java mais respecte en retour le mien de ne plus supporter ce language majoritairement mal utilisé.
#17.1
Je n’ai accusé personne de troller. Vous avancez un argument et j’en avance un autre. Quel est le problème ?
D’ailleurs je constate que votre propos a évolué. Au début vous accusiez clairement les langages d’être les problèmes (en disant qu’ils n’étaient pas sérieux notamment), maintenant vous reconnaissez que c’est uniquement la manière dont on les utilises.
En revanche, je n’aime pas particulièrement java et son écosystème.
Je suis d’ailleurs d’accord pour dire que c’est une mauvaise solution dans beaucoup de situations.
Je vais continuer à me faire l’avocat du diable mais vous ne mentionnez que ce qu’Orange a “perdu” en passant de C++ à Java mais jamais ce qu’ils ont pu gagné (temps de dev ou facilité à trouver du personnel compétent, par exemple).
Comme je le disais, l’informatique c’est avant tout des compromis et il n’y a pas que les performances brutes qui comptent.
#18
L’accusation de troll ne venait pas de vous en effet mais d’une autre personne à qui je n’ai pas répondu, préférant discuter avec des personne qui argumentent.
Pour le cas d’orange qui date du début des années 2000, le logiciel appelé SMS center est passé de C++ à java en passant d’une version majeure à une autre. C’est une décision de l’éditeur dudit logiciel. L’opérateur n’avait pas d’autre choix que de s’adapter car il n’est pas souhaitable de rester à la traine sur les mises à jour des machines de production et la migration d’un logiciel vers un autre n’est pas une chose qui se décide du jour au lendemain.
Avec un doublement des machines de production et un surcroit de prestations attenantes, je ne suis pas certain qu’il puisse y avoir eu un gain pour Orange. Mais je n’ai pas d’informations pour étayer cela.
Je ne sais pas ce qu’il en est aujourd’hui. Peut-être que l’éditeur à tout ré-écrit en javascript pour suivre la mode.