Discussion :

[EyZox]

Pour l'idée du garbage collector, comme certains l'ont dit Unity utilise aussi un garbage collector et les jeux fonctionnes très bien dessus.
Ensuite, il existe une multitude de jeux sous Android, donc écrit en Java pour tourner sur des appareils à faible capacité matérielle. On ne fait certes pas des miracle, mais on fait des jeux quand même. Minecraft doit-il forcément être écrit en C++ pour tourner correctement ? Un pacman doit-il être écrit en C++ pour tourner correctement ? Est-ce une aberration de faire un tetris en Java alors que la plupart des jeux se font en C/C++ ? La plupart des PC moyen de gamme ont entre 2 et 4 Go de RAM. 2Go de RAM n'est-ce pas suffisant pour jouer sur un jeu comme Minecraft ?
Il n'est pas rare de voir certaines version de Minecraft prendre jusque 6 Go de RAM surtout à partir de la 1.8 (Et je ne parle pas des gros serveurs).
Faire passer le GC sur 6 Go, ça prend plus de temps que le faire passer sur 2Go. De plus, il me semble que le GC utilise un thread a part, Minecraft étant mono-thread, le GC se sert de ressources que le jeu n'exploite pas. Je me trompe peut-être, je ne suis pas un dev JV donc mes connaissances se limite à des généralités.

Je trouves les trucs de mods totalement useless

Ça dépend des gouts de chacun. Puis il en existe un paquet, il y a en forcément que tu trouvera utile sans qu'ils changent radicalement le jeu
Inventory Tweak par exemple, sauf si tu adores trier ton inventaire toi-même toutes les 10 minutes Question de gout !

Le passage en C++ en tant que tel ne facilitera en rien la maintenance.
Ce qu'il faut, c'est avoir une API officiellement supportée qui gère la retro compatibilité.
On nous a annoncé une API il y a 3 ans et tout les 6 mois on nous dit qu'elle arrivera dans 6 mois.
Le jour où elle sera disponible, on sera tous entrain de jouer à Half-Life 3.

[Uther]

Pour l'idée du garbage collector, comme certains l'ont dit Unity utilise aussi un garbage collector et les jeux fonctionnes très bien dessus.
Ensuite, il existe une multitude de jeux sous Android, donc écrit en Java pour tourner sur des appareils à faible capacité matérielle. On ne fait certes pas des miracle, mais on fait des jeux quand même.

Enfin sous Android, la plupart des jeux qui nécessitent de la puissance sont presque intégralement codés en natif.

Minecraft doit-il forcément être écrit en C++ pour tourner correctement ? Un pacman doit-il être écrit en C++ pour tourner correctement ? Est-ce une aberration de faire un tetris en Java alors que la plupart des gens se font en C/C++ ? La plupart des PC moyen de gamme ont entre 2 et 4 Go de RAM. 2Go de RAM n'est-ce pas suffisant pour jouer sur un jeu comme Minecraft ?

Minecraft a prouvé qu'il pouvait fonctionner en Java dans une certaine mesure. Mais si on veut des performances optimales, le C++ peut clairement aider. Minecraft est loin d'être optimal notamment au niveau de la consommation mémoire.

Faire passer le GC sur 6 Go, ça prend plus de temps que le faire passer sur 2Go. De plus, il me semble que le GC utilise un thread a part, Minecraft étant mono-thread, le GC se sert de ressources que le jeu n'exploite pas. Je me trompe peut-être, je ne suis pas un dev JV donc mes connaissances se limite à des généralités.

Je ne sait pas si Minecraft utilise plusieur Thread ou non, mais le GC actuel de la JVM d'Oracle n'est pas sur un thread séparé. En fait il est dit "Stop the word" : c'est a dire que de toute façon il interrompt de temps en temps complétement tous les Thread pour faire son travail.

[Beanux]

implémenter toutes les fonctionnalités de la version Java et que celles-ci restent compatibles aussi bien sur les ordinateurs, tablettes, smartphones et consoles de jeu Windows.

Chtite question, quid des autres OS que windows ?

[Saverok]

Chtite question, quid des autres OS que windows ?

Question stupide, on parle de Microsoft

Par ailleurs, dans la com, ils oublient la xbox one

[kolodz]

Pour ma part, je ne vois pas bien comment, ils vont faire avec les mod/plugin de Minecraft. Sans compter, les communauté autour de serveur de jeu...

[Uther]

