Metin2 MySQL-tabellen: de player- en account-structuur

Wanneer je een Metin2-server start, leeft alles — van gevechten tot gildes, van inventarissen tot gildeoorlogen — eigenlijk in MySQL. De Metin2 MySQL-tabellen zijn het permanente geheugen van de spellogica: de kern (de db- en game-processen) leest, schrijft en cachet deze tabellen. De standaard Metin2-serverbron verdeelt de data over twee aparte databases: account, die de authenticatie bevat, en player, die alles in het spel bevat. In dit artikel leg ik de belangrijkste tabellen van beide schema's helder uit en waar elke tabel voor dient.

Twee databases: account en player

De data in twee logische gebieden opsplitsen is een bewuste keuze in Metin2. Account-/logingegevens (login, wachtwoord, banstatus, e-mail) staan in de account-database, terwijl personages, items, gildes en quests in de player-database staan. Deze splitsing maakt het later makkelijker om meerdere spelwerelden (kanalen) aan hetzelfde accountsysteem te koppelen en de bevoegdheidsgrenzen gescheiden te houden.

account — authenticatie, betaling/cash, bans en beveiligingscodes.
player — spelstatus: personages, items, gildes, kluis, quests, vriendenlijst.

De account-database

De belangrijkste tabel is de account-tabel. Elke rij vertegenwoordigt een spelersaccount. Typische kolommen zijn:

id — de unieke primaire sleutel van het account; account_id in de player-tabel verwijst hiernaar.
login — de gebruikersnaam (om in te loggen).
password — het wachtwoord, gehasht met MySQL's PASSWORD()-functie.
social_id — een tweede beveiligingswachtwoord (voor de kluis/pincode).
email — het e-mailadres van het account.
status — accountstatus (zoals OK of BLOCK).
securitycode, availDt — beveiligingscode en de geldigheids-/premiumvervaldatum van het account.

Een eenvoudige query om te zien hoe het wachtwoord wordt opgeslagen:

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

Bij het aanmaken van een nieuw account wordt het wachtwoord als hash geschreven, niet als platte tekst:

INSERT INTO account.account (login, password, social_id, email)
VALUES ('speler1', PASSWORD('geheimWW'), '7777', 'mail@voorbeeld.com');

Het hart van de player-database: de player-tabel

De player-tabel bewaart elk personage als een rij. Van het level van de speler tot zijn positie, van stats tot goud — alles staat hier. Veelgebruikte kolommen:

id — de primaire sleutel van het personage (meestal pid genoemd).
account_id — bij welk account het hoort (account.account.id).
name — personagenaam (uniek op de server).
job — klasse (0 krijger, 1 ninja, 2 sura, 3 sjamaan).
level, exp, level_step — level en ervaring.
st, ht, dx, iq — respectievelijk kracht, vitaliteit, behendigheid en intelligentie.
gold — de hoeveelheid yang van het personage.
hp, mp, stat_point, skill_point — leven/mana en niet-verdeelde punten.
map_index, x, y — de map waarop het personage staat en de coördinaten.
part_main, part_hair — het uitgeruste wapen/harnas en het haaruiterlijk.
skill_group, playtime — de skillboom en de totale speeltijd.

Om het level en goud van een personage uit te lezen:

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

Personageslots: player_index

Een account kan meerdere personages dragen. De player_index-tabel registreert welk account welke personage-id's bezit. Doorgaans is er een id (account_id) samen met de kolommen pid0, pid1, pid2, pid3, die elk naar een personageslot wijzen. Het personageselectiescherm leest deze tabel.

Items: de item-tabel

De item-tabel bewaart alle fysieke items in het spel (inventaris, uitrusting, opslag) in één tabel. Belangrijke kolommen:

id — de unieke id van het item.
owner_id — de pid van het personage dat het item bezit.
window — waar het item zich bevindt (INVENTORY, EQUIPMENT, SAFEBOX, MALL).
pos — de slotpositie binnen dat venster.
vnum — het protonummer van het item (welk item het is; het verwijst naar item_proto).
count — de hoeveelheid (voor stapelbare items).
socket0–socket2 — geplaatste stenen of speciale waarden.
attrtype0–attrtype6 en attrvalue0–attrvalue6 — de bonustypen en -waarden van het item.

item_proto en mob_proto zijn de "sjabloon"-tabellen: ze definiëren de basiseigenschappen van elk item/monster (naam, type, prijs, aanval). De vnum in de item-tabel komt overeen met een rij in item_proto.

Gildes, opslag en andere tabellen

Sociale en progressiesystemen leven in hun eigen tabellen:

guild — gildenaam, leider, level en ervaring.
guild_member — welk personage in welke gilde en op welke rang zit.
safebox — kluiswachtwoord en kluisgoud; de items zelf staan nog steeds in de item-tabel met window=SAFEBOX.
quest — de questvlaggen van elk personage (questvoortgang als sleutel/waarde).
affect — buff-/effectstatussen die blijven bestaan wanneer een personage uitlogt.
messenger_list — vriendenlijstrelaties.

Deze tabellen zijn met elkaar verbonden via de pid (personage-id); je haalt bijvoorbeeld alle items van een personage op met de relatie item.owner_id = player.id. Zodra je het schema met deze logica leest, wordt de schijnbare rommel een nette relationele structuur.

Aandachtspunten bij het werken met de tabellen

Een belangrijk punt: het db-proces cachet personage- en itemdata in het geheugen. Als je een UPDATE direct uitvoert terwijl de speler online is, kan de data die de kern bij het uitloggen schrijft die van jou overschrijven. Doe data-aanpassingen dus wanneer de speler offline is, maak altijd eerst een back-up (mysqldump) en test in een staging-omgeving.

Veelgestelde vragen

Waarom zijn de account- en player-databases gescheiden?

Authenticatie van speldata scheiden geeft veiligheid en flexibiliteit. Meerdere spelwerelden kunnen aan hetzelfde accountsysteem koppelen, rechten blijven gescheiden en de logintabel wordt niet beïnvloed door de spelbelasting.

Waar staan alle items van een personage?

In de item-tabel van de player-database. De kolom owner_id is gelijk aan de id (pid) van het personage; de kolom window vertelt of het item in de inventaris of in de opslag zit.

Is het veilig om goud toe te voegen terwijl de speler online is?

Meestal niet. De kern houdt de data in cache en overschrijft de tabel bij het uitloggen. De veilige manier is een in-game commando gebruiken of bijwerken wanneer de speler offline is.

Hulp nodig bij het bewerken van je Metin2-database of het opzetten van een net schema? Voor ondersteuning met het MySQL-schema, prestaties en serverinstallatie, neem contact met me op.