tiens lis ça et ensuite re-lis ta phrase
http://www.commentcamarche.net/contents/617-les-langages-informatiques

" Je l'ai arrêté uniquement parce que plus le temps "

Avoue que t'avais aussi foiré l'architecture de ton code et que ça devenait trop dur de faire évoluer le jeu.

Genre t'as sûrement fait tenir le jeu dans un main d'une centaine de milliers de lignes.

• unity_user Voir le profil de unity_user

* Posté le 25 janvier 2014 à 23:25:23 Avertir un administrateur
* tiens lis ça et ensuite re-lis ta phrase
http://www.commentcamarche.net/contents/617-les-langages-informatiques

C'est un article qui explique ce qu'est un langage de programmation, mais bien sûr, je vais lire ça, genre j'en ai besoin.

"Avoue que t'avais aussi foiré l'architecture de ton code et que ça devenait trop dur de faire évoluer le jeu. "

Non, uniquement le PALTAN, quelquefois je pleure si fort en repensant à ce projet prometteur.

Histoire de déverser de l'essence sur le feu, je souhaiterais rebondir sur quelque chose dit précédemment :

"Mieux, en langage assembleur coder par vous meme !

Ca a pas de sens, voyons !!"

J'ai là un jeu, voxelstein 3D : http://www.ddams.com/FR/44-Voxelstein-3D.html

Dans lequel tout est matière, tout est destructible. TOUT

Car tout est en voxels. Et le moteur utilisé pour afficher ces voxels n'est pas celui de minecraft, non, c'est quelque chose codé avec une écrasante majorité d'assembleur, car il n'y avait pas vraiment moyen de faire autrement... En 2008.

Y a un moment où il faut sortir des petits canevas préconfigurés des moteurs du marché, des langages qui mâchent le travail, si on veut essayer de se démarquer.

"Y a un moment où il faut sortir des petits canevas préconfigurés des moteurs du marché, des langages qui mâchent le travail, si on veut essayer de se démarquer."

ya bien d'autres moyen de se démarquer comme un univers graphique unique, un gameplay original, une sénario prenant

Et en gros tu dis que quand on peut pas faire avec Unity il faut faire autrement, oui et en quoi ça argumente sur le fait que quand on PEUT faire avec Unity on devrait faire autrement ?

"ya bien d'autres moyen de se démarquer comme un univers graphique unique, un gameplay original, une sénario prenant "

Pff, c'est tellement mainstream de se démarquer comme ça, de nos jours, surtout que plus personne ne le fait, le JV est actuellement bloqué dans le post-apocalyptique, quoique je crois qu'on passe, lentement mais sûrement, aux zombies, c'est la porte à côté cela dit.

"oui et en quoi ça argumente sur le fait que quand on PEUT faire avec Unity on devrait faire autrement ? "

Et bien, pour des raisons de licence d'abord, de compatibilité ensuite, de pérennité après, et de fierté enfin.

Question d'opinion, je ne serais personnellement pas fier de pondre une horreur sous prétexte que j'ai tout fait moi même

De toute façon sur le produit fini, l'utilisateur lambda ne voit pas la différence entre un jeu fait avec un moteur et un autre à partir de rien.

On a d'un côté un jeu codé en C++ from scratch, avec un code bordélique au possible, des sprites moches, un gameplay bridé par le manque de capacités. De l'autre un jeu plus ou moins abouti et présentable, dont le gameplay sera néanmoins bridé par les capacités du moteur.
Je pense que la fierté ce sera d'avoir réussi à mener un projet à son terme au lieu de rester coincé au bout d'une semaine...

Peu de gens ont le temps et surtout les compétences nécessaires pour pouvoir faire un jeu de a à z. Heureusement qu'il existe des solutions pour permettre aux gens d'en créer facilement

J'ai là un jeu, voxelstein 3D : http://www.ddams.com/FR/44-Voxelstein-3D.html

Dans lequel tout est matière, tout est destructible. TOUT

Car tout est en voxels. Et le moteur utilisé pour afficher ces voxels n'est pas celui de minecraft, non, c'est quelque chose codé avec une écrasante majorité d'assembleur, car il n'y avait pas vraiment moyen de faire autrement... En 2008

Ok, bien d'avoir codé tout cela en assembleur ? Bien qu'il soit bloqué sur TOUTES les machines qui ne peuvent pas comprendre son langage assembleur.
Si on code pas en assembleur la majorité du temps, c'est pour plusieurs raison évidentes.

On peut faire du voxel sur Unity.

Tu veux cracher sur le moteur, c'est cool. Mais tu manques TELLEMENT d'arguments que je n'ai pas a débattre.

Si tu veux faire un jeu AAA, fais ton moteur ou ... OH WAIT tu achète un moteur fait ou utilisé par ton entreprise. Quelle surprise !

Surtout que l'argument de la fierté...

Ahhh, ce débat n'est pas pour moi, c'est pourquoi je me retire.

Bonne chance, bon débat et bonne soirée.

"On a d'un côté un jeu codé en C++ from scratch, avec un code bordélique au possible, des sprites moches, un gameplay bridé par le manque de capacités. De l'autre un jeu plus ou moins abouti et présentable, dont le gameplay sera néanmoins bridé par les capacités du moteur."

Je ne sais pas si on peut se permettre d'etre aussi binaire que ça. Je suis sûr que les utilisateurs de jeu mobile seraient dans cette optique là mais faut-il passer le C++ a la trappe pour autant? Bien qu'unity remplisse potentiellement 90% des usages de développement multimédia qu'on peut faire, et que ce pourcentage ne cesse de grimper, je pense qu'il est dangereux de se livrer a corps perdu dans ce logiciel ou de raboter ses ambitions pour rentrer dans le cadre d'utilisation et je m'inquiète pour la perennité de mes projets. Les moteurs trop envahissants sont bien plus soumis aux aléas de l'existence d'une entreprise/de technologies et un moteur comme unity me donne l'impression de devoir me forcer a me dépécher et, globalement, a rester dans un cadre d'ou je ne pourrais pas vraiment sortir. C'est une forme d'aliénation comme une autre, dira t'on. je me sert beaucoup d'unity pour des petit projets de prototypage qui m'intéressent moyennement mais pour mes plus gros projets, c'est de l'opensource only, comme ça j'ai la paix et ça m'a souvent été utile de pouvoir modifier un moteur comme il me plait, même si il est frustrant de se rendre compte qu'on galère a coder quelque chose fourni de base dans un autre moteur.

"On peut faire du voxel sur Unity. "

Pas assez pour faire des voxelstein 3D, apparament... Déjà que c'est un miracle d'obtenir des clones de minecraft qui ne rament pas trop.

"Tu veux cracher sur le moteur, c'est cool. Mais tu manques TELLEMENT d'arguments que je n'ai pas a débattre. "

C'est toi qui refuses de les regarder, je crois.

Enfaite le problème vient surtout du fait que beaucoup de programmeurs pensent qu'ils ont plus de mérite d'avoir crée un jeu from scratch que ceux qui l'ont fait avec un moteur,alors que c'est complètement faux puisque peu importe comment tu l'a crée,l'importe est de réussir à le faire.

Si le jeu vidéo était resté dans cette mentalité tous les modélisateurs/concept artist/compositeurs n'auraient jamais pu un jour créer un jeu vidéo,et là où le programmeur réussit à avoir pleins de scripts qui fonctionnent,il n'aura jamais un jeu d'une qualité visuelle similaire au jeu de l'artiste,ou encore du compositeur,et c'est valide dans tous les cas et métiers .

