How to configure Castle Deep and territories in MU Online

Castle Deep and territory systems take MU Online's concept of territorial dispute beyond the traditional Castle Siege. Instead of a single castle, the map is divided into controllable zones, each with its own owner, tax rate, and benefits. Guilds that dominate territories gain economic advantages and status, which creates a metagame of alliance, defense, and expansion. This advanced guide shows how to enable Castle Deep, map the territories in the database, configure the disputes, and balance the system so that it enriches the server without concentrating too much power in a single guild. As always, the file and table names are references: the exact details vary by emulator, but the architecture is common to almost all modern builds.

Prerequisites

This is an advanced tutorial. Before you begin, you need a fully functional server and familiarity with database editing. If you are still building the base, first see how to create a MU Online server.

• GameServer, ConnectServer, and DataServer stable and tested.
• Access to the MuOnline database with write permission (SQL Server or MySQL).
• SQL Server Management Studio (or an equivalent client) installed.
• A full backup of the database and the server's configuration folder.
• Knowledge of your emulator's map indexes and coordinates.
• At least three test guilds to simulate disputes.

> Note: Castle Deep does not exist identically in every emulator. Some implement it as a second Castle Siege; others as a separate territory system. Confirm in the readme and the SQL scripts of your package before proceeding.

Step 1 — Understand the territory architecture

A territory system works on three basic concepts:

• Zone/territory: an area of the map bounded by coordinates, with a unique index.
• Owner: the guild that currently controls the zone, referenced by the guild's name or ID.
• Dispute cycle: the period in which guilds register, fight, and a new owner is determined.

In the database, this usually translates into a synchronization table (similar to Castle Siege's CastleSiegeSync) and, optionally, a table registering the participating guilds. The capture logic runs on the GameServer, which reads and writes these values during the event.

Step 2 — Locate the event configuration

Look in the GameServer's configuration folder for a file dedicated to Castle Deep or territory. An example structure:

[CastleDeep]
CastleDeepEnable    = 1      ; enables the system
TerritoryCount      = 3      ; number of active territories
RegisterDay         = 6      ; registration day (0=Sun ... 6=Sat)
BattleDay           = 0      ; battle day
BattleStartHour     = 20     ; start hour (24h)
BattleDurationMin   = 60     ; dispute duration in minutes
MaxTaxRate          = 10     ; tax ceiling (%) the owner can charge

> The key names above are an example and vary by emulator. In many builds, Castle Deep has no .ini of its own and reuses the Castle Siege structure, changing only map indexes and tables. Consult your package's documentation.

Step 3 — Prepare the territory tables in the database

Confirm that the necessary tables exist. If your emulator reuses Castle Siege, you will see its tables; if it is a separate system, you may need to create auxiliary tables. An example structure for independent territories:

USE MuOnline;
GO

-- State table for each territory
CREATE TABLE TerritorySync (
    TerritoryIndex  INT PRIMARY KEY,   -- territory index
    OwnerGuild      VARCHAR(8) NULL,   -- current owning guild
    TaxRate         INT DEFAULT 0,     -- tax charged (%)
    State           INT DEFAULT 0,     -- 0=neutral 1=registration 2=battle
    LastCaptured    DATETIME NULL
);

-- Registration of participating guilds per cycle
CREATE TABLE TerritoryRegist (
    TerritoryIndex  INT,
    GuildName       VARCHAR(8),
    RegDate         DATETIME DEFAULT GETDATE()
);

Initialize the territories in a neutral state:

INSERT INTO TerritorySync (TerritoryIndex, State) VALUES (0, 0), (1, 0), (2, 0);

Step 4 — Map coordinates and maps

Each territory needs to be anchored to coordinates on a real map. Check your emulator's map indexes (for example, the maps of Land of Trials, Loren Deep, or custom maps). Document each zone in a clear table so you don't get lost:

> The map indexes above are examples. The real index of each map depends on your emulator and your MapServerMove configuration. Always validate by teleporting a GM to the location before opening to the public.

Step 5 — Define the dispute cycle

The cycle is the heart of the event. A typical flow:

1. Registration phase: guilds pay a fee (zen or item) and register in TerritoryRegist. Set a minimum master level and a minimum number of members.
2. Battle phase: at the scheduled time, the GameServer changes State to 2, enables combat in the zone, and counts the capture according to the emulator's rules (time controlling the point, kills, or destruction of an objective).
3. Resolution: at the end, the winning guild becomes OwnerGuild, State returns to 0, and LastCaptured is updated.
4. Dominion: while owner, the guild charges the defined TaxRate and can access exclusive benefits.

Some emulators run this cycle weekly; others allow multiple disputes per day. Adjust according to the population.

Step 6 — Configure the tax and the benefits

The tax is the main economic incentive. The owning guild sets a percentage (capped by MaxTaxRate) charged on transactions within the territory — repairs, NPC purchases, or entry into premium areas. Example of reading the current tax rate:

SELECT TerritoryIndex, OwnerGuild, TaxRate
FROM TerritorySync
WHERE OwnerGuild IS NOT NULL;

Beyond the tax, consider non-financial benefits to diversify the value of each territory: access to a better hunting spot, an exclusive NPC, or a small experience bonus within the zone. Territories with different identities create more interesting disputes than identical zones.

Step 7 — Integrate with the ranking and the website

Expose the territory state to the players. A simple view summarizes who dominates what:

CREATE VIEW vw_Territorios AS
SELECT
    t.TerritoryIndex AS Territorio,
    ISNULL(t.OwnerGuild, 'Neutro') AS Dono,
    t.TaxRate AS Imposto,
    t.LastCaptured AS UltimaCaptura
FROM TerritorySync t;

The website can read this view every few minutes and display a control map. Transparency here is gold: players love watching the map change color as guilds advance.

Common errors and fixes

Balancing and monopoly prevention

• Limit territories per guild: prevent a single guild from dominating all zones at once; many servers cap it at 1 or 2 territories per guild.
• Realistic tax ceiling: taxes that are too high drive players away from the dominated zones. Keep the ceiling between 5% and 10%.
• Seasonal reset: resetting owners every month or season gives new guilds a chance and renews interest.
• Compensation for the loser: a small participation prize keeps smaller guilds from giving up on trying.

Launch checklist

• Full backup of the database and the configuration
• System confirmed as available in your emulator
• Territory tables created and initialized in a neutral state
• Coordinates and map indexes validated with a GM
• Dispute cycle (registration, battle, resolution) configured
• Tax and benefits per territory defined
• Territory-per-guild limit applied
• View/cache integrated with the website and tested
• Seasonal reset scheduled
• Dispute simulated with test guilds before the public launch

The territory system turns the map into a living board of power. Well configured and balanced, Castle Deep gives guilds reasons to organize, ally, and fight week after week — one of the strongest retention engines a MU server can have. The heavy lifting is in the initial planning; once the cycle spins on its own, your role becomes simply adjusting the balance as the community evolves.

Frequently asked questions