Principe de fonctionnement

ADS Save System sépare clairement l’orchestration d’une sauvegarde des données propres à votre jeu. Le ADS Save Subsystem coordonne l’opération ; les objets de votre jeu conservent la responsabilité de leurs données.

Les rôles

Le ADS Save Subsystem

Le subsystem est le point central du système. Il reçoit une demande de sauvegarde ou de chargement, prépare le Save Game Object, gère le slot, le niveau à ouvrir si nécessaire et l’ordre des opérations. Il sait aussi quand l’opération peut être terminée, mais il ne connaît pas la structure de vos données de jeu.

Il délègue donc la sauvegarde et le chargement effectifs aux participants, puis attend leur réponse avant de poursuivre. Une seule opération est traitée à la fois : cela évite d’écrire ou d’appliquer des données incomplètes.

Les participants

Un participant est un objet de votre jeu qui possède une partie de l’état à conserver. Il peut s’agir, par exemple, du personnage joueur, d’un gestionnaire d’inventaire, d’une quête, d’un système de progression ou d’un acteur important du niveau.

Chaque participant s’enregistre lui-même auprès du subsystem et s’abonne, sur son BeginPlay, aux dispatchers On Save Requested et On Load Requested. Il reste propriétaire de ses données : le subsystem ne décide ni quelles variables enregistrer, ni comment les restaurer.

Le Save Game Object

Le Save Game Object est la boîte commune qui voyage pendant l’opération. Les participants y écrivent leurs données lors d’une sauvegarde et les y relisent lors d’un chargement. Il contient aussi les informations gérées par le système, comme le slot, le niveau associé, la version et, si activée, la miniature.

Déroulement d’une sauvegarde

1. Votre interface ou votre logique de jeu demande une sauvegarde au subsystem avec Save Slot.
2. Le subsystem prépare le Save Game Object, puis appelle le dispatcher On Save Requested.
3. Chaque participant inscrit récupère ses propres données, les écrit dans le Save Game Object, puis confirme sa fin de traitement avec Set Part Saved.
4. Quand tous les participants attendus ont répondu avec succès, le subsystem écrit le Save Game Object dans le slot choisi et appelle On Save Completed.

Un participant qui ne répond pas, répond en échec ou dépasse le délai empêche volontairement la sauvegarde finale : le système préfère annuler l’opération plutôt que produire une sauvegarde partielle.

Déroulement d’un chargement

1. Votre interface ou votre logique de jeu demande un chargement au subsystem avec Load Slot.
2. Le subsystem lit le Save Game Object depuis le slot. Si la sauvegarde appartient à un autre niveau, il ouvre d’abord le niveau enregistré.
3. Lorsque le niveau est prêt, le subsystem appelle le dispatcher On Load Requested.
4. Chaque participant inscrit lit sa propre partie dans le Save Game Object, applique ses données, puis confirme avec Set Part Loaded.
5. Quand tous les participants attendus ont répondu avec succès, le subsystem appelle On Load Completed.

Ce que vous configurez dans votre projet

Votre projet décide quels objets deviennent participants et quelles données chacun doit gérer. Il déclenche aussi les sauvegardes et les chargements depuis son interface ou sa logique de jeu. Le subsystem, lui, centralise le cycle de l’opération, la coordination entre participants, les slots, les transitions de niveau et les notifications de fin.

Les sauvegardes manuelles sont choisies par le joueur. Les sauvegardes automatiques utilisent plusieurs slots à tour de rôle. Un profil distinct mémorise notamment la dernière sauvegarde connue. Enfin, si une sauvegarde utilise une ancienne version de vos données, la logique projet peut la convertir avant son chargement.