Je suis presque sûr que cela se fait le plus souvent dans un format propriétaire (binaire), en écrivant simplement chaque variable de la structure d'état de jeu que vous utilisez dans un fichier, ou en lisant ce fichier dans une instance de la structure. En C ++, par exemple, vous pouvez traiter un objet comme un tableau d'octets et simplement l'écrire () dans un fichier, ou fread () à partir du fichier et le restituer sous sa forme d'objet.
Si vous utilisez Java ou un autre langage, vous pouvez choisir d'utiliser la sérialisation pour rendre la tâche vraiment facile. L'explication Java est au bas de cette réponse; d'autres langages (de niveau supérieur à C ++) ont sûrement leurs propres bibliothèques de sérialisation ou fonctions intégrées, que vous devriez choisir d'utiliser. Peu importe l'inefficacité de la routine de sérialisation, l'espace sur le disque dur est bon marché de nos jours, surtout lorsque l'état du jeu ne devrait pas être très grand, et cela vous empêche d'écrire et de maintenir vos propres routines de sérialisation.
Vous ne devez absolument pas utiliser MySQL (lisez simplement la première phrase de cette revue ). Si vous avez vraiment besoin d'une base de données relationnelle pour une raison quelconque, utilisez SQLite ; il s'agit d'un système de base de données léger et existe dans un seul fichier de base de données. Mais pour la plupart des jeux, les bases de données relationnelles ne sont pas la voie à suivre, et les entreprises qui essaient de les utiliser finissent généralement par les utiliser comme table de recherche de valeurs-clés plutôt que comme une véritable base de données relationnelle.
Toute sorte de cryptage des fichiers de disque locaux n'est que de l'obscurcissement ; n'importe quel pirate informatique reniflera juste les données juste après que votre programme les ait déchiffrées. Je suis personnellement contre ce genre de chose, EN PARTICULIER avec les jeux à un joueur. À mon avis, les propriétaires du jeu (clients payants, pensez-vous) devraient être autorisés à pirater le jeu s'ils le souhaitent. Dans certains cas, cela peut créer un plus grand sens de la communauté, et des "mods" peuvent être développés pour votre jeu qui attirent plus de clients vers vous. L'exemple le plus récent qui me vient à l'esprit est le mod Portal in Minecraft récemment publié. Il est publié sur les sites d'actualités des joueurs sur Internet, et vous pouvez parier que cela a fait grimper les ventes de Minecraft.
Si pour une raison quelconque, vous êtes assez fou pour utiliser Java pour le développement de jeux comme je le suis, voici une explication rapide de la sérialisation en Java:
Conservez toutes vos données d'état de jeu dans une classe, rendez la classe sérialisable en l'implémentant
Serializable, utilisez letransientmot-clé si vous mélangez des variables instanciées spéciales dans la classe (les objets transitoires ne sont pas sérialisés), et utilisez simplementObjectOutputStreampour écrire dans un fichier etObjectInputStreampour lire à partir d'un fichier . C'est ça.
[field: NonSerialized]Si vous écrivez votre propre code, disons en C ++, vous pouvez utiliser des fichiers binaires. Les fichiers binaires vous offrent une forme de cryptage par obscurcissement. Mais comme documenté partout sur les internets, c'est une forme de sécurité très faible.
OU, vous pouvez utiliser quelque chose comme RapidXML si vous voulez une solution lisible par l'homme.
Si vous utilisez une sorte de framework, examinez ses fonctions de support de fichiers. HTH
la source
La plupart des jeux que j'ai vus utilisent simplement du code manuscrit pour lire / écrire à partir de fichiers binaires. Souvent, le format sur disque sera une réplique exacte de la disposition de la mémoire d'un objet, le chargement est donc juste:
C'est rapide, mais c'est une corvée à maintenir, spécifique à la plate-forme et inflexible.
Dernièrement, j'ai vu quelques jeux utiliser SQLite. Les gens à qui j'ai parlé semblent l'aimer.
la source
La sérialisation est mentionnée dans certaines des autres réponses, et je conviens que c'est une solution raisonnable. Cependant, il échoue dans le versioning.
Supposons que vous libériez votre jeu et que les gens y jouent et créent des sauvegardes. Ensuite, dans un patch ultérieur, vous souhaitez corriger un bug ou ajouter des fonctionnalités. Si vous utilisez une méthode de sérialisation binaire simple et que vous ajoutez un membre à vos classes, votre sérialisation peut ne pas être compatible avec les anciennes sauvegardes lorsque les clients installent votre correctif.
Quelle que soit l'approche que vous utilisez, assurez-vous de penser à ce problème avant de lancer le jeu la première fois! Les clients ne seront pas satisfaits s'ils doivent recommencer après avoir appliqué un patch.
Une façon d'éviter cela consiste à faire en sorte que chaque type de données de base implémente des méthodes Save (version) et Load (version) suffisamment intelligentes pour savoir quelles données enregistrer et charger pour chaque version du jeu. De cette façon, vous pouvez prendre en charge la compatibilité descendante de vos sauvegardes et échouer avec élégance si un utilisateur essaie de charger une sauvegarde depuis une version plus récente du jeu que celle qu'il exécute.
la source
Si vous pouvez utiliser le même format que vous utilisez pour stocker vos niveaux, c'est un bonus.
Par exemple, un jeu comme Peggle peut avoir une disposition initiale du plateau, le nombre de balles, le score actuel (0 pour le plateau initial), etc. Une partie enregistrée peut alors utiliser exactement le même format.
Si vous utilisez le même format, le jeu de sauvegarde et la charge de niveau peuvent partager du code, ce qui facilite votre travail!
Pour un jeu avec de très gros fichiers de carte, le jeu de sauvegarde peut inclure le fichier de carte par référence. Les fichiers de niveau initial peuvent même faire la même chose, ce qui facilite également le retour sur cette carte si, pour une raison quelconque, l'histoire a fait revenir le personnage au même endroit, sauf que certains PNJ sont morts et qu'il y a des cadavres allongés tous plus de.
la source