Voir la version complète : Choix de langage de programmation
Khornichon
24/01/2014, 16h54
Coin coin tout le monde :),
(Je ne sais pas si il y a un topic dédié aux questions, je n'en ai pas trouvé alors si il existe je laisse le soin aux modos de déplacer ce topic.)
Voila ma situation :
Je me dirige vers une période où je vais avoir pas mal de temps à ma disposition et je souhaite depuis un moment me remettre à mon plaisir d'adolescence : La programmation.
Le projet plus général serait de réaliser, à terme, un petit jeu de gestion avec une interface 3D (un peu à la simcity ou tropico. Je sais, ca fait un gros projet pour commencer mais je ne suis pas pressé ^_^).
Mes connaissances actuelles sont limitées (voir très basiques ) mais j'ai déja une bonne connaissance du fonctionnement des portes logiques, du fonctionnement des boucles et de la structure d'un programme (déclaration, initialisation etc.) et je suis rempli d'une bonne dose de motivation.
J'ai déja commencé à apprendre via le cours du site du zero dédié au C++ (que je trouve très bien fait) en me disant que ca pouvait pas etre mal d'avoir de bonne base dans ce langage.
Et puis, en voyant le temps (et la compléxité) que demanderait de réaliser un moteur 3D maison et curieux de voir ce qui existait de "tout prêt", je me suis dirigé vers UNITY.
Et là, j'ai pris une grosse claque. :O
Le Hic, c'est qu'UNITY dans sa version gratuite ne gère pas le C++ dans ses script mais seulement le CNET ou le java...
Ma question est donc simple :
Est il judicieux que je poursuivre un apprentissage qui s'annonce long sur un langage dont je ne pourrai pas me servir pour réaliser mon projet final, du moins si je choisi de prendre UNITY comme moteur 3D ou devrais je commencer par apprendre le java ou CNET quite à regretter mon choix par la suite :tired:?
Voila pour la situation... Merci d'avance pour les réponses.
Alors, avec Unity tu peux programmer qu'en C# ou en Javascript et non Java (c'est pas du tout la même chose), ensuite, je te conseillerai de programmer des petits jeu à la main en C++ (avec SDL par exemple) histoire de te faire la main.
Pratiquement entièrement d'accord avec war-p:
1) Commencer petit est vraiment nécessaire. Genre Pong, puis Tetris.
La raison : tu vas forcément faire des erreurs, notamment d'architecture. Commencer petit permet de les faire, de les détecter, et de les résoudre à un niveau gérable.
2) Le langage initial est pas très important. C++, Java et C# sont assez proches (orientés objets).
Si tu veux faciliter la transition petits projet -> gros projet, tu peux commencer avec le langage que tu penses avoir pour le gros (ici, C# pour Unity), mais même s'il y a une différence, tu devras bosser genre 1 mois pour te mettre à niveau, pas 1 an ou 2.
La programmation OO, l'architecture sera le plus gros de l'acquisition des connaissances, et c'est (quasiment) communs à ces 3 langages.
3) Réaliser ton propre moteur 3D : Non. Oublie.
Black Wolf
24/01/2014, 20h48
De toute façon rien n'est perdu. Si tu connais le C++ tu passera relativement facilement au C#, le C# simplifiant plus les choses qu'il ne les complique par rapport au C++. Donc pourquoi pas te lancer déjà dans quelques tutoriaux C++/SDL comme suggéré ci-dessus si c'est ce qu'il te plait, pour bien comprendre les principes de la programmation, puis retenter unity une fois que t'as les bases. Genre fait un mini jeu, puis reproduis-le ensuite dans Unity. La philosophie de travail et l'organisation de ton projet seront quand même bien différentes, mais tu te rendra bien compte de tout ce qu'il fait pour te simplifier la vie et comment en tirer parti.
Si tu te lances dans Unity je te conseille plutôt le C# que le javascript, pas mal de tutoriaux et d'addons sont plutôt basés sur le C# que le js. Par contre il ne s'agit pas d'une limitation de la version gratuite, c'est pareil pour la version pro à la seule différence que tu peux appeler des DLL écrites en C++ depuis ton code C# (à noter quand même que ce n'est pas "fait pour", tu ne développes pas ton jeu en C++ tu fais juste appel à certaines fonctions, généralement qui se rapportent à ton OS et trop "bas niveau" pour qu'Unity les expose de lui même).
Khornichon
25/01/2014, 09h47
Merci pour les réponses,
Je vais suivre vos sages conseils et poursuivre l'apprentissage en C++ et découvrir SDL. Une fois que j'aurais réalisé quelques petites applications je m'orienterai vers un moteur 3D gratuit. Ça me parait en effet beaucoup plus raisonnable :)
En C++, la SFML est bien sympa aussi, écrite en C++ sur un modèle objet.
Humf je comprends pas le raisonnement ?!
Si ton but c'est de réaliser un ptit jeux,sur Unity par exemple, autant que tu passes directement à l'apprentissage du C# et/ou javascript.Y'a plein de tuto sur le net, des tuto generalistes ou des tuto orientés jeux videos, donc bon..autant en profiter !
Je suis assez d'accord, surtout que tu peux utiliser SFML en C#.
Khornichon
26/01/2014, 21h38
Je me dis qu'il vaut mieux commencer par un langage plutôt complexe pour me faire la main puis une fois celui ci maitrisé (au moins de bonnes bases), apprendre celui qui me servira dans mon projet. Parce que là je parle d'unity mais après avoir regardé, il y en a plein d'autre (cryengine, unreal..) qui eux, gèrent le C++. C'est peut être une fausse idée que je me fais mais avec les cours que j'ai commencé à prendre, j'ai l'impression que les possibilités du C++ sont vraiment intéressantes dans le sens ou tu peux vraiment tout contrôler (mémoire, input etc.) Bref, on verra bien ou tout ça me mène.
Sahnvour
26/01/2014, 23h51
Unity n'est pas à mettre dans le même sac que CryEngine ou UE3. Il est beaucoup plus adapté aux amateurs (avec sa version gratuite) et le fait qu'il ne gère pas le C++ n'est pas un inconvénient.
Apprendre le C++ c'est une bonne idée, il faut juste garder à l'esprit que tu devras te taper des cours sur le langage (comme pour tous vous me direz) un certain temps avant d'avoir la possibilité de faire un petit jeu qui te plaise.
Pour son apprentissage je sais pas si le cours d'openclassrooms est bien (ni gardé à jour), et il vaudrait mieux commencer dans un environnement C++11 pour profiter de toutes les nouvelles features. Si t'es motivé je pense que le bouquin "A Tour of C++" par le créateur du langage est une bonne ressource si tu n'a pas de problème avec l'anglais (il est en pdf ici (http://isocpp.org/tour), je sais pas si c'est la version finale/complète).
Et sinon SFML c'est bien :)
Alors je lis le titre du thread, puis le debut du message et je me retrouve face a un probleme : souhaites tu apprendre a programmer, ou souhaites tu faire un jeu ? En fait, ce n'est pas un probleme, parce que la question du "choix de langage de programmation" n'a pas de sens au niveau ou tu sembles etre (debutant-debutant). Pire que ca, je dirais qu'attaquer du cpp direct c'est se rajouter des contraintes debiles.
Tu souhaites apprendre a programmer, pour pouvoir programmer ? Fais toi un compte sur CodeCademy ( http://www.codecademy.com/ ), fais du python, du ruby, apprends les bases. Les bases c'est pas seulement faire un for ou un switch. C'est piger la difference entre plusieurs data structures, les types, savoir ce qu'est une liste ou un hashset, un dictionary et un array, un structure, etc. Tu veux apprendre a programmer ? Apprends a programmer avec un langage simple. Il faut que tu empruntes le "path of least resistance" (vous m'excuserez l'anglicisme, j'arrive pas a trouver d'expression equivalente tout de suite la comme ca). Quand tu pigeras vraiment ce que tu fais, que tu connaitras au dela des principes des langages et de l'algorithmie (qu'est ce qu'un package, une lib, etc etc) la tu pourras te dire que tu sais un peu programmer.
Tu souhaites faire un jeu ? Fais un jeu. Chope GameMaker, Scirra Construct, Twine, AGS, Flash, whatever. Programmer ? C'est accessoire, tu apprendras au passage. Ton objectif c'est de faire ton jeu pas vrai ? Fais ton jeu. Mais surtout, SURTOUT, ne te dis pas : je vais faire mon moteur pour faire mon jeu. Tu veux faire ton jeu : fais ton jeu. (Je pourrais l'ecrire plusieurs fois encore mais ca deviendrait lourd non ?). Ne te dis pas "Je vais apprendre le C++, et faire mon jeu en parallele avec cette lib, et bliblablou" et partir dans des delires du genre "comment je charge mes sprites ? mes modeles ? comment je joue une animation ? Comment je joue un son ? Comment j'arrete un son ? Combien de sons je joue en meme temps ? Merde, et l'interface ? Je detecte comment l'interaction clavier/souris ? Et mes fenetres de reporting, il faut qu'elles soient dynamiques et gerent differentes villes ?". Si tu ne sais pas la tout de suite me repondre avec une solution technique, je te conseille de prendre un truc tout pret avec une grosse communaute existante, des gens qui on deja fait face a ces problemes avant. Et surtout, tu seras en train de faire ton jeu, et pas a perdre du temps a consommer ta motivation dans des etapes preparatoires chiantes.
Ah oui, si, dernier : commencer par des petits jeux. Pleins. Pleinpleinpleinplein.
Alors je lis le titre du thread, puis le debut du message et je me retrouve face a un probleme : souhaites tu apprendre a programmer, ou souhaites tu faire un jeu ? En fait, ce n'est pas un probleme, parce que la question du "choix de langage de programmation" n'a pas de sens au niveau ou tu sembles etre (debutant-debutant). Pire que ca, je dirais qu'attaquer du cpp direct c'est se rajouter des contraintes debiles.
Tu souhaites apprendre a programmer, pour pouvoir programmer ? Fais toi un compte sur CodeCademy ( http://www.codecademy.com/ ), fais du python, du ruby, apprends les bases. Les bases c'est pas seulement faire un for ou un switch. C'est piger la difference entre plusieurs data structures, les types, savoir ce qu'est une liste ou un hashset, un dictionary et un array, un structure, etc. Tu veux apprendre a programmer ? Apprends a programmer avec un langage simple. Il faut que tu empruntes le "path of least resistance" (vous m'excuserez l'anglicisme, j'arrive pas a trouver d'expression equivalente tout de suite la comme ca). Quand tu pigeras vraiment ce que tu fais, que tu connaitras au dela des principes des langages et de l'algorithmie (qu'est ce qu'un package, une lib, etc etc) la tu pourras te dire que tu sais un peu programmer.
Tu souhaites faire un jeu ? Fais un jeu. Chope GameMaker, Scirra Construct, Twine, AGS, Flash, whatever. Programmer ? C'est accessoire, tu apprendras au passage. Ton objectif c'est de faire ton jeu pas vrai ? Fais ton jeu. Mais surtout, SURTOUT, ne te dis pas : je vais faire mon moteur pour faire mon jeu. Tu veux faire ton jeu : fais ton jeu. (Je pourrais l'ecrire plusieurs fois encore mais ca deviendrait lourd non ?). Ne te dis pas "Je vais apprendre le C++, et faire mon jeu en parallele avec cette lib, et bliblablou" et partir dans des delires du genre "comment je charge mes sprites ? mes modeles ? comment je joue une animation ? Comment je joue un son ? Comment j'arrete un son ? Combien de sons je joue en meme temps ? Merde, et l'interface ? Je detecte comment l'interaction clavier/souris ? Et mes fenetres de reporting, il faut qu'elles soient dynamiques et gerent differentes villes ?". Si tu ne sais pas la tout de suite me repondre avec une solution technique, je te conseille de prendre un truc tout pret avec une grosse communaute existante, des gens qui on deja fait face a ces problemes avant. Et surtout, tu seras en train de faire ton jeu, et pas a perdre du temps a consommer ta motivation dans des etapes preparatoires chiantes.
Ah oui, si, dernier : commencer par des petits jeux. Pleins. Pleinpleinpleinplein.
Voila.
Mais après vient cette question: Pourquoi tu fais du c++ ? Tu suis une filière informatique ou parce qu'on t'a conseillé d'apprendre ce langage pour développer un jeu ?
Il y a des tonnes d'outils dédiée à la réalisation d'un jeu vidéo. N'hésites pas à les utiliser (dont Construct 2, qui est un bon début à mon gout).
https://www.scirra.com/
Khornichon
27/01/2014, 18h43
Alors là, je ne m'attendais pas à autant de réponse. Merci bien pour les conseils. :)
J'ai de mon coté fait un peu le ménage dans ma tête et effectivement je me suis posé la question si c'était le code ou si c'était la réalisation du jeu qui m'attirait. La réponse est clair, c'est d’abord la logique du code qui me plait. Cet aspect de création et d'assemblage de briques de codes pour obtenir un résultat au combien gratifiant.
Bien sur mon objectif final est de réaliser, de créer quelque chose et si possible (à la fin) d'être en capacité de créer un petit jeu de gestion.
Je suis parti sur le C++ en sachant que c'est un langage complexe et en pensant de façon sans doute naïve que c'estunlangagequiesttroprapideettropbien pour faire des jeux et en plus, utilisé par la majorité des développeurs (donc autrement dit, si eux l’utilisent c'est que ça doit être bien).
En tout cas j'ai pris bonne note des liens que vous m'avez fournis et je vais aller potasser tout ça. ;)
Tomaka17
27/01/2014, 20h23
J'ai déja commencé à apprendre via le cours du site du zero dédié au C++ (que je trouve très bien fait)
Sans être méchant, en tant qu'élève tu ne peux pas savoir si un cours est bien.
Peut être qu'ils expliquent bien et tu comprends facilement, mais en l'occurrence ce cours devient dangereusement obsolète. Le C++ connaît une petite révolution depuis quelques temps, et est en train de continuer sur cette voie. Autant dans les écoles d'informatique ils sont à jour, autant ce n'est pas le cas pour les cours en ligne.
[/hors-sujet]
Sans être méchant, en tant qu'élève tu ne peux pas savoir si un cours est bien.
Peut être qu'ils expliquent bien et tu comprends facilement, mais en l'occurrence ce cours devient dangereusement obsolète. Le C++ connaît une petite révolution depuis quelques temps, et est en train de continuer sur cette voie. Autant dans les écoles d'informatique ils sont à jour, autant ce n'est pas le cas pour les cours en ligne.
[/hors-sujet]
Moi qui n'ai plus touché au C++ depuis des éons, c'est quoi la révolution que tu cites ?
Tomaka17
28/01/2014, 08h21
Le C++11, et à venir le C++14 et le C++17.
Parmi les gros trucs :
- Il est possible de déplacer des objets au lieu de les copier, ce qui signifie que tu peux par exemple passer des std::vector par valeur en paramètre de fonction sans aucun surcoût.
- std::function et les fonctions lambdas te permettent de mettre en place beaucoup plus facilement des callbacks ou de l'injection de dépendance, et augmentent le découplage.
- Les templates avec un nombre variable de paramètres et constexpr te permettent d'avoir de gros morceaux de code exécutés en compile-time, et il n'y a plus aucune raison d'utiliser les macros à part comme include guards.
- std::array (et bientôt std::dynarray) sont des wrappers autour des tableaux C. Il n'y a plus aucune raison d'utiliser les tableaux natifs du langage.
Et avec un peu de chance on devrait avoir les concepts et les modules en C++17, ce qui signifie qu'il n'y aura plus aucun intérêt à utiliser l'héritage.
De plus on a déjà quelques smart pointers, et ils vont rajouter dummy_ptr, du coup il n'y aura presque plus aucun intérêt à utiliser les pointeurs natifs du langage.
Sahnvour
28/01/2014, 10h38
C++, le seul langage qu'il faut apprendre à désapprendre :trollface:
Le C++11, et à venir le C++14 et le C++17.
Parmi les gros trucs :
- Il est possible de déplacer des objets au lieu de les copier, ce qui signifie que tu peux par exemple passer des std::vector par valeur en paramètre de fonction sans aucun surcoût.
- std::function et les fonctions lambdas te permettent de mettre en place beaucoup plus facilement des callbacks ou de l'injection de dépendance, et augmentent le découplage.
- Les templates avec un nombre variable de paramètres et constexpr te permettent d'avoir de gros morceaux de code exécutés en compile-time, et il n'y a plus aucune raison d'utiliser les macros à part comme include guards.
- std::array (et bientôt std::dynarray) sont des wrappers autour des tableaux C. Il n'y a plus aucune raison d'utiliser les tableaux natifs du langage.
Et avec un peu de chance on devrait avoir les concepts et les modules en C++17, ce qui signifie qu'il n'y aura plus aucun intérêt à utiliser l'héritage.
De plus on a déjà quelques smart pointers, et ils vont rajouter dummy_ptr, du coup il n'y aura presque plus aucun intérêt à utiliser les pointeurs natifs du langage.
J'ai rien bité, mais je te remercie pour tes explications :P
Shingo San
29/01/2014, 23h08
La question ne se pose pas : C++ !!!!
Je suis parti sur le C++ en sachant que c'est un langage complexe et en pensant de façon sans doute naïve que c'estunlangagequiesttroprapideettropbien pour faire des jeux et en plus, utilisé par la majorité des développeurs (donc autrement dit, si eux l’utilisent c'est que ça doit être bien).
Alors, les développeurs (pour PC) utilisent le C++ parce que les jeux vidéos sont des programmes dont les performances sont critiques. Cela dit, tu peux faire du jeux vidéo avec n'importe quel langage : Java (Android), Objective C (IOs), Flash (jeux du même nom), HTML/Javascript, C# (jeux basé sur Unity)... Surtout que je ne pense pas que ton jeu mette à genou une machine récente. Un des principes de la programmation, c'est "faire fonctionner un truc en 1er, puis éventuellement optimiser là où on passe trop de temps". Bref, le C++ n'est pas obligatoire (désolé Shingo) pour un amateur ou un débutant.
J'ai rien bité, mais je te remercie pour tes explications :P
En gros, le C++ vient d'avoir une mise à jour majeure (C++11) qui ajoutent pleins de fonctionnalités sympas, et qui permet de combler une partie du manque d'ergonomie (par rapport à Java et C#). Cette mise à jour majeure sera suivie d'une mineure (C++14), puis d'une majeure (C++17).
Pour le cpp dans le JV c'est surtout a cause des toolchains et des compilos filés par les consoliers. Tu pourrais tout a fait en tant que studio te dire "je vais tout coder de A a Z, et faire mon compilo Java pour Ps4" (c'est potentiellement du domaine de l'eventuellement possible), mais disons que personne n'est assez stupide pour le faire. Unity c'est une autre approche : ils buildent en natif, et la partie gameplay (les assemblies .net) sont executées sur un mono embarqué (en gros ils executent une sandbox .net dans le process du jeu et font communiquer le gameplay avec le code natif). C'est ce que faisait deja Les Sims 3 sur consoles.
Tomaka17
30/01/2014, 10h04
Un des principes de la programmation, c'est "faire fonctionner un truc en 1er, puis éventuellement optimiser là où on passe trop de temps".
Ouai mais avec bémol.
Ce principe de ne jamais optimiser en premier, ça veut dire qu'il faut par exemple écrire "a * 2" et non pas "a << 1". Le fait d'optimiser prend du temps, et rend le code difficile à lire et à comprendre et donc plus difficile à débugger. Si une fois que le jeu presque terminé tu remarques que "a * 2" bouffe beaucoup de CPU, alors tu remplaces par "a << 1".
En revanche il faut choisir dès le départ une bonne plateforme et un bon design pour ton code. Il est évident que tu ne vas pas coder en Java, puis tout recoder en C++ six mois plus tard quand tu auras remarqué que c'est trop lent. De même tu vas par exemple dès le départ utiliser des callbacks plutôt que de vérifier à chaque frame si quelque chose a bougé.
Attention avec Unity, Scirra et autres solutions propriétaires: tu seras à la merci de la politique de licence de l'éditeur, voire du destin de l'entreprise.
Un jeu peut prendre plusieurs années à développer. Pendant ce temps, l'outil peut être abandonné ou devenir trop cher, la boite peut couler... Tu risques de perdre tout ton travail.
Même avec les solutions libres, il faut faire attention à la pérennité: un langage/sdk tout nouveau tout beau peut être abandonné par ses devs.
Je te conseille d'utiliser des solutions libres et bien établies sur le marché:
- C++ et SDL ou SFML.
- Java et Playnou libgdx ou jmonkey.
- HTML5 en évitant les API trop nouvelles.
Attention avec Unity, Scirra et autres solutions propriétaires: tu seras à la merci de la politique de licence de l'éditeur, voire du destin de l'entreprise.
Un jeu peut prendre plusieurs années à développer. Pendant ce temps, l'outil peut être abandonné ou devenir trop cher, la boite peut couler... Tu risques de perdre tout ton travail.
Ouai m'enfin, quand tu payes une licence d'utilisation, tu ne le fais pas quand le projet est terminé mais plutôt au début.
Et si l'auteur de l'outil devait abandonner le projet, ce dernier reste fonctionnel mais ne recevra plus de mise à jours (officiels).
J'ai du mal à voir un outil offline qui ne doit plus fonctionner, du jour au lendemain, parce que la société a fermée. On ne parle pas d'un logiciel amateur qui nécessite une connexion à internet pour marcher.
Il faut voir la licence en détail pour ce genre de situation, mais ca m'étonnerait fortement.
Ouai m'enfin, quand tu payes une licence d'utilisation, tu ne le fais pas quand le projet est terminé mais plutôt au début.
Et si l'auteur de l'outil devait abandonner le projet, ce dernier reste fonctionnel mais ne recevra plus de mise à jours (officiels).
J'ai du mal à voir un outil offline qui ne doit plus fonctionner, du jour au lendemain, parce que la société a fermée. On ne parle pas d'un logiciel amateur qui nécessite une connexion à internet pour marcher.
Il faut voir la licence en détail pour ce genre de situation, mais ca m'étonnerait fortement.
Sur plusieurs années, tu peux avoir des mises à jour majeures des OS incompatibles avec ton logiciel. Je parle d'expérience, j'avais fait des petits jeux avec Klik And Play, ça m'étonnerais qu'ils marchent toujours sous des OS modernes. La société existe toujours, peut être que ses nouveaux produits me permettraient de récupérer mon boulot, mais je devrais sans doute repasser à la caisse :-(
Bref utiliser des outils commerciaux pour des jeux non commerciaux, ça me semble hasardeux.
Khornichon
31/01/2014, 14h13
Je poursuis mon apprentissage, j'en chie mais ca ce passe bien.
Je suis resté sur le C++ pour l'instant mais je suis toujours sur les cours de la vieille version du langage. Par contre ce qui est bien c'est que la version C++11 du cours est sortie :) donc une fois que j'aurai de bonne bases je passerai à la maj.
Un jeu peut prendre plusieurs années à développer. Pendant ce temps, l'outil peut être abandonné ou devenir trop cher, la boite peut couler... Tu risques de perdre tout ton travail.
Même avec les solutions libres, il faut faire attention à la pérennité: un langage/sdk tout nouveau tout beau peut être abandonné par ses devs.
Je te conseille d'utiliser des solutions libres et bien établies sur le marché:
Sage conseil en effet.
Tomaka17
31/01/2014, 14h20
D'habitude je suis fanatique du C++. Si tu parcours le topic de la programmation tu verras que 80 % de mes posts sont à propos du C++.
Mais tu peux pas coder un jeu en C++ sans avoir accumulé de l'expérience le langage, c'est impossible.
C'est comme vouloir fabriquer une télévision en découvrant l'électronique, ou vouloir écrire une oeuvre littéraire dans une langue que tu ne connais pas.
En fait, je vais traduire Khornichon, le prend pas mal, mais ta question n'a aucun sens. En général tu choisis une techno en fonction de tes préférences, et tu fais pas l'inverse.
En revanche il faut choisir dès le départ une bonne plateforme et un bon design pour ton code. Il est évident que tu ne vas pas coder en Java, puis tout recoder en C++ six mois plus tard quand tu auras remarqué que c'est trop lent. De même tu vas par exemple dès le départ utiliser des callbacks plutôt que de vérifier à chaque frame si quelque chose a bougé.
Pour le design, il faut évidemment choisir une bonne archi ; mais l'avantage de ne pas trop optimiser est justement de garder une structure aussi aisée que possible à modifier. Bref, je pense qu'on est d'accord, même si je suis passé un peu rapidement.
Pour le langage, en revanche : s'apercevoir que le langage Java est trop lent ne lui arrivera pas. Il fait un jeu amateur (donc probablement pas très gourmand), sur du PC (donc pas de limitation comme les consoles). A moins de partir sur un RTS visant le millier d'unité à l'écran ET faire en Flash ou Javascript, il peut partir sur ce qu'il veut : le Java est devenu assez rapide pour qu'un peu d'optimisation au bon endroit résolve tes soucis. Ex: Minecraft.
Mais tu peux pas coder un jeu en C++ sans avoir accumulé de l'expérience le langage, c'est impossible.
C'est comme vouloir fabriquer une télévision en découvrant l'électronique, ou vouloir écrire une oeuvre littéraire dans une langue que tu ne connais pas.
Gros +1. Partir sur des mini-projets, suivi par des jeux simples (Pong, ...) est nécessaire avant de partir sur le RTS. Mais je crois que c'est ce que Khornichon fait.
Pour ce qui est du choix de la plate-forme : Unity est assez mature/utilisée pour que ce ne pose pas de soucis. Même s'ils plongent dans 2 ans, l'outil sera toujours utilisable (et utilisé). Sans compter les possibilités de rachats + passage éventuel en open-source (comme Qt). De plus, un projet open-source peut devenir abandonné/tomber en désuétude lui aussi. Bref, pour un projet amateur, il faut choisir selon le goût / la qualité de l'outil, le côté open-source ou pas est vraiment 2ndaire selon moi.
Attention avec Unity, Scirra et autres solutions propriétaires: tu seras à la merci de la politique de licence de l'éditeur, voire du destin de l'entreprise.
Un jeu peut prendre plusieurs années à développer. Pendant ce temps, l'outil peut être abandonné ou devenir trop cher, la boite peut couler... Tu risques de perdre tout ton travail.
Même avec les solutions libres, il faut faire attention à la pérennité: un langage/sdk tout nouveau tout beau peut être abandonné par ses devs.
Je te conseille d'utiliser des solutions libres et bien établies sur le marché:
- C++ et SDL ou SFML.
- Java et Playnou libgdx ou jmonkey.
- HTML5 en évitant les API trop nouvelles.
Il en est pas a se poser ces questions, il veut juste apprendre pour le moment.
Sur plusieurs années, tu peux avoir des mises à jour majeures des OS incompatibles avec ton logiciel. Je parle d'expérience, j'avais fait des petits jeux avec Klik And Play, ça m'étonnerais qu'ils marchent toujours sous des OS modernes. La société existe toujours, peut être que ses nouveaux produits me permettraient de récupérer mon boulot, mais je devrais sans doute repasser à la caisse :-(
Ce genre de situation touche tout: Les technologies et les systèmes de l'information évoluent constamment; Ce qui est fait aujourd'hui ne sera plus pareil dans 5 ou 10 ans. Ce qui marche maintenant ne le sera probablement plus - sans émulateur ni patch - dans un futur proche.
Alors oui, si tu utilises un outil, tu vas devoir investir une certaine somme pour suivre ses évolutions. Mais cela évite de maintenir un moteur de jeu aux évolutions du système.
Je peux comprendre qu'on peut avoir peur de cela. Mais ca arrivera malheureusement. Le développeur doit s'adapter :).
Je pense que tu veux faire marcher ton jeu sur les machines d'aujourd'hui - Pc, Console, Mobile, Windows 7 et/ou Linux. Pas sur Windows 2045 :p.
Ce principe de ne jamais optimiser en premier, ça veut dire qu'il faut par exemple écrire "a * 2" et non pas "a << 1". Le fait d'optimiser prend du temps, et rend le code difficile à lire et à comprendre et donc plus difficile à débugger. Si une fois que le jeu presque terminé tu remarques que "a * 2" bouffe beaucoup de CPU, alors tu remplaces par "a << 1".
Le décallage de bit pour diviser par 2 ^ x c'était une optimisation des années 80, maintenant tous les compilos savent gérer ce cas B)
Au final tu es passé dans ton code en cherchant des optimisations, tu as modifié ton code en pensant gagner quelque chose et tout ce que tu recoltes c'est une perte de lisibilité.
conclusion : NE JAMAIS OPTIMISER SON CODE !
ok 1 fois sur 1000 ça peut servir ;)
Sinon pour le choix du langage, je pense qu'on devrait toujours éviter C++ si on en a la possibilité !
Trop complexe, trop peu intégré (suffit de voir la différence de productivité en un dev en C++ et un en Java/Python...)
Tu veux faire ton jeu ?
- Love (http://love2d.org/) est un framework de jeu open souce et super sympa en Lua (un langage très simple, à des années lumière du C++ ^_^), une grosse communauté et une bonne doc... que demander de plus ?
- GameMaker/Unity qui proposent des outils plus haut niveau (modification des scenes en temps réel, orienté assets plutôt que code) mais qui sont proprio. L'avantage étant que tu codes des bouts de scripts plutôt que du gros code et qu'une grosse partie du dev se fait de manière graphique (et donc plus ludique et plus simple)
Dans tous les cas, t'es pas programmeur professionnel, t'es pas là pour coder un moteur de jeu AAA, t'as pas de temps à perdre, alors ne code pas en C++ !!!
(pour les trolls, sachez que je gagne ma vie en codant du C++ :p)
thogrinn
14/02/2014, 12h54
[...]"Tu veux faire ton jeu ?
- Love est un framework de jeu open souce et super sympa en Lua (un langage très simple, à des années lumière du C++ ), une grosse communauté et une bonne doc... que demander de plus ?
- GameMaker/Unity qui proposent des outils plus haut niveau (modification des scenes en temps réel, orienté assets plutôt que code) mais qui sont proprio. L'avantage étant que tu codes des bouts de scripts plutôt que du gros code et qu'une grosse partie du dev se fait de manière graphique (et donc plus ludique et plus simple)
Dans tous les cas, t'es pas programmeur professionnel, t'es pas là pour coder un moteur de jeu AAA, t'as pas de temps à perdre, alors ne code pas en C++ !!!"[...]
+1 Le LUA, génial est simple, le C# avec Unity, (même version gratuite), excellent. Et il ne faut pas oublier le HTML5 qui permet de faire pas mal de trucs sympas...et effectivement, le C++ est utilisé par les dev's sur des AAA mais quand on code à la maison pour un projet quand on débute, c'est le meilleur moyen de se dégouter de la programmation :). En plus, il y a moyen de trouver des tutos sympas !!!
http://www.developpez.com/
http://fr.openclassrooms.com/
Fouilles et "google" tes besoins, il y a tout ce qu'il faut. :)
Bon courage !
Sur plusieurs années, tu peux avoir des mises à jour majeures des OS incompatibles avec ton logiciel. Je parle d'expérience, j'avais fait des petits jeux avec Klik And Play, ça m'étonnerais qu'ils marchent toujours sous des OS modernes. La société existe toujours, peut être que ses nouveaux produits me permettraient de récupérer mon boulot, mais je devrais sans doute repasser à la caisse :-(
Bref utiliser des outils commerciaux pour des jeux non commerciaux, ça me semble hasardeux.
une anecdote amusante la dessus, c'est le Torque Game Engine.
C'etait un peu le grand oncle de Unity.
mais comme il était payant, et plutôt cher, il n'a jamais décollé et Unity et ses licences gratuites à fini de couler la boite qui le développait, garageGames.
Les droits ont été cédés à un nouveau propriétaire qui a complétement changé le modèle économique, en passant le moteur sous licence MIT et en ouvrant une boutique permettant à tous de vendre des outils/ressources payants pour le moteur exactement comme le fait Unity.
Les nouveaux devs de Torque ont bossé un bon moment à rajeunir le moteur, mais surtout à le rendre compatible android, ios et même steam OS et ça marche, la communauté se reveille ( il n'y en a jamais vraiment eu durant sa période commerciale ) et de petits studios indépendants se tournent vers lui.
Comme quoi un moteur peut parfois survivre à sa société commerciale.
Autres exemples amusant, les moteurs développés par les fans pour récupérer un jeu prisonnier de leur exploitants :
Zod Engine, qui est un remake open-source du jeu des bitmaps brothers. Codé en c++ par des fans du jeu original, permet de rééquilibrer totalement le jeu, d'ajouter des unités et même de jouer en multijoueur sur internet !
fonline, développé par un psychopathe russe, est un framework libre de droits en AngelScript qui permet de reprogrammer quasiment tout le jeu d'origine fallout/fallout2 et apporte le multijoueur ( qui est carrément un mmo en fait ). mais la, Interplay/Vivendi n'a pas été très sympa et a menacé le développeur d'attaques judiciaires.
Il y a des gens qui ne sont pas très doués pour les affaires, ça aurait pu devenir un hit comparable à DayZ.
Je pense que tu veux faire marcher ton jeu sur les machines d'aujourd'hui - Pc, Console, Mobile, Windows 7 et/ou Linux. Pas sur Windows 2045 :p.
Si justement! Mon premier jeu doit avoir environ 20 ans, si j'avais utilisé une techno portable et durable, je pourrais le remettre au goût du jour sans devoir tout réécrire.
En 2045, je pense qu'on aura toujours du C++, du Java ou du Javascript, car ces langages sont les cobols et fortran de demain :-) Je pense qu'on ne peut pas en dire de toutes les autres technos...
Conneries. "Portable et durable" tu ne te poses pas cette question. Produit un truc. Tu reflechiras a la portabilite et la durabilite quand ca tournera. L'argument original que tu evoques c'est "Utiliser des outils commerciaux pour des jeux non commerciaux c'est pas top". Je ne suis pas d'accord, du tout du tout du tout. Ton but c'est de faire un jeu ? Tu fais un jeu. Sinon si tu veux tomber dans le sweet spot ou tu choisiras l'API, le Language, et les outils qui vont bien pour faire du cross platform perenne, il faut aussi une bonne grosse dose de moule pour choisir des trucs qui avec de la chance seront la dans 20 ans.
Et au final, tu fais pas ton jeu, parce que tu passes X annees a ecrire tous les outils et le moteur pour le faire.
Conneries. "Portable et durable" tu ne te poses pas cette question. Produit un truc. Tu reflechiras a la portabilite et la durabilite quand ca tournera.
Ce n'est pas très gentil comme reproche, ni très juste, car j'en suis à mon quatrième jeu! J'en ai produit deux ni portable, ni durable (un avec une vieille version de Klik & Play, l'autre avec des appels en assembleurs...). Un peu dégoûté de ne plus pouvoir les faire tourner, je fais attention pour les nouveaux ( http://devnewton.bci.im/games/newton_adventure et http://devnewton.bci.im/games/nedetlesmaki ) à la fois en terme de technos et d'architecture.
Je pense qu'il parlait du contexte de "Khornichon" qui veut simplement faire un jeu.
Si si c'est tres juste. http://scientificninja.com/blog/write-games-not-engines (et effectivement, c'est pas tres gentil, mais je devais surement etre un peu fatigue ce jour la)
Et surtout, on est a une autre epoque. Les solutions actuelles sont plus etablies, plus perennes, et plus solides qu'il y'a quelques annees. Que tu fasses du GameMaker (tres bon soft), Construct (tres bien aussi), du SFML a la roots en C/C++, du UDK, du Unity, tu peux difficilement tomber sur un truc qui ne tournera pas dans 5 ans, voire 10. Donc libre a toi de precher "la solution durable", mais dire "Je pense qu'on ne peut pas en dire de toutes les autres technos...", je maintiens, c'est de la connerie. De la divination tout au plus.
Et surtout: c'est quoi "toutes les autres technos" ?
Tomaka17
18/02/2014, 20h50
Personnellement je flippe un peu quand je vois que Microsoft a mis la moitié de l'API win32 dans une catégorie qui s'appelle "legacy" (http://msdn.microsoft.com/en-us/library/windows/desktop/hh309470(v=vs.85).aspx).
Même s'il n'y a eu aucune annonce officielle sur le sujet, ça fait un peu "ces technologies sont désormais obsolètes" et on s'attendrait presque à ce qu'ils disent qu'une future version de Windows ne les supportera pas. D'un autre côté, ce serait méchamment casse-gueule pour eux de faire ça.
Nattefrost
19/02/2014, 02h53
Oh y a openGL aussi avec.
ID Tech 3 serait donc bientôt mort, pour de vrai? Tristesse :'(
Si si c'est tres juste. http://scientificninja.com/blog/write-games-not-engines
Tiens justement j'en parle dans mon dernier billet! http://devnewton.bci.im/fr/node/89
Et surtout, on est a une autre epoque. Les solutions actuelles sont plus etablies, plus perennes, et plus solides qu'il y'a quelques annees. Que tu fasses du GameMaker (tres bon soft), Construct (tres bien aussi), du SFML a la roots en C/C++, du UDK, du Unity, tu peux difficilement tomber sur un truc qui ne tournera pas dans 5 ans, voire 10. Donc libre a toi de precher "la solution durable", mais dire "Je pense qu'on ne peut pas en dire de toutes les autres technos...", je maintiens, c'est de la connerie. De la divination tout au plus.
Et surtout: c'est quoi "toutes les autres technos" ?
Comme je l'ai dit, avec Gamemaker, Unity ou Construct, tu es à la merci de la politique de l'éditeur. La techno peut continuer, mais avec des variations de prix ou des changements de licences.
Récemment on a vu:
- Microsoft laisser tomber XNA (qui va peut être survivre à travers Monogame heureusement pour les devs).
- la SFML sortir en version 2 en cassant complètement l'API et sans vrai guide/outil de migration.
Attention, je ne dis pas qu'il existe des solutions éternelles, mais des solutions plus durables que d'autres:
- C++ a plus de 30 ans, est toujours n'a pas de concurrents sérieux et continue à évoluer.
- la SDL a une quinzaine d'années et malgré un changement d'API récent, les devs ont pris des pincettes et documenté la façon de migrer en douceur.
- OpenGL est là depuis plus de 20 ans, mes vieux programmes tournent encore avec malgré des changements majeurs dans le monde des GPUs.
- Java approche de la vingtaine et est utilisé tellement d'entreprises qu'il ne disparaîtra jamais sans solution de migration.
- HTML5 est le plus jeune, mais basé sur de vieilles technos et est tellement déployé à travers le monde qu'on ne le verra pas abandonné non plus de sitôt.
Bref pas besoin d'être devin pour conclure qu'elles sont les technos ont duré et qui dureront :-)
Tu aimes comparer des oranges avec des echelles visiblement. D'un cote tu me sors des environnements complets (authoring tools, level editor, etc) et tu les compares a des langages ou des APIs bas niveau sur lesquelles certains sont meme construit, pour conclure "donc les APIs et les langages ils sont perennes eux". Ok, merci Captain Obvious pour cette demonstration sans veritable sens, c'etait tres interessant.
Je continue de penser que c'est un faux probleme, et que si tu veux faire ton moteur, fais ton moteur; mais ne le justifie pas en disant "je veux que mes jeux soient jouables dans 25 ans parce que j'ai eu des deconvenues avec Klik & Play", dis "je veux faire mon moteur parce que je veux tout maitriser de A a Z". Je dois etre trop pragmatique ou je dois avoir trop de projets non finis pour pouvoir comprendre ce genre d'etat d'esprit mais soit.
Je ne comprends pas trop comment l'histoire du moteur est arrivé là (surtout que regarde bien mes projets, je ne développe dans de moteur de jeu :-) ). A la base on demandait conseil sur un choix de langage, ça s'est mélangé avec les environnements et c'est normal, car dans certains produits le langage et les outils sont intégrés. Effectivement on peut avoir l'impression que je compare des choux et des carottes, mais le marché des technos de développement de jeux n'est pas simple. Bref je voulais juste dire que la pérennité est un critère de choix d'une solution à considérer au même titre les performances, la facilité d'apprentissage ou le coût.
Si ça peut te rassurer, concluons que les gens n'accordent pas tous la même importance à chaque critère et que ce n'est pas sale :-)
Tu as tout a fait raison. J'ai du encore m'egarer en chemin. Je reviendrai l'ouvrir quand j'aurais recuperer ma capacite a m'exprimer clairement ^_^
(et faut faire du C#, c'est tres bien le C#)
(et faut faire du C#, c'est tres bien le C#)
Ou pas quoi. Serieux, KSP sous Linux rame sa mère.
Ou pas quoi. Serieux, KSP sous Linux rame sa mère.
Toi aussi, 'spèce de hippie...
Ou pas quoi. Serieux, KSP sous Linux rame sa mère.
Rien a voir avec le langage. KSP c'est Unity, Unity c'est un ensemble de composants compiles nativement pour les plateformes concernees, et qui vont taper sur la bonne API en fonction de la dite plateforme (OpenGL pour mac/linux, DirectX pour Windows, OpenGL Es pour les mobiles, etc).
Si ca rame sur Linux, regarde du cote de ton fournisseur de carte graphique (AMD/nVidia), fait lui les gros yeux, et demande des drivers dignes de ce nom. Et un vrai support de l'OpenGL.
Precisions : la partie C# c'est un runtime Mono Embedded, a savoir un runtime - similaire au CLR de .Net, ou a une VM Java - qui est contenu dans le process du jeu lui meme. Les assemblies .net sont chargees dedans et une couche d'interoperabilite permet les appels aux composants natifs - ce qui permet de changer les materiaux des modeles, acceder aux rigidbodies de la physique, etc. En terme de perfs, faire tourner ca, c'est peanuts par rapport a la gestion de la physique ou le rendu. Et quelque soit le langage, un mauvais algorithme sera toujours pire qu'un mauvais runtime.
Si ca rame sur Linux, regarde du cote de ton fournisseur de carte graphique (AMD/nVidia), fait lui les gros yeux, et demande des drivers dignes de ce nom. Et un vrai support de l'OpenGL.
Merci mais je sais de quoi je parle, le problème vient bien du langage et/ou du framework.
Show me the profiler :p
Le probleme ne vient pas du langage. Le langage c'est la couche tres haut niveau. Ils pourraient ecrire leurs assemblies dans n'importe lequel de ces langages (https://en.wikipedia.org/wiki/List_of_CLI_languages), les compiler, les appeler depuis KSP que ca ne changerait rien. Le framework est un ensemble d'algorithmes et d'helpers, des API et des interfaces. Si leur implementation est foireuse, tu peux avoir un probleme, comme dans toute techno (le classique time vs space).
Je redis ce que j'ai dit plus haut. Unity c'est leur Mono embeded. C'est le meme *runtime* sur Windows, Mac et Linux. C'est le meme code, execute sur le meme Runtime d'un env a l'autre.
RE-Edit: je reflechissais au cas KSP sur le chemin du boulot, et si je ne m'abuse, c'est un jeu avec une grosse simulation de la physique, des contraintes de joints, de rigidbody et autres. C'est quoi les perfs de PhysX sur Linux ?
Last Edit: je ne joue pas a qui a raison, mais je connais assez la plateforme et la tech pour avoir de serieux doutes sur ce que tu avances. Je serais plus qu'heureux que tu m'expliques en quoi j'ai tort; ma comprehension n'en sortira que grandie. :smiley bisous & friendship:
Toi aussi, 'spèce de hippie...
We are many!
Ouais tu me connais pas... ;)
Show me the profiler :p
Le probleme ne vient pas du langage. Le langage c'est la couche tres haut niveau. Ils pourraient ecrire leurs assemblies dans n'importe lequel de ces langages (https://en.wikipedia.org/wiki/List_of_CLI_languages), les compiler, les appeler depuis KSP que ca ne changerait rien. Le framework est un ensemble d'algorithmes et d'helpers, des API et des interfaces. Si leur implementation est foireuse, tu peux avoir un probleme, comme dans toute techno (le classique time vs space).
Je redis ce que j'ai dit plus haut. Unity c'est leur Mono embeded. C'est le meme *runtime* sur Windows, Mac et Linux. C'est le meme code, execute sur le meme Runtime d'un env a l'autre.
RE-Edit: je reflechissais au cas KSP sur le chemin du boulot, et si je ne m'abuse, c'est un jeu avec une grosse simulation de la physique, des contraintes de joints, de rigidbody et autres. C'est quoi les perfs de PhysX sur Linux ?
Last Edit: je ne joue pas a qui a raison, mais je connais assez la plateforme et la tech pour avoir de serieux doutes sur ce que tu avances. Je serais plus qu'heureux que tu m'expliques en quoi j'ai tort; ma comprehension n'en sortira que grandie. :smiley bisous & friendship:
Le langage va forcément avoir un petit impact, puisqu'il va être plus ou moins simple à transcrire dans la représentation intermédiaire exécutée par le runtime. Après on est d'accord, ça reste limité. J'ai dit le C# ça pue, mais par extension j'englobe toute la CLI.
Je trolle sur la performance parce que effectivement KSP rame plus sous Linux que sous Windows (sans parler des différences de fonctionalités visuelles) et que ça me fait chier. PhysX n'est certainement pas disponible sous Linux, mais de toute manière je doute que KSP en tire parti.
Le problème vient très certainement du runtime, Mono, qui n'a rien de spécialement excitant en terme de performances. On pourra critiquer les benchs synthétiques, mais http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=csharp&lang2=java&data=u64q donne une idée des perfs relatives à d'autres langages (sous Linux).
Dernier point, mis à part des cas particuliers comme Unity qui offrent un écosystème autonome, le C# n'est pas vraiment le langage le plus populaire sur les plateformes autres que made in Microsoft. Ce qui restreint beaucoup le potentiel de portabilité (surtout à l'heure ou le jeu sous Mac, Linux et Android gagne en popularité). Tu aurais dit "Faites de l'Unity, c'est bien", j'aurais peut être rien dit, mais juste le C#... non :).
Quand je parlais de PhysX, je faisais reference au fait que Unity utilise PhysX pour la physique, et comme KSP utilise enormement de physique, bah y'a pas de secret: si l'imple PhysX linux est perrave, il ne va pas y avoir de miracle de ce cote la (same shit avec la partie graphique hein, on est d'accord).
Les microbenchmarks ca m'a toujours fait chier, mais je prends note. Pour ajouter de l'eau a ton moulin, le Mono de Unity est un peu a la bourre et ne beneficie pas des dernieres features cool (genre le nouveau GC, qui serait un gros plus). Apres, je considere qu'il n'ya pas de mauvaise tech, mais plein de mauvais programmeurs.
Apres, je viens de checker rapidos les assemblies, et ils utilisent un obfuscateur. Alors autant je peux comprendre faut proteger son code tout ca, mais obfusquer en petant le flow LibNoise qui est open source, ca genere une IL degueulasse, et j'ai beau etre optimiste, ca m'etonnerait que ca soit vraiment sympa niveaux perf de rajouter des jumps inconditionnels partout; c'est fantastique, ca faisait des annees que j'avais pas vu des goto. Alors a moins que le compilo modifie de Unity soit super youpi, j'ai l'intuition que c'est pas gratuit.
Je serais curieux de voir leur profiler en remote sur un build non obfuscated et un obfuscated. C'est pas un domaine que je maitrise vraiment l'obfuscation et son cout. Je vais aller me faire des amis, je vais leur demander sur Twitter ^_^
PS: Oh, ne vous laissez pas abuser par mon avatar. Je ne joue pas a KSP du tout, mais je suis un gros fan de l'optimisme indefectible de Jeb. Il me met de bonne humeur.
Tomaka17
20/02/2014, 22h04
Faites du C++, vous aurez pas de problème d'obfuscation :siffle:
C'est vrai. On aura tous les autres problemes. :3
Tomaka17
20/02/2014, 22h18
D'ailleurs j'ai une question con : pourquoi est-ce que les langages comme le C# ou autre ne sont pas conçus pour être compilés en bytecode (comme essaye de le faire gcj avec java) ?
Si c'est pour la portabilité c'est vraiment un argument débile.
le MSIL est l'equivalent du bytecode, mais je pense que tu fais plutot reference a la compilation AOT (Ahead of Time) qui permet de faire une compilation native du code C# vers une plateforme donnee, et donc de bypasser le Just In Time compilation (JIT). Ngen.exe permet de le faire sur plateforme windows (mais vu l'ecosysteme .Net/CLR, je vois pas vraiment l'interet sur les plateformes Windows et assimilees, sauf pour des cas de performances vraiment tres tres critiques), et le compilo Mono le propose.
C'est ce que Xamarin, qui est une societe fondee par ceux qui ont bosse sur Mono chez Novell met en avant dans ses produits. Ils ont une toolsuite complete pour target a peu pres tout ce qu'on trouve comme plateforme mobile majeure (W8, iOS, et Android). La target iOS est compilee en AOT, pour ARM.
Black Wolf
25/02/2014, 11h41
C'est bien dommage d'ailleurs que Xamarin est Unity n'arrivent pas à trouver un terrain d'entente vu que c'est eux qui détiennent les droits de Mono maintenant. C'est pour ça qu'on se traine toujours une veille version des runtime mono avec Unity. Je me demande comment ils vont s'en sortir à long terme d'ailleurs chez Unity...
Laisser leur implémentation C#/Mono dans sa version actuelle et proposer un nouveau langage en "option" ? Garder pour toujours cette vieille version ?
Nope, rien a voir. Mono reste un projet open source (le runtime est en LGPL 2). Cependant, Xamarin permet a ceux qui ne souhaitent pas redistribuer les sources modifiees sous la licence GPL de dealer une licence commerciale. Unity redistribue son implementation de Mono (https://github.com/Unity-Technologies) en accord avec la LGPL. La raison pour laquelle Unity n'a pas mis a jour le runtime Mono de Unity est simplement parce qu'ils ont modifie de facon assez lourde, et que plein de sous systemes natif dependent de ce runtime (la communication avec le runtime physx ou le rendu). Integrer les changements des dernieres versions de Mono est un processus long et difficile, et n'etait clairement pas dans les priorites de Unity. C'est la reponse qu'on lit le plus souvent dans les requetes d'integration de Mono.
(avant que je ne lise un "y'a juste a", gardez bien en tete que faire une integration de cette envergure demande de la tester avec le plus grand soin, et donc de recoder au passage les systemes impactes par un tel changement; et on parle d'un truc central, pas d'un petit bidule independant des autres. Donc oui, ca prend du temps, et pour l'instant "ca fonctionne sans probleme majeur", donc pas besoin non plus de pousser l'integration).
EDIT: Je modere mon "Nope" d'entree de post: ils ont effectivement besoin de le licencier pour les autres plateformes que les PC/Mac
EDIT2: tain c'est plus fouilli et complexe niveau licensing que ce dont je me souvenais: http://forum.unity3d.com/threads/197948-New-version-of-Mono-with-Unity-4-3-Any-additional-details-on-that/ My bad donc.
EDIT3: et donc ca me conforte dans ma position que la GPL-like c'est vraiment une licence de chie. (si vous me demandez de quel cote je penche, je suis plus WTFPL (http://en.wikipedia.org/wiki/WTFPL), et MIT BSD et assimilees)
Black Wolf
26/02/2014, 18h33
Hééé oui en effet, c'est une sacrée histoire du côté des licences le mix Mono/Xamarin maintenant, surtout pour les plateformes mobiles, et vu les prix qu'ils réclament je vois mal Unity et Xamarin trouver un accord sans faire exploser les couts de licence.
deathdigger
27/02/2014, 10h13
XNA est aussi toujours vivant, même si ce n'est plus trop microsoft qui met à jour.
Y'a par exemple XNA Refresh (https://msxna.codeplex.com/releases/view/117564) qui marche très bien (suis en train de l'utiliser pour un petit jeu). L'avantage de la plateforme .Net, c'est qu'il y'a peu de chances que MS l'abandonne, et que si jamais entre une version et une autre ton projet ne marche plus (par exemple si t'as utilisé des librairies qui sont devenues obsolètes), y'aura toujours moyen de facilement mettre à jour.
Tu peux jeter un oeil du cote de MonoGame aussi. Le but a la base etait de porter XNA sur Mono, et depuis c'est devenu un truc multiplateforme avec iOS et Android en targets
Une autre suggestion: http://www.libretro.com/
Cette API propose de faire des jeux comme si c'était des roms pour un émulateur.
Au lieu de faire un jeu autonome, on distribue une bibliothèque (dll, so...) qui sera chargé par un programme (il en existe plusieurs: Retroarch, XMBC...) qui se charge de tout: réglage de la résolution, configuration du clavier ou des manettes, sauvegarde, capture vidéo...
Je trouve cette approche géniale pour les joueurs (une seule GUI pour gérer pleins de jeux) et les développeurs (moins de boulot).
C'est encore jeune et il faut fouiller pour trouver la documentaiton, mais c'est très prometteur!
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. Tous droits réservés