Salut ! Y'a pas longtemps que j'ai commencer a apprendre Gamemaker et je voulais savoir (le problème n'est pas Gamemaker) par ou commencer le dev' d'un jeux ? Car j'ai un +ou - petit projet et je voulais savoir par ou commencer, et connaitre les étapes a suivre, car le soucis c'est que je commence quelque chose et je me dit que j'aurais du faire ceci avant ça, etc... du coup je me perd et je recommence.

Je doit commencer par quoi ? SVP (je parle au niveau programmation)

Commence par faire un gdd (game design document). Ca t'aide a organiser ton projet et y voir plus clair (meme pour un petit projet).

Ensuite pour la programmation ca depend vraiment de ton projet...

d'accord merci et tu pense qu'il faut que je fasse des note genre

si je clic sur ceci ça fais cela et ainsi de suite ?

Dis nous ce que tu veux faire et ton dira comment procéder et par ou commencer
Et surtout, on te dira si c'est faisable en tant que premier jeu.

Pour un débutant, la boucle idéale c'est :

1. Essayer de réaliser une idée
2. Échouer
3. Repenser/épurer son idée (pour qu'elle soit plus simple)
4. 1.

Si tu n'échoue pas et que tu réalise/publie ton idée/jeu, félicitation, tu peux passer a un autre projet !

ps: Je ne parle pas de prototype, je parle d'un vrai jeu avec un menu, un score, un systeme de sauvegardes, etc..
Les prototypes c'est bon pour les dev expérimentés qui connaissent leur limites et veulent juste savoir si leur idée est bonne ou pas. Toi tu veux apprendre, pour apprendre il faut programmer!

edit: je te conseil de commencer par faire un truc simple: pong.
C'est super simple :

1. Tu choisi un langage
2. Tu choisi un engine (genre GameMaker, Unity, peu importe)
3. Tu fais un pong (menus, score, AI, etc..)

Merci beaucoup je souhaite faire un top down shooter multi joueur local sur gamemaker mais mais dans le même principe qu'un super smash bros donc il faut pousser l'autre hors de l'arene

Quand je parle de multi local je parle d'un multi sur la même machine évidement

Je ne connais pas gamemaker.

Tu peux proceder comme ca :

1. Faire l'écran d'accueil / menu
2. Faire un niveau simple (1 seule plateforme)
3. Créer le joueur 1, reste simple.

A partir de la, tu peux étoffer :

1. Ajouter des rounds
2. Possibilité de choisir son joueur
3. Plusieurs niveaux
4. Des combos

merci beaucoup pour tes conseil hself

C'est aussi une question de préférence, personnellement je fait le prototype du jeu avant le menu.

Essaye de commencer par les parties les plus simple et une fois que ta une bonne base ( histoire de bien être motivé ) tu peux commencer les parties compliqué ( Networking , IA , Pathfinding etc etc).

Ne jamais se dire je fais le plus compliqué comme ça je suis débarasser et aprés j'aurai qu'a faire le plus simple Grosse erreur

Bonjour,

Le 11 janvier 2017 à 13:05:44 CPUGamer a écrit :
C'est aussi une question de préférence, personnellement je fait le prototype du jeu avant le menu.

C'est une très mauvaise option. Cela sous-entend que soit vous n'avez pas assez réfléchi sur ce que vous allez proposer aux joueurs, soit que vous écrivez et adaptez votre GamePlay au fur et à mesure de vos compétences et ou de découvertes de l'outil que vous utilisez.
D'autre part entre votre création et l'user (dans ce cas le joueur, on va dire de façon plus générique "Le client"), c'est une des première interfaces qui va conditionner le fait de cliquer sur suivant ou sur l'action Cancel.
Vous devez donc amener le client à avoir l'envie de continuer cette nouvelle expérience et mettre toutes les chances de votre côté.
C'est le Gui de départ qui conditionne cela (votre menu start en fait).
Cela finalement va vous obliger a valider a

Pour l'auteur du sujet :
Bon, il existe tellement de choses à dire sur l'aspect interface Appli=>User que des tonnes de paragraphes pourraient être mises en ligne.

De toute façon la logique minimale expliquée par "hself" est une bonne option d'organisation de planning de départ.

À noter toutefois, qu'il existe dans toute création dite technique, une notion qui n'est jamais employée ici, qui est une étape de faisabilité technique. Cela est bien en amont de l'aspect prototypage.
Cette étape est cruciale et permet de façon concrète de valider la faisabilité du projet et qui tient compte d’une part de ses capacités, de ses connaissances techniques et ou de ses possibilités d'auto apprentissage.
Tout cela est très récursif car on ne peut connaitre sans apprendre, et l'on apprend d'autant plus si l'on connait.
C'est un processus facile pour certains, pour d'autre c'est une vrai galère (question de gènes peut être ?).

Maintenant pour vous répondre de façon plus personnelle à votre demande initiale.
Ne vous embêtez pas à réinventer la roue.
Prenez simplement un jeu de type basique qui comporte un exemple d'évolution de Game Play(je n'aime pas ce terme).
Tentez de réaliser la même chose avec les outils que vous pensez pouvoir maîtriser à terme.
Ayez toujours l'esprit que le remake que vous créez est à destination des joueurs (clients) et non pour votre égo.
Pensez toujours, que même si vous êtes seul dans votre démarche de création, celle-ci doit être mise en place pour que celle-ci soit possible dans un travail en équipe avec d'autres partenaires.
Prenez du recul, le temps de la réflexion est votre alliée. Réfléchir pendant des mois n'est pas une tare, pisser de la ligne sans ligne directrice en est une.
Envisagez toujours que votre projet actuel puisse être porté dans un autre environnement de dev, moteur, de support.
Ne prenez pas mon intervention comme argent comptant, nous sommes juste sur un forum d'échanges d'opinions à défaut d'être technique.

Si vous avez besoin d'aide, mes MP sont ouverts.
Bonne continuation.

UnityCoder Je t'aime il est toujours aussi plaisant de lire tes pavés, c'est instructif, c'est bien écrit, c'est détaillé et surtout ça change du 18-25
Dès que je voie une de tes réponse sur un topic je ne peu empêcher de la lire j'y apprend toujours quelque chose

Personnellement j'ai toujours lu qu'il fallait commencer par un prototype, et si quelqu'un cherche un tuto sur n'importe quel langage, le menu sera probablement fait en dernier ou presque dans le tuto.

Le menu c'est un peu l'emballage final... le coeur du jeu passe avant selon moi

Tu peux reflechir a un concept autant que tu veux et le detailler sur papier tant que tu ne le tests pas tu ne peux pas savoir a coup sur si il va fonctionner ou pas.

C'est pour cette raison que la plupart des programmeurs font un prototype pour commencer, pour tester le concept et voir si il est fun.

Faire un menu avant ca est une perte de temps a mon sense mais bon apres chacun a sa manière de travailler.

C'est aussi une question de préférence, personnellement je fait le prototype du jeu avant le menu.

C'est une très mauvaise option. Cela sous-entend que soit vous n'avez pas assez réfléchi sur ce que vous allez proposer aux joueurs

Je ne peux etre qu'en desaccord profond avec ce propos -

Le gameplay, ou experience de jeu au sens large, est par essence voué a changer et a evoluer au fur et a mesure de la construction du jeu. La creation d'un jeu est un processus fortement iteratif, et il faut composer avec cela car c'est la nature meme du produit. Ce n'est pas pour rien si de nouvelles methodes de travail et de production ont emergee pour supporter les projet creatifs. Designer sur papier un truc qui sera "fun" a coup sur, ca n'exite pas.

C'est pourquoi, toujours, le gameplay passe avant tout. Puis on raisonne par prioritisation ; notamment en terme de risque et de faisabilite. Or les menus ne presentent aucun facteur de complexite, ce n'est que le l'habillage et la qualite sera proportionnelle au temps passe en phase de production.

La ou ca peut devenir interessant, c'est les cas ou l'interface utilisateur fait partie du gameplay, c-a-d souvent les puzzle games. On prototype donc l'ergonomie de l'UI en meme temps que le gameplay. Mais ce n'est pas du tout ici le cas, ou on parle de simples menus.

On peut faire un jeu avec des menus basiques ; on ne peut pas faire un jeu qu'avec les menus.

Euh..
J'ai mi les menus en #1 mais c'était totalement arbitraire. Arretez de vous batté!

Certes ce n'etait qu'un exemple, mais la discussion qui s'en suit montre des approches bien differentes, donc le debat est interessant en soi.

Oui tout y es a prendre

En effet.

Meme si, a l'heure actuelle je n'ai fait que des simples reproductions de classiques, j'ai toujours fait les menus en dernier. Allez savoir pourquoi je l'ai mis en #1 dans ma liste...

ça doit être une peu l'usine à gaz de faire les menu après le gameplay en tout cas, il faut bien avoir fait un code propre au préalable pour savoir quel bloc de code exécuté ou non selon le menu actuel