EQWeb Features

EQWeb Features

Related: FantasyWeb · FantasyWeb Research · FantasyWeb Features

Imported from local source file: research/eqweb-features.md.

EQWeb Feature and Mechanics Design

Created: 2026-06-05 Purpose: Convert the action-centric everquest-features.md research into a complete web-based MMO / persistent browser RPG design while preserving EverQuest’s core game loops. Primary source file: everquest-features.md Web design reference files consulted:

• melvor-features.md — idle action engine, offline progression, mastery, bank/shop upgrades, completion goals.
• simplemmo-features.md — browser navigation, stepping/travel, timed actions, tasks, market, guild/PvP systems, premium currency, web safety patterns.
• torn-features.md — persistent browser resources, dashboard/status bars, cooldowns, markets, organizations, logs, risk-state design, account/API/security patterns.
• discworldmud-features.md — text command model, help/discovery systems, deep social institutions, player-run systems, roleplay verbs.
• common-features.md — local consolidation of the above into a cross-game web/PBBG/MUD feature vocabulary.

This document is not implementation architecture. It intentionally avoids database schemas, frameworks, API route plans, deployment details, component libraries, and code-level mechanics. It focuses on product design, feature shape, player actions, game loops, and web-native adaptation choices.

1. Design thesis

EQWeb is a web-native interpretation of EverQuest: not a 3D client, not a zone-by-zone map clone, and not a pure idle game. It is a persistent browser MMO that keeps EverQuest’s defining mechanics — class interdependence, dangerous combat, pulling, aggro, healing, death recovery, factions, quests, loot, spell kits, raids, guilds, trade, and long-term advancement — but expresses them through web-friendly systems:

• dashboards,
• action pages,
• timers,
• logs,
• queues,
• encounter cards,
• party/raid coordination tools,
• persistent resources,
• asynchronous and synchronous group content,
• rich text descriptions,
• web markets,
• notifications,
• account/session summaries,
• mobile-friendly short-session loops.

The goal is not to remove EverQuest’s friction. The goal is to translate the right friction into web form:

• Pulling remains meaningful, but can become encounter selection and add-management.
• Camps remain meaningful, but can become contested/instanced hunting objectives and session plans.
• Aggro remains meaningful, but can become explicit threat state and role-based turn/tick resolution.
• Death remains meaningful, but can become corpse/XP recovery, resurrection requests, and recovery timers.
• Travel remains meaningful, but can become bind points, route timers, travel risk, and destination unlocks.
• Group dependence remains meaningful, but can support asynchronous preparation and synchronous encounter execution.
• Raids remain meaningful, but can be scheduled, lockout-bound, role-assigned browser events.

In short:

EQWeb should feel like EverQuest’s systems were rebuilt for a browser-first persistent world, not like EverQuest was flattened into a generic clicker.

2. Source-to-web conversion map

{| class=“wikitable”

! EverQuest source loop/system !! Web-native EQWeb interpretation !! Web examples borrowed from other files
Character creation: race/class/deity/stats
-
Newbie commands: target, consider, hail, attack, sit, cast, loot, chat
-
Combat grind/camping
-
Pulling and aggro
-
Group loop
-
Raid loop
-
Quest dialogue and item turn-ins
-
Spellbooks/spell gems
-
Skills and tradeskills
-
Death/corpse/resurrection
-
Economy/bazaar/barter
-
Factions
-
AAs/long-term advancement
-
Overseer/mercenaries/personas
-
Housing/guild halls
-
Server rules/progression servers
}

3. High-level game identity

EQWeb is a persistent, party-oriented browser MMORPG with the following pillars:

Role interdependence. Classes are not skins. Tanks, healers, crowd controllers, pullers, support, DPS, pet classes, teleporters, and crafters should all matter.

Readable danger. Players must evaluate targets, faction, adds, aggro, death risk, resources, lockouts, and travel before acting.

Short-session compatible, long-session meaningful. The browser format should support a 2-minute check-in and a 2-hour raid night.

Asynchronous preparation, synchronous moments. Travel, crafting, market, training, buff prep, and party formation can be async; difficult fights and raids should still reward live coordination.

Text-rich world presence. Location descriptions, NPC dialogue, item lore, faction messages, combat logs, and guild/player-written text carry the world instead of graphics.

Economy as a core loop. Farming, crafting, rare drops, market speculation, player trading, bags/banks, and currency sinks are not side systems.

Consequences without cruelty. Death, corpse recovery, XP loss/debt, lockouts, travel time, and failed pulls create stories; they should not make web play feel arbitrarily hostile.

Persistent social memory. Guilds, raid logs, faction history, market reputation, resurrection assists, crafted items, and player notes should make other players memorable.

4. Web adaptation principles

4.1 Preserve loops, not camera movement

EverQuest’s core is not its camera. The web version should preserve:

• evaluating threats,
• preparing spells and gear,
• travelling to opportunity,
• finding safe camps,
• pulling and controlling enemies,
• coordinating roles,
• recovering from mistakes,
• improving character power,
• trading and crafting,
• joining guilds,
• raiding on lockouts.

It does not need to preserve:

• 3D movement precision,
• real-time positional navigation as the main input,
• graphics settings,
• visual zone fidelity,
• exact interface windows.

4.2 Turn invisible spatial skill into explicit tactical choices

A web game cannot rely on players visually reading a dungeon corner in the same way. It should expose tactical choices as readable mechanics:

• pull method,
• camp safety,
• target social radius,
• scout result,
• path risk,
• add chance,
• faction reaction,
• crowd-control availability,
• escape routes,
• resurrection availability.