En ce qui concerne l'asset store,je pense que c'est la plus grande invention qu'on a jamais vu pour un moteur de jeu,parceque pour une fois tout le monde peut combler les manquements de son projet grâce à divers assets,que ce soit Terrain Composer pour créer des terrains de plusieurs KM,Instant OC pour une OC hyper réactive et avancé par rapport à celle de base,Skyshop pour crée des rendus similaires à Toolbag,Amplify texture pour stocker plusieurs centaines de GB de textures sans la moindre latence dans Unity,Shader Forge pour créer ses shaders à partir de nodes,Final IK,UFPS,etc....

Bref,tous tes soucis peuvent être réglés sur l'asset store.Si tu es programmeur et que tu n'arrive pas à trouver un modélisateur,l'asset store fera ton bonheur,si tu es modélisateur et que tu n'arrive pas à trouver un outil de shaders artist friendly,shader forge est là,etc...

Unity a été développé pour des jeux mobile,mais aujourd'hui il peut aller bien au delà :

http://survivetheforest.com/

Ah et,l'auteur à la base se dit que le moteur est limité si on veux faire quelque chose de poussé,et pourtant avec du travail et de la persévérance aucun moteur n'est limité,l'utilisateur si par contre,et biensur il se dit que c'est la faute du moteur

"et pourtant avec du travail et de la persévérance aucun moteur n'est limité"

On ne peut pas, a ma connaissance, charger de texture de plus de 4k dans unity, il veut pas charger mes modèles de 500000 polygones, il semble que sa consommation assez délirante de ram pose problème pour une publication lorsqu'il atteint la limite de 2GB de ram alloué pour un processus 32 bits, il n'existe pas sous linux.. Des limitations quasi incontournables, ça se trouve facilement.

Toutes ces "limites" peuvent être réglés soit par un plugin soit par le code source que tu peux obtenir source code auprès d'UT si tu es prêt à payer,mais dans tous les cas ça reviendra toujours moins cher que de devoir créer un moteur comme Unity .

Et puis,si les gens commencent de plus en plus à ce tourner vers ce genre de solutions,c'est parceque les moteurs open-source ne valent plus la peine depuis qu'Unity,UDK et CE sont sortie.Pourquoi moi,modélisateur 3D,vais-je me torturer à travailler sur une horreur comme OGRE alors qu'Unity est fait pour moi,modélisateur ?

PS : En ce qui concerne le voxel il existe des tas de solutions,faut juste savoir les trouver :

https://www.assetstore.unity3d.com/#/content/9180

Je ne sais pas si il est aussi complet que Voxelstein,mais il n'est pas le seul outil de voxel et la majorité d'entre eux s'améliorer de jours en jours .

En fait, le voxel originel est un mode de rendu qui n'utilise pas openGL mais une sorte de lancé de rayon très optimisé, et faire des cubes (ou marching cubes) avec douze triangles pour otenir un rendu volumétrique est un gaspillage délirant de ressources. Ce que disait caelacanthe c'est surtout qu'avec unity tu pourra difficilement faire un autre mode de rendu que du rasterisé. Pourtant des techniques intéressantes commencent a arriver comme le path-tracing, bien qu'elles soient effroyablement lourdes.

Quand a ogre, non, ce n'est pas une horreur. Il est difficile a utiliser mais c'est l'un des meilleur moteur opensource existant en terme de workflow et de robustesse. Comme je l'ai dit, le problème ce n'est pas simplement d'avoir des fonctionnalités disponibles. Si les gens continuent d'utiliser de l'opensource, c'est entre autre parce que c'est souvent gratuit (et tout le monde n'est pas emprisonné dans une optique de rentabilité a court terme permanente) mais aussi parce que les licences sont plus permissives, ou que la dynamique de la communauté leur plait, qu'on ne dépend pas du bon vouloir de la maison mère, et que ça soutiens l'existence d'alternatives a du logiciel propriétaire et privatif, et dieu sait que ce genre de problématique peut avoir son importance. Après je veut bien admettre qu'en tant que modélisateur 3D ça te concerne pas trop (après je déplore a quel point ce milieu est dépendant de materiel hors de prix et de logiciels effroyablement chers, qui fait qu'ils se livrent souvent au piratage). Je reste persuadé que laisser les trois gros moteurs avoir le monopole est potentiellement néfaste.

