AzerothCore General Roadmap

[Yehonal]

Hello everyone,

In the last few days I thought it could be useful to put down a roadmap for AzerothCore.
Sometimes there are different takes in the community about what AzerothCore is and where it’s heading, although I tried to explain it at the best in our code of conduit & philosophy thread.
So this roadmap is meant to give everyone a clearer picture. It’s both a look back at what has already been built, and a look ahead at what could come next.

AzerothCore is more than just an emulator: over the years it has grown into a framework and an ecosystem of tools thanks to contributions, testing and a lot of passion. With this roadmap we want to stress a double goal: keeping the core strong and reliable for WoW, while also preparing the ground for it to evolve into a more general, flexible open‑source MMO platform.

This isn’t just a list of tasks. It’s more about setting a direction. Each milestone will be posted here with updates in the comments, so everyone can follow and take part.

Guiding principles: We will always prioritize stability first, followed by player experience, then framework evolution, and finally ensuring a great contributor experience for everyone who takes part in the project.

---

Key past implementations

Before looking ahead, these past changes already made AzerothCore more agnostic, flexible, and extensible:

1. Module system - full extensibility of the core without forking. You can add, replace, or disable features cleanly.
2. DBC overrides via database tables - lets us override client DBC data through SQL so the game data can live in the DB, decoupled from client files and fixing issues in the original DBCs.
3. Native support for many tools - first-class integrations with Acore-CMS, Keira3, and dozens of community tools to speed up content and ops.
4. Docker support - ready-to-use Docker setups both for development and production deployments.
5. Unit testing support - built-in frameworks to write and run unit tests consistently.
6. Git-Wiki - an official Git-based wiki to centralize documentation and knowledge sharing.
7. And much more...

---

Architecture & Organization

1) Decouple network GUIDs from database IDs

• Why: 32-bit DB IDs eventually hit limits on high-volume servers. Network identifiers must not depend on storage keys.
• Outcome: network-safe GUIDs independent from DB primary keys for characters and auth.
• Acceptance: clear migration guide, optional dual-write period, verification tooling, zero player-visible breakage.
• Status: 🟡 In progress
• Links:
  • feat(DB): decouple item GUIDs to BIGINT UNSIGNED for future-proof database integrity #22781
  • Feature: Decouple DB GUIDs from runtime low GUIDs to eliminate overflow and future-proof IDs #22777

2) Git self-hosted runner deployment workflow

• Why: we are building this for ChromieCraft and it makes spinning up test or prod on any Linux shell trivial.
• Outcome: reference workflows, playbooks, and hardened defaults for builds, releases, rollbacks.
• Acceptance: one-command bootstrap, safe rollbacks, documented secrets handling.
• Status: 🟡 In progress

3) Service manager and Module Dashboard

• Why: common operations should be handled with a single, and configurable commands. Manage restarters, install/update/track modules, and audit changes from one place.
• Outcome: supported manager with CLI, health checks, restart policies, and module provenance log.
• Acceptance: reliable restarts, module pinning and audit trail.
• Status: 🟡 In progress
• Links:
  • feat(Bash/ServiceManager): enhance path portability  #22982

4) Rebranding scope

• Why: remove wording that locks us to WoW as the only supported client. WoW remains our focus and default lab, but the framework should be client-agnostic.
• Outcome: updated docs, repo descriptions, and FAQ to reflect a broader mission without confusing WoW users.
• Acceptance: public docs updated and consistent.
• Status: 🟢 Planned

5) AI-assisted contribution instructions

• Why: AI is now part of daily developer workflows. We should teach models how to help here, safely.
• Outcome: prompt packs, contribution guides, and examples that let anyone use AI to improve the core with guardrails.
• Acceptance: a public AI guide that includes patterns for tests, benchmarks, and safe changes.
• Status: 🟢 Planned

6) Multiple-opcode support

• Why: at compile-time, select different opcode sets to support other patches/expansions or even different clients.
• Outcome: default opcodes stay intact, extensions are possible. DB and logic layers expose interfaces that can be replaced or extended.
• Acceptance: clear boundaries, tests for at least two opcode sets, no performance regression for the default.
• Status: 🟢 Planned

7) Native scripting layer: Lua and TypeScript

• Why: scripting lowers the entry barrier. TypeScript brings strong typing and a C-style feel. Scripts should hot-reload without recompiling the core.
• Outcome: first-class scripting runtime with safe bindings for gameplay logic and tools.
• Acceptance: sample scripts, hot-reload, performance and safety guardrails, docs to migrate from C++-only.
• Status: ⚪ Not planned yet
• Links: prior exploration eluna-ts

8) Better testing framework, including easy end-to-end tests

• Why: avoid regressions that hurt players. ChromieCraft is a great test bed, but we also need fast automated coverage.
• Outcome: fast unit tests, deterministic integration tests, and easy e2e scenarios anyone can run locally and in CI.
• Acceptance: a quick smoke test suite under 10 minutes in CI, plus automated player bots for longer runs.
• Status: ⚪ Not planned yet

9) Experimental Web and Desktop client (TypeScript & Electron)

• Why: a lightweight client that connects directly to the server helps us prototype features, test network changes, and run automated scenarios without a full game client.
• Outcome: a minimal Web client (TypeScript) and a Desktop wrapper (Electron or similar) that can authenticate, send/receive opcodes, and render simple scenes or debug views.
• Acceptance: connects to a test realm, supports scripted sessions for CI, can visualize basic world state and logs, documented dev workflow.
• Status: ⚪ Not planned yet

---

Game Experience

1) Playable content A to Z

• Why: AzerothCore is highly customizable, but it must also deliver a complete game experience. ChromieCraft tracks this and we estimate about 70% coverage today.
• Outcome: green status for all leveling brackets, dungeons, raids, and core systems.
• Acceptance: per-zone and per-feature checklists, no showstopper bugs on the main progression paths.
• Status: 🟡 In progress

2) Cross-realm and multi-service features

• Why: AC is a Modular Monolith that scales well. Optional multi-service components and cross-realm communication can improve UX and let owners connect multiple communities. Open-source still lacks robust public solutions here.
• Outcome: optional services for cross-realm chat, grouping, instances, battlegrounds, with clear isolation rules per realm.
• Acceptance: opt-in design, defined latency budgets, graceful failure modes, admin tooling included.
• Status: ⚪ Not planned yet

---

Community model

Help other communities follow the ChromieCraft model

• Why: we want more communities to adopt the ChromieCraft approach: release everything open source and contribute back to AzerothCore. This grows the project and strengthens the ecosystem.
• Outcome: partnership framework where, in exchange for fixes and contributions, partners get benefits such as priority in PR reviews, technical support, and an additional package of incentives (to be defined with the community).
• Acceptance: at least one external community adopts this model, agreements are clear, and a steady flow of contributions lands in AC.
• Status: ⚪ Not planned yet

---