Pour moi s'il arrivent a faire quelque chose de mieux et de plus stable, les gens suivront. Un serveur Minecraft réclame quand même beaucoup de ressources, s'ils arrivent a faire des serveur qui consomment moins les hebergeurs ne seront pas difficile a convaincre.
Quant aux mods existants s'ils arrivent enfin a proposer une API propre et stable, je suis sur que beaucoup de développeurs accepteront de faire l'effort du portage. Le gros problème actuellement c'est qu'il n'y a pas d'API définie donc le moindre changement casse systématiquement tout.

[atha2]

A nuancer car lorsque l'on développe un jeu avec Unity, on va principalement utilisé le C# (qui est très similaire à Java). Or, Unity a fait ses preuves depuis longtemps et on a aujourd'hui un nombre conséquent de jeux fluides qui ont été conçu avec. Après, il faut pas se mentir les binaires d'Unity sont le résultat d'une compilation d'une base de code en C++. Tout ça pour dire que c'est pas très malin de vouloir faire un jeu entièrement en Java (ou C#) mais c'est largement possible de coder son moteur (les parties bas niveaux) en C++ et de faire des bindings Java (ou C#) pour faire le développement de son jeu dans un langage plus "accessible".

Oui c'est notamment au C# et à Lua dans Unity auxquels je pensais quand j'ai précisé "autre que pour le scripting des niveaux". De ce que je comprends, avec Unity, tu décris ton jeu dans un langage de haut niveau et ensuite tu appuis sur le bouton "générer mon jeux" et tu as un super jeu. Mais dans le produit final, tu n'as aucun trace de C#/lua/Java donc pas de problèmes de fluidité liés au Garbage Collector (Java/C#).

Pour l'idée du garbage collector, comme certains l'ont dit Unity utilise aussi un garbage collector et les jeux fonctionnes très bien dessus.

Alors il y a garbage collector et garbage collector. Je ne savais pas qu'Unity en utilisait un au sein des jeux générés, mais comme ils gèrent le cycle de vie du jeux, ils peuvent adapter le GC aux besoins (ex : passage entre 2 niveaux) et ne pas freezer le jeu.

Ensuite, il existe une multitude de jeux sous Android, donc écrit en Java pour tourner sur des appareils à faible capacité matérielle.

Comme dis plus haut, ces jeux ne sont pas codés en Java mais en natif avec le NDK (et non je ne rentrerais pas dans les trolls "Android ce n'est pas du Java", "Android c'est comme Java, c'est lourd" ...)
Et puis je n'ai jamais dis que Java avais des problèmes de performance (d'ailleurs dans certain cas, il est même meilleurs que du C/C++). Java est utilisé dans des machines à café et carte SIM donc les devices à ressource limité ne pose pas vraiment problème... Encore une fois, le problème de Java dans le domaine des jeux vidéos, c'est qu'on ne peux pas garantir un framerate constant.

[koala01]

Salut,

Je ne suis pas expert en minecraft, pour la bonne et simple raison que... je n'y ai jamais joué

Cependant, je me rend compte que ce qui risque de poser problème pour beaucoup d'entre vous est... que tous le mods créés pour minecraft risquent d'être à refaire.

J'ai simplement envie de poser la question "Ah bon, et pourquoi donc "

Car, à moins qu'il ne s'agisse réellement de remplacer un fichier .class par un autre (dans lequel on a modifié le code d'origine, oserais-je dire), il y a énormément de projets "multi langages" qui utilisent une base de C++ dans certains coins, une base de java dans d'autres et, qui sait, pourquoi pas un peu de C#, de python ou de n'importe quel autre langage encore ailleurs.

A vrai dire, je me demande même s'il y a vraiment un seul langage qui soit tout à fait incompatible avec n'importe quel autre (mis à par le C peut-être ). Dés lors, j'ai envie de dire que, pour que les mods fonctonnent, il "suffit" de deux choses :

1. que microsft puisse mettre un système de plugins cohérent au point pour son code C++ et
2. qu'ils fassent en sorte que ces plugins puissent être écrits dans différents langages

Entre des projets "à plugins multiples" comme peut l'être visual studio (et d'autres projets de chez eux) et l'expérience tirée de .NET en ce qui concerne la compatibilité, je ne doute pas vraiment qu'ils aient les connaissances et la capacité à résoudre ces deux points

Maintenant, il me semble avoir lu dans la discussion que les mods créés correspondaient d'avantage au fait de remplacer un fichier .class qu'à la création d'un véritable plugin. Si c'est le cas, mon argumentation tombe évidemment à l'eau! Mais, ne serait-ce pas le moment d'en profiter pour "homogénéiser" les mods et, qui sait, en faire une revue de code un peu correcte

