Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
En tous les cas, si il y a bien une chose dont je suis sûr à lire tes posts fleuves pour la lutte finale,
c'est que visiblement (et au delà du reste, comme la création/production de jeux y compris en indé), tu ne connais vraiment pas Unity (base du sujet au départ)
(pas sérieux quand on veut critiquer de manière constructive)
Ouais et alors ? je suis très content de ne pas être un spécialiste de unity. J'ai fait deux semaines de benchmark et de bug test avec pour tester la fiabilité du truc et c'était déjà deux semaines de trop. Et puis à l'époque où ils mettaient pleins de jeux en ligne pour se faire de la pub, ça plantait sur tellement de machines qu'ils ont préféré arrêter parce que ça leur faisait pas vraiment de la promo. Et en plus ils mendiaient des tests de debug à gauche et à droite parce qu'ils n'ont pas l'envie (ou les moyens) d'engager des testeurs, donc quand ils disent que leur truc est génial et super portable et qu'il marche sur tous les ordinateurs du monde entier, ILS MENTENT. Y'a que sur ios que ça tient la route. Quand on fait un produit qui est sensé marcher sur des tonnes de configs, ça veut dire qu'on a un budget conséquent pour se payer une tonne de testeurs et une tonne de machines, or ils n'ont même pas les moyens de leurs prétentions. C'est quoi leurs tech-demo aujourd'hui ? Ils est où leur super jeu multi-plateforme qui marche chez tous les ordinateurs du monde entier ? rien, juste des vidéos. on dirait de la com de vaporware
Dernière modification par gbdivers ; 12/11/2012 à 19h06. Motif: Pas de HS politique
tu parles de angry birds sur iphone ?Envoyé par punkcoders
ou celui sur android qui est sorti bien plus tard ?
tu connais le moteur utilisé dans angry birds ?
tout comme ton code c++ prévu pour opengl
pas d'opengl sur x360
ou ton code c# pour xna, tournera pas sur les autres consoles de salon
en fait, je pense que tu ne sais pas ce que signifie portable techniquement
ce n'est pas à la console de supporter Unity, mais plutôt à Unity de supporter la console ciblée
et quand tu dis aucune console, en dehors de la Wii, la PS3 et la xbox360, il y a quelle console à supporter pour viser plus de 90% du marché ?
moins limité que ton moteur maison à t=0
ton moteur maison, entre le moment où tu commences à coder, et le moment où il est stable (utilisable commercialement), portable sur ne serai-ce que les 3 Consoles actuelles, tu auras dépensé combien de temps et d'argent dedans ?
que viens faire Apple ici ?
ça fait partie de tes arguments anti Unity ?
en fait on ne peux pas argumenter avec toi, tu es dans ta bulle et tu craches ta rancune ou je ne sais quelle haine sans argument valable et constructif
si encore tu pesais les pour et les contre, visiblement c'est trop demander
au final, à part pourrir le sujet, tes interventions ne servent à rien
à bon entendeur
Tutoriels OpenGL
Je ne répondrai à aucune question en MP
- Si c'est simple tu dis que c'est compliqué et tu le fait
- Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.
Ceci dit ça prouve que si vous voulez travailler sur unity vous avez plutôt intérêt à être formé sur des trucs plus sérieux parce que les patrons qui veulent un scripteur unity, ils préfèrent embaucher un ingénieur qui touche sa bille en c++ plutôt qu'un codeur multimédia qui ne sait faire que du c#.
Alors si y'a des jeunes qui rêvent de se faire embaucher dans une boite qui fait du jeu pourrave unity, je leur recommande vivement de cliquer sur la petite croix de la fenêtre unity et d'ouvrir celle de visual studio.
Hrem, je voudrais pas t'apprendre ton métier hein monsieur l'ingénieur, je ne sais pas quelle est ta définition du portable mais, moi y m'semble qu'un programme portable c'est pas du tout la partie qui s'occupe de directx ou opengl et tout ce qui se passe dans la machine, ça justement c'est le bout du programme qui est pas portable du tout (et qu'on réduit au strict minimum quand on bosse proprement au lieu de pisser du code comme un goret), il me semble que la partie portable du programme c'est la couche du dessus qui ne fait que du calcul pur et qu'on va pouvoir porter dans l'environnement qu'on veut... mais ça les code source de jeux en open-source te l'expliqueront mieux que moi.tout comme ton code c++ prévu pour opengl
pas d'opengl sur x360
ou ton code c# pour xna, tournera pas sur les autres consoles de salon
en fait, je pense que tu ne sais pas ce que signifie portable techniquement
La seule chose que tu peux faire de portable avec unity c'est une lib de calcul pur que tu pourras ensuite transplanter sur xna ou java. C'est vachement large comme éventail de portabilité didonc.
Dernière modification par gbdivers ; 12/11/2012 à 19h07. Motif: Pas de HS politique
ah oui, vu comme ça, c'est sûr que c'est portable
si tu développes un moteur de jeu en ne te souciant que de la partie "calculs" en terme de portabilité, c'est pas gagné, surtout que c'est pas là où tu as le plus de boulot bien au contraire
Tutoriels OpenGL
Je ne répondrai à aucune question en MP
- Si c'est simple tu dis que c'est compliqué et tu le fait
- Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.
Ca c'est vrai pour un jeu de pong (et encore je devrais tester pour voir tiens...). Mais là on est dans le cadre des jeux amateurs, chez les amateurs la portabilité on s'en fiche pas mal et de toutes façons cette partie chiante du code on la fait sous-traiter par sfml, allegro et autres sdl.
Mais pour faire un vrai jeu, sans même aller taper dans du AAA, disons un jeu de bagnole ou de baston, hé bien c'est le contraire. Tout le gameplay est dans la partie calcul pur (en particulier la physique), et toute la logique graphique également. L'implémentation sur la couche matériel ça n'est que la toute dernière phase de la pipeline graphique et audio. Si tu t'amuses à compter dans un programme le nombre de lignes qui envoient réellement des instructions à la carte vidéo (et à la carte son), à moins d'avoir trois tonnes de shaders, ça représente pas grand chose, tu remplis tes vertbuffer et pixelbuffer au loading et puis tu traces ça avec les matrices au runtime, ça fait pas des milliers de lignes. Ben il suffit de les ranger proprement dans un coin au lieu de les éparpiller n'importe où dans un tas de boue.
Ce qui fait le jeu c'est le coeur du moteur, c'est pas le numéro de la version de directx utilisé pour tel portage. Tous les portages des vieux jeux ms-dos qu'on a fait tourner ensuite sur opengl ou directx, et sans besoin de budgets maousse, on s'est pas amusé à réecrire tout le programme, y'avait juste la toute dernière étape de la pipeline graphique/son à remplacer.
Et ça c'est vrai pour unity aussi. Tout le gros du code c'est l'interpréteur mono, le moteur de culling umbra, le moteur physique physx, et toute la phase calcul de la pipeline graphique (batching, etc) c'est là dedans qu'elle est la viande, dans les calculs, pas dans la fin de pipeline sur la dernière version de directx.
Dernière modification par punkcoders ; 12/11/2012 à 17h19.
et le systeme de fichier qui est particulier a chaque plate-forme, et le systeme de threading (donc aussi mutex et sections critiques), et l'encodage (utf-8 sous linux et ucs-2 sous windows) pour l'internationalisation, et l'input qui depend de la plate-forme mais aussi du systeme de fenetrage, sans compter que le compilateur peut etre different entre windows et linux et creer des problemes de compatibilite, et en general l'allocation memoire, puis quand on y est, comptons aussi le SSE2/3/4 different du Neon sur ARM et du
Altivec sur PowerPC, souvent utilises par les moteurs physiques dont tu parles plus haut (pourquoi tant de #define specifiques au plate-formes dans bullet?), et puis ajoutons aussi les differences entre OpenCL et DirectCompute, et si enfin on parle de Unity, on doit aussi prendre en compte le portage de Mono (runtime CIL) sur toute cette tripotee de plates-formes, y compris certaines qui interdisent le JIT
faire un jeu c'est plus complique que tu le crois apparemment, enfin je veux dire quand on en fait un pour de vrai, pas quand on en parle sur un forum.
Un point pour screech j'avoue j'ai exagéré j'ai été de mauvaise foi sur ce coup là.
Oui je sais les portages ça demande du travail, et y'a toujours besoin de bras là dedans d'ailleurs. Unity ça permet à des boîtes de se passer de ces bras là et donc ça met plein de monde au chômage donc c'est MAL.
Et oui je sais, faire des jeux c'est difficile, c'est plein de travail, c'est de la prog, et la prog c'est difficile et c'est plein de travail. Hé oui. Il faut se ligoter à sa machine et coder comme un fou au lieu d'aller à la machine à café toutes les 5 min.
Alors Unity c'est super cool pour augmenter ton timing de pauses café parce que tu peux faire des jeux sans taper la moindre ligne de code et sans rien connaître à la 3d ni à la programmation (ça doit être vachement vendeur d'avoir unity sur ton cv hihihi lol)... mais si ça vous emmerde de taper du code bah fallait faire graphiste.
(et pour la boutade à propos du com du jeunot qui s'imagine que ton métier est merveilleux et qui vient te quémander du piston avec ses gros sabots, bah je sais pas, le com est drôle, non ? enfin on peut en pleurer aussi mais je suis pas négatif à ce point)
En tout cas il est très intéressant le com de screech parce qu'il laisse entrevoir un aperçu d'aperçu d'aperçu d'aperçu (il faudrait répéter quelques milliers de fois le mot pour être exact) des compétences qu'on attend d'un developpeur de jeux:
Si vous croyez que vous allez acquérir ces compétences en faisant mumuse avec Unity bah allez-y engagez-vous...et le systeme de fichier qui est particulier a chaque plate-forme, et le systeme de threading (donc aussi mutex et sections critiques), et l'encodage (utf-8 sous linux et ucs-2 sous windows) pour l'internationalisation, et l'input qui depend de la plate-forme mais aussi du systeme de fenetrage, sans compter que le compilateur peut etre different entre windows et linux et creer des problemes de compatibilite, et en general l'allocation memoire, puis quand on y est, comptons aussi le SSE2/3/4 different du Neon sur ARM et du
Altivec sur PowerPC, souvent utilises par les moteurs physiques dont tu parles plus haut (pourquoi tant de #define specifiques au plate-formes dans bullet?), et puis ajoutons aussi les differences entre OpenCL et DirectCompute, et si enfin on parle de Unity, on doit aussi prendre en compte le portage de Mono (runtime CIL) sur toute cette tripotee de plates-formes, y compris certaines qui interdisent le JIT
Dernière modification par gbdivers ; 12/11/2012 à 19h08. Motif: Merci de ne pas utiliser un vocabulaire déplacé
Bonsoir à tous
Merci de rester dans les discussions (pseudo) techniques et de ne pas partir dans des discussions politiques.
Petite remarque pour tout ceux qui répondent. Pour faire un troll, il faut être au moins deux, celui qui troll et celui qui le nourrit.
Merci de montrer l'exemple, et sinon un troll est une discussion inutile, et, il me semble qu'apporter une voix discordante en face d'un troupeau qui bêle en choeur en faveur d'une techno controversée car arnaque à bien des points de vue, ça n'a rien d'inutile, et peut-être même que c'est salutaire.
Dans tous les débats sur les techno concurrentielles y'a des "pour" et des "contre". Là on est dans un cas étrange où bizzarement tout le monde est "pour" et où y'a pas un seul "contre"... alors on pourrait m'opposer que c'est parce que unity est une éspèce de dieu-logiciel parfait et irréprochable, mais moi je sais que c'est faux et je suis bien placé pourdégueulpour critiquer ce genre demerproduit douteux.
Pour la ribambelle de produits équivalents qui ont précédé unity (blitz et compagnie) ben moi j'ai travaillé dessus alors je sais comment ça marche.
Si personne ne cogne sur ces trucs c'est tout simplement parce que c'est des logiciels d'usage super marginal dont les défauts et les bugs sont très peu relevés, excepté par les gens qui travaillent avec, or les gens qui travaillent avec sont d'une mauvaise foi absolue parce que pour de simples raisons de survie de la bulle spéculative ils sont obligés de mentir et de faire croire que la camelote qui les fait vivre (ou dont ils comptent éventuellement vivre dans l'avenir) c'est le summum du progrès.
La différence avec Unity c'est que ses ancêtres faisaient bien gaffe de pas s'approcher trop près du feu des projecteurs... ils n'ont pas eu cette prudence chez unity et ils ont fait tellement de tapage médiatique promotionnel que ça a fini par attirer l'attention de ceux qui sont en position de dénoncer l'arnaque.
On va bien rigoler quand Unity va se casser la gueule (et plus tard ça arrivera et plus ça va mettre dans une merde noire ceux qui ont trop longtemps travaillé avec), parce que quand un midware se casse la gueule, le premier effet kiss cool c'est que ceux qui en vivaient deviennent inemployables, qu'ils sont reconvertibles nulle part parce que trop spécialisés dans un truc qui n'a plus aucune valeur, et là brutalement tous les fanboyz se transforment en antifans et se mettent à hurler la vérité en choeur et dénoncent l'interminable liste de défauts de la cochonnerie dont ils ont chanté des louanges mensongères (c'est bien fait pour eux en un sens) et ils maudissent le patron et l'équipe de la boite fabricante du midware une fois qu'elle a coulé, mais eux ils s'en fichent parce que les dev qui fabriquent le midware ils ont aucun problème de reconversion, ceux qui l'ont dans l'os c'est les users qui ont engraissé ces charlatans.
L'avenir me donnera raison.
Dernière modification par E.Bzz ; 13/11/2012 à 09h08.
@punkcoders
J'ai lu votre argumentation de long en large. Dans l'ensemble, vous avez raison, mais vous semblez oublier un détail important : Le marché des jeux vidéos ne pourrait en aucun cas "absorber" ou proposer du travail à tout les "devs" qui suivraient la filière que vous préconisez. Si les développeurs qui travaillent actuellement avec des midwares appliquaient votre conseil, combien décrocheraient un CDI (votre cheval de bataille) auprès d'entreprises spécialisées dans les jeux vidéos?
Contradiction ici : Vous auriez du conseiller un outil Open Source quelconque.Alors si y'a des jeunes qui rêvent de se faire embaucher dans une boite qui fait du jeu pourrave unity, je leur recommande vivement de cliquer sur la petite croix de la fenêtre unity et d'ouvrir celle de visual studio.
Pour ce qui est du "portable" je pense que cette discipline (développement de jeux vidéos Casual ou AAA) s'en fiche un peu : L'important est le multi-plateforme.
La release d'Unity V4 est officiellement disponible.
http://en.wikipedia.org/wiki/Bad_Piggies
Si même Rovio s'y met, il n'y a plus beaucoup de raisons de ne pas s'y mettre....
Merci pour cette citation, ma réticence à alimenter les trolls m'avait empêché de la faire lorsque j'ai parcouru cette discussion et vu Angry Birds en diagonale
Au passage, je plussois le conseil donné plus haut : si vous utilisez Unity3D, programmez en C# avec Visual Studio. Vous ferez ainsi d'une pierre deux coups et si ce n'est pas déjà le cas, vous apprendrez un langage et un IDE qui pourront vous être utile dans votre vie professionnelle.
Personnellement j'ai découvert le C# il y a 3 ans avec mon hobby Unity3D et c'est ça (le C#) qui me fait vivre (très bien) actuellement.
On vient juste d'acheter nos licences nousCa nous allège beaucoup de boulot, et j'aime beaucoup pouvoir modifier l'éditeur facilement!
Arcane's Tower defense pour toutes les plateformes !
Je comprend pasla haine là..... Si Unity te permet de réaliser ce que tu veux faire et le fait bien en moins de temps, pourquoi cracher dessus. C'est pas l'outil, le langage ou la qualité graphique qui fait un bon jeu, c'est son concept.
Même Carmack conseil aux débutants de faire du c# plutot que du c++ http://www.developpez.net/forums/d10...rp-jeux-video/, et je suis désolé si je te vexe PunkCoder, mais je fait pus confiance a Carmack qu'à toi, sauf si tu nous montre une de tes réalisation et qu'elle remet ce cher Jonh à sa place.......
Opengl ça représente rien niveau embauche.Contradiction ici : Vous auriez du conseiller un outil Open Source quelconque.
J'ai passé deux ans à étudier les sources des moteurs de Carmack et je suis formel, ce type c'est un gros bourgeois qui se la pète, c'est un dev qui se comporte comme une rockstar et je supporte pas les dev qui se comportent comme des rockstars, y'a rien d'intelligent dans ses moteurs c'est bourré d'erreurs de conception, de trucs qui coutent cher à faire pour se la jouer j'ai la plus grosse et qui n'apportent rien à part pourrir la vie à l'user à au cpu, et c'est intégralement basé sur la frime parce qu'il a chourré des trucs à l'imagerie militaire dont y'a jamais eu besoin pour faire des jeux qui tiennent la route à partir du moment où c'est fait avec un langage qui tient la route. Au final ils font que des jeux cons et moches chez id.
C'est pas la peine de causer économie de moyens pour ensuite citer le baratin d'une grosse boîte à fric qui a de la thune à foutre par la fenêtre.
Y'a des manières bien plus intelligentes et moins coûteuses que la sienne pour programmer du volume 3d mais pour ça faut un langage qui tient la route et pas du c# qui met le cpu à genoux.
Quoi tu parle du mec qui faisait de la 3d sur un 286dx2 !!!!!!!! Non c'est certain tu es très crédible
Et c# met le cpu à genoux......
Parce que je prends le parti du dev contre le commercial.
Si tu manques de moyens alors soit tu sacrifies le gouffre à fric du portage sur douze mille machines (et ça c'est la politique indé qui a donné les vrais bon jeux indé = d'abord je fais un bon programme et seulement en deuxième temps j'essaye de le vendre, parce que si mon programme est mauvais je suis sûr qu'il se vendra pas), soit t'es trop faible ou trop malhonnête pour passer par la case vache enragée et te contenter de sources de revenu moins gratifiantes en attendant (quand on veut faire l'artiste faut pas s'attendre à avoir une planque pèpère de fonctionnaire) alors t'achètes un moteur camelote au rabais.
La deuxième alternative est pensée à 100% dans l'intérêt du commercial et la première à 100% dans celle du développeur ET du public.
Moi je défends l'intérêt des développeurs et du public contre l'intérêt du commercial. Je défends l'intérêt de celui qui fabrique le produit et de celui qui l'achète, et pas l'intérêt du parasite qui achète pas cher pour revendre cher. Parce que tu peux toujours courir pour qu'un commercial défende un autre intérêt que le sien, ces gens n'ont aucune valeur morale, alors pour que le bras de fer soit en équilibre, pour se défendre face à leurs mensonges il faut être égoïste méchant calculateur et hater comme eux, mais pas menteur parce que là ça serait rouler pour leur camp.
C'est la même éthique chez les paysans qui font du bio. Si ta logique c'est de ramasser le maximum de thunes en travaillant le moins possible alors tu fais du transgénique, tu choisis la facilité. Mais la facilité c'est la logique des gens qui ne voient pas plus loin que le bout de leur nez, parce que le transgénique ça rapporte à court terme et puis ça finira tôt ou tard par un boycott.
Vendre un programme c'est pareil, tu peux prendre la clientèle pour des poires pendant un temps mais tôt ou tard ils vont s'apercevoir que tu te payes leur tête... et alors là ça fait mal, quand une bulle de buisness spéculatif se casse la gueule vaut mieux pas être en dessous.
Bon... y'a sans doute un malentendu entre nous, c'est que je m'adresse à deux catégories de gens différents:
1/ y'a ceux qui vivent de unity, ceux là tant pis ils seront dans la merde quand ça se cassera la gueule, bon mais ceux là c'est une minorité, tant pis.
2/ y'a les codeurs amateurs (ou freelance sans job la moitié du temps, c'est pareil) qui eux sont théoriquement libres mais ils n'en ont pas forcément conscience.
Moi le jv je n'en vis plus et n'ai pas spécialement envie d'en re-vivre (c'est un boulot de merde), donc je suis passé dans la catégorie 2. Donc je fais des pong en gros pixel pour windows en amateur dans mon coin avec mes copains. Donc je ne me pose plus les questions du crevard qui veut du fric tout de suite par n'importe quel moyens. Ca libère l'esprit on peut se poser des questions moins connes.
Bon donc à partir de là, je ne pourrais strictement rien faire avec unity d'un point de vue technique... j'ai besoin de pouvoir tripoter les buffers gpu au runtime et faire des calculs compliqués au runtime (voir même tripoter les pixels au runtime avec du shader en assembleur) et avec unity je pourrais pas le faire.
Bon après j'avoue que j'ai ma part de subjectivité là dedans. J'ai plus un profil de codeur graphique que de gamedev, les jeux vidéo j'en ai un peu rien à foutre au fond, ce que j'aime c'est jouer avec les pixels et les vecteurs, donc forcément unity ça m'emmerde.
Dernière modification par punkcoders ; 15/11/2012 à 17h08.
Répondre avec citation
Partager