Live-Service Cadence
Seafight Live Events
Event pipeline: Concept → Spec → Implementation Support → Launch → Feedback → Tuning. Shipped 6–7 live events per year for a veteran MMO audience.
Role
Live-Service Game Designer
Status
Shipped · Ongoing
Tools
Jira, Confluence, Analytics dashboards, Figma
Design Breakdown
Live Event Delivery Loop
A compact view of the live-service loop behind Seafight event work: define the player reason to return, support delivery, then tune from live feedback.
Concept
Frame the player problem and define the event hook.
Spec
Document rewards, rules, beats, and UX states.
Implementation
Clarify dependencies and edge cases while content is built.
Launch
Ship inside the live calendar without losing the player-facing intent.
Feedback
Review participation data and internal community reporting.
Tuning
Adjust the next run based on where motivation or clarity weakened.
Context
- Seafight is a long-running browser MMO with a veteran community, a mature economy, and players who notice immediately when an event wastes their time. My work at Bigpoint covered recurring event concepts, reward structures, feature support, documentation, implementation follow-up, and post-launch tuning.
- The job was not to add content in isolation. It was to build event loops that players could read quickly, teams could ship reliably, and the live calendar could sustain over time.
Problem
- Seafight's long-running player base knows the game deeply, so new live content must feel valuable without breaking long-standing systems.
- Recurring events need enough change to feel fresh without becoming harder to read for returning players.
- Design changes have to respect a 20-year economy, live cadence, and existing player progress.
My role
- Live-Service Game Designer
- 6–7 live events per year with production, community, monetization, and implementation dependencies.
- Work must fit Seafight's existing systems and avoid devaluing player inventories.
- Design specs need to be precise enough for distributed implementation and live tuning.
Design decisions
- A typical event starts with three questions: what should bring players back, what has to feel different this time, and what counts as a successful run. From there I shape the loop, completion goals, reward structure, special encounters, UI support, and the spec that implementation works from.
- After launch, I review participation signals and internal community reporting, then adjust the next run where clarity, pacing, or value dropped off. That cycle matters because live content gets judged immediately and publicly.
Outcome
- Owned design for recurring, seasonal, and experimental Seafight events across the yearly calendar.
- Created reusable event systems and interface improvements that carried forward into later releases.
- Events I designed were frequently rated 9–10/10 in internal post-event community reports compiled from player feedback. Reports are internal, so raw excerpts are not public.
What this shows
- This is my clearest example of owning a live content loop end to end: recurring events, specs, implementation support, launch follow-up, and tuning across 6-7 events per year.
- The output was not just one-off event content. It included reusable systems and interface improvements that helped future events ship with more consistency.
- Events I designed were frequently rated 9–10/10 in internal post-event community reports compiled from player feedback. Reports are internal, so raw excerpts are not public.