Most games once reaced a certain size will need to persist data between game sessions. In our game dev jargon, we call this data a Save Game.
Your first reflex would be to think: oh this is easy, we only need to find the user's documents or data folder and use simple file read and write operations to handle the save data.
Assumming we are using the Zig programming language, our favorite here at Cold Bytes Games, and the library known-folders, a naive save game serialization code could look like this (this code has not been tested).
const known_folders = @import("known-folders");
const std = @import("std");
pub const SaveGame = struct {
current_level: i32,
death_count: i32,
huge_sword_unlocked: bool,
awesome_shield_unlocked: bool,
const Name = "SaveGame.sav";
pub fn read(path: []const u8) !SaveGame {
var file = try std.fs.cwd().openFile(path, .{});
defer file.close();
var reader = file.reader();
var result: SaveGame = undefined;
result.current_level = try reader.readIntLittle(i32);
result.death_count = try reader.readIntLittle(i32);
result.huge_sword_unlocked = try reader.readByte() > 0;
result.awesome_shield_unlocked = try reader.readByte() > 0;
return result;
}
pub fn write(self: SaveGame, path: []const u8) !void {
var file = try std.fs.cwd().createFile(path, .{});
defer file.close();
var writer = file.writer();
try writer.writeIntLittle(i32, self.current_level);
try writer.writeIntLittle(i32, self.death_count);
try writer.writeByte(std.mem.toBytes(self.huge_sword_unlocked));
try writer.writeByte(std.mem.toBytes(self.awesome_shield_unlocked));
}
pub fn delete(path: []const u8) !void {
try std.fs.cwd().deleteFile(path);
}
};
pub fn main() !void {
var gpa = std.heap.GeneralPurposeAllocator(.{}){};
var document_path_opt = try known_folders.getPath(gpa.allocator(), .document);
defer gpa.allocator().free(document_path_opt);
if (document_path_opt) |document_path| {
var save_file_path = try std.fs.path.join(gpa.allocator(), &.{ document_path, "Cold Bytes Games", "MyGame", SaveGame.Name});
var save_game = try SaveGame.read(save_file_path);
save_game.death_count += 1;
try save_game.write(save_file_path);
}
}However, once you want to submit your game to a store that use cloud storage or submit your game to consoles, handling save game gets a little more involved.
In this article, we would like highlight things to keep in mind while implementing save data management.
Some definitions:
- platform = any online service (Steam, EGS, GDK) or console
- system = a sub-system inside your game engine.
Once you know that save data can be syncronized to a cloud storage, never assume that any save operation will execute and resolve instantly. Execute your save operation on another thread or queue a task in your task system. It is far more important on some platforms because their save game API needs to be executed on another thread than the rendering thread if you use the blocking version of their API.
For reading, you should display any loading indicator in your UI before showing a list of your save data or any save information.
For writing, usually games display an animated save indicator at the bottom-right on the screen to notify the user that their previous save data information is persisted.
Like stated before, some platforms use cloud storage and don't necessary use standard file operations. When using XGameSave from Microsoft GDK for instance, you need to handle containers and blobs.
If you have a hard time imagining what is a container and a blob, here an example how you could configure your save data using GDK:
+ My Game Name (Container)
- First Save Slot (Blob)
- Second Save Slot (Blob)
- Third Save Slot (Blob)
- Options (Blob)
So your save game management should always serialize to memory and let the specific platform implementation handle how it is serialized on disk or to the cloud storage.
On some platforms, multiple users can be logged at the same time and save game need to be handled per user. With some API, you need to pass an user handle in order to open the save data repository. For single player games, it is really easy to handle you just use the initial logged user but for local multiplayer games you'll need to tie save game data to a user.
Always initialize your user management system before initializing your save game management system.
On some platforms, you can use standard file operation, but you'll need to open a special save folder first. And they expect you to use the path given to you for that opened directory.
On some platforms, it is required that when opening your save data repository that you handle typical errors and let the user decided to how handle it.
If you are lucky, there is some platforms that have standard system dialogs for those failures.
It is recommended to display to the user that a save game got corrupted. You can let the user deals with it and delete/overwrite the corrupted save.
Display a dialog that display the space required to create a new save game so that the user know how much space it need to reclaim from its file system in order to save.
On some platforms, when opening your save data repository, you'll need to pass the maximum size of your save game data. So know the maximum size of all your save game data.
Include a version field in your save game. It will really useful to be able to read any save game from a prior version of your game and migrate it to a newer version.
An quick example:
const Version_AddedInventory = 2;
const Version_NewInventory = 3;
pub fn read(self: SaveGame, serializer: Serializer) {
const version = serializer.readIntLittle(u16);
// Format of the inventory was changed
if (version < Version_NewInventory) {
var old_count = serializer.readIntLittle(u32);
// Assume code to insert old data into the new format
} else {
// Read new version of the inventory
}
}Use a binary or text format that can loaded back into a dictionary or a generic object so you can retrieve any fields by name or id. It will simplify the handling of the previous advice but it can be done without a structured format as well.
I hope you have enjoyed my advice on how to handle save game in your game. In the future, I may dedicate another article on how I implemented my save game system inside our engine.
Don't delete user files without notice.
Don't discourage people from tinkering with game files.