Sans compter enfin que l'on parle d'une version "éducation"... La version destinée à tout le monde, on y viendra tôt ou tard (apparemment plus "tôt" que tard, si j'ai bien compris ) mais, avec un peu de chance, cela laissera l'occasion aux créateurs des mods concernés par d'éventuels changement le temps de s'y préparer...

[adiGuba]

Salut,

Mais dans le produit final, tu n'as aucun trace de C#/lua/Java donc pas de problèmes de fluidité liés au Garbage Collector (Java/C#).

C'est parce qu'il existe plusieurs types de GC, et qu'ils ne sont pas tous bloquant, ou en tout cas plus prédictible...

Après bien sûr il faut aussi gérer proprement la création d'objets, mais cela poserait problème avec ou sans GC...

Comme dis plus haut, ces jeux ne sont pas codés en Java mais en natif avec le NDK (et non je ne rentrerais pas dans les trolls "Android ce n'est pas du Java", "Android c'est comme Java, c'est lourd" ...)
Et puis je n'ai jamais dis que Java avais des problèmes de performance (d'ailleurs dans certain cas, il est même meilleurs que du C/C++). Java est utilisé dans des machines à café et carte SIM donc les devices à ressource limité ne pose pas vraiment problème... Encore une fois, le problème de Java dans le domaine des jeux vidéos, c'est qu'on ne peux pas garantir un framerate constant.

Le problème de Java pour le développement d'un jeu-vidéo, ce n'est pas le GC ou la "performance" en tant que tel, mais plutôt le fait qu'il n'existe pas de "type-valeur".
On a soit des types primitifs, soit des objets.
Il n'y a rien qui ne permette de représenter une structure native (c'est à dire uniquement les données brutes).

Or si les objets peuvent être très utile, ils ne peuvent pas être manipulé en dehors de Java (par exemple pour passer des calculs au GPU)
Du coup on ne peut pas les passer "tel quel" et on doit faire des conversions Objet Java <-> structure native, et inversement.
Et c'est çà qui est très couteux, surtout lorsqu'on manipule de grosses quantités de données...


C'est une des futurs grosses évolutions du langages (mais pas pour tout de suite).


a++

[Beanux]

Salut,
Maintenant, il me semble avoir lu dans la discussion que les mods créés correspondaient d'avantage au fait de remplacer un fichier .class qu'à la création d'un véritable plugin. Si c'est le cas, mon argumentation tombe évidemment à l'eau! Mais, ne serait-ce pas le moment d'en profiter pour "homogénéiser" les mods et, qui sait, en faire une revue de code un peu correcte

En effet, les mods sont plus qu'un simple .class a changer. Il y a même des mods spécifique pour fournir une api stable (au hasard modForge) pour intégrer des mods.


Et si le systeme s'avere ne pas être compatible avec java, je pense que le jeu en lui même aura une mort lente.

Au vu de l'avancement de certain mod, certes minecraft ce n'est pas que des mod, je ne suis pas sur que la conversion se fera.
Actuellement, certaines version restent volontairement dans d'anciennes version pour éviter des problème de compatibilité. C'est probablement ce qui se passera si les nouvelles versions coupent la communauté de developpeurs/moddeur java de minecraft.

Enfin cela sera peut être compatible, qui sait !

[bacelar]

Rien n'interdit d'avoir des plug-ins JAVA à un programme en C++.
Ce n'est qu'un problème d'API.
Il est tout aussi possible de faire un mécanisme de plug-ins à base de Dll, mais là, il faudra spécifier des API et arrêter de faire du développent en mode cow-bow qui peut tout péter s'il veut (ou s'il est pas doué, c'est plus courant).

[Gruzzyh2]

Pour info : http://education.minecraft.net/

[vivid]

Moi perso je reste toujours étonner que l'on programme quoi que se soit dans ce langage techniquement aussi minable comme java.... faut vraiment pas aimer programmer.. pouuuf

[cchatelain]

Ça ne transformera plus les PC en grille pain ?

[Freem]

Salut,
Cependant, je me rend compte que ce qui risque de poser problème pour beaucoup d'entre vous est... que tous le mods créés pour minecraft risquent d'être à refaire.

J'ai simplement envie de poser la question "Ah bon, et pourquoi donc "

