Bonsoir,

Moi qui ai connu le jeu vidéo depuis déjà quelques décennies, l'état que tu dresse est plutôt vrai mais s'applique à mon sens non pas au studio indépendant mais à tous les studios, il faut pas croire que la problématique est différente pour une gros studio, plus le jeu sort vite plus on peut en faire un autre rapidement et plus on rentabilise, la seule différence, c'est que les programmeurs bossent sur l'évolution du moteur maison, pendant que les autres programme les jeux, mais il est clair que le programmeur à tendance à disparaître par rapport à l'artiste, mais faut aussi se poser la question en fait par rapport à l'évolution de l'informatique en soit, il y a un lien (ce n'est que mon avis) avec l'évolution informatique (que ce soit console ou ordi et aussi bien dans le monde pro que ludique). Il y a 20 ans, peu de visuel mais beaucoup de programmeurs car on gros tout devait être fait à la main, puis est apparu les co-pro comme par exemple le blitter sur Amiga et la on a eu moins besoin de programmeur parce que lorsque l'on voulait afficher quelques chose on ne faisait plus une routine pour le faire mais on demandait au blitter de le faire pour soit, et ainsi de suite. Du coup vu la surenchère de technique, il fallait bien créer du contenu visible, et ce de plus en plus. Donc on a eu insidieusement une favorisation du visuel par rapport au factuel.
Le constat que tu fais n'est qu'une suite logique de l'évolution de l'informatique et je pense que cela ne s'arrêtera pas là, par contre il faudra toujours des programmeurs, il ne faut pas croire que les outils actuels permettent de faire tout et permettront dans le futur de tout faire mais il est clair que cela va encore s'accentuer dans les années à venir, le seul truc c'est qu'un Artiste n'aura pas forcément le schéma de programmation en tête, et de plus pour des jeux burger, ok pas besoin de programmeur, pour des jeux un peu plus évolué, il y aura toujours besoin pour ne serait-ce qu'un algo sur l'IA. Enfin tout ça n'est aussi qu'un avis. Mais là ou avant il y avait un rapport de 5 programmeurs pour 1 artiste, maintenant c'est l'inverse ^^.

Alors question :

Je dis n'importe quoi ?
Des exceptions ?
Ce n'est que le début ?

Fais gaffe, hors-contexte, c'est une perche tendue pour que l'on réponde :
- Oui
- « Je dis n'importe quoi »
- Le pire est à venir

Dans les faits je suis d'accord avec le propos tenu, donc ça ne s'applique pas vraiment… Mais la blague était trop tentante pour que je résiste. :3

Taquineries mises à part, c'est un sujet que je trouve vraiment intéressant ! Je suis moi-même défenseur des outils spécialisés, qui sont appliqués dans bien d'autres domaines que le jeu-vidéo. Faire des programmes en utilisant des langages génériques ne se fait plus beaucoup en entreprise : on utilise soit des librairies appropriées, soit des outils (langages ou interfaces) dédiés à une utilité précise.

