Inventory system

Prompt de base pour IA:

je developpe un système d’inventaire pour MMO medfan sous unreal 5.

Structure des données :

– struct S_ItemInstance qui reprend ItemID, InstanceGUID, Quantity, Durability, Charges (pour baguettes par exemple)
– struct S_ItemTableRow qui reprend ItemID, ItemCategory, InventoryIcon, ItemWeight, GoldValue, MaxStackSize, ShortDescription, EquimentSlot, Rarity, BasicMagicCharge, IsQuickslotCompatible
– BP DA_ItemData composé des S_ItemTableRow
– data table DT_AllItems qui reprend tous mes S_ItemTableRow
– E_EquipmentSlot, enum des emplacements traditionnels, armure, bijoux, armes

Composant BP_InventoryComponent attaché aux différents types d’inventaires avec
1° variables:
– InventoryArray (de S Item Instance)
– EquippedItems (array de E_EquipmentSlot)

2° fonctions:
GetItemData
AddItemToInventory
RemoveItemFromInventory
CalculateTotalWeight
CalculateTotalMagicCharge (chaque objet magique a une valeur qui se cumule avec les autres, que le joueur ne peut pas dépasser, en guise de limitation de puissance)
ToggleInventory
RequestAddItem

BP_BaseContainer, placeholder pour les différents types de containers avec:
– InventoryComponent
– fonction TransferItemToPlayer

Interface graphique

1° BP GameUD dans lequel je peux afficher d’autres inventaires.

– On Drop qui acte le déplacement de l’inventaire à l’endroit choisi
– On drag over qui déplace le widget d’inventaire pendant le drag

2° WBP_InventoryScreen du joueur :

– Event Construct qui peuple l’inventaire par un bind event sur la fonction Populate Inventory Grid
– On mouse button down pour detecter un drag
– On drag detected pour initier le drag and drop, le default visual est non assigné pour que toute la fenêtre d’inventaire bouge

3° WBP_InventorySlot: les cases des inventaires avec:
– override du mouse button down qui appelle TransferItemToPlayer du BP_BaseContainer (logique temporaire de dev qui sera rapatriée dans l’inventory component au moment de la programmation de la réplication/sauvegarde DB)

Pour le développement, je dispose d’un coffre A_Chest02 de type BP_BaseContainer avec un BP_InventoryComponent et une variable InventorySize dans lequel je spawn un objet Test_Sword.

La réplication est écrite dans l’event graph de ce coffre. Réplication light, un seul utilisateur à la fois pour chaque container.

 

🛠️ Analyse Fonctionnelle : Système d’Inventaire et d’Interaction (Prototype Blueprint)

Cette analyse décrit la structure d’un système d’inventaire complet pour un prototype de jeu multijoueur, développé exclusivement en Blueprints, avec une attention particulière à la flexibilité pour une future migration de la persistance vers une API REST.

I. Objectif et Contraintes

Point Clé Détail
Technologie Uniquement Blueprints (pas de C++ pendant le prototypage).
Persistance Actuellement : Savegame. Évolution prévue : REST API.
Multijoueur Mode MMO minimal (réplication limitée au strict nécessaire).
Sécurité Priorité à la fonctionnalité et à la structure, non à la prévention de la triche pour cette phase.

II. Structure des Objets et des Données

Afin de faciliter la persistance et la gestion des mises à jour, la structure de l’objet est scindée en deux parties : les données statiques (référencées) et les données dynamiques (instanciées).

1. Data Asset / Données Statiques de Base (Immutable)

Toutes les données de base de l’objet sont stockées dans un Data Asset (ou une Data Table) et référencées par les instances dans l’inventaire.

  • Champs Clés :
    • Nom, Catégorie (Arme, Armure, Potion, etc.).
    • Icône et Image 256x256.
    • Poids unitaire, Valeur en Or unitaire.
    • Quantité Max par Pile.
    • Description Courte et Description Longue (“Utilisations possibles”).
    • Charge Magique de Base.
    • Qualité (Enum : Normal, +1 à +5) : Détermine la couleur du descriptif (Blanc, Vert, Bleu Ciel, etc.).
    • Slot d'Équipement (Enum) : Définit l’emplacement possible dans la garde-robe (Tête, Corps, Arme, None, etc.).
    • Quickslot Compatible (Bool) : Placeholder pour une étape future.

