Live Event Design
Seafight Live Events
Designing and releasing 6–7 live events a year: the loop, rewards, interface support, and the specifications they ship from.
Role
Game Designer · Live Event Design
Status
Shipped · Ongoing
Tools
Figma, Confluence, Jira, Analytics dashboards
Transferable design problemDesigning features people return to again and again, under legacy-system, commercial and production constraints.
Case study
Designing live events from player problem to post-launch tuning.
This shows how I turn a live-product goal into a scoped, shippable event while protecting player value and production reliability.
Context
Seafight is a long-running browser MMO with a veteran audience, a mature economy and a continuous live-content calendar.
Problem
Each event needs a clear reason for players to return without destabilising established systems, inventories or expectations.
What I design
For roughly 6–7 events a year I design the loop, progression, rewards, quests, encounters and the player-facing interface, and I write the specifications developers and artists build from.
Constraints and trade-offs
I balance player needs and commercial goals against technical dependencies, production scope, live-economy risk and a fixed release calendar.
Collaboration
I work with development, QA, production and community from specification and refinement through implementation support, launch and review. I attend stand-ups and follow implementation; I do not run sprint planning or own the backlog.
After launch
I review participation data, including results from SQL scripts, along with internal community reporting, then carry what I learn into tuning and later event runs.
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.
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, the interface that supports them, and the specification 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
Reusable event systems and interface patterns made later events more consistent to design and to build. Commercial performance is internal to Bigpoint and is not published here.