Discussion :

[.Rain]

Bonjour, je souhaiterais commencer le développement de mon jeux, par un moteur 2D, qui devrait me permettre de créer mon jeux de manière graphique.

Cependant je n'arrive pas à déterminer comment une fois, le projet terminé graphiquement, j'en ressors un jeux, autonome, séparé du moteur dans lequel il a été créé.

J'ai pensé à trois solutions :

• Ecrire des fichiers json, qui seront parsés à l’exécution du jeux. Cependant ça n'est pas du tout sécurisés, l'utilisateur peut les modifier et le chargement peut devenir asse long en fonction de la taille du fichier à parser.
• Ecrire les classes et leurs contenus dynamiquement, c'est à dire que le moteur créera un nouveau dossier pour le projet, une classe Main et dans celle ci il écrira directement, le code source pour instancier les objets, faire appel aux méthodes etc.. Je trouve cette solution assez chiante à implémenter.
• Le top ça serait de compiler directement le projet dans le moteur et de ressortir directement un exécutable. Seulement je ne vois absolument pas comment utiliser un compilateur c++ dans une app, et de plus pour compiler il faut un code source c++, donc on en revient à la méthode du dessus ...

Je suis bloqué, pourriez vous m'éclaircir, sur la démarche à suivre ? MERCI.

[P.S:Je compte me baser sur SFML]

[ternel]

D'abord un gros avertissement:

Ne fais pas de moteur de jeu.

Un moteur de jeu est un sous-sytème de certains jeux. Il n'a d'intérêt que s'il est suffisamment souple pour être adapté à plusieurs jeux.

Code ton jeu, puis quand tu en auras un second en cours, la partie commune deviendra une amorce de moteur.
Un jeu est assez compliqué comme ca pour ne pas avoir en plus à prévoir ce qui sera utile dans un autre.


A présent, pour ta question proprement dite, regarde comment font les grands jeux professionels

Guild wars (1 ou 2) procède avec un gros fichier data.dat qui contient tout
Starcraft ou Diablo ont quelques fichiers de base.
la série des command&conquer ont des archives complexes souvent nommés machin.mix (dont on peut même extraire un sous-fichier, rules.ini)

D'une manière générale, les données ne sont pas dans l'exécutable, pour ne pas avoir à recompiler pour changer les données.
Une raison sous-jacente, c'est que la compilation du jeu est longue, et que les gens qui créent les données (level designer) ne sont pas ceux qui créent le binaire.

Fais un format très simple, textuel (json, xml, ini, ce que tu veux), et si tu veux un controle de qualité, regarde du coté des signatures de fichiers.

[Romaiiin]

Merci pour ta réponse complete !

Tu as raison c'est vrais que je n'avais pas pensais à ce probleme de temps de compilation pour un gros projet ca doit être infaisable !

Je vais suivre tes conseils ne pas commencer par un moteur car en effet c'est vrai que je ne savais pas par quel bout le prendre. Et stocker mes données dans des fichiers json.

[foetus]

Effectivement, les jeux ont un développement orienté données pour permettre aux créa et autres de tester/ montrer les "assets" de façon rapide.
Donc pas forcément utile pour toi Et comme dit leternel déjà faire 2-3 jeux, différentes approches avant de commencer à dégager un squelette de jeu ("back bone" il me semble)

Sinon, pour le parser, oui il peut être long, mais tu ne peux pas faire autrement.
Ensuite tu peux chiffrer tes "assets".

Et enfin, tu peux faire un système de DLLs/ plugins par niveau/ groupe de niveaux, si tu veux en plus du code de l'obfuscation, ...

[ternel]

Je te conseillerai de chercher à cloisonner ton jeu.

Que ce soit tetris, pong, pacman, zelda, diablo, starcraft, ou WoW, il y a toujours un schéma global en commun:

Il existe une situation courante du jeu.
Les joueurs demandent des modifications de cette situation (ordre aux unités, déplacement du personnage, tir)
le coeur du jeu exécute les demandes et controle le rythme d'évolution de la situation
L'interface graphique est un type de joueur (les autres étant un joueur distant sur le réseau, et les IA)
L'interface graphique présente cette situation courante avec un point de vue particulier, c'est aussi le point d'entrée des commandes du joueur
La partie chargement du jeu lit et écrit des fichiers correspondant à la situation du jeu.

Certains jeu dispose de deux voire trois ensemble de données.
Les données propre à la partie en cours, comme le nombre de point de vie du joueur
Les données maîtresse qui permettent de créer une situation réelle
Les données de contrôle de ces dernières.

Prenons un jeu de stratégie comme OpenRA (open red alert, reconstruction des jeux Westwood: Dune2000, Command&Conquer et Command&Conquer: Red Alert)
Il n'y a qu'un seul jeu, qui dispose de trois mods. Chacun liste les camps jouables, les types d'unités utilisables par ceux-ci, les cartes, le type de ressource utilisable, etc
Lorsqu'on lance une partie d'un de ces mods, le jeu crée une situation concrète, et commence à la faire vivre, jusqu'à la fin de la partie.

La situation concrète, ce sont des données vives comme les unités effectivement présentes, avec leurs points de vie, leur niveau, mais aussi l'argent de chaque joueur, son niveau technologique, etc
Les données maîtresse, c'est le fait que le camp "Soviétique" du mod red alert dispose de la bobine tesla, que celles-ci coute un certain prix, inflige tant de dégats, etc
La version du jeu, la liste des mods compatibles et le mod actuellement sélectionné constitue la troisième catégorie.

Mon gros conseil est de coder la situation de manière totalement autonome.
Puis de coder le coeur du jeu comme le chef d'orchestre: c'est lui qui gère les règles du jeu (vitesse des unités, dépenses des prix, etc), et applique les requetes du joueur
En parallèle, tu voudras probablement coder le joueur graphique qui ne doit en gros faire qu'afficher la situation courante et transmettre au coeur les actions du joueur
Et de même, le chargeur de données.

C'est la représentation interne de la situation courante qui est primordiale, et elle doit être autonome.
Certain jeu font des joueurs (dont le joueur graphique) des plugins extérieurs au code du coeur et de la situation