EQRaidBot

2022 – present

A guild management platform for EverQuest. Intelligent raid splitting, DKP tracking, attendance management, and Discord integration - all the tools raid leaders need without the spreadsheet hell.

Raid Splits - Automated class balancing in seconds, not 45 minutes
DKP System - Three distribution styles with decay, caps, and full audit trails
Discord Bot - Character registration, event signups, DKP checks
Admin Dashboard - Guild configuration, permissions, reporting

EQRaidBot Architecture — System architecture - two Go services sharing core packages, multi-tenant with guild isolation

Dashboard — Guild dashboard showing upcoming events and recent activity

The Problem

Raid leaders on EverQuest private and TLP servers were spending 45+ minutes manually balancing raid splits - multiple times a week. You need the right mix of tanks, healers, and DPS in each group. You need to keep mains with their alts. You need to respect the social dynamics (friends together, rivals apart). Tools like EQDKP+ handle guild management fine, but nobody had solved the splitting problem.

The Solution

The split algorithm is the heart of the system. It balances class composition across raids while respecting constraints - main/alt relationships, affinity rules, and ensuring each split has a raid lead. What used to take 45 minutes now takes seconds.

Split Algorithm Flow — Raid split pipeline - preprocessing, pair extraction, class distribution, constraint enforcement, balancing

The algorithm works in phases: first it prunes alts and extracts raid leads into their own groups. Then it identifies “bot pairs” (main + box characters owned by same player) and merges affinity rules. Class distribution uses round-robin assignment into buckets (tanks, healers, casters, melee, bards) to ensure each raid has the right composition. Affinity constraints keep friends together and rivals apart. Post-processing smooths any imbalances with a high-low walk.

DKP System — DKP distribution styles, decay mechanics, and audit trail

The DKP layer supports three distribution strategies: individual (each character earns independently), mirrored (alts auto-sync with main’s adjustments), and pooled (guild-wide shared currency). Rank-based dispersal rates let guilds reward veterans differently. Decay keeps the economy healthy - either flat value or percentage, applied on a configurable interval. Every adjustment is persisted with full context for audit trails.

Growth

DKP Leaderboard — DKP standings with earned, spent, and current totals

I built this for my guild. Word spread. At peak, around 500 players across 10-12 active guilds were using it regularly. What started as a raid split generator evolved into a full platform over 2.5 years as guilds requested features and I kept shipping.

Day-to-Day

The Discord bot is how most players interact with the system. Register characters, sign up for events, check your DKP, generate splits - all through conversational commands with multi-step workflows. Raid leads use the web dashboard for the heavier lifting: event scheduling, DKP adjustments, loot history, attendance reports.

Permissions & Config

RBAC Permissions — Guild-scoped role permissions powered by Casbin

Every guild has different politics. Who can adjust DKP? Who can see attendance reports? Who’s trusted to run splits? RBAC is guild-scoped using Casbin - leaders define roles and permissions that match how their guild actually operates. DKP style, decay rates, attendance windows, loot rules - all configurable per guild.

Under the Hood

Two Go binaries (bot + web) share a common package layer. The Discord bot handles stateful multi-step workflows with 15-minute TTL sessions - if you start registering a character and walk away, it cleans up automatically. Background workers run on intervals: DKP cache rebuilds every 30 minutes, event watcher checks for repeatable events hourly, and a guild watcher triggers attendance computation every 24 hours via a signal channel.

Split algorithm: prune → pair extraction → class buckets → round-robin → affinity constraints → high-low balance
Multi-tenant: all queries scoped to guild, Casbin RBAC with guild-specific policies
Discord bot: stateful workflows with TTL cleanup, DM-based commands for privacy
DKP: strategy pattern for distribution styles, rank dispersal rates, configurable decay
Background workers: cache refresh (30min), event repeat (1hr), attendance signals (24hr)
Game abstraction: common.GameInfoImpl interface supporting EQ and EQ2 class mappings
Data: PostgreSQL for app state, read-only connection to EQEmulator DB for character validation

Stack: Go (Echo), Next.js, PostgreSQL, Discord API, Casbin (RBAC), Terraform

Built over 2.5 years, pre-AI - every line of architecture and code is mine. Battle-tested through real guild drama and edge cases. Runs unattended without issues. Still live today.