You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implement the Castle Siege weekly guild-vs-guild event and the tightly-coupled Guild Alliance system in OpenMU. Castle Siege is a large-scale PvP event where alliances of guilds battle for control of a castle, with the winning alliance gaining ownership, tax revenue, and access to exclusive content.
Implementation Plan:CastleSiege_Implementation_Plan.md — full architectural mapping to OpenMU's plug-in system, data model, persistence, network packets, and game logic layers.
Per-Phase Details: — individual sub-issues with requirements, file lists, and acceptance criteria.
Architecture Decision
Castle Siege runs on a permanent map (Valley of Loren, map 30) — not a per-instance mini-game map. The chosen pattern is:
A custom IPeriodicTaskPlugIn (CastleSiegePlugIn) driving the 10-state weekly cycle (OpenMU's PeriodicTaskBasePlugIn only supports 3 states).
A CastleSiegeContext class holding all runtime state (analogous to GuildWarContext / MiniGameContext).
One context per IGameServerContext, single-server initially, with interfaces designed for future multi-server support via IEventPublisher.
Overview
Implement the Castle Siege weekly guild-vs-guild event and the tightly-coupled Guild Alliance system in OpenMU. Castle Siege is a large-scale PvP event where alliances of guilds battle for control of a castle, with the winning alliance gaining ownership, tax revenue, and access to exclusive content.
Reference Documentation
Architecture Decision
Castle Siege runs on a permanent map (Valley of Loren, map 30) — not a per-instance mini-game map. The chosen pattern is:
IPeriodicTaskPlugIn(CastleSiegePlugIn) driving the 10-state weekly cycle (OpenMU'sPeriodicTaskBasePlugInonly supports 3 states).CastleSiegeContextclass holding all runtime state (analogous toGuildWarContext/MiniGameContext).IGameServerContext, single-server initially, with interfaces designed for future multi-server support viaIEventPublisher.Phase Breakdown
IGuildServerextensions, message handlersCastleSiegeConfiguration,CastleSiegeData, etc.)CastleSiegeContext,CastleSiegePlugInDependency Graph
Suggested Implementation Order
Estimated Scope
~83 new files, ~22 modified files across DataModel, Interfaces, GuildServer, GameLogic, GameServer, Network.Packets, Persistence, and Web.AdminPanel projects.
Key Design Decisions
IPeriodicTaskPlugIninstead of extendingPeriodicTaskBasePlugIn— the 10-state cycle doesn't map to the base's 3-state model.uintguild IDs for network/logic, persistentGuidfor database — map at load/save boundaries.GameMapTerrainattribute bytes.Startstate only.AssistantMasteradded toGuildPositionenum for castle NPC management permissions.IEventPublisher-based multi-server support.