Concept: User Profile¶
Pitch¶
A two-layer player identity surface — a Profile Card that glorifies the player (who they are, where they rank, who their friends are), and a Hero Screen that glorifies the character (class, power, build). Every avatar in the game is one tap away from this surface, so identity, social action, and build inspection live in a single, consistent place.
Problem / opportunity¶
Overlord today already exposes a lot of "who is this person" signals across chat, friends, party, leaderboards, arena, vassals, and gifts. But there is no single canonical place a player can go to see another player as a person and as a build, decide what to do with them (befriend, message, gift, copy their loadout, block), and — for their own profile — express who they are.
A good profile system unlocks three things at once:
- Social glue. A common destination behind every avatar. Friend, party, chat, vassal, and gift actions all converge here, instead of being scattered per-screen.
- Aspirational comparison. The Hero Screen lets players inspect builds of stronger players, see deltas vs. their own, and one-tap-copy a loadout. The corpus is consistent that "show off / compare" is a core mid-core retention driver (Legend of Mushroom's inspect+compare panels; the "peacocking" motivation in Mid-Core Success Part 3 and CAPS framework).
- Cosmetic monetization surface. Avatars, frames, card backgrounds, model skins, and statuses are the cheapest, most visible expression slot we have. Industry trend reports (Episode 41) flag cosmetic item-type expansion — frames, backgrounds, customizable cosmetic sets — as a low-risk addition layered on top of core monetization.
Today none of this is centralized. The PDF-era design (gd/profile.md)
sketched the shape but is older intent, predates several systems (vassals,
party, classes-as-shipped, statue), and doesn't sit cleanly next to current
Friends / Chat / Ratings / Arena / Equipment behavior.
The concept¶
Profile Card (the player) is a popup. It opens when you tap any avatar anywhere in the game — your own avatar in the top-left, a friend in the friend list, a chat author, an arena opponent, a leaderboard row, a party member, a vassal/suzerain link. It shows:
- Avatar (with frame), nickname, gender, copyable player ID
- A short status / bio line the player writes themselves
- Current arena rank & league for the active season
- Class icon and current Power
- Suzerain / Vassal context, where applicable (a "you're someone's vassal" badge, or "you have N vassals")
- Server / timezone (so friends know when the player is likely on)
- Online indicator (online / last-seen bucket)
From the card you can act on the player: message, friend/unfriend, open their Hero Screen, block, send a gift (if relationship allows). On your own card, the same slots are replaced with "Customize", "Account settings", "Friends list", "Edit status".
Hero Screen (the character) is a full-screen view. It glorifies the character itself: a large model, an animated background, class banner, Power number, the player's equipped skills, equipped items, pets, and a "Stats" detail subscreen. From here you can:
- On someone else's Hero Screen: Compare — diff their skills, stats, and equipment against your own; Copy Build — clone their equipped skills and items into your own build (with class-mismatch and missing-skill warnings).
- On your own Hero Screen: open the Skills manager, switch class (subject to the same constraints class change has today), and open Customize (model skin, background, frame).
The pair forms a consistent identity surface: the Card is "who the player is, and what social action do I take on them"; the Hero Screen is "what their character is made of, and can I learn from / copy their build."
References¶
Grounded in retrieved corpus chunks:
- Legend of Mushroom — inspect + compare panels ("The Magic of Legend of Mushroom"): the game devotes screen real estate to letting players inspect any other player's gear and stat-compare it directly. This is cited as a key driver of "ability to show off hard work in front of peers" — which is exactly the role Hero Screen plays in Overlord.
- Mid-Core Success Part 3: Social — collaboration mechanics work because players compare progress; the place where comparison happens is the lever ("collaboration… should take place in an area of the game where players can easily show off"). The Profile Card + Hero Screen is that area for Overlord.
- CAPS framework — Cosmetics first (Episode 10, Mobile Game Doctor): the first letter of the player-motivation mnemonic is Cosmetics — how do players appear, how do they peacock to other players. Frames, statuses, card backgrounds, and skins on Hero Screen all serve this.
- Pokémon Unite postmortem — explicitly warns about putting deep cosmetic systems on screens players don't visit. Implication for us: the Profile must be visited often (every avatar tap, every social interaction), or the cosmetic layer underperforms.
- Episode 41 (2023 mobile trends) — cosmetic item type expansion (frames, customizable item sets, collection albums) is a current practice; we are sized to adopt the cheapest tier (avatar frames, card backgrounds, statuses) without building a full wardrobe system.
- "Identity with anonymity" (Teatime, Episode 8) — players want to express themselves via avatars/frames/status without exposing their real identity. Our nickname + chosen avatar + status model fits this cleanly; we don't need real photos.
Fit with Overlord¶
How this sits next to current systems (intent in gd/, shipped behavior
in gd-generated/):
- Account / accounts (
gd-generated/account-lifecycle.md): the username, avatar pool, andSetUsernamecooldown already exist. The Profile Card renders this data; "Edit status" and "Customize" are the only genuinely new player-driven account fields we add (status string, selected frame/background/avatar). - Friends (
gd/friends.md): the friend-list summary plaque is already defined (avatar, nickname, online dot, class icon, Power, profile button). The Profile Card is the destination behind that "profile button" and behind every friend-list avatar tap. Bond level shown on the friend's card is a natural addition (the friend-friend pair stat). - Chat / Mail / Party / Vassals / Arena / Ratings / Leaderboards: these are the entry points to the Profile. Every place that shows an avatar should route to the Card on tap; the spec doesn't change those features, it consolidates their "tap-an-avatar" behavior.
- Equipment / Abilities / Pets / Statue / Talents: these feed the Hero Screen as read-only displays. Compare and Copy Build read their state; nothing in the underlying systems changes.
- Class & Party (
gd-generated/class-party.md): class is already central to character identity; Hero Screen is the canonical place to show the class banner and (for self) initiate Change Class. TheSetCharacterBlockedevent already exists and is honored by chat and skins — Profile's Block action reuses it and should explicitly extend to gift sending (the generated doc notes this is currently not blocked, which is a small drift to fix as part of this feature). - Skins & Customize: skins today (
gd-generated/skins.md— 9 skin slots, visual only) feed model appearance on Hero Screen. Avatar / frame / card background are new cosmetic categories layered on top — they sit on the Profile Card, not on the character model. - Monetization: cosmetic surface for the Shop, Offers, Progress Pass, and seasonal rewards. We do not need to launch the cosmetic catalogue with the profile — V1 ships with a small starter set (avatars + 1–2 frames + 1–2 backgrounds) and the cosmetic slots exist as inventory categories ready to be filled by later content.
Drift between gd/ and gd-generated/ we need to flag for the designer:
gd/profile.mdmentions "сюзерене и вассалах (tba)" on Hero Screen — vassals did ship (gd-generated/vassals.md). The Profile Card and Hero Screen should now actually surface suzerain/vassal context.gd/profile.mdpredates the class system as shipped; "Change Class" should follow currentclass-partyrules, not the older PDF.- The old doc says "Block" affects chat —
gd-generated/social.mdconfirms blocking does not currently filter gift sends. Profile-driven Block should either fix this or explicitly document the limitation.
Risks & open questions¶
- Where does the Card surface for own profile — top-left avatar tap? Or a dedicated tab? PDF says top-left; we should confirm there is no conflict with the current main-screen UI.
- Online status granularity. Showing exact last-online time is a privacy risk and a churn signal. Likely bucket: "online / today / this week / longer". Designer to confirm.
- Status string moderation. 150-char free-text status needs the
same moderation as
SetUsername. Cooldown on status changes (to stop spam-flipping abusive statuses)? Suggest 1 hour, designer to confirm. - Copy Build economy impact. If new players can one-tap-copy top-arena builds, the build-discovery loop collapses. Mitigations: (a) Copy Build only sets which items/skills to equip from what the copying player already owns — it does not grant items; (b) skills the copier doesn't have are flagged and the slot is left empty (matches PDF intent); (c) consider a "Copy Build" daily cap to prevent grief-spam / scraping.
- Compare scope. Stats-only? Or also DPS estimate / mock-fight result? Stats-only is simpler and safer; designer to confirm.
- Cosmetic catalogue size at launch. V1 needs at least 1 paid frame + 1 paid background, otherwise we ship the cosmetic slot without a reason to ever open the Customize screen.
- Block consistency. Should Block now also block gifts (per
gd-generated/social.mdnote)? Recommend yes; designer to confirm. - Profile visit rate. Pokémon Unite warning applies: if the card is only reachable from "tap your avatar", it will under-visit. We need it reachable from every avatar surface (chat, friends, party, arena, leaderboard, vassal, gift sender, mail sender) for the cosmetic monetization layer to make sense.