Como configurar o Castle Deep e territórios no MU Online

O Castle Deep e os sistemas de território levam o conceito de disputa territorial do MU Online além do Castle Siege tradicional. Em vez de um único castelo, o mapa é dividido em zonas controláveis, cada uma com seu dono, sua taxa de imposto e seus benefícios. Guilds que dominam territórios ganham vantagens econômicas e status, o que cria um metajogo de aliança, defesa e expansão. Este guia avançado mostra como habilitar o Castle Deep, mapear os territórios no banco de dados, configurar as disputas e balancear o sistema para que ele enriqueça o servidor sem concentrar poder demais em uma só guild. Como sempre, os nomes de arquivos e tabelas são referências: os detalhes exatos variam por emulador, mas a arquitetura é comum a quase todas as builds modernas.

Pré-requisitos

Este é um tutorial avançado. Antes de começar, você precisa de um servidor plenamente funcional e de familiaridade com edição de banco de dados. Se ainda está montando a base, veja primeiro como criar servidor de MU Online.

• GameServer, ConnectServer e DataServer estáveis e testados.
• Acesso ao banco MuOnline com permissão de escrita (SQL Server ou MySQL).
• SQL Server Management Studio (ou cliente equivalente) instalado.
• Backup completo do banco e da pasta de configuração do servidor.
• Conhecimento de índices de mapa e coordenadas do seu emulador.
• Ao menos três guilds de teste para simular disputas.

> Atenção: o Castle Deep não existe de forma idêntica em todos os emuladores. Alguns o implementam como um segundo Castle Siege; outros como um sistema de território separado. Confirme no readme e nos scripts SQL do seu pacote antes de seguir.

Passo 1 — Entender a arquitetura de territórios

Um sistema de território funciona sobre três conceitos básicos:

• Zona/território: uma área do mapa delimitada por coordenadas, com um índice único.
• Dono: a guild que controla a zona no momento, referenciada pelo nome ou ID da guild.
• Ciclo de disputa: o período em que guilds se registram, brigam e um novo dono é definido.

No banco, isso costuma se traduzir em uma tabela de sincronização (semelhante à CastleSiegeSync do Castle Siege) e, opcionalmente, uma tabela de registro de guilds participantes. A lógica de captura roda no GameServer, que lê e escreve esses valores durante o evento.

Passo 2 — Localizar a configuração do evento

Procure na pasta de configuração do GameServer por um arquivo dedicado ao Castle Deep ou território. Um exemplo de estrutura:

[CastleDeep]
CastleDeepEnable    = 1      ; habilita o sistema
TerritoryCount      = 3      ; número de territórios ativos
RegisterDay         = 6      ; dia de registro (0=Dom ... 6=Sab)
BattleDay           = 0      ; dia da batalha
BattleStartHour     = 20     ; hora de início (24h)
BattleDurationMin   = 60     ; duração da disputa em minutos
MaxTaxRate          = 10     ; teto de imposto (%) que o dono pode cobrar

> Os nomes de chave acima são um exemplo e variam por emulador. Em muitas builds o Castle Deep não tem .ini próprio e reaproveita a estrutura do Castle Siege, mudando apenas índices de mapa e tabelas. Consulte a documentação do seu pacote.

Passo 3 — Preparar as tabelas de território no banco

Confirme se as tabelas necessárias existem. Se seu emulador reaproveita o Castle Siege, você verá as tabelas dele; se for um sistema separado, pode ser preciso criar tabelas auxiliares. Um exemplo de estrutura para territórios independentes:

USE MuOnline;
GO

-- Tabela de estado de cada território
CREATE TABLE TerritorySync (
    TerritoryIndex  INT PRIMARY KEY,   -- índice do território
    OwnerGuild      VARCHAR(8) NULL,   -- guild dona atual
    TaxRate         INT DEFAULT 0,     -- imposto cobrado (%)
    State           INT DEFAULT 0,     -- 0=neutro 1=registro 2=batalha
    LastCaptured    DATETIME NULL
);

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

