Un site de base de données Metin2 transforme les données d'objets et de monstres du jeu en un wiki web que les visiteurs peuvent chercher et filtrer. Les joueurs peuvent répondre à des questions comme « où tombe cet objet ? », « quel est le niveau de ce monstre ? » ou « quels bonus donne ce costume ? » sans se connecter. Dans ce guide, je détaille comment prendre les données item_proto et mob_proto, les importer dans une base web propre et construire pas à pas un site de base de données rapide et cherchable.
Comprendre les sources de données : les fichiers proto
Dans Metin2, chaque objet et monstre connu du jeu est défini dans deux structures principales : item_proto et mob_proto. Sur la plupart des serveurs, elles existent à la fois sous forme de fichiers binaires item_proto/mob_proto et de sources en texte brut :
item_proto/item_names.txt— levnumde chaque objet, son type (arme, armure, costume, potion…), son sous-type, ses champsvalue0–5, ses bonus (applies), son prix et ses noms.mob_proto/mob_names.txt— levnumde chaque monstre, son niveau, son rang (pawn/boss/king…), ses valeurs de PV/attaque, son expérience et ses noms.item_names.txtetmob_names.txt— la correspondance vnum → nom localisé. Pour un wiki multilingue, ces fichiers sont essentiels.
La voie la plus propre pour un site web est d'importer ces données dans une base wiki séparée sans toucher aux tables player actives. Ainsi tu peux construire le schéma que tu veux sans jamais lancer le serveur de jeu.
Importer les données dans une base web
De nombreux serveurs conservent aussi les données proto dans MySQL (par exemple une table player.item_proto). Si tu n'as que des fichiers texte, l'approche la plus saine est un petit script d'import qui les analyse une fois et écrit dans tes propres tables wiki. Commençons par un schéma simple :
CREATE TABLE wiki_items (
vnum INT UNSIGNED PRIMARY KEY,
name VARCHAR(64) NOT NULL,
type VARCHAR(32) NOT NULL,
subtype VARCHAR(32) NULL,
level SMALLINT UNSIGNED DEFAULT 0,
price INT UNSIGNED DEFAULT 0,
KEY idx_name (name),
KEY idx_type (type)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE wiki_mobs (
vnum INT UNSIGNED PRIMARY KEY,
name VARCHAR(64) NOT NULL,
level SMALLINT UNSIGNED DEFAULT 0,
rank VARCHAR(16) NULL,
exp INT UNSIGNED DEFAULT 0,
KEY idx_name (name),
KEY idx_level (level)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;Stocker les champs de bonus (types d'apply et valeurs) dans une table séparée wiki_item_attrs, sous forme de lignes liées par vnum, rend possibles de futures recherches comme « tous les objets avec puissance d'attaque +X ».
Analyser le proto séparé par tabulations
Les fichiers comme item_names.txt sont généralement des colonnes séparées par des tabulations, avec une ligne d'en-tête. Un import sûr en PHP ressemble à ceci :
<?php
$fh = fopen('item_names.txt', 'r');
fgets($fh); // ignorer la ligne d'en-tête
$stmt = $pdo->prepare(
"INSERT INTO wiki_items (vnum, name, type)
VALUES (:vnum, :name, :type)
ON DUPLICATE KEY UPDATE name = VALUES(name)"
);
while (($line = fgets($fh)) !== false) {
$cols = explode("\t", trim($line));
if (count($cols) < 2) continue;
$stmt->execute([
':vnum' => (int) $cols[0],
':name' => $cols[1],
':type' => 'unknown',
]);
}
fclose($fh);Tu peux lire le type et les informations de bonus depuis item_proto et mettre à jour la même ligne. Utiliser ON DUPLICATE KEY UPDATE te permet de relancer l'import après une mise à jour du jeu pour rafraîchir les données sans les effacer à chaque fois.
L'API de recherche et de filtrage
Le cœur d'un site de base de données Metin2 est la recherche. Construisons un point d'accès (endpoint) qui renvoie les objets et monstres correspondants quand l'utilisateur tape une partie d'un nom. N'intègre jamais l'entrée utilisateur directement dans la requête ; lie-la comme paramètre avec une requête préparée :
<?php
$q = trim($_GET['q'] ?? '');
$type = $_GET['type'] ?? null;
$sql = "SELECT vnum, name, type, level FROM wiki_items WHERE name LIKE :q";
$params = [':q' => '%' . $q . '%'];
if ($type) {
$sql .= " AND type = :type";
$params[':type'] = $type;
}
$sql .= " ORDER BY level DESC, name ASC LIMIT 50";
$stmt = $pdo->prepare($sql);
$stmt->execute($params);
header('Content-Type: application/json; charset=utf-8');
echo json_encode($stmt->fetchAll());Pour de très grands ensembles d'objets, name LIKE '%...%' peut devenir lent. À mesure que le site grandit, envisage un index FULLTEXT MySQL ou un moteur de recherche (comme Meilisearch) ; mais pour quelques milliers de lignes, un LIKE indexé suffit largement.
Construire la relation de drop : « où ça tombe ? »
L'information que les joueurs cherchent le plus est de savoir quel monstre lâche un objet. Les données de drop se trouvent sur le serveur dans des sources comme mob_drop_item.txt, common_drop_item.txt et drop_item_group. En important cette relation dans une table reliant le vnum du mob au vnum de l'objet, tu débloques des requêtes bidirectionnelles :
CREATE TABLE wiki_drops (
mob_vnum INT UNSIGNED NOT NULL,
item_vnum INT UNSIGNED NOT NULL,
chance DECIMAL(8,4) NULL,
PRIMARY KEY (mob_vnum, item_vnum),
KEY idx_item (item_vnum)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;Désormais, une page d'objet peut lister « les monstres qui lâchent cet objet » et une page de mob peut lister « la table de drop de ce monstre » avec un JOIN. Quand tu affiches la chance de drop, souviens-toi que le format brut de probabilité dans les fichiers peut varier selon le type de serveur ; si tu n'es pas sûr, ne présente pas le taux comme exact — indique-le comme « approximatif ».
L'interface : info-bulles et icônes
Peu importe l'exactitude des données, personne ne les utilise si la présentation est mauvaise. Une bonne page d'objet imite l'info-bulle (tooltip) en jeu : nom, type, niveau requis, liste de bonus et prix. Pour les icônes, tu peux exporter les icônes d'objets du client du jeu en PNG et les associer par vnum. Quelques conseils pratiques :
- Échappe chaque chaîne issue de la base avec
htmlspecialchars()avant l'affichage — les noms à caractères spéciaux peuvent provoquer du XSS. - Convertis les bonus en libellés lisibles (ex. apply type 1 → « PV max »). Garde cette correspondance dans un petit fichier dictionnaire.
- Sur mobile, place les tableaux dans un conteneur défilable horizontalement pour éviter le débordement.
Performance, mise en cache et SEO
Les sites de base de données sont orientés lecture : les données changent rarement mais sont beaucoup lues. Cette structure est idéale pour la mise en cache. Chaque page d'objet et de mob doit avoir une URL permanente (ex. /item/27003) et tu devrais mettre les résultats en cache quelques minutes. Côté SEO, donner à chaque page un <title> descriptif, une meta description et idéalement des données JSON-LD améliore la visibilité pour les recherches « Metin2 [nom de l'objet] ». Générer un sitemap.xml contenant toutes les URL d'objets et de mobs accélère aussi l'apparition dans les résultats de recherche.
Questions fréquentes
Le site wiki affecte-t-il le serveur de jeu ?
Pas quand il est bien configuré. Si tu importes les données proto dans une base wiki séparée et ne laisses le site lire que ces tables, tu ne touches jamais à la base de jeu active.
Je n'ai pas de fichiers proto en texte brut, seulement du binaire. Que faire ?
La plupart des serveurs gardent aussi une table item_proto/mob_proto dans MySQL où tu peux lire. Sinon, il te faudra des outils communautaires (proto unpackers) qui convertissent les fichiers proto en version texte.
Les noms s'affichent avec des caractères cassés, pourquoi ?
C'est généralement une incompatibilité de jeu de caractères. Crée les tables en utf8mb4, convertis l'encodage réel du fichier (beaucoup de protos utilisent un encodage Latin/Windows) en UTF-8 lors de l'import, et ajoute <meta charset="utf-8"> à la page.
Tu veux un site de base de données/wiki professionnel pour ton serveur ? Je peux importer en toute sécurité tes données proto et construire un wiki rapide, cherchable et multilingue. Pour discuter de ton projet, contacte-moi.