En tant que développeur, je vais te faire pas mal de réponses précises sur l'idée de faire "du jeu vidéo".
Le domaine est extrêmement vaste, ce qui sous-entend que les compétences peuvent être variées.. malheureusement!
Cependant, on peut résumer l'idée sur trois axes principaux
1° La conception
Quand on programme, connaître le langage ne suffit pas du tout. Il y a des concepts derrière qui nécessitent de la réflexion, de l'étude, et surtout de la maîtrise une fois que l'on s"attaque au code.
Il y a plusieurs concepts
- Algorithmie: comment se comporte le programme
- L'architecture: comment on "organise" le code et les composants. Il y en a plusieurs radicalement différentes
- La conception objet: indispensable à maîtriser pour pouvoir ne serait-ce que commencer à coder à peu près proprement.
2° Les langages
Les plus courants sont nécessairement de type "objet" (d'où la remarque précédente), et ont des syntaxes qui, si elles se ressemblent, ne sont en rien identiques.
- C/C++ : les fondements. De "moins en moins" (quoique...) utilisés au profit de C# (prononcer C Sharp)
- Java: utile mais pas toujours indispensable. Je ne connais pas vraiment de projet de jeu complet tournant avec ce langage (mais ça n'exclue pas que cela existe!)
- Objective C: pour Mac/IOS
- Flash: au cas où tu commencerais par des mini jeux sur navigateur.
3° Les outils annexes
Certains développeurs utilisent des environnements "déjà prêts". En 3D, c'est assez courant d'utiliser un moteur (Cry Engine, Unreal Engine etc...). Ce sont des logiciels costauds de conception 3D, avec en interne du langage spécifique pour faire les scripts. Cela nécessite une couche supplémentaire de compétences, et un côté artistique pour concevoir les objets 3D intégrés au jeu.
J'ai entendu parler de moteur spécifiques aux jeux 2D... Mais je ne maîtrise pas du tout le périmètre.
Tu as aussi unity qui est de plus en plus courant et qui gère la 3D de fort belle manière.
4° la conception du "premier jeu"
Ne surtout pas être trop ambitieux. Il est aisé de se noyer soi-même en pensant "tout faire". Ce n'est pas si simple.
Généralement, je suggère d'oublier le côté graphique pour déjà mettre au point un moteur de jeu.
Exemple: un petit soft de duels de personnages en rédigeant des règles de combat façon RPG (points de vie/magie/mana, défense, armure...). En enrichissant au fur et à mesure, on connaît de mieux en mieux l'environnement de développement (ce qu'on appelle un IDE), et l'on se familiarise avec le debug (analyse en live du code qui s'exécute).
Les étapes pour un mini jeu non graphique sont:
- J'écris sur le papier les règles que je veux établir
- Je commence à mettre en place une ou deux règles élémentaires
- Je teste et je valide
- J'ajoute dedans une nouvelle règle
- Je teste et je valide
Je continue ainsi de suite jusqu'à avoir un moteur "viable" même s'il est minimaliste.
Ensuite:
- J'apprends à stocker l'information (résultats... mini base de données? fichier texte? Fichier binaire de sauvegarde?)
- J'apprends à améliorer l'interaction avec le joueur (interface super simple de boutons? Intégration de graphismes? Librairies complémentaires?)
- Je continue ainsi de suite jusqu'à ce que le jeu, en deux joueurs (sans IA) fonctionne correctement
- Je m'attaque à la compréhension de ce qu'est une pseudo IA minimaliste (du style "si le joueur attaque, l'IA regarde son niveau de vie, son niveau d'armes, et estime si le PNJ doit ou non fuir sous les coups de l'adversaire).
Et ainsi de suite.
Il faut faire preuve:
- de beaucoup de rigueur, DOCUMENTER un maximum pour savoir "ah oui j'ai fait ça parce que...", sous peine de ne rien comprendre à son propre code.
- De patience, coder s'apprend assez "vite" (quelques semaines de pratique et l'on fait des petites choses rigolotes), mais requiert de l'expérience, et l'on en apprend tous les jours quand on programme
- De l'imagination, car il faut parfois trouver des solutions à des problèmes totalement imprévus. Par exemple, un cas stupide: j'ai un inventaire de matériel. Je gère le nombre d'emplacements. Ai-je prévu le cas où j'essaye d'ajouter un objet de plus dans un sac plein? Que faire? Refuser? Perdre l'objet? le garder en main et alors bloquer les combats ultérieurs?
Ce sont des choses à anticiper mais qu'on peut oublier faute d'y avoir songé au bon moment... d'où l'aspect initial de rigueur notée à plusieurs reprises.
Bon courage! il y a énormément de bouquins pour appréhender les bases du développement, beaucoup de tutos très bien foutus pour te faire saisir l'importance de la maîtrise des concepts de programmation (ce qu'est l'objet, les design patterns...)
