Pourquoi ne parle t on jamais d'unity 3D ?

[niahoo]

C'est même l'inverse, mieux vaut avoir une pensée latérale assez ouverte pour se dépatouiller d'une API ben touffue et d'architectures de code un peu complexes !

[OurPleasure]

Je me suis surement mal exprimé.
Pourtant ce que je "reproche" à la discipline du code c'est que quand je bosse en tant que game designer avec un programmeur, lui il veut juste une liste définitive de ce que doit faire chaque élément à un instant T, une place P alors que je vais plutôt lui donner ces informations en expliquant aussi les relations entre tous les éléments et pourquoi l'un est issu ou interagit avec l'autre mais cela pose soucis lorsque le projet conçu est en mode prototype attendant des améliorations et donc des changement de code. C'est d'ailleurs aussi à ça que sert un proto il me semble.

C'est comme la manie du codeur à pas faire ce qui est demandé :
Tu lui donne par exemple une interface d'une partie du jeu à développer où tu précise bien pourquoi il faut que les choses soient de telle façon (cad l'impact sur le ressenti du joueur et le jeu et les réaction que cela doit engendrer).
1er retour : en général il revient avec un truc qui fait pas du tout ce que tu voulais > En fait après maintes discussion tu te rends compte qu'il n'avait pas tout lu sur le GD ... Et oui si tu explique les choses .. Et ben il s'en fiche le bougre. Donc tu lui ré-explique tout par skype ce qui te rappelle que tu as écrit ce GD juste pour ta pomme.
2eme retour : Là ça commence à ressembler à ce que tu as demandé mais pourtant c'est différent. Le résultat fonctionnel est là mais ce n'est pas ce qui est demandé.
En gros le codeur simplifie au maximum l'idée en effaçant tout ce qui te paraissait primordial pour l'impact attendu parce que apparemment, lui, il voit pas ça.
3eme retour : Le programmeur vous dit qu'on ne peut pas faire ça. Évidemment, vous ne comprenez pas parce que vous avez déjà vu la même chose. Vous partez alors faire des recherches parce que c'est important pour le jeu et vous découvrez que c'est possible. Vous présentez la solution et là vous avez 2 réponses possibles : "En fait, je sais pas faire" ou "C'est trop la galère à faire.".
4eme retour : Enfin on a réussi après 4 sessions de taf a faire ce qu'il fallait apparaissant au bon endroit et au bon moment avec tout agissant quand il faut.
Dommage que ça recommence presque à chaque fois

Je pense que c'est aussi pour ça que beaucoup de GD sont très très souvent des programmeurs. Ils sont sur la même longueur d'onde.

Ne m'en veuillez pas trop pour ce petit coup de gueule, j'ai pas envie de me fâcher avec tout les développeurs . Et j'ai peut-être un peu dévié de la discussion.
Si je devais faire une allégorie du codage, pour moi, c'est comme si l'aboutissement de la réalisation du code d'un programme était un couloir ultra-serré où mon corps pouvait à peine se faufiler et qu'il faudrait arriver à atteindre l'autre bout de ce couloir. Oui c'est pas très engageant et contraignant.

Malgré tout je suis sur que les programmeurs éprouvent beaucoup de liberté à coder mais je ne la ressens pas. C'est plutôt de la frustration par la limitation.

[SorenS]

Je pense surtout que tu n'es pas tombé sur les bonnes personnes. Ou alors que tu n'explique pas bien à ton dev peut être

[niahoo]

Ouais, c'est peut être un boulet ton "codeur" ... D'ailleurs, quelqu'un qui se définit comme "codeur" considère sa discipline comme "l'art de savoir appuyer sur un clavier pour dessiner des symboles à l'écran". On est loin du développement logiciel

Mais d'un autre côté, si tu le paie à l'heure et/ou ne l'implique pas dans la création du jeu, en gros tu lui demandes effectivement de pisser du code (ce qui n'est pas non plus désagréable comme taf) alors il te faut une spec en béton. Mais bon, d'après ce que tu dis tu est tombé sur un mec qui a pas envie de se casser la binette. Change de mec.

Si tu te sens limité par tes compétences, ne rentres pas dans le développement. C'est très chronophage et on arrive pas toujours à ce qu'on veut. Vu que tu fais déjà pas m'al d'autres trucs, c'est pas la peine de te casser le cul sur ça.

[Etienne]