The player still makes a skillful decision, but through information and risk management rather than camera manipulation.

4.3 Replace constant movement with meaningful travel states

Travel should not be removed. It should become:

• destination unlocks,
• travel timers,
• route danger,
• teleport class utility,
• bind/gate/origin choices,
• mounts and speed buffs,
• caravan/group travel,
• guild hall/fellowship travel,
• travel interruptions/events,
• market access differences by region.

4.4 Convert command complexity into layered actions

EverQuest and Discworld both show that deep command systems are powerful. In EQWeb, commands become:

• buttons for common actions,
• command/search palette for expert players,
• saved macros/action sets,
• contextual action menus,
• logs that show underlying verbs,
• help pages for each action.

A web action should still map to a clear verb: consider, pull, attack, taunt, mez, loot, bind, gate, trade, camp, resurrect.

4.5 Use timers carefully

Web MMOs often lean on timers. EQWeb should use timers to support pacing, not to replace gameplay.

Good timer uses:

• travel time,
• memorization/rest/rebuff,
• crafting combines,
• lockouts,
• resurrection windows,
• market auctions,
• agent/Overseer tasks,
• offline gathering/skilling,
• raid scheduling.

Bad timer uses:

• making every combat decision a generic cooldown button,
• hiding all class skill behind waiting,
• turning raids into passive claims,
• replacing group coordination with progress bars only.

4.6 Respect unsafe actions

From Torn and SimpleMMO, web games need strong boundaries around state-changing actions. EQWeb should classify risky actions clearly:

• spend currency,
• attack player,
• start lockout encounter,
• destroy/drop/sell valuable item,
• accept no-drop loot,
• consume resurrection timer,
• change bind point,
• leave guild/raid/group,
• switch hardcore/progression choice,
• commit to travel,
• activate expensive buff/clicky/reagent.

Risky actions should be confirmed, logged, and reversible only when the design intentionally allows reversal.

5. Web information architecture

This is product-level structure, not implementation detail.

5.1 Global shell

A browser EQ needs a persistent shell similar to Torn/SimpleMMO but tuned for RPG party play.

Persistent areas:

• Character summary: name, race, class, level, deity, server, title.
• Resource bars: HP, mana, endurance, XP, AA XP, weight/carry, coin.
• Status effects: buffs, debuffs, resurrection sickness, food/drink, invisibility, levitation, poison/disease/curse.
• Current activity: travelling, fighting, meditating, crafting, camping, dead, in raid, offline action.
• Notifications: tells, group invites, guild messages, market sales, raid ready checks, corpse/resurrection requests.
• Quick actions: rest/meditate, inventory, spells, group, guild, market, map, quests, logs.
• Warning state: KOS faction, low food, encumbered, spell mem incomplete, corpse timer, lockout, PvP danger.

5.2 Main navigation areas

A useful web navigation model:

Home / Dashboard — status, current activity, next recommendations, pending rewards, alerts.

Character — stats, skills, class, AAs, personas, titles, achievements.

World — current location, routes, camps, travel, map, bind points, faction context.

Hunt / Combat — hunting areas, camp plans, encounter queue, combat log, dungeons.

Group / Raid — party finder, role assignments, ready checks, raid calendar, lockouts, loot.

Spells / Abilities — spellbook, memorized spells, disciplines, AAs, hot actions, pets.

Inventory / Bank — items, bags, equipment sets, bank, shared storage, parcels.

Quests / Tasks — quest journal, NPC conversations, turn-ins, missions, heroic adventures.

Skills / Tradeskills — recipes, skill actions, trainers, mastery, gathering, crafting.

Market — merchants, bazaar, barter, auctions, direct trade, price history.

Factions — faction standings, enemies/allies, vendor/quest gates, reputation changes.

Guild / Social — guild, friends, chat, forums/boards, mail, fellowships.

Housing / Hall — property, trophies, guild hall, anchors, storage.

Events / Progression — world events, progression server unlocks, seasonal tasks, achievements.

Account — membership, settings, API, security, notifications, server list.

5.3 Dashboard philosophy

The dashboard should answer:

• What am I doing now?
• Am I safe?
• What resources are low?
• What opportunities are pending?
• Who needs me?
• What goals did I set?
• What changed while I was away?

Examples:

• “You are meditating at Camp: Lower Ruins. Mana full in 4m 20s.”
• “Your group is waiting for a healer.”
• “Corpse expires in 1h 12m; resurrection request pending.”
• “Auction sold: Fine Steel Longsword.”
• “Faction warning: Guards of Qeynos would attack you here.”
• “Raid lockout expires tomorrow.”
• “Offline fishing completed: 184 fish, 2 rare catches, skill +1.”

6. Core web gameplay loops

6.1 New-character loop

EverQuest’s new-character loop converts directly into a browser onboarding sequence:

Choose server/ruleset.

Choose race, class, deity, starting city/origin, and stats.

Land on a beginner dashboard with simple goals:

** inspect character, ** equip starter weapon, ** memorize starter spell if applicable, ** consider a target, ** defeat a low-risk enemy, ** loot corpse, ** sell item, ** train skill, ** speak to NPC, ** join newbie chat.

Teach faction and danger early through readable con states.

Teach rest/meditation and downtime.

Teach travel through a short route.

Offer first group/guild/social prompt after the player understands solo basics.

6.2 Short web session loop

A browser MMO must support quick check-ins without invalidating deeper play.

Typical 3-minute session:

Open dashboard.

Claim offline or timed results.

Read notifications.

