Un outil comme "Multimedia Fusion" permet de créer des jeux sur PC / Mac / Android / IPhone/Flash/XBOX en un projet et sans pour cela avoir besoin de taper des milliers de lignes de code....

Sujet très intéressant.

Pour ma part, je fais des petits jeux depuis quelques années, en utilisant le système de blocs développés en libre par le MIT, principalement sous un dérivé de Google App et l'excellent Scratch. Je fais aussi quelques trucs sous Phun, mais l'aspect programmation est très différent. Je tapais aussi un peu Game Salad, mais le Mac OS only me donne des boutons.

Par contre, quels que soient les outils, il est malgré tout impératif de savoir programmer.
Déjà, il faut connaître et comprendre la logique du langage que l'on emploi. Ensuite, quand on a les bases, viennent les projets plus conséquents. Et là, il faut savoir jongler avec les maths si l'on ne veut pas se retrouver avec des jeux truffés de bugs ou, plus simplement, qui ne correspondent pas à ce que l'on souhaitait faire.
C'est la face cachée de ces outils. Beaucoup pensent qu'il suffit de trois clics et un glissé-déposé pour faire un jeu. Ben non, c'est beaucoup de boulot. Car non seulement il faut littéralement chier du code ( simplifié ou non, ça reste du code ), mais aussi bosser tout l'aspect visuel et sonore. Et là, on constate que même un pauvre sprite typé 8-bits nécessite plusieurs étapes d'animation, des bruitages qui vont bien, une gestion de la "physique" et des collisions, etc.

Actuellement, je galère pas mal sur un point'n clic à cause de la gestion d'inventaire, qui m'oblige à "tricher" pour faire croire au joueur que tel ou tel objet est en stock, alors qu'en réalité il est simplement masqué sur son emplacement initial. Ça et les interactions possibles entre chaque objet qui nécessite de penser leurs différentee combinaisons, elles-même dépendantes de l'ordre dans lequel le joueur les a récolté...
_________________

"Il n'est pas de lutte plus violente et déterminée que celle d'un homme face à son envie d'aller aux toilettes" - Karate Boy

Vous allez dire que je suis bizarre mais moi ce qui m'interesse plus c'est pas de programmer un jeu, mais comment on arrive à faire ce genre de moteur qui permettent de programmer des jeux.

J'ai beau tourner le problème dans tous les sens j'arrive pas à en concevoir (de moteur de jeux)
_________________

Pas forcement besoin de concevoir de vrai moteur de jeu generique pour creer son jeu video.

Personellement, je serais incapable de bien game-designer et level-designer un jeu. Ca ne m'empeche pas d'etre tres curieux sur la creation de jeux video, et en particulier la programmation.

Tout gamin en AMOS, j'avais utilise l'un des sprites par defaut pour faire un jeu ou un petit canard doit descendre une riviere en evitant des bouts de bois. Je m'etais inspire du niveau 2 des schtroumpfs sur Game Gear, mais le jeu ressemblait d'avantage a Falldown (que j'ai decouvert bien plus tard, au debut des annees 2000).

Ma routine etait extremement simple: joystick dans une direction = le canard se deplace d'un pixel. Comme le jeu etait concu pour attendre le rafraichissement d'ecran avant de lancer la frame suivante, ca marchait tres bien.

Plus tard j'ai fait un petit jeu de plate forme en C sur PC.

D'abord, j'avais essaye d'utiliser la meme approche, mais ca ne fonctionnait evidemment pas (selon la frequence de rafraichissement choisi, et a l'epoque sur CRT chacun bricolait sa frequence a soit dans son coin, le jeu allait plus ou moins vite)

Donc j'ai utiliser des timers, et le personnage se deplacait d'une distance proportionelle au temps ecoule depuis la derniere frame. Ca commencait a devenir un peu complexe, j'avais une fonction qui ne se chargeait que de ca.

Puis je n'etait pas satisfait de l'absence d'inertie, donc je faisais en sorte qu'atteindre la vitesse max du personnage ne soit pas instantane mais demande environ 5/10 de secondes. Encore une autre fonction.

Bref, plus j'avancais, plus je creeais d'intermediaires entre la pression de la touche et le deplacement a l'ecran. Et je prend l'exemple du controle, mais c'etait valable pour a peu pres tous les elements. Je ne creais pas un moteur de jeu, juste "mon jeu" directement, mais petit a petit j'implementais ce qu'un moteur de jeu devrait faire.

Il aurait simplement fallu mieux decouper/separer la partie "moteur" du reste pour obtenir un moteur de jeu.

Rien de bien sorcier la dedans, il suffit de vouloir creer son jeu de maniere naive et directe, en se basant simplement sur son intuition de "comment donc que ca pourrait bien fonctionner ?", et petit a petit, en resolvant les problemes successifs, on "cree" naturellement le moteur sans s'en rendre compte.

Le plus dur dans un "petit" jeu 2D, ce n'est pas le code. C'est avoir les bonnees idees de game design, les sprites, les sons, et surtout la volonte quand on commence a realiser que meme notre petit jeu de rien du tout que l'on imaginait etre une rigolade represente en fait un travail de fourmi, repetitif et de longue haleine.

