Metin2 guild war is the core PvP mechanic where two guilds formally declare war on each other, rack up kill scores under a set of rules, and the winner takes the bet pot and ranking points. Configured well, it gives your server a living rivalry and a social goal around the clock; configured badly, it turns into a feature that stays permanently open, can be exploited, or never actually resolves. In this article I walk through, step by step, the war types, how a war is declared and accepted, the score and bet rules, the warp war maps, and how to set up the rewards for the winning guild.
Guild war types
Most Metin2 sources support three different war types, and the one you offer shapes the character of your server:
- Normal war (score war): The war happens out in the open world. Wherever members of the two guilds kill each other, the kill counts toward the score. The first guild to reach the predefined score limit wins. It is the easiest to set up but exposed to third parties interfering in the open world.
- Warp war (arena/invitation war): Members of both guilds are teleported to a separate war map. They fight in an isolated area with no outside interference, which makes this the fairest and most popular type.
- Flag war (CTF): Built around capturing symbol/flag points on the map; it rewards area control rather than pure kills. Used less often, but it gives a distinct feel.
All three share the same skeleton: declaration, acceptance, score counting and result. They differ only in where the war takes place and how the score is earned.
Declaring a war and the acceptance flow
A war is started from the in-game guild menu. The guild leader of the attacking guild selects the target guild, picks the war type, and enters the bet amount if any. The system sends a war invitation to the target guild's leader; if the other leader accepts within a time window the war begins, otherwise the request expires. This "two-sided approval" logic matters because it prevents anyone from forcing a war.
For the declaration to be valid, two conditions are usually required: both guilds must meet the minimum member count, and the leader must have enough yang to cover the bet amount. You will find these rules in your source's guild war configuration; the relevant code typically lives in guild.cpp, guild_manager.cpp and, on the quest side, questlua_guild.cpp.
Configuring score and bet rules
The core rules of a war are kept in a configuration table with a separate row for each war type. The name varies by source but the logic is the same: per type you define a bet limit, a minimum member count and a winning score. A sample table looks like this:
// for each war type: { winning_score, min_members, bet_limit }
const SGuildWarInfo c_aGuildWarInfo[GUILD_WAR_TYPE_MAX_NUM] =
{
// NORMAL : 100 score, at least 7 members, max bet 5,000,000 yang
{ 100, 7, 5000000 },
// WARP : 100 score, at least 10 members, max bet 10,000,000 yang
{ 100, 10, 10000000 },
// CTF : 100 score, at least 10 members, max bet 10,000,000 yang
{ 100, 10, 10000000 },
};
Scale these values to your server's population. On a small server a min_members = 10 requirement means no guild can ever declare war, so keeping the minimum low (say 3–5) at launch is more realistic. Test the winning score with a test guild too: 100 score may take minutes between busy guilds, while between small guilds it can drag on exhaustingly long.
The arena: warp war maps
The heart of warp war is the dedicated war maps where the fight takes place. These are separate map indexes, isolated from the open world and allocated to the two guilds only for the duration of the war. The source keeps a pool of war maps so several wars can run at once; when a war starts a free map is rented from the pool and released back when the war ends. The typical steps are:
- Register the war maps in your server's
CONFIG/atlas configuration; each map must be loaded with its own index and closed to regular players. - Teleport the guilds to two separate spawn points on the map; leave distance between the spawns so there is no instant contact.
- When the war ends, teleport all players back to their original locations and return the map to the pool.
The number of simultaneous wars is limited by how many maps you define. If you do not reserve enough war maps on a busy server, guilds run into a "no free war arena right now" error. Document which map indexes are reserved for war; do not add these maps to the normal portal/teleport list, otherwise players can sneak into the arena.
Rewards and guild ranking points
The part that motivates players is the outcome. There are two core reward mechanisms:
- Bet pot: If both guilds put up the same amount, the entire pot is transferred to the winning guild's storage. This adds a tangible sense of a wager; but if you set the bet limit too high, a single war can shake the economy.
- Guild ranking points (ladder): The winning guild gains ranking points and the loser loses them. Publishing this score as a guild ranking on a website adds prestige to wars and makes the rivalry persistent.
On top of that, you can react to the war result on the quest side and hand out extra rewards. The example below gives a symbolic reward chest to the leader of the winning guild:
when button or info begin
local winner = guild.get_guild_id() -- guild in context
if winner == arg1 then -- arg1: winning guild id
pc.give_item2(50300, 1) -- reward chest (sample item vnum)
notice_all("Guild war won by "..guild.get_name().."!")
end
end
Always replace the item vnum and function names with the real values from your own source; the block above only shows the logic. Keep rewards modest: if every war rains valuable items, it devalues those items and pushes players into staging fake wars just for loot.
Balancing and common mistakes
After you enable the guild war system, the most common problems come from configuration:
- Fake wars: Two guilds owned by the same person keep declaring war on each other to farm rewards. Keeping bets and rewards low, plus adding a same-IP/same-player check, discourages this.
- Minimum members too high: No guild can meet the requirement and the system goes unused. Tune it to your population.
- Outside interference in open-world wars: In a normal war, third guilds can jump in and break the balance. If you want fair competition, make warp war the default.
- War map leakage: If war map indexes end up in the normal teleport list, players enter the arena. Always keep these maps closed.
- Score abuse: You can limit score farming by killing the same player over and over with a short kill cooldown.
After every change, run a full war end to end with two test guilds: declaration, acceptance, teleport, score counting, result and reward. Going live without this end-to-end test is the common cause of most guild war failures.
Frequently Asked Questions
I declare a guild war but it does not start, why?
There are usually two reasons: either one of the guilds does not meet the minimum member requirement, or the target guild's leader did not accept the invitation before it timed out. Lower the min_members value in the configuration table, try again, and make sure the acceptance window actually opens.
In a warp war we are not teleported to the map, what is wrong?
Usually the war maps are not loaded correctly into the server configuration, or there is no reserved war map left. Make sure the war map indexes are defined in your atlas/CONFIG file and that you reserved enough maps for the number of simultaneous wars.
The winning guild does not receive the bet, how do I fix it?
The bet transfer is tied to the code that processes the war result; check that the bet limit is defined correctly and that the win condition (reaching the score limit) is actually triggered. If the war ends on time before the score limit is reached, some sources treat the result as a draw and refund the pot.
Want to set up a fair, stable guild war system on your server? We can work together on warp war maps, score/bet balance and ranking-point integration. To talk about your project, get in touch with me.