Repair/rebuff/rest if needed.

Start a safe action: meditate, craft, gather, travel, train skill, list item, send merc/agent.

Queue a goal or join a group notification.

6.3 Medium session loop

Typical 15–30 minute session:

Choose goal: XP, faction, quest item, trade, dungeon step.

Travel to camp or join party.

Pull several encounters.

Manage resources and loot.

Complete quest/task or gain progress.

Return to merchant/bank/trainer.

Set offline action.

6.4 Long group session loop

Typical 1–3 hour session:

Form group with roles.

Choose camp/dungeon objective.

Travel and establish camp.

Pull, control adds, kill, recover resources.

Handle named spawns, quest steps, rare drops, deaths.

Decide whether to stay, move deeper, or disband.

Split loot and summarize progress.

6.5 Raid session loop

Guild schedules raid.

Players sign up with class/persona/role.

Raid leader publishes requirements and strategy notes.

Players prepare flags, keys, resist gear, consumables, spells, and lockout availability.

Raid opens at scheduled time.

Boss phases are resolved through role actions, timers, logs, and coordination.

Deaths, resurrections, wipes, recovery, and reattempts matter.

Loot is distributed by rules.

Lockouts, achievements, flags, and raid logs update.

6.6 Offline support loop

EQWeb should not turn EverQuest into a pure idle game, but it can borrow Melvor-style offline support for non-critical activities:

• forage,
• fishing,
• tradeskill prep,
• travel,
• meditation/rest,
• spell research,
• merchant selling/listing,
• mercenary/agent errands,
• safe faction chores,
• low-risk skill practice.

Offline should generally avoid:

• high-stakes dungeon pulls,
• raids,
• contested named encounters,
• PvP attacks,
• irreversible quest choices,
• corpse recovery decisions,
• expensive trades without explicit setup.

7. Character model in web form

7.1 Race

Races should remain mechanically meaningful but web-readable:

• allowed classes,
• starting faction,
• vision/utility traits expressed as mechanics,
• stat modifiers,
• innate actions such as hide, slam, forage, regeneration, or tinkering where appropriate,
• cultural crafting/gear hooks,
• starting regions and faction risk.

Web presentation:

• race card with strengths/penalties,
• faction preview,
• class compatibility grid,
• starting danger warnings,
• long-term consequence note.

7.2 Class

Classes must preserve EverQuest’s role identity.

Web class pages should define:

• group role,
• solo difficulty,
• primary resources,
• spell/ability categories,
• gear restrictions,
• pet/merc interaction,
• travel utility,
• raid desirability,
• downtime pattern,
• newbie complexity.

Classes:

• Warrior.
• Paladin.
• Shadow Knight.
• Rogue.
• Monk.
• Ranger.
• Bard.
• Enchanter.
• Necromancer.
• Magician.
• Wizard.
• Cleric.
• Druid.
• Shaman.
• Beastlord.
• Berserker.

7.3 Deity

Deity can be more visible in the web version:

• faction changes,
• faith quests,
• deity-restricted items,
• title/flavor,
• worship tasks,
• deity events,
• minor long-term identity differences.

Borrowing from SimpleMMO’s worship/gods and Discworld’s faith systems, deity can support optional social/reputation loops without replacing class identity.

7.4 Stats and resources

Core stats:

• Strength.
• Stamina.
• Agility.
• Dexterity.
• Wisdom.
• Intelligence.
• Charisma.

Derived/status resources:

• HP.
• Mana.
• Endurance.
• Armour class/mitigation.
• Resistances.
• Accuracy/evasion.
• Weight/carry.
• Food/drink duration.
• Buff/debuff slots or limits.
• XP and AA XP.
• Coin/currencies.

Web presentation should expose what each stat changes. Avoid hiding too many crucial formulas behind mystery; EverQuest-style uncertainty is fine, but players need enough signal to make informed web decisions.

8. Classes as web action kits

8.1 Tank classes

Warrior

Web actions:

• taunt,
• defensive discipline,
• shield/weapon stance,
• intercept/add control,
• hold main target,
• emergency mitigation,
• assist/mark target.

Web design challenge:

Warriors can feel passive in a browser if reduced to “take damage.” They need meaningful choices around defensive timing, threat, target marking, and raid survival windows.

Paladin

Web actions:

• stun for snap aggro,
• heal self/ally,
• Lay on Hands,
• root/lull utility,
• undead specialization,
• resurrection support,
• defensive buffs.

Web design challenge:

Paladins should be the readable “safe tank” with recovery tools, but not replace clerics.

Shadow Knight

Web actions:

• lifetap,
• disease/darkness DoTs,
• snare,
• fear,
• Feign Death split,
• pet assist,
• Harm Touch.

Web design challenge:

Feign Death pulling must become a clear web mini-loop: attempt split, check adds, choose wait/stand/retreat, return to camp.

8.2 Melee and hybrid classes

Rogue

Web actions:

• backstab from proper combat state,
• sneak/hide travel,
• pick lock,
• pick pocket,
• apply poison,
• disarm trap,
• high-risk burst DPS.

Rogue web gameplay should include non-combat utility pages: locked doors/chests, traps, stealth scouting, and market value from rare loot access.

Monk

Web actions:

• Feign Death pull,
• Mend,
• special strikes,
• weight discipline,
• avoidance tanking,
• split pack.

Monk is a perfect web pulling class because the player can manage risk states explicitly.

Ranger

Web actions:

• track,
• snare/root,
• archery volley,
• melee DPS,
• forage,
• outdoor scouting,
• utility buffs.