Personnellement je penses que prendre un codeur comme un simple executant (ou "pisseur de code" pour reprendre l'expression de Niahoo ^^) ne mènera jamais très loin. Ce n'est que mon avis, mais il me semble qu'on aboutit forcément à genre de situation quand on est dans ce rapport : J'ai les idées -> tu as les petites mimines pour les mettres en place.

Comme dans beaucoup de domaine où l'interaction entre créatif/technique existe, le plus important reste le dialogue constructif. Car soyons clair le GDdocument sert surtout pour les GDs eux même et leurs communications, les programmeurs iront piochés l'essentiel de ce qui les intérèsses et quelques part on les comprends ^^. D'où l'intérêt du dialogue préliminaire qui va non seulement permettre au prog de comprendre la démarche (a condition qu'il soit receptif ce qui n'a pas l'air d'être le cas du tien, je te l'accorde :p) mais aussi ce qui va lui permettre de t'opposer son point de vue technique sur la chose, ce qui est faisable ou pas, ce qui est faisable autrement. C'est pour ça que comme tu le dis bien souvent les GD ont une bonne expé de prog ou du moins de la logique de prog, ça fait clairement avancer le dialogue plus vite quand on parle avec les même termes et la même logique derrière.

Voilà tout ça pour dire que j'ai un peu de mal avec la notion de programmeur sur commande comme ça, pour moi cela restera toujours plus ou moins contreproductif. Je penses pas qu'on puisse exclure le programmeur du processus créatif, il y a pas de miracles si on veut impliquer quelqu'un dans un projet, il faut qu'il sente qu'il ait un rôle à jouer autre qu'un simple traducteur.

D'ailleurs je penses que beaucoup ici ce sont tournés vers la prog avant tout par désir créatif, et que c'est le cas de nombreux progs, c'est rarement une ambition personnelle de juste vouloir être capable de sortir des lignes de codes.

[Xenos]

Le programmeur vous dit qu'on ne peut pas faire ça.

Ca, c'est faux. Tout est faisable en informatique, mais ce n'est pas toujours évident, et les "codeurs" (les mauvais) ont tendance à classer dans "pas faisable" ce qu'ils ont la flemme de faire. La seule limite est le temps: le temps de codage (souvent, une excuse pour "justifier" la flemme du codeur) et le temps de calcul.

Quant à Unity 3D, bof... Ce SDK ne m'a jamais branché, je lui ai toujours préféré NeoAxis, qui est assez similaire (sans l'ultra-cross-plateform) mais que je trouve immédiat à prendre en main, avec une démo bien fichue, souvent mis à jour, et la licence de dev contient 100% des possibilités de la licence commerciale.

Edité pour affiner ce que je souhaitait dire, merci à Ter Rowan.

[OurPleasure]

Je suis tout à fait d'accord et je n'aime pas le genre pisse-code car j'aime avoir du retour dans ce que je fais et surtout d'un dev qui a, à tout les coups, une vision opposé à la mienne. Souvent ça fait des litiges mais aussi cela fait émerger de très bonnes idées, comme dit avant, c'est constructif.

Je n'ai jamais essayé d'engager un codeur juste en tant qu’exécutant, c'est surtout certains qui n'ont tout simplement pas envie de s'investir plus loin que ça. Chose que je comprends selon le contexte (le projet ne les fait pas forcément kiffer, ils ont un emploi du temps où ils privilégient parfois autre chose, la situation personnelle etc).

Sinon, j'ai tenté de me mettre au code plusieurs fois (html, php, C++, actionscript) pour une seule et même raison : arrêter d'avoir des idées auxquelles je tiens moisir dans un de mes répertoires attendant qu'un dev avec qui ça colle du tonnerre se pointe (je connais un dev avec qui le taf est génial et avec qui je voudrais lancer des projets seulement il est embauché avec un bon salaire et forcément je ne peux pas rivaliser avec ma situation).

Il en est ressorti que j'ai les bases et que j'ai perdu le fil par la force des choses qui s'impose et sont prioritaires (trouver du taf pour manger par exemple ^^). Ou tout simplement parce que d'apprendre à coder en ligne ben c'est pas pareil qu'avec un prof. Quand tu bloques, il y a pas forcément quelqu'un qui va t'expliquer correctement pourquoi t'es bloqué.

[Auronake]

Le programmeur vous dit qu'on ne peut pas faire ça.

Ca, c'est faux. Tout est faisable en informatique, mais ce n'est pas toujours évident, et les "codeurs" (les mauvais) ont tendance à classer dans "pas faisable" ce qu'ils ont la flemme de faire. La seule limite est le temps: le temps de codage (flemme du codeur) et le temps de calcul.

Bonjour,

J'aimerai juste rebondir sur cela en disant que ce n'est pas toujours de la flemme que de dire "que ce n'est pas faisable".
Cela peut être simplement "pas faisable dans le temps imparti" et donc ton rapprochement "temps de codage = flemme du codeur" est un peu facile.

Selon ce qu'on veut faire et selon son planning de développement, on veut faire son projet plus ou moins rapidement et une fonctionnalité "faisable" mais qui prendrait 1 mois à faire (la fonctionnalité trop bien mais très complexe à faire) peut ne pas être acceptable.

Il faut dialoguer et savoir "en quoi" ce n'est pas faisable. Techniquement ? Au niveau du temps ? Fausse bonne idée ?.



Sinon, pour ma part, je fais du code par plaisir et par envie créative aussi. Même si l'on peut considérer le code comme rigide, il te permet de faire tant de chose . Il est rigide parce que tu ne peux pas écrire comme en français peut-être ?

Je n'ai pas de talent graphique mais je pense savoir m'exprimer par le code et par ce qu'il permet de faire...

[Xenos]

En fait, ce que je souhaitais dire exactement, c'est qu'un codeur qui te réponds "c'est pas faisable" te ment (par omission du terme "dans le temps imparti" ou simplement par désenvie de le faire). Un codeur ne devrait effectivement que te répondre:

• Ok, c'est possible, et je le fais
  
• C'est possible, mais j'ai besoin de plus de temps / plus de moyens / plus de gens / plus de détails
  
• Je ne sais pas (sous-entendu "j'ai besoin de plus de connaissances")
  

La réponse simple du "c'est pas faisable" est hors de propos.

Ce qui te gène peut-être en temps que graphiste, en ayant moi-même côtoyé certains, c'est qu'un code est "hyper-rigoureux" dans sa syntaxe et dans ses idées. En ce sens, un code est très précis sur un point particulier, et l'ensemble de tous ces points précis génère le tout que tu souhaites réaliser (un jeu par exemple). C'est une vision très "scientifique", très rationnelle, disons donc très "programmeur". Les graphistes que je connais ont bien plus une vision d'ensemble qu'une vision des éléments un à un. Du coup, tu as peut-être du mal à entrer dans cette structure "atomique", qui ne correspond aps du tout à ta façon macroscopique de voir les choses.
Par exemple, la vision atomistique d'un codeur qui doit dessiner un personnage le pousserait à faire une petite esquisse générale d'abord (conception), puis à dessiner hyper-bien et de façon très précise un morceau du personnage (la tête par exemple). Ensuite, une fois qu'il a dessiné, puis colorié, puis ombré la tête, il fait de même avec un bras, et ainsi de suite. A chaque "morceau" élémentaire, le codeur fait tout à fond avant de passer au morceau suivant.
Les graphistes (en tous cas ceux ou plutôt celles que je connais) sont bien plus généraux: ils dessinent d'abord une esquisse, puis affinent tout le personnage en un crayonné, puis ils dessinent tout le personnage (souvent en "sautant" d'un morceau à l'autre, c'est à dire qu'ils avancent un peu la tête, puis le bras, puis une jambe, puis ils reviennent à la tête, à la jambe, la tête, le bras etc), puis ile le colorient en entier, et enfin, ils appliquent les ombres sur tout le personnage d'un coup.

Cette différenciation de méthode est peut-être la source de ton "blocage" sur Unity: tu n'as pas la même façon de penser que les codeurs, tu penses plus par "thème" que par "élément".

[OurPleasure]

Est ce que la complexité est un frein si le succès en dépend ?
J'entends par là que certaines fonctions forment la valeur ajoutée, le plus qui différencie le jeu, ce qui donne envie aux joueur de se dire "Tiens, c'est quoi ça ?"
Parfois, il semble impossible d'expliquer au programmeur pourquoi c'est absolument impossible de se passer d'un élément au risque de rendre le jeu obsolète. Et c'est toujours dans ce cas que le programmeur dis "on ne peut pas faire ça" ou "trop long / trop compliqué et je vois pas l’intérêt".

Je suppose aussi que les codeurs/programmeurs expriment leur créativité grâce au code.