Car, à moins qu'il ne s'agisse réellement de remplacer un fichier .class par un autre (dans lequel on a modifié le code d'origine, oserais-je dire), il y a énormément de projets "multi langages" qui utilisent une base de C++ dans certains coins, une base de java dans d'autres et, qui sait, pourquoi pas un peu de C#, de python ou de n'importe quel autre langage encore ailleurs.

A vrai dire, je me demande même s'il y a vraiment un seul langage qui soit tout à fait incompatible avec n'importe quel autre (mis à par le C peut-être ).

Pas expert en dev non plus donc.
Pour info, quand on fait des bibliothèques partagées, le C++ est incompatible avec lui-même, potentiellement d'une version d'un compilateur à une autre version du même compilateur, sans parler entre divers compilateurs. Je parle bien des binaires générés, hein, par du code source.
Les langages ne sont généralement compatibles qu'avec le C, et c'est de par cette compatibilité C (qui est quand même limitée, qui impose en général de se taper du code spécifique d'import de fonctions, pas toujours si simple. En C# j'avais essayé, mais essayer de comprendre ces histoires de pointeurs sécurisés ou non, et le fait d'appeler tel ou tel truc sécurisé ou non d'une portion de code qui ne l'est pas était une galère sans nom. En Java il me semble que c'est moins lourd.) qu'ils sont compatibles les uns avec les autres.

Quelques éclaircissements au sujet de l'incompatibilité du C++ avec lui-même, il faut savoir que l'ABI n'est pas imposée par le standard, pour que les éditeurs de compilo/lib standard puissent optimiser le comportement dans la direction qui leur sied. Et ensuite, garder une API stable d'une version à l'autre d'un système n'est pas aussi évident pour un langage natif que pour un langage interprété/semi-interprété (ou qui tourne sur une VM, comme vous préférez). Ajouter à ça les différences entre les systèmes, que ce soit l'OS (win/linux/*BSD) ou le matos (32/64bits, x86/arm, big/small/whatever endian,...).
Quelques exemples:

* Le C (et donc le C++) fournit des types par défaut dont la taille varie selon l'architecture. En 16 bits, un int faisait 16 bits, en 32 bits il en fait 32. En 64 bits, ça dépend de l'OS sous-jacent. A savoir que, le C++ fournit en standard des types dont la taille minimum et/ou maximum depuis plus longtemps que C++ (uint32_t, uintleast32_t, ce genre de trucs). A l'origine, ils ne fournissaient que ces types à taille variable. J'ai découvert ce problème en BTS, parce que je savais programmer avant, et que j'utilisais de vieux compilos 16bits, et j'ai très rapidement cessé d'utiliser les types natifs, sauf les char (qui eux, sont stables à priori... pas garantit, mais ça doit au moins être compatible ASCII, donc minimum 7 bits, et je doute qu'il reste beaucoup de proco qui utilisent des bytes de 7 bits...). D'ailleurs, pourquoi la SDL offre-t-elle des types non natifs (INT32 p.e.) (on peut aussi se demander pourquoi elle n'utilise pas les types standards, mais la réponse est simple: Visual Studio, au moins jusqu'au 2005 inclus, ne fournissait pas stdint.h, pourtant standard C99 (mais C++11 seulement, oui ce sont des langages différents)).
* L'implémentation des vtables, le truc qui permets le support de la RTTI (qui est d'ailleurs un mécanisme coûteux), est laissée à la discrétion du compilateur. Si la vtable est encodée en mémoire au début de la classe, ou après les données de la classe, ou dans un segment différent selon le compilateur, les ABI de la classe pètent, et un binaire C++ ne pourra pas être exploité d'un système à l'autre.
* les exceptions, dont l'implémentation n'est pas spécifiée par le standard, encore une fois. Par exemple, que spécifie le standard quand une exception n'est jamais rattrapée? Et si elle est lancée d'un binaire différent (appel d'une "DLL" par une autre ou par un exécutable, par exemple et pour faire simple) sans être rattrapée dans ce binaire (mais l'est dans le binaire appelant)?
* l'alignement mémoire, qui est un problème matériel mais qui ne concerne pas les langages non natifs (sauf ceux qui font joujou avec le réseau, j'imagine?).

Bref, écrire du code natif et portable n'est pas aussi trivial qu'on peut le croire. Surtout si en plus on veut un truc un peu performant.
Le faire en C++ relève de l'impossible, sauf si l'on accepte de ne pas utiliser un certain nombre de fonctionnalités C++. Je m'étais penché à une époque sur la création d'un système de plug-in, où l'API comme l'ABI doivent être rétrocompatibles au maximum d'une version à l'autre (il y à de bons articles dessus sur drdobbs pour les curieux) et en gros, la méthode classique (la plus simple aussi), c'est de ne fournir que des structures et des fonctions qui prennent ces structures en paramètre qui les génèrent et les nettoient, des "classes dépliées" donc.
Sauf que... pour qu'une telle bibliothèque soit exploitable à fond en C++, il faut fournir les détails d'implémentation de la structure, sinon il sera impossible de l'utiliser dans des templates, tels que std::unique_ptr. Ou, au moins, donner au compilateur un moyen de connaître la taille de cette structure (attention à l'alignement, ici).

Je pense que le C est probablement le langage qui à la compatibilité maximale avec les autres langages, grâce à son manque de complexité. Et pourtant, ça reste loin d'être simple, de faire du code portable et efficace.

Dés lors, j'ai envie de dire que, pour que les mods fonctonnent, il "suffit" de deux choses :

1. que microsft puisse mettre un système de plugins cohérent au point pour son code C++ et
2. qu'ils fassent en sorte que ces plugins puissent être écrits dans différents langages

Entre des projets "à plugins multiples" comme peut l'être visual studio (et d'autres projets de chez eux) et l'expérience tirée de .NET en ce qui concerne la compatibilité, je ne doute pas vraiment qu'ils aient les connaissances et la capacité à résoudre ces deux points

J'aurai surtout cité le fait qu'ils maintiennent un OS depuis +20 ans, et le fait qu'ils arrivent encore à exécuter des binaires datant de w95, quand le binaire en question n'est pas trop mal écrit. Pas sûr que ce serait faisable sous linux (et je suis un linuxien développeur C++, je suis parti pris, mais de l'autre côté ).

En tout cas, la réécriture complète d'une application est vraiment l'avant dernier recours en général. Le dernier étant de changer le langage au passage, et je ne le ferai que si il ne m'est pa possible de trouver les outils nécessaires pour travailler dans l'ancien langage sur mon environnement (typiquement, du code delphi exploitant des routines win32 quand on ne dispose que d'une Debian...).
Le code originel doit vraiment être dégueu, donc, parce que le plus simple aurait été de balancer le code dans des bibliothèques tierces, potentiellement écrites dans un autre langage. Certains arrivent même à faire ça à partir d'un binaire après tout (bon, forcément, quand on à pas le source originel... je pense notamment à keeperfx). Ou alors ça doit vraiment en valoir la chandelle.

[Uther]

Oui le C++ est naturellement difficile a interfacer avec d'autres langages, mais si le programme a été pensé pour, il y a quand même moyen d'assurer l'interopérabilité, COM est typiquement le genre de techno prévue pour permettre ça.

Et pour le bibliothèques graphiques natives, Minecraft repose déjà sur LWJGL pour la 3D et le son.

[Médinoc]

Cette nouvelle version, est-elle censée être en C++ natif ou en C++/CLI?

[epsilon68]

franchement il fallait le ré-écrire car avoir le CPU à 100% et les ventilos à fond faisait que ce jeu était juste injouable.
Vivement qu'il arrive sur Mac en c++, je pourrais finalement y jouer sur ordi et pas que sur tablette.
Encore un pas, mais pourraient-ils écrire le serveur aussi en c++, parce que pocketmine est aussi une horreur (écrit en PHP)

[Uther]

T'impatiente pas trop, la version C++ de Minecraft sera probablement dédié à Windows.

[r0d]

Le code (java) de Minecraft a été beaucoup optimisé. Avec la version 1.9, on arrive presque à quelque chose d'acceptable en terme de performance.
Mais il y a des erreurs de design qui limitent les optimisations possible. Notamment sur la gestion des events (communication client serveur).

Il est tout à fait possible d'implémenter un serveur Minecraft dans n'importe quel langage, puisque le client et le serveur communiquent par le réseau, et selon un protocole spécifique inventé par Notch, donc totalement indépendant des langages de programmation.

Mais comme il a été dit, le problème c'est les mods. Aujourd'hui plus personne ne joue à Minecraft sans mod. Même les serveurs dits "vanilla" utilisent les mods classiques pour le claim, les privilèges, etc.

La plupart des mods sont écrits par des développeurs non professionnels. Je ne crois pas que la majorité d'entre eux seraient partant pour réécrire leur mod en c++.
Implémenter une API qui permette à un noyau c++ d'utiliser des mods écrits en java me parait trop compliqué pour une usine à gaz comme Minecraft. Et puis créer une API de modding pour un studio de développement n'est pas qu'un problème technique. C'est un problème très compliqué, il y a énormément de choses à prendre en compte. Regardez le bordel qu'il y a avec les mods pour Factorio par exemple.

Bref, à mon avis, ce qui va se passer, c'est que un clone de Minecraft va s'imposer et le remplacer bientôt. La liste des prétendants s'agrandit de jour en jour. Fortresscraft, cubeworld, portal knights, castle story, starmade, ...., et le petit dernier (cocorico!) mais non le moindre, stellar overload.