Rangers should make exploration and target discovery easier in a browser environment.

Bard

Web actions:

• choose song set,
• twist songs,
• mez/charm/pull,
• speed song,
• mana song,
• resist song,
• group support.

Web challenge:

Bard intensity should not become carpal tunnel clicking. Use song rotations, timing windows, and encounter-level choices rather than requiring every few seconds of manual input.

8.3 Caster classes

Enchanter

Web actions:

• mez add,
• charm enemy,
• lull pull,
• haste ally,
• clarity/mana regen,
• slow/debuff,
• stun emergency.

Enchanters should be high skill because their decisions prevent wipes. Web logs should make their impact obvious.

Necromancer

Web actions:

• DoT stack,
• snare/fear,
• lifetap,
• Feign Death,
• undead charm,
• pet management,
• mana/HP transfer.

Necromancers should be strong solo and recovery-oriented, with clear risk/reward over time.

Magician

Web actions:

• summon pet,
• equip pet,
• nuke,
• damage shield,
• summon utility items,
• mod rod/support.

Magicians fit web play well because pet state can persist across actions and sessions.

Wizard

Web actions:

• burst nuke,
• root/snare utility,
• teleport/evac,
• AoE/quad-style encounter plans,
• mana burn windows.

Wizards need meaningful travel economy and burst windows so they do not become “wait for mana, click nuke.”

8.4 Priest classes

Cleric

Web actions:

• heal,
• Complete Heal timing,
• resurrection,
• HP/AC/resist buffs,
• cure,
• undead nukes,
• root safety.

Clerics should be socially valuable because resurrection and efficient healing change group risk.

Druid

Web actions:

• heal,
• snare/root,
• DoT/nuke,
• damage shield,
• regen,
• animal charm,
• teleport,
• forage/track-like utility.

Druids should connect world travel, solo play, and support economies.

Shaman

Web actions:

• slow,
• buff stats,
• regen,
• debuff,
• DoT,
• heal,
• Cannibalize,
• alchemy.

Shamans should define efficiency: slower enemy damage, better sustain, and crafted consumable support.

9. Combat conversion

9.1 Combat page model

A web combat encounter should show:

• target name/type/faction,
• con/difficulty,
• HP bars,
• player/party resources,
• current threat target,
• adds/controlled enemies,
• buffs/debuffs,
• action log,
• available class actions,
• escape/flee options,
• loot/XP preview where appropriate,
• death/corpse risk.

9.2 Combat time model

EQWeb can support several combat pacing modes:

Solo quick combat: streamlined resolution for low-risk mobs.

Tactical round combat: player chooses actions per round or tick for meaningful fights.

Group live combat: party members act during timed windows.

Raid phase combat: boss phases, ready checks, assignments, and event logs.

Idle low-risk grind: only for content safely below the player’s power, with limited rewards and clear risk thresholds.

9.3 Auto-attack and ability timing

Auto-attack can be represented as:

• baseline damage ticks,
• weapon delay/haste effects,
• offhand checks,
• proc logs,
• stance effects.

Player agency comes from:

• ability timing,
• target switching,
• crowd control,
• heal timing,
• taunt/threat decisions,
• pet commands,
• consumable use,
• retreat decisions.

9.4 Pulling and camp safety

Pulling is too central to EverQuest to omit. In EQWeb, a camp can have:

• camp name/area,
• known enemy pool,
• respawn pressure,
• safe/rest quality,
• social-add risk,
• faction risk,
• named spawn chance,
• group recommended roles,
• pull methods available.

Pull action flow:

Scout/track/consider camp.

Select pull target.

Choose pull method: body, ranged, spell, lull, harmony, pet, Feign Death, snare, bard song.

Resolve social-add risk.

If adds arrive, choose mez/root/offtank/flee/FD/reset.

Bring target to camp.

Fight.

Rest/rebuff/loot.

9.5 Aggro and threat

Aggro should be explicit enough for web play:

• current target of each enemy,
• tank threat lead,
• recent threat events,
• taunt result,
• heal aggro warnings,
• mez/root break warnings,
• pet threat.

Do not remove threat mystery completely. Some uncertainty is good, but players should understand why a wipe happened.

9.6 Crowd control

CC should be a first-class web state:

• mezzed enemy with break risk,
• rooted enemy with distance risk,
• slowed enemy with duration,
• charmed enemy with break chance,
• feared enemy with path risk,
• stunned enemy with short timer,
• lulled enemy with pull modifier.

The encounter log should celebrate CC success because it is core to EverQuest identity.

9.7 Damage, mitigation, and resistances

EQWeb should preserve:

• weapon damage/delay,
• haste,
• armour class,
• avoidance,
• resists,
• spell schools,
• damage types,
• buffs/debuffs,
• critical/special attacks in later-era style,
• gear importance.

9.8 Food, rest, and downtime

Melvor’s Auto Eat and EverQuest’s meditation/rest can combine carefully:

• food can be consumed manually or through limited auto-consume settings,
• meditation/rest should recover mana more efficiently at safe camps,
• group downtime can become a tactical planning moment,
• buffs and songs reduce downtime,
• danger can interrupt rest.

10. Death and recovery in the browser

10.1 Death states

Possible death/recovery states:

• defeated but recoverable,
• dead with corpse,
• corpse in dangerous location,
• resurrectable by player/NPC/mercenary,
• XP loss/debt pending,
• resurrection sickness,
• hardcore death/permanent consequence in special mode.

10.2 Corpse page

A corpse/recovery page can show:

