Metin2 Server : checklist complète avant l'ouverture

Le jour d'un Metin2 server launch, des mois de préparation sont mis à l'épreuve en une seule nuit. Dès l'instant où les premières centaines de joueurs tentent de s'inscrire, de se connecter et de jouer en même temps, le moindre détail négligé peut tourner à la crise : le formulaire d'inscription plante, le système de paiement ne crédite pas le yang, la première pierre metin lâche le mauvais item, ou le game core meurt pendant la toute première guerre de guilde. Dans ce guide, j'ai rassemblé sous forme de checklist ordonnée chaque système à passer en revue avant l'ouverture. L'objectif : transformer la nuit de lancement d'une surprise en une simple tournée de contrôle.

Infrastructure serveur et processus

Avant tout, tu dois être sûr que la machine tiendra. La charge de lancement, c'est plusieurs fois plus de connexions qu'un jour de test normal. À vérifier :

• Les processus auth, db, game et channel démarrent-ils dans l'ordre et sans erreur ? Aucune ligne SYSERR ne doit subsister dans les logs de démarrage.
• Si tu utilises plusieurs canaux (channels), vérifie le mappage port/core de chacun. Un mauvais mappage envoie les joueurs dans un canal vide.
• Comment se comportent CPU et RAM sur un seul canal sous 100 à 200 connexions fictives/de test ? Surveille avec top ou htop.
• Redémarrage automatique : prépare un watchdog (une simple boucle bash ou un service systemd) qui relance le game core en cas de crash.

# Vérifie que les processus tournent réellement
ps aux | grep -E "auth|db|game" | grep -v grep
# Contrôle les ports en écoute
netstat -tlnp 2>/dev/null | grep -E "1100[0-9]|net"

Inscription, connexion et sécurité des comptes

La page d'inscription est le premier contact du joueur avec toi ; une erreur à cet endroit, c'est un joueur perdu sur-le-champ. Avant l'ouverture, déroule tout le flux d'inscription de bout en bout dans un vrai navigateur :

• La création de compte, la vérification par e-mail (le cas échéant) et la première connexion fonctionnent-elles sans accroc ?
• Les mots de passe sont-ils stockés hachés, pas en clair dans la base ? Utilise un password_hash() moderne ; l'ancien mysql_password seul ne suffit pas.
• Le formulaire d'inscription est-il protégé contre les tentatives d'injection SQL et de XSS ? Assure-toi d'utiliser des requêtes préparées.
• Existe-t-il une limitation de débit (rate limit) ou un captcha contre les bots qui ouvrent des centaines de comptes depuis la même IP en quelques secondes ?

Système de paiement et cash shop

La plupart des serveurs ouvrent leur source de revenus le soir du lancement. Un bug ici brûle à la fois la confiance et l'argent. Pendant les tests, joue les scénarios réussis comme échoués :

• Le callback/webhook du prestataire de paiement crédite-t-il le bon montant de cash/coin sur le bon compte ?
• Si la même notification de paiement arrive deux fois, le système évite-t-il un double crédit ? (Idempotence — traiter chaque identifiant de transaction une seule fois.)
• Les étapes d'achat d'un item au cash shop, de livraison dans l'inventaire et de débit du solde de cash sont-elles cohérentes ?
• En cas de paiement échoué, le joueur ne doit recevoir aucun item, mais son solde ne doit pas non plus être débité.

Si possible, effectue une petite transaction de test en argent réel et vérifie une fois le flux de bout en bout de tes propres yeux.

Items, drops et équilibre économique

L'économie de lancement laisse une trace durable durant les premières semaines. Un drop trop généreux ou un bonus cassé peut gonfler l'économie de façon irréversible. À vérifier :

• item_proto et mob_proto sont-ils cohérents ? Un vnum manquant, un anti-flag erroné ou une définition de bonus incorrecte peut faire planter le game core.
• Les tables de drop des pierres metin, des boss et des grandboss lâchent-elles les items attendus aux taux attendus ? Casse quelques metins et observe.
• Les failles de duplication de yang et d'items (dupe) sont-elles fermées ? Stresse en particulier l'échange, le market/offline shop et la messagerie.
• Les multiplicateurs d'EXP, de drop et de yang (CONFIG et réglages associés) correspondent-ils exactement aux valeurs annoncées ? Les joueurs le remarquent dès le premier jour.

PvP, systèmes et quêtes

Le cœur d'un serveur Metin2, ce sont son PvP et ses systèmes. Avant l'ouverture, teste chaque mécanique phare avec un personnage en jeu :

• Équilibrage des skills : aucune classe ne tue en un coup ni n'est totalement inutile. Oppose plusieurs classes différentes.
• Guerre de guilde et arène : y a-t-il un crash sous la foule ? C'est généralement là que survient le premier gros crash.
• Systèmes actifs (costume, monture, pet, alchimie, ceinture, switchbot, etc.) : chacun s'ouvre-t-il et fonctionne-t-il ?
• Leveling et quêtes de départ : un nouveau personnage peut-il progresser dans un flux jouable depuis zéro ? Les dialogues, récompenses et quest timers fonctionnent-ils ?

Sauvegardes, sécurité et supervision

C'est l'étape pré-lancement la plus négligée et pourtant la plus critique. Si quelque chose tourne mal le premier jour, il te faut un point de retour en arrière.

• Une sauvegarde MySQL automatique est-elle en place et tourne-t-elle réellement ? La mettre en place ne suffit pas ; teste que tu peux restaurer une sauvegarde.
• La protection DDoS et un pare-feu (par ex. règles iptables) sont-ils actifs ? Le jour du lancement est un aimant à attaques.
• L'accès SSH est-il par clé, avec connexion par mot de passe root désactivée ?
• Le soir du lancement, un terminal est-il prêt pour suivre syserr.txt et syslog.txt en direct ? Tu veux voir un problème dès qu'il atteint le log.

# Intègre la sauvegarde à une tâche planifiée (exemple)
mysqldump -u root -p --single-transaction player account > backup_$(date +%F).sql
# Suis les logs en direct le soir du lancement
tail -f syserr.txt syslog.txt

Questions fréquentes

Combien de temps avant le lancement faut-il ouvrir un serveur de test ?

L'idéal est d'ouvrir une bêta/un serveur de test fermé au moins une semaine avant le lancement et de simuler des conditions réelles avec quelques joueurs de confiance. Sans test de charge, un système qui fonctionne avec un seul joueur ne garantit pas qu'il tiendra sous la charge de lancement.

Quel système plante le plus souvent au lancement ?

D'après mon expérience, les premiers gros crashs surviennent généralement à deux endroits : le trafic intense d'inscriptions/connexions qui arrive d'un coup, et la première guerre de guilde/arène bondée. Partir en live sans simuler les deux avec une vraie foule est risqué.

Puis-je modifier les réglages de drop et de multiplicateurs plus tard ?

Techniquement oui, mais baisser des réglages qui touchent à l'économie (yang, drop, EXP) après le lancement provoque une forte réaction des joueurs. Choisis donc soigneusement tes valeurs de lancement dès le départ ; les augmenter ensuite est toujours plus facile que les baisser.

Si tu prépares ton lancement, je peux t'aider à auditer chaque système de ton serveur avant la mise en ligne et à colmater les failles critiques. Pour l'installation, la stabilité et la checklist de lancement d'un serveur Metin2, contacte-moi.