Penser son jeu, c'est déjà le créer

Ceci est un copié collé de mon post sur le forum Construct-French, mais il a sa place ici aussi, et j'attends vos avis sur la question(maintenant que j'ai écrit ça, je sais que il va y avoir 53 allusions sexuelles sans rapport avec le post dans les com'):

Aujourd'hui, une discution pour apprendre à penser son jeu, afin de savoir comment l'organiser au mieux dans votre logiciel de création vidéo-ludique.
Note: Ceci est valable AVANT le début de la programmation, donc l'outil utilisé importe peu

Spoiler:

Quand vous comptez faire un jeu, il faut se poser plusieurs question avant même de commencer à programmer:

Questionman a écrit:

-Qu'est-ce que j'attends de mon jeu? (montrer une idée, être populaire, représenter la vie des canards-pastèques en mangeant des palmiers, etc..)
-Qu'est-ce que les joueurs peuvent attendre de mon jeu? (on pense surtout à une minorité de joueur, on ne peut pas plaire à tous)
-Comment représenter mon idée au mieux(si applicable)?
-Liste très loin d'être complète (si vous avez d'autres idées, n'hésitez pas à répondre )

hein? quoi? ah oui, j'ai pas encore parlé des problèmes liés à la programmation ou autre, car ces questions doivent venir Après que l'on sache ce qu'est le jeu.

Questionman a écrit:

-Comment rendre la vie du joueur plus simple au niveau confort de jeu, ex: choix des touches etc... (Je parle d'un point de vue confort, l'immersion d'un jeu pour moi, signifie la capacité d'un jeu à pouvoir faire penser le joueur sur ce qu'il va faire, ou ce qu'il ce passe, plutôt que sur "Zut! c'est ou que j’appuie déjà")
-Comment me rendre la vie plus simple niveau programmation/débogage (lorsque un programmeur est à l'aise dans son code, il aura plus de facilité à travailler, et sera donc plus efficace)
-Comment retranscrire l'émotion que doit susciter le jeu (musiques? graphismes particuliers? voix? il n'y a pas forcément besoin de grand chose dans certains cas, mais dans d'autres si)
-Sur quoi mon jeu va tourner? (si c'est sur mobile, il faudra tenir compte des faibles performances, et du touch screen)
-liste incomplète là aussi

Pour ma part, je pense que un jeu réussi signifie un jeu qui répond à toutes ces questions, et il vaut mieux se les poser AVANT de commencer quoique ce soit (c'est de là que viens l'idée de "commencez pas par faire la jaquette du jeu")

Maintenant, passons aux jeux qui démontres certains aspect auxquels il faut penser:
Dans Monster World 4 (mégadrive), Asha est le personnage principal, un personnage qui n'a pas un seul dialogue de tout le jeu, mais qui reste néanmoins attachant, de même pour son pepelogoo (une créature bleue toute mignonne), et ceux qui auront joué au jeu saurons que quand on voit cette scène (spoil): https://www.youtube.com/watch?feature=player_detailpage&v=iV_xvfGawmc#t=316s , on à tendance à se sentir mal, pourtant, les moyens techniques employés sont assez faibles, juste, ils sont bien utilisés, et ce, tout le long du jeu, en nous attachant aux deux personnages (on remarque aussi que la musique peu avant le boss final: https://www.youtube.com/watch?v=4bgdKLi6ysg impose le respect... bon le boss un peu moins, mais passons)

Donc, si vous voulez faire un jeu (aka: un jeu vraiment poussé, pas juste un test), la programmation sera la phase de réalisation, mais la phase de création est bien avant.

PS: merci de laisser un commentaire sur vos avis

Au niveau de la programmation, je peux te donner un conseil : abstraction.
Je veux dire par là éviter d'aller toute de suite dans le concret, le précis, pendant le développement. Exemple, tous les sprites seront à la base des Personnages qui réaliseront des action, et c'est par la suite que tu pourras les distinguer par leur méthode de contrôle.

Oui bon ca doit pas forcément être clair mais si tu programmais en Java, je te dirais de bien concevoir tes interfaces et d'utiliser de l'héritage, ca te faciliterait la vie.

ca reflechit dur ici !

sylesis a écrit:

Au niveau de la programmation, je peux te donner un conseil : abstraction.
Je veux dire par là éviter d'aller toute de suite dans le concret, le précis, pendant le développement. Exemple, tous les sprites seront à la base des Personnages qui réaliseront des actions, et c'est par la suite que tu pourras les distinguer par leur méthode de contrôle.

Oui bon ca doit pas forcément être clair mais si tu programmais en Java, je te dirais de bien concevoir tes interfaces et d'utiliser de l'héritage, ca te faciliterait la vie.

Pour ma part, je commence d'abord par voir les concepts de mon jeu, puis de comment les rendre réalisables.

La programmation est une étape importante, certes, mais elle ne doit pas être un frein à l'imagination, par exemple:

Je veux faire ça si la touche espace est appuyée, je répertorie les conditions, et les actions que je veux, toutes, et je fais ça pour la majorité des cas possibles, et ensuite je vois comment les lier. Ensuite, je regarde si je peux le coder, si oui, je fais, sinon, je regarde si il y a un moyen de faire quelque chose de similaire.

Bien entendu, si presque aucune des actions n'est possible, revoir le langage choisi.

Essaie une autre approche vis à vis du langage : définie les éléments de ton gameplay mais pour ce qui est du langage de prog, renseigne toi quant à celui qui serait le plus approprié pour faire un jeu. Tous ne conviennent pas et certains conviennent mieux à certaines situations ( je ne recommanderais pas Turbo-pascal pour gérer une base de donnée via une interface graphique, par exemple).
Quand tu l'auras trouvé, restes y et apprend le pour le maitriser : si tu creuses dans un langage, puis abandonne et creuse un autre, tu n'en sortiras jamais.

La programmation est un domaine dont je peux parler : à la fin de mes études, je voulais travailler dans le développement java. Ca ne s'est pas concrétisé mais je continue à toucher un peu à là JVM : j'ai codé un programme appelé Twindows pour mes besoins personnels ( le TW que l'on voit dans la barre de lancement sur mes captures Sonic Spinball) et je l'améliore quand j'ai besoin de fonctionnalités en plus. Sans être transcendant, je suis content de la façon dont il a été codé et n'ai pas honte de montrer mes sources.

"Tous ne conviennent pas et certains conviennent mieux à certaines situations ( je ne recommanderais pas Turbo-pascal pour gérer une base de donnée via une interface graphique, par exemple).
Quand tu l'auras trouvé, restes y et apprend le pour le maitriser : si tu creuses dans un langage, puis abandonne et creuse un autre, tu n'en sortiras jamais."

c’était bien ce que je voulait dire (je ne disais pas de changer de langage si ça marchait pas, mais de voir si ça serait possible avant de commencer).

Il faut en effet essayer de se tenir à un langage une fois choisi, et cela peut aussi être utile pour plus tard (on sait le maitriser déjà, donc si il convient de nouveau pour quelque chose, ça reste valable)

Le choix du langage dépend surtout de la plate-forme qu'on souhaite utiliser. En ce moment je bidouille sur Android, c'est soit Java, soit du C/C++, à la limite Unity (qui est un environnement complet, pas juste un langage).

Tout va dépendre aussi des frameworks disponible. Tout faire juste avec le langage "de base" c'est juste pas faisable actuellement.

Citation :

Tout faire juste avec le langage "de base" c'est juste pas faisable actuellement.

En effet, il n'existe pas de langage tout export, ou compilable pour tout (peut être l'ASM, mais ça serait vachement hardcore quand même)

Mais comme je l'ai dit, le choix du langage ne doit pas être ce qui va influencer ce que devrait être le jeu, le support lui par contre...si c'est Master System, on évitera d'essayer la 3D avec 2^19 - 1 couleurs au total.

Et si au final, c'est de l’interprété et non du natif, il faut là aussi voir si le support y arrive (les jeux pas navigateurs ne sont pas en natif il me semble)

Binding of Isaac est un exemple de jeu où le choix du langage(flash) à affecté lourdement le jeu (10 fps pour 20 mouches à l'ecran, c'est pas cool)

l'ASM n'est meme pas "multi supports".
les instructions sont "propres" au processeur. (68000, Z80, etc.)

avec du C voir du C++ tu es -je pense- un peu plus "fourre tout".

Perso en 1er définir sur quelle plateforme tu veux faire ton jeu, déjà meme sans penser "au code", tu sauras vers quelle(s) solution(s) tu pourras te tourner (et celles a bannir/impossible).
Tu connaitras aussi les contraintes (couleurs, nb de sprites, etc...)

ensuite je dirais une reflexion sur l'univers ; type de jeu, but du jeu, ambiance de couleurs, un synopsis qui tiens en 3 lignes max... ca devrait suffire a esquisser une/des maquettes.

Citation :

ensuite je dirais une reflexion sur l'univers ; type de jeu, but du jeu, ambiance de couleurs, un synopsis qui tiens en 3 lignes max... ca devrait suffire a esquisser une/des maquettes.

Il vaut mieux connaître le plus son jeu, peu importe le style, avant de commencer à le coder, afin de prévoir ce qui sera important, afin de pas faire des allers et retours sans cesse dans le code pour ajouter telle ou telle chose, niveau histoire, tu as raison, l'histoire n'est de plus, pas rattachée au code, à moins que on y fourre des cinématiques (dans ce cas, les prévoir serait une bonne chose).

Au niveau de la plateforme, en effet, c'est la première contrainte, et la seule que l'on ne peut influencer

pour ceux qui ont des problemes d'ASM, je recommande la ventoline !

Piranahman a écrit:

En effet, il n'existe pas de langage tout export, ou compilable pour tout (peut être l'ASM, mais ça serait vachement hardcore quand même)

C'est même pas de ça dont je parlais. Et l'ASM c'est bien le truc le moins portable qui soit tellement c'est spécifique à une plateforme.

Je parle de frameworks, le truc qui va te mâcher une bonne partie du boulot en fournissant des éléments de base pour développer. Par exemple LibGDX en Java, SDL en C, etc...

Pour l'asm, j'etais pas sur si c'etait tout ou rien ^^"'

Un framework, je vois bien ce que c'est, c'est un ensemble de choses prédéfinis, qui sont utilisables, plutot que de devoir réinventer la roue.

PS: j'ai l'impression que certains ont pas compris que le sujet était plus sur la préconception d'un jeu que sur sa programmation, mais ça reste interressant