• corpse location,
• decay timer,
• items/XP risk summary depending on ruleset,
• consent list,
• resurrection offers,
• guild recovery help,
• summon corpse options,
• safe recovery alternatives,
• last combat log.

10.3 Resurrection social loop

Preserve the social value of clerics/paladins/necromancers:

• players can post resurrection requests,
• guild/friends can receive alerts,
• resurrection percentage/quality matters,
• corpse summoning matters,
• consent permissions matter,
• resurrection actions generate social reputation or logs.

10.4 Web-friendly penalty tuning

Web penalties should be meaningful but not session-destroying:

• XP loss/debt can exist,
• corpse recovery can create risk,
• resurrection reduces loss,
• repeated unsafe deaths can escalate penalties,
• beginner protections should exist,
• hardcore/progression servers can opt into stricter rules.

11. Quests, NPCs, and faction in web form

11.1 NPC interaction

NPC pages should support:

• hail/greeting,
• keyword-style dialogue,
• visible known topics,
• hidden/discovered keywords,
• faction reaction,
• merchant/trainer/quest services,
• item hand-ins,
• lore text,
• conversation log.

Borrow from Discworld’s text depth: conversation should feel like interacting with a world, not just clicking “Accept Quest.”

11.2 Quest models

Supported quest forms:

• classic item turn-ins,
• kill tasks,
• delivery routes,
• faction tasks,
• class quests,
• epic quests,
• tradeskill quests,
• raid flagging quests,
• key quests,
• repeatable tasks,
• daily/weekly optional tasks,
• heroic adventure-style missions.

11.3 Quest journal

A web quest journal can include:

• active quests,
• discovered NPCs,
• incomplete clues,
• required items,
• faction requirements,
• group/raid requirements,
• lockouts,
• completed quest history,
• spoiler-light hint toggles.

11.4 Faction presentation

Faction should have a dedicated page:

• standings by faction,
• con message equivalents,
• recent changes,
• hostile/friendly vendors,
• quest availability,
• illusion/sneak/invis modifiers,
• faction repair paths,
• faction conflict warnings.

Web adaptation should avoid making exact numbers mandatory. Qualitative states preserve EverQuest flavor.

12. Progression and advancement

12.1 Levels and XP

Preserve:

• level-based power,
• XP from kills and quests,
• group XP rules,
• difficulty-based XP,
• death XP penalties or debt,
• level-gated abilities.

Web additions:

• XP history logs,
• goal tracking,
• session summaries,
• offline safe XP limits,
• recommended next camps based on level/role/faction.

12.2 Skill system

EverQuest skills can become visible pages:

• weapon skills,
• defensive skills,
• casting schools,
• class abilities,
• tradeskills,
• utility skills,
• racial skills.

Players can see:

• current skill,
• cap,
• how it improves,
• recent skill-ups,
• relevant stats,
• trainers,
• practice actions.

12.3 Alternate Advancement

AAs should be treated like Torn merits plus EverQuest class depth:

• AA XP allocation,
• passive and active abilities,
• class-specific trees,
• utility unlocks,
• tradeskill improvements,
• build presets,
• long-term planning,
• respec rules if any.

12.4 Mastery-style adaptation

Melvor’s mastery can inspire EQWeb, but should not overwrite EverQuest.

Potential mastery targets:

• spell use mastery,
• weapon type mastery,
• tradeskill recipe mastery,
• camp familiarity,
• faction work mastery,
• pull method mastery,
• pet command mastery.

Mastery should be subtle: improve efficiency, reduce failure, unlock quality-of-life, or grant titles. Avoid making it a mandatory grind for every action unless the game intentionally leans idle.

12.5 Education/training equivalent

Borrowing from Torn, EQWeb can support long-term training tracks without violating EverQuest flavor:

• guild lessons,
• spell research apprenticeships,
• combat drills,
• crafting apprenticeships,
• bard colleges,
• priest devotional study,
• rogue underworld contacts.

These are long timers/passives, not replacements for active leveling.

13. Skills, crafting, gathering, and production

13.1 Tradeskill pages

Each tradeskill should have:

• current skill/cap,
• recipes known,
• recipe discovery,
• required ingredients,
• success chance band,
• tool/container requirements,
• output quality/quantity,
• market value hints,
• trophy/progression goals.

Tradeskills:

• baking,
• brewing,
• blacksmithing,
• fletching,
• jewelcraft,
• pottery,
• tailoring,
• research,
• alchemy,
• poison making,
• tinkering,
• fishing.

13.2 Gathering and farming

EverQuest is less gathering-first than Melvor, but web EQ benefits from safe, session-friendly gathering:

• fishing,
• foraging,
• harvesting tradeskill components,
• hunting for drops,
• mining/woodcutting only if lore/ruleset supports them,
• scavenging dungeon components,
• vendor restock arbitrage,
• faction-gated component acquisition.

13.3 Production chains

Examples:

• mob drops → crafting components → gear/consumables,
• fish → food → combat sustain,
• herbs/reagents → potions/spells,
• ore/metal → weapons/armour,
• hides/silks → tailoring,
• research pages/runes → spells,
• poison ingredients → rogue poisons,
• raid drops → augments/upgrades.

13.4 Crafting and market integration

Crafting must feed the economy:

• crafted gear for leveling brackets,
• consumables for raids,
• spells/research for casters,
• cultural/deity/race items,
• trophy/equipment progression,
• buy orders for components,
• guild crafting requests,
• market price discovery.

14. Items, inventory, bank, and loot

14.1 Web inventory needs

EverQuest item management is central. A browser version should make it powerful:

• bags within inventory,
• weight/capacity,
• equipment slots,
• gear sets,
• bank,
• shared bank,
• guild bank,
• tradeskill storage,
• search/sort/filter,
• item locking,
• loot history,
• no-drop/lore warnings,
• compare equipment,
• augment management.

14.2 Loot systems

Loot should support:

• corpse loot,
• solo auto-loot preferences,
• group need/greed/pass,
• master looter,
• raid loot rules,
• lockout chests,
• rare drop announcements,
• loot logs,
• item claims,
• vendor trash marking,
• parcel/mail delivery.

14.3 Item identity

Items need EverQuest-like specificity:

• race/class/deity restrictions,
• lore/no-drop/tradeable flags,
• focus effects,
• click effects,
• procs,
• charges,
• aug slots,
• tribute value,
• faction or quest relevance,
• market history,
• collection/discovery status.

14.4 Bank and storage upgrades

Borrow from Melvor and Torn:

• bank slot upgrades,
• bags as meaningful purchases,
• shared bank/mule reduction,
• tradeskill depot,
• vault/property storage,
• guild hall storage,
• premium or membership storage benefits if monetized.

15. Economy and markets

15.1 Currencies

EverQuest currencies:

• copper,
• silver,
• gold,
• platinum,
• alternate currencies,
• loyalty-like currency,
• mission/raid currencies,
• marketplace currency,
• Krono-like membership token.

15.2 Merchant economy

NPC vendors should provide:

• buy/sell,
• faction/charisma price effects,
• location stock,
• spell vendors,
• tradeskill vendors,
• food/drink vendors,
• limited stock or restock timers where useful,
• vendor search for discovered merchants.

15.3 Bazaar and auction design

Web EQ should make the bazaar a major product surface:

• search/filter listings,
• item detail pages,
• price history,
• seller reputation or shop pages,
• buy now,
• auctions,
• buy orders/barter,
• listing fees/taxes,
• favorites/watchlist,
• parcel delivery,
• trade confirmations.

15.4 Direct trading

Direct trade should include:

• offer/accept/confirm stages,
• item and currency preview,
• no-drop/lore warnings,
• trade logs,
• cancel safety,
• anti-scam UI,
• escrow options for high-value trades.

15.5 Economy loops

Primary web economy loops:

• farm rare drops → sell/buy upgrades,
• craft consumables → sell to raiders,
• buy components → craft → market,
• faction grind → access vendor → arbitrage/use,
• raid currency → buy gear,
• bazaar speculation,
• Krono/membership-token trading,
• guild bank contribution.

16. Social, groups, guilds, and communication

16.1 Chat and messaging

Web EQ should support:

• local say,
• tells,
• group chat,
• guild chat,
• raid chat,
• auction/trade chat,
• newbie/help chat,
• custom channels,
• mail/parcel notes,
• emotes,
• combat/loot/faction logs.

16.2 Friends and reputation

Features:

• friends list,
• ignore/block,
• notes about players,
• recent group history,
• resurrection/help history,
• trade history,
• invite preferences,
• online/offline status privacy.

16.3 Group finder

A browser EverQuest needs strong group discovery:

• looking-for-group flag,
• desired role,
• class/level/gear notes,
• target camps/quests,
• session length,
• voice/chat preference,
• replacement requests,
• mercenary willingness,
• reputation/previous grouping if appropriate.

16.4 Party management

Group page:

• member roles,
• HP/mana/endurance summaries,
• buffs/debuffs,
• current camp,
• pull target,
• loot rules,
• ready states,
• AFK markers,
• encounter log,
• resurrection/corpse state.

16.5 Guilds

Guilds should be more than chat:

• ranks and permissions,
• guild bank,
• raid calendar,
• signups,
• DKP/loot notes if desired,
• guild hall,
• guild achievements,
• recruitment page,
• crafting requests,
• corpse/resurrection alerts,
• progression targets,
• officer logs.

16.6 Fellowships and small circles

For friend groups:

• small persistent group,
• campfire/meeting point,
• shared vitality/catch-up,
• lightweight chat,
• shared goals,
• travel assistance.

17. Raids and high-end content

17.1 Raid identity

Raids are the web test of EverQuest’s social systems. They should include:

• required roles,
• flags/keys,
• lockouts,
• scheduled windows,
• preparation checklists,
• phase mechanics,
• wipe/recovery,
• loot rules,
• raid achievements,
• progression unlocks.

17.2 Raid preparation

Before raid:

• sign up,
• select class/persona,
• confirm spells/gear/resists,
• verify lockout availability,
• acquire consumables,
• set bind/travel route,
• review strategy notes,
• assign tanks/healers/CC/pullers/DPS/support.

17.3 Raid execution

During raid:

• live encounter log,
• boss phase cards,
• role assignments,
• timed mechanics,
• add waves,
• debuff/curse warnings,
• death/resurrection queue,
• loot lock after kill,
• ready checks between attempts.

17.4 World bosses and public events

Borrow from SimpleMMO world bosses but keep EverQuest depth:

• public targets with contribution thresholds,
• limited windows,
• guild competition or cooperation,
• lockouts/eligibility,
• faction consequences,
• rare drops and currency,
• server-wide logs.

18. Travel, maps, and world structure

18.1 Locations without 3D zones

A web location can be:

• city/hub,
• wilderness route,
• camp,
• dungeon layer,
• raid instance,
• player/guild property,
• market district,
• faction stronghold.

18.2 Location page

Show:

• description,
• faction danger,
• available exits/routes,
• NPCs/services,
• camps/enemies,
• quests,
• shops,
• bind/travel options,
• players present if appropriate,
• weather/time modifiers if supported.

18.3 Travel utility as class identity

Druids and Wizards should matter economically/socially:

• teleport services,
• group ports,
• evacuation,
• travel contracts,
• guild travel networks,
• portal cooldowns,
• tip/payment conventions.

18.4 Bind, gate, origin

These should be prominent:

• current bind point,
• change bind warnings,
• gate availability,
• origin cooldown,
• corpse recovery implications,
• unsafe bind warnings.

19. Modern EverQuest systems in web form

19.1 Mercenaries

Web mercenaries:

• hire from mercenary liaison,
• choose role: tank, healer, melee DPS, caster DPS,
• pay upkeep,
• set stance,
• suspend/resume,
• take group slot,
• contribute to solo/small-group content,
• not replace skilled players in hard content.

19.2 Pets and summons

Pet management page:

• active pet,
• pet HP/buffs,
• stance/commands,
• pet gear,
• summon/reclaim,
• pet threat,
• charmed-pet break risk,
• swarm pet effects.

19.3 Overseer / agent tasks

A web version of Overseer fits naturally:

• collect agents,
• assign timed missions,
• use traits/counters,
• claim rewards,
• catch-up support,
• avoid replacing core adventuring.

19.4 Alternate personas

Personas can work well in browser:

• switch class build under safe conditions,
• shared identity/inventory/achievements,
• separate spellbooks/loadouts/binds where required,
• group/raid signup by persona,
• gear compatibility warnings.

19.5 Heroic characters

Heroic characters become:

• skip-to-level option,
• starter gear/spells/AAs,
• tutorial for high-level systems,
• limited server/ruleset restrictions,
• account/membership purchase or reward.

19.6 Housing and guild halls

Web property can be functional:

• storage,
• trophies,
• travel anchors,
• crafting stations,
• guild staging,
• social page,
• access permissions,
• market/vendor integration if desired.

20. Idle and asynchronous systems

20.1 What can idle

Appropriate idle/asynchronous systems:

• meditation/rest,
• travel,
• tradeskills with prepared materials,
• fishing/foraging,
• low-risk skill practice,
• spell research,
• market listings,
• agent/Overseer tasks,
• mercenary errands,
• housing/guild hall tasks,
• faction chores with low risk.

20.2 What should stay active

Should require active decisions:

• meaningful pulls,
• dangerous dungeons,
• raid fights,
• PvP,
• death recovery choices,
• high-value trades,
• class-defining crowd-control/heal/tank decisions,
• rare named encounters,
• irreversible quest hand-ins.

20.3 Offline summary

Upon return:

• activity completed,
• XP gained,
• items gained/lost,
• skill-ups,
• money changes,
• market sales,
• messages/invites,
• risks encountered,
• action stopped reason.

20.4 Automation upgrades

Borrow from Melvor carefully:

• auto-eat for trivial/known content,
• auto-loot rules,
• auto-sell trash rules,
• saved spell/gear sets,
• crafting repeat options,
• travel route presets,
• market saved searches.

Automation should not trivialize group interdependence.

21. Web-specific risk and confirmation model

21.1 Risk classes

Classify actions:

• Read-only: view profile, inspect item, open map, read quest, check market.
• Low-risk reversible: change filters, set notes, rearrange inventory.
• Resource-spending: buy, sell, train, craft, travel, cast reagent spell.
• Commitment: accept raid lockout, change bind, start long travel, switch persona, start education/agent task.
• High-risk irreversible: delete/destroy item, no-drop loot, epic turn-in, leave guild, hardcore death choice.
• Social-impact: attack, trade, message, invite, promote/kick, declare raid/war.

21.2 Confirmations and logs

High-risk actions should create:

• preview,
• confirmation,
• post-action log,
• notification if social,
• undo only where design allows.

21.3 Anti-frustration design

Web players are often interrupted. EQWeb should include:

• safe camp/logout states,
• clear danger if leaving mid-fight,
• auto-flee thresholds,
• group AFK markers,
• reconnection summaries,
• timeout handling for raids/groups,
• safe beginner protections.

22. Monetization and account status

22.1 Membership

If modeled after live EverQuest:

• free play,
• All Access-like membership,
• character slots,
• AA access limits/unlocks,
• spell rank access,
• mercenary access,
• market/broker access,
• housing/guild hall access,
• progression server access,
• monthly premium currency,
• marketplace discount.

22.2 Marketplace

Possible categories:

• cosmetics,
• convenience storage,
• character slots,
• persona slots,
• server transfers,
• name changes,
• mount/familiar cosmetics,
• heroic character upgrades,
• non-combat boosts,
• account services.

22.3 Krono-like token

A tradable membership token can fit the economy but needs caution:

• high-value item,
• tradeable in market/direct trade,
• redeemable for membership time,
• strong anti-fraud and confirmation needs,
• economy impact tracking.

22.4 Monetization principle

Do not let web conversion become pay-to-win. EverQuest’s identity depends on earned class mastery, social reputation, and difficult progression.

23. Server rulesets and game modes

23.1 Standard web server

• Modern features enabled.
• Full web convenience.
• Longer-term progression.
• AAs/personas/mercenaries/housing as appropriate.

23.2 Classic/progression server

• Era unlocks.
• Restricted races/classes/features.
• More dangerous death/corpse rules.
• Slower XP/economy.
• Raid lockout rules.
• Limited automation.

23.3 Hardcore server