Je pense comme Nordine que même avec des outils "tout en un", à un moment où un autre, et surtout si on veut un minimum de flexibilité ou de spécificités, on doit finir par programmer, que ça soit sous forme de code ou de "blocs", etc..
On peut ignorer totalement certains aspects de technique pure qui eux seront gérés par l'outil (par exemple tout ce qui est la gestion de la mémoire, le fonctionnement du renderer, etc.) et ne pas se soucier d'optimisations d'aucune sorte, mais il y a bien un moment où il faut définir/préciser en terme de programme le gameplay.
Et que cela soit fait en code ou sous forme de blocs, à mon sens ça revient un peu au même : c'est de la programmation

@Nordine :

Pas sûr d'avoir compris le problème, là

Je vois bien la problématique pour la définition des réponses aux interactions entre les objets, par contre.
Tu peux peut-être définir la précédence des objets les uns par rapport aux autres à l'aide d'une structure de données adaptée (tu peux t'aider de la notion de lieux pour définir plus simplement l'accès initial aux objets), et à partir de là sortir automatiquement la liste des combinaisons possibles - sachant qu'en fonction du type d'interactions, le nombre doit vite exploser - d'ailleurs il me semble que pas mal de point'n click utilisent des réponses génériques à beaucoup d'interactions, ne proposant des réponses spécifiques que pour certaines d'entre elles.

@Rainmaker : si tu t'intéresses à la conception de moteurs de jeux, je te recommande ce livre, assez complet et même accessible aux débutants en C++, vu qu'il y a des rappels.

Houla tes un sauvage presque 900pages en anglais en plus J'aime pas lire, encore moins des bouquins de codes ^^ Mais merci pour la référence.

Faudrait que je choppe les bonnes lib. Visiblement QT ca à l'air de bien marcher maintenant.
J'avais eut une mauvaise experience avec à la fac, y'a 12a maintenant (putain 12a....)


_________________

Etonnant, le titre du topic, parce que perso, je me fais justement la réflexion inverse "Comment serait-il possible de faire un jeu sans savoir programmer ??".
Etant programmeur et ayant tenté beaucoup de choses, je suis convaincu que c'est tout bonnement impossible. Les moteurs de jeu prennent en charge un tas de choses très lourdes à développer et permettent pas mal de raccourcis mais dès qu'on veut réellement prendre la main (ce qui est normalement le cas de toute personne exigeante niveau gameplay), on est obligé de savoir programmer pour définir précisément la mécanique du jeu (IA, mouvements particuliers des cameras, mouvements particuliers du perso, gestion évoluée de collisions, ...).
Ce constat est assez triste, et c'est ce qui empêchera nombre de fans de jeu video de ne jamais pouvoir concrétiser leurs idées.

@Rainmaker : je vois pas trop l'intérêt d'apprendre à faire un moteur de jeu, c'est un peu trop ambitieux quand on est pas un grand studio avec des exigences très spécifiques. Non ?
Et si tu ne posais la question que par curiosité, je t'invite à jeter un coup d'oeil à XNA qui est à mi-chemin vers un moteur de jeu. Mais bon, si t'aimes pas lire, t'es mal barré

C'est vrai que l'on peut trouver cela dommage, mais quelque part, c'est légitime et cela concerne toute forme d'expression physique/artistique : le pan technique n'est jamais à négliger, que l'on peigne, danse ou programme - si tenté que l'on peut rapprocher la programmation de l'art, ce que je fais sans compromission, du moins peut-on parler parfois d'une forme de grâce ou d'élégance dans les lignes de codes souvent. L'on repense aux vers de Brassens, "sans technique, un don n'est rien qu'une sale manie".

Il faut qu'il y ait des idées, bien entendu, mais c'est aussi la confrontation avec ces idées et leurs expressions technologiques qui crée le jeu vidéo : l'on a tous des exemples en tête de titres qui, bien qu'ayant de charmantes intuitions, ne parviennent pas à être amusants car la technicité ne suit pas derrière. Le support participe au média : et si les outils évoqués plus haut permettent, raisonnablement, de sauter quelques étapes de programmation fastidieuses, ils ne parviennent pas à permettre d'affiner les choses comme tu le dis, Riki ; et c'est encore cela qui fait tout l'intérêt de la chose, l'astuce développée pour parvenir à maîtriser ces deux aspects du problème.
_________________

Perso, je ne trouve pas ca dommage.

Un grand jeu vidéo nait quand toutes les professions et les spécialités travaillent de concert.

Et cette synergie entre technique, art et design, c'est ce qui fait que le jeu vidéo est un média exceptionnel... Je préfère voir le jeu vidéo comme un vrai travail d'équipe que comme le boulot d'un seul gars dans son coin qui doive exceller sur tous les fronts.

En même temps l'un n'empêche pas l'autre non ? Et les deux peuvent (devraient ?) coexister pour faire le bonheur des joueurs, enfin c'est mon opinion.

Un papier intéressant sur le rapport entretenu entre l'apprentisage de la programmation par les plus jeunes et la vision qu'en ont les parents.
_________________

"Il n'est pas de lutte plus violente et déterminée que celle d'un homme face à son envie d'aller aux toilettes" - Karate Boy

N'oublions pas qu'un jeu vidéo est avant tout un programme
Ne voyez pas le code comme un obstacle à la construction d'un jeu, ça serait comme de dire que dimensionner des poutrelles est un obstacle à l'architecture. Le but c'est quand même que ça fonctionne.

_________________

Ended up in a stranglehold on a PVC chair