Programmation : simplification ou complexification ?

[Lyonsbanner]

On parle souvent de GameDesign, de direction artistique, de problématique de Gameplay ou encore de subtilité de LevelDesign. Mais je vois qu'on n'aborde pas beaucoup la programmation et la conception schématique d'un projet.
Depuis quelques années, le langage objet et la programmation objet, bien que compliqué à la base, simplifie l'utilisation dans la programmation. Avec cela, le patron MVC (Modèle - Vue - Contrôleur) qui a pour but d'organiser plus efficacement un programme. Et enfin, la méthode Merise (ou encore Agile) qui concerne la conception de schémas divers et variés qui permettent de mieux s'organiser dans le travail d'équipe ainsi que dans la répartition des tâches.

Mais vous savez quoi ? Il y a 20 ans, même sans ça on faisait des jeux de qualité, même si c'était du tout procédural. Aujourd'hui, l'évolution est telle qu'on fait des jeux encore plus compliqué à réaliser avec des équipes allant jusqu'à la centaine.

Franchement, moi ça m’ennuie énormément. Les programmeurs de l'époque ont peut-être trouvé ça génial et ont évolué avec ces procédés aux fil du temps. Mais pour les nouveaux programmeurs, je trouve que c'est une sacré épine dans le pied. Concevoir un jeu est déjà compliqué en soi. Mais rajouter des tonnes de schéma, d'un côté ça aide à s'y retrouver, mais en même temps, si on ne connait pas très bien le domaine, ça peut être plus confus qu'utile.

Qu'en pensez-vous ?

[AlexRE]

C'est compliqué si l'on souhaite connaitre tous les langages et tous les schémas/patrons. Mais le plus pertinent est de se spécialiser pour quelques années sur un seul langage pour vraiment le maîtriser convenablement pour créer un bon jeu.

Avec des rudiments de programmation objet, on peut faire un jeu pas trop mal, et sur 2 ou 3 années de développement, on peut très bien se spécialiser et se former à force de pratique.

Dire "c'était mieux avant" ce serait une erreur, car :
1) avec tous les logiciels de développement hyper développés (Code::Blocks, Eclipse, Netbeans...), certains éléments de programmation sont devenus peanuts
2) avec GitHub qui facilite les projets collaboratifs, plusieurs bibliothèques qui possèdent les bases de la programmation de jeu sont disponibles gratuitement, pas besoin de "recoder la roue" (moteur physique, etc ...)
3) avec le nombre très important de tutoriels sur un langage en particulier ou sur une bibliothèque en particulier, n'importe quel novice peut devenir programmeur et à force de persévérance s'approprier une bibliothèque, et ce plus facilement qu'un novice en graphismes pourrait faire du beau pixel art je dirais.



Tomber dans le piège de faire un jeu juste en C, sans utiliser une bibliothèque existante, en recodant un moteur physique tout à la main, c'est perdre du temps sur quelque chose qui n'en vaut pas la peine.

[Lyonsbanner]

Tomber dans le piège de faire un jeu juste en C, sans utiliser une bibliothèque existante, en recodant un moteur physique tout à la main, c'est perdre du temps sur quelque chose qui n'en vaut pas la peine.

Oui, de ce côté là, je suis d'accord. Aujourd'hui, on dispose d'un tas d'outils qui facilite grandement le développement de son moteur de jeu (ou jeu tout court) sans devoir tout recommencer.
C'est sûr qu'à l'époque, c'était sans doute très galère pour développer un jeu parce qu'il manquait de quoi organiser correctement son code. Mais aujourd'hui, la tendance s'est inversée : on arrive à organiser plus facilement son code, mais les méthodes de programmation ont tellement évolué et sont tellement nombreuses qu'on ne s'y retrouve pas.

[Gaetz]

Je suis d'accord pour dire qu'on dispose aujourd'hui d'outils beaucoup plus puissants pour programmer la plupart des jeux, et j'encourage à utiliser du code de haut niveau pour réaliser un projet de jeu.

Néanmoins, si on veut programmer quelque chose de nouveau, on ne connait plus la base, le mode de fonctionnement électronique d'un ordinateur - comment travaille la carte graphique, le processeur... Nos aînés maitrisaient ce genre de chose, savaient programmer en assembleur par exemple. Dernièrement j'ai lu une biographie d'Eric Chahi (qui n'aurait pas pu réaliser From Dust sans programmeur ayant ces connaissances), et ça m'a donné très envie de retrouver ces techniques, de me rapprocher de la machine. Évidemment, je n'en ai pas le temps

[Monos]

Nos aînés maitrisaient ce genre de chose, savaient programmer en assembleur par exemple.

C'est ce que je disais à mon collègue (Nous ne sommes pas dans l'informatique, ouvrier viticole mais on parle souvent de ça). Maintenant nous avons des outils pour nous simplifier la vie, mais avant non et de toute façon ce n'était pas possible véritablement. Je reprend la programmation sur Amstrad CPC pour le plaisir. (Je suis pas non plus programmeur) Le langage de base c'est le basic mais c'est lent et limité dans les fonctions par exemple. L'amstrad n'a pas de sprite machine, pas le choix il faut passer pas l'assembleur ou utiliser des sous programmes en assembleur déjà réalisé mais c'est pas trop. Les vieux ordis fallait souvent utiliser l'assembleur pour s'en sortir. Pour ça que les "vieux" savaient parler directement à la bécane. Mais maintenant nous avons des ordis (ou console) très puissante. Nous n'avons plus vraiment besoin de "gagner" du temps machine pour accélérer les choses. Dans beaucoup de cas c'est donc inutile de passer par l'assembleur.
Avis personnelle d'un débutant.

[Kannagi]

Ah l'assembleur , de nos jours sur un PC moderne l'assembleur est devenu inutile pas seulement que les machines sont plus puissante ou qu'un compilo fait mieux que un programmeur assembleur (ça dépend de l'architecture tout de même), mais disons que de nos jours nos ordi ne sont plus fait pour codé en assembleur , codé en assembleur devient très vite pénible , tout se passe par OS donc il faut passé par des API haut niveau qui sont souvent écrite en C.
Après le X86 avec son histoire est devenu trop compliqué pour être appréhendé par une démarche full assembleur.

Il y a eu incontestablement un simplification de la création de jeux vidéo et de la programmation ,pas sur qu'une approche a la C (ou assembleur) beaucoup n'arriverait pas a faire un résultat propant , ça demande la a ne plus être dans le domaine du débutant et donc d’être spécialisé un peu dans le domaine.

Pour ma part je dirait recodé un moteur de jeu en C , c'est pas forcément le meilleurs moyen de finir son jeu mais c'est possible du moment quand sait dans quoi on s'engage.