Adding a New Metin2 Class: Is It Possible and How?

Adding a new Metin2 class is something almost every server owner dreams about at some point, usually without realizing how deep the job actually goes. Since launch the game has been built on four core character classes: Warrior, Sura, Ninja and Shaman; on the official side the later Wolfman (Lycan) pushed that number to five. Bringing in a fifth or sixth class from scratch is very different from adding a new model or a new map: the class identity is baked into the client, the server and the database layers all at once. In this article I explain what is genuinely possible, what is practically close to impossible, and the realistic approaches in between.

Why it isn't a simple "new model" job

In Metin2 a character's class is represented by a single number, the job index. In the server source these values are defined as constants: JOB_WARRIOR = 0, JOB_ASSASSIN = 1, JOB_SURA = 2, JOB_SHAMAN = 3, and on Wolfman-enabled builds JOB_WOLFMAN = 4. A character's in-game "race" value is roughly derived from this job combined with gender — so each class occupies a separate slot for its male and female variant. This number isn't just a label; it is used as an array index everywhere in the game. Stat calculation, health and mana formulas, starting points, the skill tree, item-wear permissions and much more all look up tables through this index. The moment you add a new index, you must extend every one of those tables too.

Server side: impossible without the source

This is the most critical part. Defining a new job index forces you to edit and recompile the game source (the C++ game core), because the number of classes is treated as fixed in many places. The areas you typically have to touch are:

• Constants — The header files where job numbers and the total class count (something like JOB_MAX_NUM) are defined.
• Point and stat tables — The arrays that hold each class's per-level health, mana and starting stats (the job-info arrays around constants.cpp). If you don't add a row for the new class, the game crashes or the character spawns with zero stats.
• The skill system — The structures that map class-specific skill IDs to a job.
• Item restrictions — Which classes may wear an item is stored as a bitmask (Warrior 1, Sura 2, Ninja 4, Shaman 8). A fifth class uses the next bit, and the core has to recognise it.

The catch is this: most of the "server files" packages floating around come as compiled binaries, meaning you have no C++ source. Without the source you cannot change these constants — the only thing you can do is live with the existing four (or five) classes. If you genuinely have a compilable source, the work is hard but possible; if you don't, a "real" new class is simply off the table.

The database layer

A character's class is stored in a job column in the player table. A new job value doesn't necessarily require a schema change (the column is already numeric), but the skill and item proto data have to recognise the new class. For example, skill_proto defines which jobs each skill is open to; you must add your new class's skills there. Likewise, on the item_proto side you have to update the class restriction mask of wearable items so your new class doesn't run around with empty gear slots.

Client side: character creation and models

Even if the server recognises the new class, it's meaningless if the player can't see it. The client side forms its own list:

• Character creation screen — The Python interface in the root pack (the character select and creation modules) reads the choosable races from a fixed list. You have to add the new class to that list and give it an icon, a name and a preview model.
• Player models — Each class has separate .gr2 models, skeletons and full motion sets for male and female. You must prepare all of them and place them in the correct folder structure.
• Motion lists (.msa) and state machines — Walking, running, attacking and skill animations are bound through these files. A missing motion freezes that class during that action.
• Skill interface — Locale files and skill definitions are updated so the skill windows show the new class's tree with correct icons and descriptions.

The key point: the client-side race index and the server-side job index must match exactly. If the two sides use different numbers, the character spawns with the wrong model, skills don't stick, or the client crashes instantly on login.

Realistic approaches

A fully fledged fifth class is overkill for most projects. In practice three routes are far more common:

• Re-theming an existing class (reskin) — For instance presenting the Shaman as a "new class" with entirely new models, effects and skill visuals. Because the job index stays the same you never touch the source; you only change the visual and skill content. This is the lowest-risk and most common method.
• Wolfman (Lycan) integration — Bringing the officially existing fifth class into your project with its ready-made files. This is less "new class" and more "completing a missing class"; even so it takes serious work on skills, balance and item restrictions.
• A real new class at source level — If you have the full source, extending all the layers above to define a fifth or sixth job. The most flexible but longest path; it requires solid C++ and balance knowledge.

A practical roadmap

If you really are going the source route, the sensible order is: first extend the job constants and all stat/skill/item tables in the server source, compile, and create the class invisibly (without a model) in the DB to confirm the core accepts it. Then add the skill and item proto data. Only at the end move to the client: prepare the models, add the class to character creation and align the race indices with the server. At every step read the syserr logs — class-related array overflows (out of range) are most often caught here. If you rush and do everything at once, figuring out which layer the error came from becomes almost impossible.

Frequently Asked Questions

Can a new class be added without the source?

Not in the "real" sense. The job index and its dependent stat/skill/item tables are fixed in the game core and can only be extended by recompiling the source. Without it, the only thing you can do is re-theme an existing class (reskin).

Does adding Wolfman count as a new class?

Halfway. Wolfman is the officially defined fifth class; adding it isn't creating a class from scratch but integrating one that exists yet is missing from your project. Even so it is considerable work in terms of skills, balance and item restrictions.

What's the difference between a reskin and a real new class?

With a reskin the job index doesn't change; the game still sees that character as the old class, only the visuals and skill content differ. With a real new class an entirely new job is defined at core level, with its own stat formulas, its own item restrictions and an independent skill tree.

Do you want a genuinely new class, or a clever reskin? I can review your project's source situation and plan the route that delivers the most impact with the least risk. Get in touch with me and let's talk through what your server needs.