2. Structure d’Instance (FItemInstance)

Cette structure légère représente l’objet réel dans l’inventaire du joueur et sera stockée dans les tableaux répliqués.

  • Champs Clés (Répliqués) :
    • Item ID : Référence au Data Asset pour les données statiques.
    • Instance GUID (String) : ID Unique et Persistant pour suivre l’usure ou l’équipement spécifique.
    • Quantité (Int) : Quantité actuelle de la pile.
    • Usure (Float) : Valeur de 100.0 (Neuf) à 0.0 (Détruit). (Stocker et Afficher)

III. Gestion de l’Inventaire du Joueur

1. Inventaire Principal

  • Implémenté via un Blueprint Component (Inventory Component) attaché au Character BP.
  • L’inventaire est un tableau (Array) de FItemInstance.
  • Format : Grille de taille modifiable, initialement 6×12 avec barre de défilement.
  • Fonctionnalités : Déplacement d’objets, empilement, scission de piles. La position visuelle dans la grille n’est pas mémorisée.
  • Tri : Doit être triable par Nom, Type, Poids, Valeur, et autres critères à déterminer.

2. Variables du Personnage

Les variables suivantes sont gérées par le Character BP :

  • PlayerGold (Int) : Affiché à tout moment.
  • Poids Total : Calculé dynamiquement (Inventaire + Équipement) et affiché. Le calcul des effets du Burden est géré ultérieurement.

3. Garde-Robe (Touche C)

  • Implémenté via un Blueprint Component (Wardrobe Component).
  • Affichage : Vue de face du joueur au centre, listant les slots équipés.
  • Slots d’Équipement Prévus :
    • Tête, Épaules, Corps, Jambes, Chaussures.
    • Collier, 2x Anneaux, Brassards, Ceinture, Cape.
    • Arme Principale, Arme Secondaire / Bouclier.
  • Calculs Affichés :
    • Burden (Poids total de l’inventaire et des objets équipés).
    • Total Charge Magique (Somme des charges magiques des objets équipés).

4. Réplication

L’inventaire et les objets équipés du joueur sont répliqués avec la condition Owner Only (Serveur vers Client Propriétaire) pour minimiser la bande passante et assurer la confidentialité.

IV. Interactions et Transactions

1. Interactables

Un Interactable est un objet du monde possédant un inventaire.

  • Types : Coffre, Lootbag (droppé par monstre/joueur), Marchand.
  • Interaction : Par clic souris.

2. Inventaires du Monde (Règles d’Accès)

Les inventaires du monde sont répliqués de manière standard (du Serveur vers tous les clients).

  • Accès Exclusif : Un seul joueur à la fois peut ouvrir un inventaire mondial.
  • Fermeture :
    • Fermeture automatique si le joueur s’éloigne de plus de 3 mètres.
    • Fermeture automatique après 3 minutes d’inactivité.
  • Gestion du Loot : Les Lootbags sont détruits après 5 minutes pour éviter l’encombrement du monde (littering).
  • Déposer un Objet : Déposer un objet par terre crée un Lootbag.

3. Transactions (Marchands et Joueurs)

  • Déclenchement : Clic sur un marchand ou clic-droit sur un autre joueur (option “Trade”).
  • Panneau : Deux grilles, l’inventaire du joueur à gauche, l’inventaire d’échange (ou du marchand) à droite.
  • Logique : Les objets et l’or sont glissés dans la zone d’échange.
  • Affichage : La quantité d’or impliquée dans la transaction est affichée dynamiquement.
  • Validation : Un bouton “Accepter” envoie la transaction au Serveur qui exécute le transfert des objets et de l’or, après vérification de la disponibilité et de l’espace.

V. Persistance (Future Migration)

Concept

Le SaveGame actuel utilise des Structures Blueprints pour stocker l’inventaire. Pour préparer la migration vers une REST API, cette structure de données doit être naturellement compatible avec une sérialisation au format JSON.

Structure de Sauvegarde

L’inventaire du joueur sera sérialisé comme une simple liste (Array) d’instances d’objets :

$$\text{PlayerInventoryData} = [\text{FItemInstance}_1, \text{FItemInstance}_2, \dots]$$

Cette liste pourra être facilement sauvegardée en local via le SaveGame d’Unreal, ou envoyée comme payload à une future API externe.