Bonjour

1) Gain de temps (surtout si tu veut faire un jeu pour console).

2) Unity ne fait pas tout, comme UDK qui ne fait de base un jeu style Unreal, il faut coder, et quand on code sont gameplay c'est toujours gratifiant.

De toute facon la programmation d'un jeu passera forcément par l'utilisation de bibliotheques, et unity cest une bibliothèque

Les arguments de caelacanthe défendent enfaite la programmation d'un jeu depuis 0, sans bibliothèque

Dans l'industrie ou je bossais avant des types preferaient construire des bateaux merdiques de 0 pour avoir la "fierté" de l'avoir fait eux meme, dans 99% des cas ils le finissaient pas (4000h de travail), dans 100% des cas problemes de couple, et dans le 1% des gens qui le mettaient à l'eau le bateau etait pas franchement génial

Des types comme ca yen a dans toutes les industries, ca na rien a voir avec les jeux video c'est comment tu vois les choses caelacanthe, c'est peut etre joussif pour toi mais ca ne l'est que pour toi, personne n'en a rien a faire de la performance de faire un jeux de 0 sans bibliotheques, et certainement pas les joueurs

D'ailleurs ce qui est drole cest que dans l'industrie naval les gens avaient exactement les memes arguments : pouvoir ajouter une fonction quils estimaient génial et qu'on ne trouve pas dans les bateaux de série.
Evidement a chaque fois, ca n'en vallait pas du tout les heures de boulot en rab.

Deja finaliser un jeu avec Unity cest toujours bien plus long que prévu, comme on dit quand ta fait 90% il te reste 90%, alors la performance de le faire sans bibliotheque... "mais lol"

Rapport entre les chantiers navals et la programmation de jeux?