En matière de jeu-vidéo, si la programmation est, par nature, au cœur même de la création, on avance vers la création de plus en plus de logiciels permettant une création plus simple et automatisé. Et c'est utile aussi bien pour les non initiés à la programmation que pour les programmeurs eux-même. Parce que pour être franc, développer son propre moteur de plate-forme 2D quand il existe plein d'outils permettant d'en créer et de les paramétrer, ce n'est pas franchement utile (sauf pour apprendre, bien sûr).
D'ailleurs c'est positif qu'il existe des outils génériques, comme Construct 2 ou Unity, aussi bien que d'autres plus spécifiques à un genre, par exemple RPGMaker, Twine, ou PuzzleScript. Ça permet d'être plus précis dans la création sans offrir un logiciel qui souffrirait d'une grosse complexité en voulant être trop générique (Projetc Spark), ou d'un manque de possibilités parce qu'il gère trop de choses différentes (Project Spark). C'est comme pour tout, on ne pourra jamais créer l'outil ultime qui pourra faire des jeux en quelques clics (cela voudrait dire que le média est limité à des règles de forme, ce serait triste). Pour autant, pour un grand nombre de jeux qui ne sont pas des OVNIS complets, on peut facilement proposer des outils haut niveaux qui génèrent ce qui se fait déjà en quantité partout ailleurs. Avec pour but de donner plus d'importance au level-design et aux mécanique qu'à la pure technique.
La comparaison de Aekos est plutôt pertinente. Y a quelques années, faire du montage vidéo demandait des compétences techniques de fou. Aujourd'hui, des logiciels permettent de faire des effets classes facilement. Si on veut aller plus loin, il faut s'intéresser à l'animation et aux montages complexes, mais dans les cas simples, on a des outils de plus en plus performant. Il n'y a pas de raisons qu'il n'en aille pas de même pour la création de jeu.

D'ailleurs c'est pour ça que pas mal de boîtes utilisent des outils internes. J'ai en tête Ronitech[ des créateurs de Awesomenauts, ainsi que, bien sûr, l'UbiArt Framework. Moins de contraintes pour les créatifs ou level-designers pour manipuler le jeu, c'est le top !
(et même pour les programmeurs comme moi qui, flemmards dans l'âme, sont ravis à l'idée de moins coder)

***

Pour autant, la programmation a encore de beaux jours devant elle. Déjà parce que les outils sont encore largement perfectibles ! Le média est « jeune », il reste encore des choses à créer. Et il me semble que les développeurs de Rogue Legacy mentionnait aussi ce problème : quand on est une petite boîte, entre choisir de développer ses propres outils super polyvalents ou créer directement un jeu, il vaut mieux prendre la deuxième option. Créer des moteurs pour le long terme, pour un indépendant, c'est risqué. Après, il reste toujours les moteurs tiers déjà évoqué. Mais c'est des moteurs tiers, et donc pas toujours adapté aux besoins.

Dans un autre registre, depuis quelques temps, le développeur Jonathan Blow évoque la nécessité d'un langage de programmation dédié au jeu-vidéo. La logique est toujours qu'il y a des choses que les développeurs de jeux ont à faire systématiquement, et qu'il est donc nécessaire d'automatiser certaines choses. Ça fait des lustres qu'il peste d'ailleurs sur C++ à ce sujet.
Sauf que son point principal est la performance, et l'optimisation aussi bien du code que des moteurs. Il a fait plusieurs vidéos sur le sujet. Attention, c'est long, et très technique.

En soi, on aura toujours besoins des programmeurs pour enrichir davantage les outils ou les jeux eux-même. Je pense même que dans un avenir plus ou moins proche, on aura affaire à de nouveaux types de technologies qui demanderont d'autres ingénieurs avec d'autres types de compétences.^^ Mais la création de jeu s'ouvre malgré tout à plus large, et même pour les vétérans, devient beaucoup plus simple et rapide.

Sur Javascript, j'ai fini par rejoindre l'opinion d'un prof que j'ai eu, à savoir qu'il s'agit du langage le plus bas niveau du web dynamique. Un sorte d'assembleur web, à n'utiliser que si on veut se faire du mal. Aujourd'hui il vaut mieux utiliser les sur-couches voire les framework (ma préférence allant à AngularJS *_*), qui fonctionnent à base de javascript, mais sont beaucoup plus efficace pour développer des applications complexes.

