Cómo configurar el Castle Deep y los territorios en MU Online

El Castle Deep y los sistemas de territorio llevan el concepto de disputa territorial de MU Online más allá del Castle Siege tradicional. En lugar de un único castillo, el mapa se divide en zonas controlables, cada una con su dueño, su tasa de impuesto y sus beneficios. Las guilds que dominan territorios ganan ventajas económicas y estatus, lo que crea un metajuego de alianza, defensa y expansión. Esta guía avanzada muestra cómo habilitar el Castle Deep, mapear los territorios en la base de datos, configurar las disputas y balancear el sistema para que enriquezca al servidor sin concentrar demasiado poder en una sola guild. Como siempre, los nombres de archivos y tablas son referencias: los detalles exactos varían según el emulador, pero la arquitectura es común a casi todas las builds modernas.

Requisitos previos

Este es un tutorial avanzado. Antes de empezar, necesitas un servidor plenamente funcional y familiaridad con la edición de bases de datos. Si todavía estás montando la base, mira primero cómo crear un servidor de MU Online.

• GameServer, ConnectServer y DataServer estables y probados.
• Acceso a la base de datos MuOnline con permiso de escritura (SQL Server o MySQL).
• SQL Server Management Studio (o cliente equivalente) instalado.
• Copia de seguridad completa de la base de datos y de la carpeta de configuración del servidor.
• Conocimiento de índices de mapa y coordenadas de tu emulador.
• Al menos tres guilds de prueba para simular disputas.

> Atención: el Castle Deep no existe de forma idéntica en todos los emuladores. Algunos lo implementan como un segundo Castle Siege; otros como un sistema de territorio separado. Confirma en el readme y en los scripts SQL de tu paquete antes de continuar.

Paso 1 — Entender la arquitectura de territorios

Un sistema de territorio funciona sobre tres conceptos básicos:

• Zona/territorio: un área del mapa delimitada por coordenadas, con un índice único.
• Dueño: la guild que controla la zona en el momento, referenciada por el nombre o ID de la guild.
• Ciclo de disputa: el período en que las guilds se registran, pelean y se define un nuevo dueño.

En la base de datos, esto suele traducirse en una tabla de sincronización (similar a la CastleSiegeSync del Castle Siege) y, opcionalmente, una tabla de registro de guilds participantes. La lógica de captura corre en el GameServer, que lee y escribe esos valores durante el evento.

Paso 2 — Localizar la configuración del evento

Busca en la carpeta de configuración del GameServer un archivo dedicado al Castle Deep o territorio. Un ejemplo de estructura:

[CastleDeep]
CastleDeepEnable    = 1      ; habilita el sistema
TerritoryCount      = 3      ; numero de territorios activos
RegisterDay         = 6      ; dia de registro (0=Dom ... 6=Sab)
BattleDay           = 0      ; dia de la batalla
BattleStartHour     = 20     ; hora de inicio (24h)
BattleDurationMin   = 60     ; duracion de la disputa en minutos
MaxTaxRate          = 10     ; techo de impuesto (%) que el dueno puede cobrar

> Los nombres de clave anteriores son un ejemplo y varían según el emulador. En muchas builds el Castle Deep no tiene .ini propio y reutiliza la estructura del Castle Siege, cambiando solo índices de mapa y tablas. Consulta la documentación de tu paquete.

Paso 3 — Preparar las tablas de territorio en la base de datos

Confirma si las tablas necesarias existen. Si tu emulador reutiliza el Castle Siege, verás sus tablas; si es un sistema separado, puede ser necesario crear tablas auxiliares. Un ejemplo de estructura para territorios independientes:

USE MuOnline;
GO

-- Tabla de estado de cada territorio
CREATE TABLE TerritorySync (
    TerritoryIndex  INT PRIMARY KEY,   -- indice del territorio
    OwnerGuild      VARCHAR(8) NULL,   -- guild duena actual
    TaxRate         INT DEFAULT 0,     -- impuesto cobrado (%)
    State           INT DEFAULT 0,     -- 0=neutral 1=registro 2=batalla
    LastCaptured    DATETIME NULL
);