Je reste persuadé que laisser les trois gros moteurs avoir le monopole est potentiellement néfaste.

J'ai dit que je vous laissais la parole, mais faut que je revienne sur cette phrase.

C'est complétement vrai cette partie mais ce n'est pas sur quoi on se bat, je pense, avec l'auteur. Sinon y'aurais pas de discussion et le topic serait clos depuis

" Je reste persuadé que laisser les trois gros moteurs avoir le monopole est potentiellement néfaste. "

Si ces moteurs ont le monopole aujourd'hui,c'est parcequ'ils sont plus "complets" qu'OGRE,je veux dire,combien d'années il te faut pour créer un FPS sur OGRE,et combien il t'en faut sur UDK ?

Plusieurs facteurs importants ont fait que ces trois moteurs ont aujourd'hui le monopole,d'abord parceque graphiquement ils sont plus poussés,techniquement plus facile à prendre en main,comme ça les artistes pourront mieux vous aider à mettre leur touche dans le jeu,et enfin il y'a le fait que les moteurs comme Unity sont très très complets SI tu sais t'en servir,l'asset store est un exemple pour montrer aux gens à quel point le moteur peut être poussé.

Combien de temps il te faut pour créer ce screenshot dans OGRE ?

http://i.imgur.com/XHEZ5.jpg

http://media.moddb.com/images/articles/1/100/99438/auto/Forbidden_Lands_CE3_17.jpg

Si c'est une seule personne,je doute qu'une décennie puisse suffire .

Les moteurs Open-Source sont pour la majorité exclusivement réservés aux programmeurs,les artistes ont juste à passer les modèles+textures et le programmeur se charge du reste,et perso je pense que ce procédé est beaucoup plus néfaste au JV puisqu'on se limite à une seule personne/poste pour faire une grande partie du travail .

Je reviens et je vois un gros défouloir... Pourtant je me suis excusé de ma remarque en première page, pas besoin de m'agresser j'ai compris mon erreur

Vous êtes pas gentil

Sans vouloir trop m'étendre sur le débat "Ogre vs autres moteurs" je crois qu'ils n'ont juste pas la même utilisation. Ogre est plus un wrapper d'API graphiques je trouve, ce qui te permet de faire un équivalent DirectX/OpenGL selon la plateforme sans t'empêcher de coder ton jeu de manière assez bas niveau.

Et pour ce qui est du débat "moteurs vs from scratch", il n'a pas lieu d'être puisque les deux remplissent juste des utilisations différentes.

Il peut être recommandé d'utiliser un moteur lorsqu'on n'a pas la possibilité de tout recoder soi-même, et c'est compréhensible. Il serait beaucoup plus fastidieux de vouloir se lancer dans un projet d'envergure professionnelle sans ces outils.

Cependant certains jeux vidéo ont comme caractéristique d'être des programmes informatique amenés à repousser continuellement les possibilités de la machine, et c'est dans ce soucis d'optimisation qu'il est parfois nécessaire de comprendre absolument tout ce que le programme entreprend (et c'est loin d'être le cas avec un moteur). Les moteurs tendent à évoluer vers des modèles très optimisés mais peuvent ne pas être 100% optimisés pour votre jeu, parce qu'il est difficile pour les devs de prévoir tous les cas et de laisser une infinité de configuration.

Ah et pour finir, je trouve qu'il est important de commencer par des projets "from scratch". Pas forcément des projets démesurés mais des projets qui facilitent la compréhension du bas niveau. Parce qu'on sera tous d'accord sur le fait qu'Unity et autres sont très pratiques parce que plus haut niveau, mais apprendre à utiliser un moteur vous apprend à utiliser des fonctionnalités et pas forcément les comprendre.