Folco, pour essayer de répondre à ton problème, voilà une proposition de quelques étapes à suivre. C'est une méthode qui peut sembler très "orientée objet", mais c'est souvent le cas (ce sont les langages objets qui ont été créés pour mieux coller aux méthodes, pas l'inverse) et tout ça reste parfaitement applicable à des langages non objet (ASM, C, etc). Voilà un plan très macroscopique, chacun pourra étoffer l'une des parties (ou en proposer un différent), j'écris juste ce qui me vient à l'esprit en vrac :

Avant de commencer un jeu, une application, ou n'importe quel programme, la seule chose dont tu disposes est une idée. C'est elle qu'il va falloir creuser pour en tirer peu à peu tous les besoins de ton futur programme. À ce niveau, ça reste très littéraire, tu pourrais imaginer un document qui ne contienne que des phrases du style "le programme doit permettre de faire ça". Pour faire la liaison avec le développement pour un client, c'est ici qu'on verrait apparaître le cahier des charges.

Une fois ces idées listées, tu vas pouvoir les regrouper par nature, en décomposant ton programme en entités logiques. Il n'y a pas de formule magique pour ça, et c'est donc la première réelle difficulté, mais ça reste souvent assez intuitif : pour un SMA, on va avoir des besoins liés au joueur (je veux que le personnage se déplace, je veux qu'il perde de la vie quand il touche un ennemi, etc...), des besoins liés au "monde" (je veux que mon niveau soit composé de tiles, je veux que ces tiles portent des informations sur leur nature : espace traversable, sol, échelle, etc...), des besoins liés aux interactions du joueur (je veux que le personnage se déplace en appuyant sur des touches...). Bref, tu vas te retrouver avec tout un tas d'entités logiques avec pour chacune un ensemble de fonctionnalités. Certaines de ces fonctionnalités peuvent d'ailleurs être partagées par plusieurs entités (par exemple "mon personnage ne tombe pas quand il est sur le sol" est lié aussi bien au personnage qu'au monde).

De ces fonctionnalités on peut extraire deux composantes : ce qui définit chaque entité, et les actions qu'elle peut faire. Avec "je veux que mon personnage perde de la vie quand il touche un ennemi", on met en évidence une caractéristique de mon personnage (ses points de vie) mais également le fait qu'il va falloir détecter les collisions avec les ennemis.

Si toutes ces étapes sont suivies et que tu n'oublies rien à chacune d'elles (c'est là que se situe la deuxième difficulté), tu devrais avoir alors une vision assez décomposée de tous les objets que ton programme doit savoir gérer, et de toutes les interactions qui vont devoir exister entre chacun d'eux. Il est alors temps de descendre encore d'un niveau.

Maintenant, il va falloir traduire tout ce que tu as obtenu dans quelque chose de beaucoup plus bas niveau : un langage informatique. C'est seulement maintenant qu'il entre en considération, ce qui veut dire que tout ce qui précède y fait complètement abstraction. Tes points de vie vont devenir des int sur 16 bits, ta détection de collision va devenir une fonction qui retourne un booléen (ou une section de code qui va activer je ne sais quel flag du cpu), etc. Tu vas pouvoir aussi en profiter pour découper ton programme en respectant la logique que tu avais déjà obtenue des étapes précédentes : ce qui est lié au joueur, ce qui est lié aux interactions homme-machine, ce qui est lié au monde...

Le fait d'avoir suivi ces étapes devrait t'apporter deux avantages :

- Tu sais à l'avance tout ce que tu vas devoir coder. Tu pourrais même avoir une "todo list" complète dès le départ, et cocher au fur et à mesure les fonctionnalités que tu codes pour te rendre compte de ton avancement et de ce qu'il te reste à faire, plutôt que d'avoir à te dire "hmm... je dois en être à 75% à peu près"
- Tu ne devrais pas être bloqué par un aspect auquel tu n'avais pas pensé au départ, puisque tu avais une vision complète de ton application avant de la coder, et que tu es arrivé progressivement au code

Bien sûr, tout ça mérite d'être très largement complété, discuté, remis en cause, etc... mais peut-être que ça te donnera des pistes à creuser pour te construire ta propre méthode de développement et pouvoir mieux appréhender des grosses applications.