-- Registro de guilds participantes por ciclo
CREATE TABLE TerritoryRegist (
    TerritoryIndex  INT,
    GuildName       VARCHAR(8),
    RegDate         DATETIME DEFAULT GETDATE()
);

Inicializa los territorios en estado neutral:

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

Paso 4 — Mapear coordenadas y mapas

Cada territorio debe estar anclado a coordenadas de un mapa real. Verifica los índices de mapa de tu emulador (por ejemplo, los mapas de Land of Trials, Loren Deep o mapas personalizados). Documenta cada zona en una tabla clara para no perderte:

> Los índices de mapa anteriores son ejemplos. El índice real de cada mapa depende de tu emulador y de tu configuración de MapServerMove. Valida siempre teletransportando a un GM al lugar antes de abrir al público.

Paso 5 — Definir el ciclo de disputa

El ciclo es el corazón del evento. Un flujo típico:

1. Fase de registro: las guilds pagan una tasa (zen o ítem) y se inscriben en TerritoryRegist. Define el nivel mínimo del máster y el número mínimo de miembros.
2. Fase de batalla: en el horario marcado, el GameServer cambia State a 2, libera el combate en la zona y cuenta la captura según las reglas del emulador (tiempo de dominio del punto, kills, o destrucción de un objetivo).
3. Resolución: al final, la guild ganadora se vuelve OwnerGuild, State regresa a 0 y LastCaptured se actualiza.
4. Dominio: mientras es dueña, la guild cobra el TaxRate definido y puede acceder a beneficios exclusivos.

Algunos emuladores corren este ciclo por semana; otros permiten múltiples disputas por día. Ajusta según la población.

Paso 6 — Configurar el impuesto y los beneficios

El impuesto es el principal incentivo económico. La guild dueña define un porcentaje (limitado por MaxTaxRate) cobrado en transacciones dentro del territorio — reparaciones, compras de NPC o entrada en áreas premium. Ejemplo de lectura de la tasa vigente:

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

Además del impuesto, considera beneficios no financieros para diversificar el valor de cada territorio: acceso a un mejor spot de caza, un NPC exclusivo, o un pequeño bono de experiencia dentro de la zona. Los territorios con identidades diferentes generan disputas más interesantes que las zonas idénticas.

Paso 7 — Integrar al ranking y al sitio

Expón el estado de los territorios a los jugadores. Una view simple resume quién domina qué:

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;

El sitio puede leer esa view cada pocos minutos y mostrar un mapa de control. La transparencia aquí es oro: a los jugadores les encanta ver el mapa cambiar de color a medida que las guilds avanzan.

Errores comunes y soluciones

Balanceo y prevención del monopolio

• Limita territorios por guild: impide que una sola guild domine todas las zonas al mismo tiempo; muchos servidores lo topan en 1 o 2 territorios por guild.
• Techo de impuesto realista: los impuestos demasiado altos alejan a los jugadores de las zonas dominadas. Mantén el techo entre el 5% y el 10%.
• Reset estacional: poner a cero los dueños cada mes o temporada da oportunidad a nuevas guilds y renueva el interés.
• Compensación para el perdedor: un pequeño premio de participación evita que las guilds menores desistan de intentarlo.

Lista de verificación de lanzamiento

• Copia de seguridad completa de la base de datos y de la configuración
• Sistema confirmado como disponible en tu emulador
• Tablas de territorio creadas e inicializadas en estado neutral
• Coordenadas e índices de mapa validados con GM
• Ciclo de disputa (registro, batalla, resolución) configurado
• Impuesto y beneficios por territorio definidos
• Límite de territorios por guild aplicado
• View/caché integrada al sitio y probada
• Reset estacional programado
• Disputa simulada con guilds de prueba antes del lanzamiento público

El sistema de territorios transforma el mapa en un tablero vivo de poder. Bien configurado y balanceado, el Castle Deep da a las guilds motivos para organizarse, aliarse y pelear semana tras semana — uno de los motores de retención más fuertes que un servidor de MU puede tener. El trabajo pesado está en la planificación inicial; una vez que el ciclo gira solo, tu papel se vuelve solo el de ajustar el balanceo a medida que la comunidad evoluciona. </parameter>

Preguntas frecuentes