EQEmulator is a clean-room EverQuest server built by packet sniffing

The server was written by watching packets, not by reading code

The project is a server emulator for a 1990s MMORPG, and the part that makes it remarkable is stated plainly in the README's technical overview. EQEmulator represents over two decades of collaborative reverse engineering, building the server from the ground up without access to the original source code, achieved through community-driven analysis, network protocol decoding and in-game behavioural research. The How We Did It section spells out the method: every system, packet, opcode and game mechanic was reconstructed through live packet sniffing, client disassembly and in-game experimentation by contributors over the years, no proprietary code or server sources were ever used, and all implementations are the result of clean-room engineering. For an engineer reading the codebase, that claim is the most important thing in the README, because it tells you what kind of code you are looking at. A reimplementation from observed behaviour looks different from a port, with edge cases that look odd until you remember they exist to match a specific client quirk.

The stack is C++, MySQL and two scripting languages

The technology stack section is a short list, and each entry is a decision. The core engine is C++ with high-performance networking and gameplay logic, and the README says it has cross-platform support for Linux and Windows. The backend is MySQL or MariaDB, with a fully structured schema of over 200 tables, and the schema is described as supporting content customization, expansions and custom worlds, which is the clue that the database is not a save file but the game's world definition. The scripting engine supports Perl and Lua natively, and the README calls it powerfully extendable for quests, NPC behaviours and custom events. That last point is what separates an emulator from a museum piece. If the server's behaviour is data and scripts rather than compiled logic, a server operator can write their own quests without touching C++, and the schema plus the scripting layer is the actual product here.

The world data is ProjectEQ's, and it stops at Dragons of Norrath

The content side is borrowed from another community project rather than recreated. The README states that the open source content database includes ProjectEQ's world data up through Dragons of Norrath, and that it is 100 percent customizable to create entirely new game worlds. Two things follow. The first is that the starting point is a well-known, community-maintained world rather than a thin demo zone, which is what makes a private server viable on day one. The second is a hard boundary: the data covers the original EverQuest expansions, and the client compatibility table in the README lists Titanium Edition, Secrets of Faydwer, Seeds of Destruction, Underfoot and Rain of Fear. Those are the eras the project supports, and a reader should treat that list as the ceiling of what the server emulates rather than as a sample. The customization claim is also a warning in disguise, because the same database that lets you build a new world lets you break the rules the original game enforced, and nothing in a schema of 200 tables stops you from doing that.

The repository layout is a set of subsystems, not one binary

The top level of the repository shows the shape of a modern server platform rather than a single application. There is a common/ directory for shared code, a zone/ directory for the world simulation, a queryserv/ directory for the database access layer, a loginserver/ and a ucs/ for the account and character services, an eqlaunch/ directory for the launcher, shared_memory/ for the inter-process transport, and a client_files/ directory. Alongside those sit a CMakeLists.txt, a CMakePresets.json, a cmake/ directory and a vcpkg.json for dependency management, plus a package.json whose name is eqemu-server and whose version tracks the release. There is also a submodules/ directory and a .gitmodules file, so some dependencies arrive as git submodules rather than through the package manager, and a dependencies/ directory for the rest. The build is CMake with presets rather than a hand-written makefile, and the release process is what produces the version string in package.json.

Building and running is a documented engineering task

The repository does not document a one-command install, and it does not need to: this is a server platform that a person operates. The material in the repository is aimed at that person. There is a BUILD.md at the root, a CMakePresets.json for the supported build configurations, a vcpkg.json for C++ dependencies, a package.json for the npm side of the build, and a CMakeLists.txt. A .devcontainer/ directory and a .vscode/ directory mean there is a prepared development container and editor configuration for the language server to work, and a tests/ directory sits at the top level, so the platform has a test target rather than relying on manual verification. The deployment side has its own convention, with a Docker image referenced under the akkadius/eqemu-server name and a pull count badge in the README. None of this is documented in the README prose itself, so a reader who wants the operational detail has to go to the build file and the documentation site.

The public documentation lives on MkDocs, not in the repository

The README's resources table points at docs.eqemu.dev with a MkDocs badge, and that is where the operational documentation lives, with the Discord community and the GitHub releases page as the other two entry points. That separation is deliberate and normal for a project of this size, and it has a cost. The repository README is written as a statement of purpose and respect for the original developers, and it works as that: it credits the original creators and Daybreak Game Company and states that the project does not claim ownership of the original game or its assets. The engineering details are elsewhere. A team evaluating this for a private server therefore has to read the external documentation and the build files, and a team looking for a quick summary of the architecture will find the technology stack section and the directory listing and not much beyond them.

Fan-based, non-commercial, and GPL-3.0

The licensing and the intent are stated together, and the combination is the defining constraint. The README describes the project as a passion-driven open source server emulator dedicated to preserving the legacy of a groundbreaking classic MMORPG, existing solely out of deep admiration for the original developers, artists, designers and visionaries who created the game. It has for over 20 years and always will be a fan-based, non-commercial open-source effort made by players, for players. The project is licensed GPL-3.0, with the LICENSE.md file at the root, and there is a SECURITY.md, a CODE_OF_CONDUCT.md, a CHANGELOG.md and a changelog.txt. Two practical consequences follow for an adopter. A server run under GPL-3.0 has obligations around source distribution if it is offered to users, which is a different question from running one privately, and the non-commercial framing means a company cannot use this as the basis for a commercial service without asking.

Editorial conclusion

EQEmulator suits a server operator who wants to run a private EverQuest world, to build quests and NPC scripts in Perl or Lua, or to study how a 1990s network protocol was reconstructed. It does not suit anyone looking for a current commercial game server, since the project is explicitly fan-based and non-commercial and its content database stops at Dragons of Norrath, and it does not suit a player who expects to connect with a modern client. Before adopting, read the client compatibility table rather than assuming current clients work, plan the MySQL and Perl or Lua dependency setup from BUILD.md, and note that the last push to the repository was on 2026-10-18 with v23.10.3 from 2025-09-17 as the newest release under GPL-3.0.

Frequently asked questions

Official sources

1. EQEmu/EQEmu on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases