Sujet:
Salut la compagnie, j'ouvre à la base juste ce post pour poursuivre une discussion avec Aleph0 qui constituait une franche digression sur un autre topic. Ça ne durera peut-être pas plus de qqs messages, mais c'est pas grave ;).
Bon, quand même, prétendant ouvrir un sujet sur la programmation, je préfère prévenir tout de suite que c'est en toute modestie: en effet je suis pas du tout formé au code, l'essentiel de mon expérience remonte à mes années de lycées où je programmais de façon complètement auto-didacte pas mal de petites appli sur calculatrice programmable (TI-83 surtout, et un peu sur TI-89 d'un pote, au tout départ TI-80 mais c'était trop la loose, trop pauvre en possibilités :P), ça allait de convertisseurs de bases ou autre décomposition de nombre en nombre entiers, à des petits jeu (type "tape-taupe", balistique, bomberman ...jusqu'à un dungeon crawler sur le thème d'Alien sur TI89 :P), ou encore un ptit programme qui permettait d'afficher des objets filaires en 3D sur TI83 (tout lent, tout moche, mais qui marchait! ^^). Après le lycée, j'ai appris rapidement le code C sans en faire grand chose, et ai fait une rapide incursion vers l'assembleur (par curiosité ;)) avec lequel la seule chose notable que j'ai réalisé était un défilement de caractère façon "Matrix" en mode texte... (un truc de ouf! 
mais dont j'uis tout fier parce que j'avais dû improviser mes propre routines de débogage, ou encore routines de génération aléatoire, ce qui pour moi était beaucoup!). Mais bon au final m'étant lancé dans des études sans aucun rapport, et très prenante, j'ai depuis franchement lâché l'affaire, ce que quelque part je regrette, mais je ne désespère pas de m'y remettre un jour! 
Bref, voilà pour situer un peu mon modeste "background".
Maintenant là où on en était avec Aleph:
je disais par ici http://www.indiemag.fr/comment/9904#comment-9904 (polluant le sujet de Sentô j'avoue...) qu'une bonne façon parfois de gérer des situations complexes, plutôt que mettre des if en cascade, était d'avoir recours à une base de donnée qui permette de renvoyer un (ou des) paramètre(s) à partir d'un paramètre d'entrée ; en gros, au lieu de tester un paramètre d'intérêt selon un certain nombre de possibilités, il peut parfois suffire de lister les retours que l'on souhaite pour chacune de ses possibilités dans une liste (ou un tableau), et de les obtenir par un simple appel de ce tableau avec comme pointeur la variable à tester. Donc pas de test explicite, et surtout une instruction unique qui renvoi automatiquement ce que l'on souhaite sans avoir besoin d'envisager une série de cas de figure au sein du code.
Je trouve ça parfois très pratique, permet de contrôler parfaitement le nombre d'instruction qui seront exécutés dans une routine (alors que les if en cascade, non), et introduit bien souvent une grande souplesse dans les possibilités d'évolution du programme.
J'en ai donné un exemple extrêmement simplifié ici http://www.indiemag.fr/comment/9915#comment-9915, mais la puissance potentielle de la chose en situation plus complexe se ressent à mon avis mieux là je pense http://www.indiemag.fr/comment/9906#comment-9906 (voir les 2 posts précédents pour comprendre de quoi il retourne :P).
Sur ces entrechats, Aleph me reprochait que l'intérêt de cette solution était purement virtuelle car devenait trop complexe, et dés lors inapplicable, dés que l'on s'attaquait à de vrais projets un tant soit peu ambitieux.
Là dessus je compte rebondir en disant que j'ai utilisé cette technique assez souvent (à partir du moment où elle m'est venue en tête, à partir de mon programme de conversion de bases sur TI 83 en fait pour être précis 
), et dans des projets à finalité réelle, même s'il est vrai souvent modestes, et que cela m'a régulièrement été bien utile pour optimiser et rendre mon code plus puissant. Et pis de toute façon beaucoup de programmes complexes sont la somme de routines pour la majorité assez simples prises individuellement, et donc ce recours à des bases de données demeure au moins possible à considérer dans certains de ces cas. D'autant que cela reste à mon avis un outils quand même très puissants dans moults situations, pouvant justement simplifier parfois des fonctionnalités qui paraissent de prime abord complexes à implémenter. Après bien sûr ça ne fonctionnera pas dans n'importe quel cas où les conditions s'enchainent! Mais p.ex. dans l'exemple cité juste au-dessus sur la gestion de la succession de frame d'animations, l'exemple est bien concret et sa puissance et facilité d'implémentation me semble évidente.
Enfin, je voulais au passage faire une ouverture sur un point plus général:
Cela rejoint un peu en fait un concept que j'avais lu il y a longtemps (et je ne sais pas si on en parle encore?) qui est que pour arriver à un résultat en informatique il y a (bien sûr) pleins de solution, et que dans ces différentes solutions on va avoir toute la latitude d'opter pour l'usage de plus ou moins de ressource mémoire vs. plus ou moins de ressource de calcul.
De façon caricaturale, pour le calcul d'un cosinus p.ex., on pourra à un extrême se baser sur une solution purement calculatoire, via l'algorithme CORDIC p.ex., ou à l'autre extrême renvoyer simplement à un tableau géant comprenant tous les résultats possibles dans les limites de précision que peut prendre au sein du programme la valeur de l'angle considéré. Il n'y a sans doute pas de "bon choix" dans l'absolu, mais p.ex: si l'angle considéré est un chiffre entier, ou à une décimale, la technique du tableau a toutes les chances d'être extrêmement rentable (une simple liste de 360 ou 3.600 valeurs, une poignée de kilo-octets tout au plus!), alors que si on considère un système de calcul pointu avec des angles d'une précision allant à 10^-5, la résolution purement mémoire nécessiterait de stocker 36.000.000 de valeurs ; bon on arrive a des ordres de grandeurs du centaine de Mo certes ce qui peut paraitre acceptable isolément, mais si on doit avoir un tel tableau pour chaque fonction rencontrée dans un programme, ça commence à être problématique! Il faut aussi mettre ça en corrélation avec la vitesse d'exécution souhaitée: pour un jeu temps réel, le système 100% mémoire sera ultra-rapide d'autant que la précision requise est elle limitée (et bien définie en amont) ; pour un système de modélisation tridimesnionnelle pointue, l'importance restera une précision maximale (éventuellement potentiellement infinie selon la volonté de l'utilisateur) et on s'en fout à l'inverse que la résolution d'un problème mette au final qqs secondes: la solution 100% CPU semble s'imposer comme le meilleur choix.
Les successions de if en programmation, c'est à éviter absolument. De même que les assignations de variables à la volée. Ça alourdit énormément le code, et complexifie énormément la modification.
Vu que je développe principalement dans des langages hauts niveaux (Java et Python), je raisonne principalement en objets et en design pattern, parce que c'est vraiment nécessaire pour des projets complexes ! L'idée du génie logiciel, c'est de créer ses propres outils pour avoir ensuite à coder le moins possible, et à avoir une structure claire, avec une bonne séparation. Avoir un contrôleur d'un côté, pour pouvoir ensuite faire le modèle séparément et s'assurer qu'il soit manipulé automatiquement (aussi bien avec des tableaux que des dictionnaires, ou des classes ou interfaces plus complexes), c'est à appliquer partout.
Et pour peu qu'on n'a pas peur de la méta-programmation, on peut faire pareil pour les comportements ! Avec des Constructeurs, des Proxys, des Décorateurs, on a d'un côté une part de code plus ou moins succincte qui prend une instance d'objet à un instant t, et effectue toujours la même action avec elle, et d'un autre côté une série de différentes sous-classes qui définissent une action pour chaque cas. Pour peu que le code soit bien commenté et hiérarchisé, c'est bien plus simple à maintenir, et surtout à faire évoluer !
Le problème de procéder au cas par cas avec des algorithmes qui se contentent de faire ce que l'on veut faire, c'est que dès qu'il faut tester, debugger, ou retravailler dessus, il faut revenir à des lignes bien précises, des informations dispersées à plusieurs endroits, et aucun outil pré-établit pour automatiser des actions ! Prendre le temps de se créer des solutions pour automatiser les tâches et faire une structure propre, c'est plus long et fastidieux sur le court terme, mais vraiment utile et efficace sur le long terme ! Et c'est donc justement sur les gros projets que c'est pertinent.
Après, tout dépend des outils et langages utilisés… Certains ne permettent pas vraiment de mettre en place de la programmation objet, ou l'utilisation de structures de fonction simples. Il faut voir qu'est-ce que l'on utilise en fonction de quel besoin.
En ce sens, pour la parenthèse, je trouve l'utilisation d'outils de création de jeu carrément pertinente même pour les habitués à la programmation ! C'est le principe des DSL (Domain Specific Language) : utiliser un outil spécifié dans un tâche, mais qu'il le fait bien. Quand ton jeu n'a pas besoin d'un moteur particulièrement inédit et complètement en marge de tout (ce qui est le cas dans la plupart des cas), Game Maker est à même d'automatiser un bon nombre de points pour mettre les bases du jeu, et permettre de se concentrer davantage vers le game-design. C'est comme le web/javascript : on utilise HTML et diverses librairies js (voire CSS) pour faire un site, parce que ce serait absurde de coder tout en requêtes HTTP pures ! On perd certes la « fierté » de tout faire à la main, mais c'est quelque chose que surtout les joueurs ont en idée (comme si le jeu-vidéo était un artisanat qui doit se faire à la main, avec un marteau de forgeron). La réalité du développement informatique, c'est que ça ne sert à rien de refaire (en moins bien) ce qui existe déjà. Les langages dédiés aux jeux (de même que les moteurs physiques, qui sont là pour ça) ont justement été conçus avec un esprit assez souple pour créer le plus large éventail de genre possible. C'est encore perfectible, mais on est loin d'un simple éditeur de niveaux.
En bref : je suis pour l'automatisation et la généralisation, quand c'est possible. Ça accélère et facilite énormément la gestion du code pour pouvoir se concentrer plus facilement sur les fonctionnalités et le contenu.
Mes jeux sur itch.io
Mes vidéos sur Youtube
Mes reins sur ebay (pas encore disponible)
Ah bah on est d'accord alors Itooh ;).
)
Après je pense qu'il n'y a aucunement besoin de programmation orientée objet pour utiliser de telles techniques, d'ailleurs aucun des 2 exemples concrets que j'ai donné ne le requiert, surtout je n'ai jamais touché de ma vie à de tel langage :P.
(et la dernière approche que j'ai eu de la programmation était pour le moins "bas niveau"
Je ne suis pas forcément d'accord.
Seldell le sait j'aime créé les roues carrés.
Il faut mieux avoir une bibliothèque de fonction que tu as crée pour programmer ton jeu.
Les logiciels font perdre pas mal de temps à te faire dépasser les limitations du logiciel.
Game Maker et encore plus Construct sont horrible à utiliser quand tu sais comment faire sans et que tu veut quelque chose de compliqué.
Lorsqu'on programme un jeu vidéo, on trouve des moyens logiques qui font gagner du temps.
On est libre de tout crée donc on peut faire des classes spécialement adaptés au jeu vidéo.
Plutôt que devoir créer des tas de room fastidieusement sur Game Maker alors qu'ils partagent une logique.
Par exemple : si ton jeu contient 6 types de salles. Tu seras heureux de pouvoir programmer 6 salles différentes plutôt que de devoir créer des room sur Game Maker en copiant les éléments spécifiques.
C'est pour ça que Construct propose des espèces de classes pour les éléments en jeu.
Cependant, ça ne vaut pas la rapidité de la programmation, et la réflexion derrière qui élimine l'inutile et te permet d'avoir quelque chose de toujours adaptés.
Cependant, ces outils vont certainement s'améliorer et peut être remplacer la programmation d'un jeu vidéo (et non d'un moteur qui est déjà inutile).
Bien sûr. Mais si tu ne sais pas comment faire sans, là ça aide ;).
Crois-tu vraiment que tu irais plus vite à créer de toute pièce un jeu 3D qu'à apprendre à utiliser un Unreal Engine ou un Unity, et même à apprendre à en contourner les limitations? Et que tes roues carrés seraient aussi satisfaisantes que les roues (plus ou moins) rondes déjà proposées par ce genre de moteurs?
Je comprends très bien ce que tu veux dire, ayant toujours programmé seul, et programmé mes moteurs de jeu (même si pas de grosses choses), "développant" (si on peut dire :P) mes propres "outils" de conception (notamment pour mes mémorable dungeon crawler sur calculatrice ^^) ; ya rien de plus grisant et de plus agréable que de coder en contrôlant tout les rouages de A à Z!
Mais selon la complexité du projet, et en fonction de ses compétences individuelles, il y a un moment ou on ne peut plus assurer seul le développement d'un projet de A à Z. Il y a toujours une limite dans la complexité qu'on est capable d'aborder seul, qui fera qu'à partir d'un certain degré un projet s'avèrera finalement plus facile à réaliser avec des outils déjà faits.
Et si tu es peut-être particulièrement doué (ou en tout cas à l'aise) en codage pour repousser assez loin cette limite, tu en a à mon avis surement une ;).
Et il n'y a aucune raison à mon sens de dévaloriser ceux qui atteindraient cette limite plus tôt, en défendant l'idée que les outils d'aide à la création, qu'eux trouvent bien utiles, seraient en fait des gadgets superflus.
Complètement d'accord avec Itooh sur l'automatisation et la généralisation. Plus on approche du haut niveau, plus il y a de chance
que l'architecture fournie ne soit pas en adéquation avec la fonctionnalité voulue.
Il y a aussi tout simplement des erreurs de design qui font que l'utilisateur perd du temps sur certaine tâche. C'est d'ailleurs le cas de beaucoup d'outils comme GameMaker qui ont oublié justement de faire de la généralisation là où cela aurait été nécessaire.
Pour autant tout n'est pas à jeter.
Conceptgame
PS: j'ai édité le titre pour un truc plus nébuleux qui veut tout et rien dire, comme ça ça autorise sans arrière pensée toutes les digressions que l'on voudra sur le sujet ;).
Mais bon c'est vrai que j'ai tendance à rejoindre un peu (beaucoup) l'avis des "pro-code", comme le dit bien Xotraz et toi aussi ConceptGame, l'outil doit rester idéalement le plus souple et généraliste possible ...en fin de compte dans l'absolu un "simple" langage de programmation!
Mais pour des projets très complexes, tout développer de A à Z n'est à mon sens clairement plus faisable seul, et là les moteurs tous-fais vont être d'une aide indispensable ; même si rendra le codeur expérimenté fou devant des gymnastiques tordues, illogiques, et au final de façon évidente non optimale, nécessaires pour implémenter certaines fonctionnalités non prévues au départ! Après il faut aussi voir que ces logiciels peuvent en fait s'avérer de façon générale bien plus optimisé que ce qu'on réaliserait soi même, et qu'au final y implémenter une fonctionnalité de façon tordue et jugée inutilement consommatrice de ressource pourrait bien, au niveau du résultat final, ne pas entrainer de perte de performance.
Mais idéalement c'est sûr qu'il parait super important (enfin, du point de vus des codeurs invétérés toujours ^^) que de tels logiciels autorise un accès extrêmement souple et permissif au cœur du moteur, via son système de script. Mais j'imagine que le plus souvent, ce qui se passe réellement dans un GameMaker p.ex. reste bien opaque...
Enfin, après je suis pas très bien placé pour faire la leçon notamment à Xotraz, quand il s'avère que j'ai toujours fuit les langages orientés objets que je trouvait trop "haut niveau" et donc trop contraignants...
Oui, je suis d'accord que ces outils finissent par devenir nécessaire lorsqu'on a un projet immense et des contraintes de temps. Surtout que le temps passé à programmer est perdu en game design.
Le mieux étant de pouvoir scripter mais le problème des scripts c'est qu'ils ne font que spécifier un comportement le plus souvent. Or le programmeur voudrais je pense créer de véritables objets. Sans compter qu'on perd l'intérêt du soft.
Cependant, pour l'essentiel des jeux on peut utiliser Construct ou Game Maker.
Pour ce qui est de la limite, il est clair qu'elle existe. Mais tu peut la repousser en réutilisant ton propre code.
La POO permet surtout de mettre de l'ordre dans un premier temps, et ensuite on trouve des trucs bien pratiques (héritage, design pattern) qui font gagner du temps voir permettent des choses.