• Harsh death penalties.
• Special achievements/titles.
• Conservative automation.
• High social prestige.

23.4 Seasonal server

• Reset cadence.
• Special modifiers.
• Leaderboards.
• Unique cosmetics/titles.
• Faster progression.

23.5 Solo/self-found mode

• Reduced trading.
• Mercenary/companion adjustments.
• Separate achievements.
• No market dependence.

24. Feature/component inventory

{| class=“wikitable”

! Area !! EQWeb feature set
Account/platform
-
Dashboard
-
Character creation
-
Classes
-
Resources
-
Combat
-
Grouping
-
Raids
-
Magic
-
Skills
-
AAs/progression
-
Quests
-
Faction
-
Death/recovery
-
Travel/world
-
Inventory
-
Loot
-
Economy
-
Crafting
-
Idle/offline
-
Pets/mercs
-
Housing/guild halls
-
Social
-
Events
-
Monetization
-
Safety/logs
}

25. Player action catalog

25.1 Dashboard/session actions

• check status,
• claim offline summary,
• read notifications,
• resume activity,
• rest/meditate,
• set goal,
• join group invite,
• inspect corpse/lockout/market alert.

25.2 World actions

• look at location,
• inspect NPC,
• consider target,
• travel route,
• bind,
• gate,
• teleport,
• forage,
• track,
• scout camp,
• set camp.

25.3 Combat actions

• pull,
• attack,
• assist,
• taunt,
• bash/kick/backstab,
• cast spell,
• sing song,
• activate discipline,
• activate AA,
• send pet,
• mez/root/snare/charm/fear/stun,
• heal/cure/resurrect,
• flee/Feign Death,
• loot corpse.

25.4 Character progression actions

• train skill,
• allocate AA XP,
• buy AA,
• memorize spell,
• save spell set,
• switch persona,
• equip gear set,
• complete achievement,
• claim title.

25.5 Economy actions

• buy from merchant,
• sell to merchant,
• list bazaar item,
• search market,
• place buy order,
• bid auction,
• direct trade,
• send parcel,
• bank deposit/withdraw,
• inspect price history.

25.6 Crafting actions

• learn recipe,
• gather components,
• combine,
• repeat combine,
• evolve trophy,
• fulfill crafting request,
• research spell,
• make potion/poison,
• sell crafted output.

25.7 Social actions

• say,
• tell,
• group chat,
• guild chat,
• raid chat,
• auction chat,
• invite,
• ready check,
• assign role,
• request resurrection,
• consent corpse drag/summon,
• post forum/board,
• friend/ignore/report.

26. Key design tensions

26.1 EverQuest danger vs browser convenience

If EQWeb is too convenient, it loses EverQuest’s identity. If it is too punishing, browser players will bounce. The right balance is:

• make risk visible before action,
• keep meaningful consequences,
• provide recovery routes,
• preserve social rescue,
• reduce only the friction that came from old interface limitations.

26.2 Idle play vs class mastery

Idle support is necessary for web pacing, but class mastery must remain active. Tradeskills, travel, rest, and low-risk gathering can idle. Pulling, CC, healing, raid phases, and dangerous named fights should not be fully idle.

26.3 Market power vs adventure power

Web economies can dominate games. EQWeb should let trade matter while protecting the value of adventuring:

• no-drop/attuned/flagged items where needed,
• raid currency and lockouts,
• crafted gear niches,
• consumable demand,
• wealth sinks,
• market transparency.

26.4 Solo accessibility vs group identity

Mercenaries and idle systems help solo players, but EverQuest’s identity needs groups. Solution:

• solo/merc content supports leveling and catch-up,
• groups are more efficient and unlock key content,
• raids and high-end progression require coordination,
• class utility retains social value.

26.5 Exact EverQuest nostalgia vs web-native clarity

Some mystery is part of EverQuest. But web players expect clear state. Preserve mystery in exploration, faction, rare drops, and hidden quests; provide clarity for resource spending, death risk, irreversible actions, and group obligations.

27. What not to build yet

Avoid diving into implementation details at this stage:

• no database schema,
• no API endpoint list,
• no frontend framework choice,
• no component library selection,
• no backend architecture,
• no exact combat formulas,
• no monetization pricing,
• no full zone list,
• no precise drop tables,
• no class balance numbers,
• no server infrastructure plan.

Those come after the product loop and feature surface are agreed.

28. Suggested next design artifacts

After this feature document, the next useful non-implementation artifacts would be:

Player journey map: first hour, first week, first group, first dungeon, first raid.

Class role matrix: every class by solo/group/raid/tradeskill/travel/social value.

Resource model: HP/mana/endurance/XP/AA/coin/lockouts and what spends/regenerates each.

Combat encounter model: solo fight, group camp, dungeon boss, raid boss examples.

Web page sitemap: product pages and what each page lets players do.

Risk/confirmation matrix: all state-changing actions by severity.

Economy flow map: sources/sinks for coin, items, currencies, and premium tokens.

MVP scope proposal: minimum feature subset that still feels like EverQuest in a browser.

29. Caveats

• This is a derivative design synthesis from local feature files, not fresh public internet research.
• It uses everquest-features.md as the authoritative mechanics source for EverQuest loops.
• It uses the other local *-features.md files as examples of browser, MUD, idle, PBBG, market, timer, and social design patterns.
• It intentionally avoids implementation details.
• It does not attempt to enumerate EverQuest zones or cities.
• It does not address graphics options.
• Some live EverQuest mechanics vary by era/server/ruleset; EQWeb should represent these through ruleset modes rather than assuming one universal ruleset.