Et je ne connais pas beaucoup jeux fait en pur javascript, mais il y en a de plus en plus qui utilisent des moteurs à base de JS. Et si ça ne va pas forcément loin, ça donne des rendus propres (sans Flash :3) et fluides. D'ailleurs en général, les jeux web ne sont plus exclusivement Flash et utilisent des technologies variées, et c'est cool. (même si j'attends toujours une version Linux de Web Unity ><)
Bah d'ailleurs le seul jeu que j'ai fait jusque là se base sur un outil JS. Pertinent vu qu'il s'agit avant tout de texte et de liens dans une page. Par contre, si j'étais bien content d'avoir un outil pour gérer le moteur du jeu, ça a été galère quand il a s'agit de développer des macros pour y ajouter des fonctionnalités. >< Le javascript brut, c'est souvent très sale.

J'ose espérer quand même que les programmeurs ont une place dans le développement indé aussi, ne serait-ce que dans l'imagerie numérique. Après, pour se lancer, la solution de base est d'être à la fois artiste et programmeur…^^
… Ce qui est pas forcément simple, j'avoue. De mon côté, j'aime écrire des histoires, mais je suis un cancre dans tout ce qui touche l'esthétique visuelle. Le jour où j'essayerai de faire un jeu seul, ça sera la fête de l'épuré et du minimalisme (et encore, le minimalisme c'est plus dur qu'il n'y paraît). x)
Mais bon, un peu comme l'informatique en général, il est souvent conseillé d'avoir des compétences au-delà de la programmation. Que ce soit la gestion de projet, la vente, les relations clients… Si un programmeur souhaite se lancer dans le jeu indépendant, il gagnera à avoir des compétences autres que la simple programmation. Mais d'un autre côté, s'il souhaite faire des jeux, c'est sûrement qu'il a des idées, et c'est l'essentiel.

Pour un jeu, il y a au moins 2 types de programmeur : moteur et gameplay. Si l'utilisation de moteur tiers permet de se passer du premier type, le deuxieme est toujours nécessaire. Car c'est lui qui code (via un langage, un script, des events sheet,...) les règles, l'ia, ... et tous le dynamisme du jeu. UE4/UDK, Unity ou Construct nécessitent des connaissances en programmation (logique, optimisation,...).

Un artiste pourra programmer, au meme titre qu'un programmeur pourra dessiner, animer, composer. C.a.d plus loin qu'il y a 10ans avec l'aide des outils actuels, mais toujours limité par ces aptitudes. Par example, je suis nul en audio, dessin, et je connais des graphistes, animateur 3D qui sont allergiques à la logique "explicite" (ils en font plein mais ils l'ignorent).

Et consernant "javascript", si je me rappelle bien. Construct2 génere du code javascript non ?

Et au meme titre qu'il y a des moteurs tiers pour se dispenser d'une partie de la programmation, il a des banques d'assets (visuel, fx, audio,...) pour economiser sur les graphismes, sons,...

Je crois que l'évolution est similaire dans beaucoup de domaine, bien au-delà du JV, indépendant ou non.
A force de pousser les connaissances et capacités toujours plus loin, on ne peut plus vraiment appréhender toute la chaîne, du A au Z d'un projet, à soi tout seul. Du coup l'organisation qui va naturellement avoir tendance à prendre forme, c'est que chacun va développer dans son domaine de compétence des outils pointus pour que d'autres les utilisent. Pas le choix si plus personne n’est à même d'appréhender l'ensemble des domaines à lui tout seul.

Typiquement on voit p.ex. que Unity associe à son interface et à son propre moteur de rendu (exploitant déjà tous les effet visuels implémentés par d'autres au sein des processeurs graphiques) le moteur physique "PhysX" de Nvidia, ou encore le système d'"occlusion culling" d'Umbra. Et tout ça pour le mettre ensuite à la disposition des développeurs.

Et ceci est vrai donc dans tout un tas d'autres domaines comme les sciences, où p.ex. on n'est plus de nos jour physicien de la matière au sens large, mais p.ex. spécialiste de la mécanique quantique (et encore, surement y a-t-il encore là des sur-spécialisations plus poussées encore!). Dans l'industrie on voit que les sous-traitances ou les partenariats se généralisent. Etc.

Mais bon, pour en revenir à la programmation, je rejoins DavidB: si de plus en plus on pourra s'affranchir de programmeur au sein des équipes de développement pour ce qui est du moteur de jeu (à quoi bon réinventer la roue comme tu le dis très bien Jonathan), difficile d'imaginer la réalisation d'un jeu, avec un tant soit peu de liberté créatrice, sans coder un minimum (mécanismes de gameplay, IA, etc.).

Au final il faudra toujours des programmeurs, mais juste moins nombreux au sein d'un projet donné puisqu'on s'affranchira d'une partie du travail ; mais d'une partie seulement.
Et de toute façon ce travaille dont on se libère, on pourra s'en passer justement parce qu'il aura été fait par d'autres, d'autres programmeurs! Et des très pointus, donc l'art du code n'est pas près de se perdre, seulement ceux codant les très pointus moteurs de jeu semblent effectivement amenés à quitter les équipes de développement de projets vidéo-ludiques spécifiques pour se retrouver "délocalisés" dans la mise au point d'outils polyvalents à destination de ces équipes.

Après il faut aussi se poser la question de ce qu'on entend par « programmer », et notamment la nuance qu'il y a avec « paramétrer ».

Il existe des outils pour les moteurs et le level-design, mais il y en a aussi pour la logique du jeu (mécaniques, IA, propriétés d'un élément, réactions, etc…). Le tout étant défini souvent par des prédicats logiques ou des instructions impératives… L'écriture de cette logique se fait souvent de manière textuelle (d'où la notion de « coder »)… Mais ce n'est pas la seule représentation possible ! J'ai en tête Glitchspace, qui représente des logiques d'algorithmie sous formes de boîtes et de connecteurs. Jeu qui a suscité des débats quant à son approche de la programmation, parce que pour plus d'un, programmer signifie avant tout écrire des lignes de code. Stencyl aussi est un exemple intéressant, pour sa création d'algorithmes sous forme de drag'n drop des instructions et variables.

L'algorithmie et la définition de règles font partie, par nature, de la création d'un jeu. Si on veut construire une machine qui génère B quand 1 se produit, il faut le définir quelque part… Mais je ne sais pas si c'est de la programmation tel qu'on l'entend. Même de façon textuel, il s'agit (ou s'agira) de langages propres aux outils de création de jeux. Pour peu que l'on évolue vers une logique purement déclarative, même les programmeurs (souvent habitués à de l'impératif) devront avoir un peu d'apprentissage.

Dès lors même si la définition des mécaniques d'un jeu s'apparente à de la programmation, c'est une programmation qui tend à être très spécifique au jeu. Et ce ne serait plus des « programmeurs » qui seraient les plus aptes à fabriquer des jeux, mais des game-designer à part entière.

Oui, effectivement, il faudrait peut-être déjà définir ce qu'on entend par "programmeur".

Spontanément, je pense que je considère comme tel quelqu'un qui, pour qu'un programme fournisse un objectif défini (en tant que fonctionnalité, comportement, ou tout ce qu'on veut), conçoit un algorithme et le formalise sous forme de code fonctionnel. Sous-entendant une connaissance des fonctionnalités de l'environnement informatique utilisé et de la façon de les exploiter. Peut importe après l'environnement de développement considéré, de plus ou moins haut niveau.

A ce titre, pour moi, quelqu'un qui code un script sous Unity est un programmeur. Mais peut-être ne seront nous tous pas d'accord sur cette perception.

Après j'avoue que je ne sais pas trop comment considérer les interfaces graphiques qui permettent de nos jours de faire peu ou prou la même chose (mais qui doivent quand même rester limitées par rapport à l’utilisation de langage de programmation, non?). Et il est vrai que ma vision est probablement biaisée par mon expérience qui est très limitée mais est toujours passée par du code "brut" (jusqu'à un petit détour par de l'assembleur, qui a été très instructif et assez trippant ).