Et pardon, mais il y a une sérieuse différence entre faire un jeu sans rien du tout (ce qui est insane, là je présentais quelques cas extrêmes qui ont nécessité cette approche pour essayer d'éclairer des néophytes complets), en faire un avec quelques librairies à compiler soi-même, et en faire un en empilant des boîtes noires qui, quelquefois, vont même ne pas s'emboîter correctement, histoire de te casser les pieds.

même très déçu d'avoir du être assisté tout
au long de la conception.

Oui, c'est un peu comme les voiture. C'est nul d'aller acheter une voiture toute faite dans un garage. C'est tellement mieux de la construire soit même. Tellement gratifiant.
Ne soyez plus assistés, construisez vos voitures vous même!

"Ne soyez plus assistés, construisez vos voitures vous même! "

Merci pour cette autre comparaison hasardeuse, cela dit, elle dispose quand même d'un fond de vérité : s'il paraît aujourd'hui impossible de construire sa voiture soi-même, ceux qui n'ont pas peur de se salir les mains connaissent toutes les prodigieuses économies qu'on peut faire en n'allant pas dans un garage pour la réparer.

Pour les voitures un peu anciennes, certes, car les nouvelles sont tellement verrouillées que c'est presque de la locations que de les acheter, et on se retrouve vite à supplier les garages de les réparer en payant le prix qu'ils demandent, car il n'y a pas d'autres solutions... Ainsi va le logiciel, la manière dont il évolue et comment certains parviennent à dominer le marcher en rendant fashion l'idée d'en faire dépendre un maximum de studios, et en limitant les savoirs à l'utilisation du logiciel en particulier.

On nage quand même d'un extrême vers l'autre, là. Si les pro-unity commencent a verser dans "vas-y, code donc tes jeux en assembleur si t'es si fort", ça relèvera pas le niveau.

En fait, quitte a faire du hors sujet et partir dans des analogies hasardeuses, on peut évoquer l'artisanat vs la logique industrielle. L'artisanat, c'est long a faire, c'est cher, c'est pas optimisé, le résultat final n'est pas toujours le même d'un produit a l'autre... Est-ce qu'il faut pour autant tuer l'artisanat dans l'oeuf au nom de l'efficacité a tout prix?

En vrai, unity est pratique, certes, et pour les non-programmeurs c'est sûrement utile d'avoir un outil de ce genre là. Mais je ne suis pas sûr que ceux qui ne veulent pas l'utiliser soient simplement des masochistes. Je ne suis pas sûr que le calcul du "le prix d'unity représente quinze jours-homme de travail, largement moins que ce qu'il faudrait pour avoir un outil similaire" soit a prendre au pieds de la lettre et comme seule base de décision.

Moi par exemple, je déteste (et je suis une bille) en prog pure et dure.

En revanche j'adore coder et chercher comment faire telle ou telle chose directement sur un moteur.

En gros si je dois coder quelque chose qui ne se rapproche directement a aucun élément de gameplay dans mon JV, je vomis littéralement

En faite, c'est un combat open source vs non open source ?

Est-ce qu'il faut pour autant tuer l'artisanat dans l'oeuf au nom de l'efficacité a tout prix?

Personne n'a parlé de la mort de la programmation .La programmation est faite pour les programmeurs,et les moteurs de jeu pour tout le monde,programmeurs y compris .Les outils comme Unity ne sont pas comparables à un UDK/CE,parcequ'ils te donnent énormément plus de liberté par rapport aux autres moteurs de jeu,l'Asset Store en est la preuve,comme toujours j'ai envie de dire .

Unity est comme dDo ( http://quixel.se/ddo/ ),à la base on croit qu'il peut tout faire et que c'est facile,mais lorsqu'on l'utilise tel qu'il est le résultat ressemble à beaucoup trop au travail des autres personnes qui l'ont utilisé sans gratter le fond,mais dDo est très vaste et très complet.L

e plus important est de savoir s'en servir et profiter de tous nos acquis sur photoshop (prog ou modé) pour pouvoir tirer le maximum possible du plugin .Certains disaient à la sortie de dDo qu'il n'est pas pratique et n'apprends rien aux créateurs,et pourtant on a vu des scènes qui dépassent de très grandes productions n'utilisant pas dDo :

http://leveldesign.pl/wp-content/uploads/2013/09/WA_1.jpg

Les outils comme Unity (pas UDK/CE,beaucoup plus fermés ceux-là ) et dDo ont une place beaucoup plus importante que la programmation from scratch dans le jeu vidéo,parceque cette dernière limite la création de jeux vidéo aux programmeurs,ce qui n'est pas une bonne chose,pas parcequ'ils ne peuvent pas faire de bons jeux,mais parcequ'ils n'ont pas toujours le même degré de créativité que des artistes,et ces derniers ne veulent pas savoir comment OpenGL travail derrière pour donner tel résultat devant,ils veulent juste pouvoir créer leur jeu sans se casser la tête,où est le problème ? .

Ayant fait l'expérience des deux extrêmes moi même - tous faire soit même et utiliser un framework/unity - la réponse reste simple....

Pour débuter, je recommande de tout mon coeur de passer par un Framework au début. Sauf si l'auteur souhaite trifouiller le côté technique pur et sanglant, je recommande à celui qui veut faire un "jeu vidéo" d'utiliser Unity ou ses collègues (Construct, Game Maker, RPG Maker, etc etc...).

Le but d'un mec qui veut faire un jeu est de... faire un jeu. Non ? Pourquoi s’embêter à réinventer la roue alors que tous les outils sont là pour réaliser ce qu'on veut ?

Et ici, on ne parle pas d'un simple moteur qu'on peut coder du jour au lendemain, non. On ne parle pas du même "moteur" qu'on utilise sur une application web classique. En général, cela nécessite autant de temps de faire son jeu que de faire son propre moteur.
Combien de temps j'ai mis pour réaliser mon premier Shoot'em up (sous le nom d'HATU) ?
1 an, sur le temps libre.
Parmi ce temps, combien pour coder le moteur du jeu avec LWJGL (codé Java donc) ?
6 mois au moins, en prenant en compte le temps que j'ai mis pour le maintenir, l'optimiser, et tout ce qui va avec.

Cependant, la seule chose qui est bien en réalisant un moteur de jeu, de A à Z, c'est qu'on a une meilleure idée de comment pourrait fonctionner un jeu. "Pourrait", car les moteurs ne sont pas tous les mêmes: Par exemple, certains gèrent les entités d'une façon classique pendant que d'autres utilisent des composants.

Mon moteur de jeu, je l'ai maintenue durant 3 longues années. Il a même son petit moteur physique. J'en suis content du résultat mais... j'ai simplement réussi à réinventer la roue.

Du coup, j'ai préféré laisser la partie technique "pur" du jeu à ceux qui en sont vraiment pro, à ceux qui en font un métier. Aujourd'hui, je vais tâter de l'Unity. Et le luxe est que je n'ai pas besoin de tuto.

TL;DR: Si vous voulez faire un jeu, utilisez les outils qui sont déjà à disposition, ils sont là pour une certaine raison. Pour ceux qui sont des fous furieux de la technique, monter son propre moteur de jeu - qui marche - reste un bon défis. Mais un défis technique seulement.

c'est un débat stérile, car dans tous les cas (framework ou pas), il y aura de la programmation.

Un logiciel qui fait le jeu tout seul cela n'existe pas.

Et puis les programmeurs pur et dur, ils utilisent quoi pour faire de l'affichage ? OpenGl ? c'est une librairie déjà toute faite. Pour faire du son ? FMod ? Idem c'est tout fait. Dans tous les cas, les programmeurs pur et dur, ils n'existent plus.

Moi même qui fut un programmeur "assembleur", j'utilisais des routine déjà toutes faites pour jouer des modules.

Il faut toujours relativiser donc.

Donc oui c'est vexant qu'un jeu utilisant Unity soit plus beau qu'un jeu qui ne l'utilise pas, mais c'est le jeu ma pauvre lucette. Faut bosser un peu plus et monter en niveau.

J'aimerais comprendre a partir de quand on est tombé dans le délire du programmeur qui programme carrément son OS a partir de zéro juste pour se dire qu'il n'utilise rien qui n'ait pas été fait par lui.

C'est pas l'idée de Linux ??

ahah

Plus sérieusement, il y a peu, j'ai bossé sur Rasperry PI. On a utilisé un écran tactile, mais pas de driver correspondant. La solution c'était de coder le driver (!). Ben on se rends compte que cela sert super à rien et que c'est une perte de temps.

Le "bas niveau", c'est interessant, mais quand on ne fait que ça. Je ne vois aucun intérêt de faire du très bas niveau quand on fait un jeu. J'ai connu la période (pro) de la PS2 qui n'avait pas grand chose à son début. Fallait tout coder, quelle perte de temps. La qualité des jeux "de premier génération" en est la preuve.

En 1988, sur les ordis 16 bits, on avait déjà des OS sympas (des basics, du C, etc ...)
Faut remonter plus loin pour trouver des "je suis obligé de tout faire". Avant le premier DOS de microsoft par exemple. Quand on soudait les ordinateurs.

"Rho la honte, il a acheté un ordinateur tout fait, il ne l'a même pas souder lui même !!!"

Moi j'ai aussi pensé à inventer l’électricité et a planter les poteaux moi même, mais pas le temps.

Hey lapintade,

Ta quoi comme problème avec les mecs qui ont acheté un ZX81 en kit ?

T'es pas sympa avec moi là.

eheh, tu as tout mon respect !!

Moi je suis un petit joueur, j'en ai acheté un tout fait ! (l'an passé en vrai !)

Je dois le modifier au fer à souder cependant. J'aimerai avoir une sortie vidéo et pas UHF. Je suis justement en train de faire la liste des composants à acheter. Quel hasard.

D'ailleurs je me souviens très bien que dans les années 90, nous (les "vrais" programmeurs en assembleur) nous disions aux programmeurs en C que c'était des assistés !!
Cela veut dire deux choses :
- Que le débat a toujours exister et existera toujours
- Qu'on est con quand on est jeune

Et dire que maintenant ce sont les programmeurs C++ qui traitent les autres d'assistés ))

Si cela t'interesse je possède plein de doc d'origine sur l'architecture du hard et du noyau logiciel.

Plein de prog genre assembleur, forth, etc.

Et certainement en cherchant bien, pleins d'interfaces hard faites maison (genre interface centronic).

Fo juste me MP. Dès mon passage sur Paris je regarde et te dis l'etat et le stock qui me reste.

Certes, mais pour en revenir a unity vs le monde, est-ce que tout ceux qui décident de ne pas prendre unity font forcément un mauvais choix? ce qui me gêne avec unity est ce sentiment qu'on se plante forcément lorsqu'on décide de ne pas l'utiliser, peu importe le contexte. Dans une logique d'industrie c'est vrai qu'il est très intéressant mais mes développement personnels ne sont pas dirigés par des principes de temps-homme & co, mais maintenant il parait que le moteur ogre que je suis susceptible d'utiliser est "une horreur" et acheter des collections de plugins/assets sur le store est devenu une manière standard de fonctionner. Bien que j'utilise aussi unity de temps en temps, ce moteur m'a l'air d'instaurer un principe de "marche ou crève" même pour le développement amateur et c'est assez détestable.

Les joueurs, quand ils jouent à un jeu, ils s'en foutent en général que ce soit sous Unity, Cry Engine, ou le moteur de toto. Ils veulent juste jouer à un jeu.

Il faut prendre Unity&co comme des outils, pas pour une obligation. La démarche la plus intelligente est de déterminer ce que nous avons besoin pour notre jeu (d'un point de vue technique) et de prendre l'outil le plus adapté pour notre besoin.

De ce point de vue, Unity offre beaucoup de choses, en très propre, ce qui le rend très intéressant. Pour autant, il y a beaucoup de jeux commercialisés qui se font sur Game Maker (GunPoint, Hotline Miami...) ou sur des moteurs maisons.

Il n'est pas obligatoire d'être programmeur pour réaliser son jeu. Il y a des outils qui ne nécessitent pas d'apprendre un langage de programmation (Construct, RPG Maker, etc...).
Mais ca aide beaucoup (au moins, sur le principe et la théorie).