Inicialize os territórios em estado neutro:

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

Passo 4 — Mapear coordenadas e mapas

Cada território precisa estar ancorado a coordenadas de um mapa real. Verifique os índices de mapa do seu emulador (por exemplo, os mapas de Land of Trials, Loren Deep ou mapas customizados). Documente cada zona em uma tabela clara para não se perder:

> Os índices de mapa acima são exemplos. O índice real de cada mapa depende do seu emulador e da sua configuração de MapServerMove. Sempre valide teleportando um GM para o local antes de abrir ao público.

Passo 5 — Definir o ciclo de disputa

O ciclo é o coração do evento. Um fluxo típico:

1. Fase de registro: guilds pagam uma taxa (zen ou item) e se inscrevem em TerritoryRegist. Defina nível mínimo do mestre e número mínimo de membros.
2. Fase de batalha: no horário marcado, o GameServer muda State para 2, libera o combate na zona e conta a captura conforme as regras do emulador (tempo de domínio do ponto, kills, ou destruição de um objetivo).
3. Resolução: ao fim, a guild vencedora vira OwnerGuild, State volta a 0 e LastCaptured é atualizado.
4. Domínio: enquanto dona, a guild cobra o TaxRate definido e pode acessar benefícios exclusivos.

Alguns emuladores rodam esse ciclo por semana; outros permitem múltiplas disputas por dia. Ajuste conforme a população.

Passo 6 — Configurar o imposto e os benefícios

O imposto é o principal incentivo econômico. A guild dona define um percentual (limitado por MaxTaxRate) cobrado em transações dentro do território — reparos, compras de NPC ou entrada em áreas premium. Exemplo de leitura da taxa vigente:

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

Além do imposto, considere benefícios não-financeiros para diversificar o valor de cada território: acesso a um spot de caça melhor, um NPC exclusivo, ou um pequeno bônus de experiência dentro da zona. Territórios com identidades diferentes geram disputas mais interessantes do que zonas idênticas.

Passo 7 — Integrar ao ranking e ao site

Exponha o estado dos territórios para os jogadores. Uma view simples resume quem domina o 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;

O site pode ler essa view a cada poucos minutos e exibir um mapa de controle. Transparência aqui é ouro: jogadores adoram ver o mapa mudando de cor conforme as guilds avançam.

Erros comuns e soluções

Balanceamento e prevenção de monopólio

• Limite territórios por guild: impeça que uma única guild domine todas as zonas ao mesmo tempo; muitos servidores travam em 1 ou 2 territórios por guild.
• Teto de imposto realista: impostos altos demais afastam jogadores das zonas dominadas. Mantenha o teto entre 5% e 10%.
• Reset sazonal: zerar donos a cada mês ou temporada dá chance a novas guilds e renova o interesse.
• Compensação para o perdedor: um pequeno prêmio de participação evita que guilds menores desistam de tentar.

Checklist de lançamento

• Backup completo do banco e da configuração
• Sistema confirmado como disponível no seu emulador
• Tabelas de território criadas e inicializadas em estado neutro
• Coordenadas e índices de mapa validados com GM
• Ciclo de disputa (registro, batalha, resolução) configurado
• Imposto e benefícios por território definidos
• Limite de territórios por guild aplicado
• View/cache integrada ao site e testada
• Reset sazonal agendado
• Disputa simulada com guilds de teste antes do lançamento público

O sistema de territórios transforma o mapa em um tabuleiro vivo de poder. Bem configurado e balanceado, o Castle Deep dá às guilds motivos para se organizar, aliar e brigar semana após semana — um dos motores de retenção mais fortes que um servidor de MU pode ter. O trabalho pesado está no planejamento inicial; depois que o ciclo gira sozinho, seu papel vira apenas o de ajustar o balanceamento conforme a comunidade evolui.

Perguntas frequentes