I am a novice programmer and just learned about the concept of saving and loading games. The way I am doing it is to write data into a text file and read it afterward. However, I realize how insecure this method is. What is going to stop someone to just open the text file and edit it? Furthermore, after going through game folders of popular games, I do not seem to find any text file dedicated to saving data at all. So there must be more advanced saving methods than simply writing and reading from a text file. What are they then and how can I do something similar to that? (I mainly use Java and C++)
-
2\$\begingroup\$ It sounds like you want to create a save file in a binary format, rather than text. There's a lot of existing guides about binary serialization out there to get you started. Once you've read up on some of the basics, want to edit your question to ask about any specific detail that's still unclear? \$\endgroup\$– DMGregory ♦Jun 18, 2020 at 0:44
-
4\$\begingroup\$ Keep in mind that even if you put your save data as binary files, it won't prevent from tampering with them completely. If a "hacker" is decided enough, they'll figure a way to reverse engineer the format and do modifications. If your game is a single-player, offline game, you typically don't have to worry about it, though. \$\endgroup\$– Vaillancourt ♦Jun 18, 2020 at 1:08
-
\$\begingroup\$ A good place to save, in windows, is in appdata. It is also common to save to the documents folder. And regardless of the format there will be meant to tamper it. \$\endgroup\$– TheraotJun 18, 2020 at 1:47
1 Answer
Text files are a perfectly fine way to create savegames. It's easy to implement and it allows you as the developer to edit savegame files in a text editor in order to test things more quickly.
But for easier parsing and better compatibility between versions, you might want to use a standard markup format like XML, JSON or YAML which you serialize and deserialize with a library. This requires some more time to set up correctly and learn the interface of the library (please don't try to write your own - pain and misery awaits you down that path). But when you got it running, it is usually worth it in the long run.
Another way to do savegames is to not use text files but binary files. This is often even easier to implement, because many data types which don't use pointers/references internally can just be written to disk as they are in memory. And they are often more compact than text-based savegames. But binary savegames are harder to troubleshoot because files are no longer human-readable and it is harder to ensure compatibility between versions.
When your savegames can get very large, then it can be useful to run them through a stock compression algorithm like ZIP to conserve the players storage space. It might seem counter-intuitive, but in some cases it even has speed benefits. Loading uncompressed data from storage can take longer than decompressing data in memory (sometimes - you might want to measure it on your target hardware).
Modern games usually do not store files in their own program directory. On some operating systems that's not even allowed anymore unless the game runs as administrator. Best practice is to store savegames in the personal files directory of the user. On UNIX systems, that's ~/.[game]
. On Windows, that's C:\Users\[username]\AppData\Local\[company]\[game]
. Many programming languages, frameworks and engines have platform-independent convenience functions to locate the user directory. Stackoverflow.com will certainly be able to tell you how to do it with the programming language / framework / engine you use for your current project.
Encrypting your savegames is usually not necessary. Few players will actually invest the effort to locate, understand and edit their savegames. Of those who do, they usually consider it a benefit if a game allows easy savegame editing. When it's a single player or cooperative multiplayer game, then editing a savegame allows the player to experiment with the game and create interesting situations or work around bugs. When it's a competitive multiplayer game, then any savegame data worth manipulating should be stored on a server, not on the clients.