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]

Je ne suis pas sur d'avoir bien compris la question, mais je vais essayer de repondre -

Il faut bien dissocier la phase de compilation du programme de la phase de packaging des assets.

Au niveau du code source il y a tout un travail d'architecture logicielle a faire pour decoupler les librairies, du moteur, du framework, du projet en lui-meme (partie gameplay, ici).

Au niveau des ressources, on trouve generalement 2 grandes tendances :
- la compilation des assets (textures, modeles, sons, etc.) pour les stocker dans des formats proches du runtime et faciliter/accelerer chargement et streaming. On ecrit souvent des compilateurs et parsers maisons, qui peuvent parfois s'appuyer sur des outils externes, comme les libs nvidia/amd de processing des textures
- le packaging, ou on organise generalement les ressources dans des archives utilisees comme systemes de fichiers virtuels. Ca permet de masquer les fichiers a l'utilisateur, mais aussi de decoupler les fichiers logiques de l'arborescence physique sur le disque (qui peut etre TRES differente pour raison d'optimisation ; par ex. la disposition physique sur un support optique est prise en compte pour les temps de chargement)

Toute cette complexite n'est cependant vraiment utile que pour des AAA consoles. Pour des projets plus simples, tu peux te contenter par exemple de packager tes ressources dans une simple archive .zip (que tu renommes et/ou proteges par mot de passe). Tu gardes l'essentiel des avantages cites, avec une simplicite de mise en oeuvre bcp plus abordable.

Pour mon moteur sous SFML j'ai trois types de données : Les scripts Lua, les images et les données (comme JSON mais c'est un format maison), tout est en clair (après tout c'est plus drôle de pouvoir bidouiller). Cependant une fois le jeu fini, le créateur peut packager le contenu de son workspace dans un paquet (.msp) qui pourra être exécuté ou installé par le moteur (exécuté si c'est un jeu, l'utilisateur ne voit pas les données) et installé si c'est genre une lib pour le moteur, un pack de texture etc.. Un jeu peut aussi être installé si le créateur le permet et dans ce cas il sera reconverti en Workspace ce qui permet au joueur d'éditer le jeu si il a envie.