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

---

[v-mstrs]

But this does not address the underlying issue this core faces, which is (imo) a lack of knowledge of how everything works under the hood, and maybe, but less so, of WoW emulation in general. You can somewhat verify this by checking the PRs being made (primarily DB, scripts), and also by what gets pushed, #23349. (Sure, this one will probably get fixed, but still.)

And because of the many hacks/changes that exist from SunwellCore, good luck porting anything from Trinity... #13320. Not saying it's impossible, but you would assume it would have been done already. The more time goes on, the harder it is to implement. (Threat/aggro/proc/spell system probably more?)

And listen, I'm not trying to be meanie or a hater, quite the opposite, in fact. I only started contributing here because of ChromieCraft (with 0 knowledge), but as time went on, I eventually came to said conclusion.

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.

Lastly, it was a mistake, in hindsight, to choose SunwellCore as a base instead of just forking TrinityCore, given your goal. Maybe in 2016 it was better, but certainly not now. It could have been a modular, something-something version of TC, but still 1:1, with, idk, DB changes being pulled upstream. Somewhat of a wasted opportunity, as it would have aligned with Chromie’s values, but alas!

[Yehonal]

I think this point needs a bit more perspective.

I wouldn't say AC lacks knowledge, but while many other cores have narrowed their focus to pure WoW emulation, AC evolved into something much broader. We don’t just focus on “decrypting” WoW, but also on improving everything around it, a full ecosystem of platforms and tools that empower people to build on top of it. That’s why many of our contributions go far beyond reverse-engineering WoW itself.

The choice of Sunwell back then was intentional. It gave us a playable, stable base and, combined with our modular structure, allowed AC to gain huge traction early on. That decision made perfect sense, we wanted something that worked, that people could actually play on right away, and we’ve never regretted it. From day one we’ve been improving, refactoring, and constantly expanding our knowledge in every direction and we will keep doing it.

We likely are the most active and lively project of our kind nowadays

As for the TC path, we’ve been there. We tried multiple times, and none of those projects ever went anywhere. AC succeeded because it took its own route... not because it stayed in someone else’s shadow.