Tables MySQL Metin2 : structure player et account

Quand vous lancez un serveur Metin2, tout — du combat aux guildes, des inventaires aux guerres de guildes — réside en réalité dans MySQL. Les tables MySQL Metin2 sont la mémoire persistante de la logique de jeu : le cœur (les processus db et game) lit, écrit et met en cache ces tables. La source standard du serveur Metin2 répartit les données dans deux bases distinctes : account, qui contient l'authentification, et player, qui contient tout ce qui est en jeu. Dans cet article, j'explique clairement les tables principales des deux schémas et le rôle de chacune.

Deux bases de données : account et player

Séparer les données en deux espaces logiques est un choix délibéré dans Metin2. Les informations de compte/connexion (login, mot de passe, statut de bannissement, e-mail) résident dans la base account, tandis que les personnages, objets, guildes et quêtes résident dans la base player. Cette séparation facilite l'ajout ultérieur de plusieurs mondes de jeu (canaux) au même système de comptes et le maintien de frontières d'autorité distinctes.

account — authentification, paiement/cash, bannissements et codes de sécurité.
player — état du jeu : personnages, objets, guildes, coffre, quêtes, liste d'amis.

La base account

La table la plus importante est la table account. Chaque ligne représente un compte de joueur. Les colonnes typiques sont :

id — la clé primaire unique du compte ; account_id dans la table player y est lié.
login — le nom d'utilisateur (pour se connecter).
password — le mot de passe, haché avec la fonction PASSWORD() de MySQL.
social_id — un second mot de passe de sécurité (pour le coffre/le code).
email — l'adresse e-mail du compte.
status — statut du compte (par exemple OK ou BLOCK).
securitycode, availDt — code de sécurité et date d'expiration de validité/premium du compte.

Une requête simple pour voir comment le mot de passe est stocké :

SELECT id, login, status FROM account.account WHERE login = 'joueur1';

À la création d'un compte, le mot de passe est écrit sous forme de hachage, pas en clair :

INSERT INTO account.account (login, password, social_id, email)
VALUES ('joueur1', PASSWORD('motDePasse'), '7777', 'mail@exemple.com');

Le cœur de la base player : la table player

La table player contient chaque personnage sous forme de ligne. Du niveau du joueur à sa position, des stats à l'or, tout y est. Colonnes couramment utilisées :

id — la clé primaire du personnage (souvent appelée pid).
account_id — le compte auquel il appartient (account.account.id).
name — nom du personnage (unique sur le serveur).
job — classe (0 guerrier, 1 ninja, 2 sura, 3 chaman).
level, exp, level_step — niveau et expérience.
st, ht, dx, iq — force, vitalité, dextérité et intelligence respectivement.
gold — le montant de yang du personnage.
hp, mp, stat_point, skill_point — vie/mana et points non distribués.
map_index, x, y — la carte où se trouve le personnage et ses coordonnées.
part_main, part_hair — l'arme/armure équipée et l'apparence des cheveux.
skill_group, playtime — l'arbre de compétences et le temps de jeu total.

Pour lire le niveau et l'or d'un personnage :

SELECT name, level, gold, map_index
FROM player.player
WHERE name = 'Heros';

Emplacements de personnages : player_index

Un compte peut porter plusieurs personnages. La table player_index enregistre quel compte possède quels identifiants de personnage. On y trouve généralement un id (account_id) ainsi que les colonnes pid0, pid1, pid2, pid3, chacune pointant vers un emplacement de personnage. L'écran de sélection des personnages lit cette table.

Objets : la table item

La table item contient tous les objets physiques du jeu (inventaire, équipement, coffre) dans une seule table. Colonnes importantes :

id — l'identifiant unique de l'objet.
owner_id — le pid du personnage qui possède l'objet.
window — où se trouve l'objet (INVENTORY, EQUIPMENT, SAFEBOX, MALL).
pos — la position de l'emplacement dans cette fenêtre.
vnum — le numéro proto de l'objet (de quel objet il s'agit ; il pointe vers item_proto).
count — la quantité (pour les objets empilables).
socket0–socket2 — pierres serties ou valeurs spéciales.
attrtype0–attrtype6 et attrvalue0–attrvalue6 — les types et valeurs de bonus de l'objet.

item_proto et mob_proto sont les tables « modèles » : elles définissent les propriétés de base de chaque objet/monstre (nom, type, prix, attaque). Le vnum de la table item correspond à une ligne de item_proto.

Guildes, coffre et autres tables

Les systèmes sociaux et de progression vivent dans leurs propres tables :

guild — nom de la guilde, chef, niveau et expérience.
guild_member — quel personnage est dans quelle guilde et à quel rang.
safebox — mot de passe du coffre et or du coffre ; les objets eux-mêmes restent dans la table item avec window=SAFEBOX.
quest — les drapeaux de quête de chaque personnage (progression de quête en clé/valeur).
affect — états de buff/effet qui persistent quand un personnage se déconnecte.
messenger_list — relations de la liste d'amis.

Ces tables sont reliées entre elles par le pid (identifiant du personnage) ; par exemple, vous récupérez tous les objets d'un personnage avec la relation item.owner_id = player.id. Une fois le schéma lu selon cette logique, le désordre apparent devient une structure relationnelle propre.

Points de vigilance lors du travail avec les tables

Un point important : le processus db met en cache les données de personnage et d'objet en mémoire. Si vous exécutez un UPDATE directement pendant que le joueur est en ligne, les données que le cœur écrit à la déconnexion peuvent écraser les vôtres. Faites donc les modifications de données lorsque le joueur est hors ligne, faites toujours une sauvegarde d'abord (mysqldump), et testez dans un environnement de préproduction.

Questions fréquentes

Pourquoi les bases account et player sont-elles séparées ?

Séparer l'authentification des données de jeu apporte sécurité et flexibilité. Plusieurs mondes de jeu peuvent se connecter au même système de comptes, les permissions restent séparées et la table de connexion n'est pas affectée par la charge du jeu.

Où se trouvent tous les objets d'un personnage ?

Dans la table item de la base player. La colonne owner_id est égale à l'id (pid) du personnage ; la colonne window indique si l'objet est dans l'inventaire ou dans le coffre.

Est-il sûr d'ajouter de l'or pendant que le joueur est en ligne ?

Généralement non. Le cœur garde les données en cache et écrase la table à la déconnexion. La méthode sûre est d'utiliser une commande en jeu ou de mettre à jour lorsque le joueur est hors ligne.

Besoin d'aide pour modifier votre base de données Metin2 ou mettre en place un schéma propre ? Pour un accompagnement sur le schéma MySQL, les performances et la configuration du serveur, contactez-moi.