Professional project · NDA-protected
Live-service
production direction
How do game design, narrative, art, and engineering move one feature from intent to a live product without hiding feasibility, dependencies, or release risk?
- Environment
- Established live service
- Public scale
- 10,000+ monthly users
- Role
- Project lead
- Disciplines
- Design · Narrative · Art · Engineering
- Project work
- Existing-system redesign · New features
- Tools
- YouTrack · Notion · Obsidian
The client, feature names, schedules, proprietary systems, team structure, internal materials, and product metrics remain private. Project names and private details are replaced with generic labels in the diagrams.
Context
An active product, not a blank slate.
Work entered an active service rather than a blank implementation environment. Definition therefore had to include the current product, affected disciplines, and consequences of change.
Existing systems
Older systems needed redesign while their surrounding product remained in use.
ImplicationCurrent behaviour and integration points belong in the initial definition.
Live users
Changes entered a service with more than 10,000 monthly users.
ImplicationRelease, observation, and revision remain part of the production loop.
Four knowledge domains
Design, narrative, art, and engineering each held information the other disciplines needed.
ImplicationDependencies and unresolved decisions must remain visible between specialisms.
Mixed work
The programme combined redesign of older systems with production of new features.
ImplicationOne roadmap must distinguish exploration, definition, production, and integration states.
My role
I led the path from intent to release.
I coordinated the feature path across game design, narrative, art, and engineering. Work advanced when the current decision, owner, dependencies, and release implications were understood.
- 01
Intent
State the player-facing outcome and reason for change.
- Output
- Shared outcome
- Gate
- Purpose understood
- 02
Definition
Describe behaviour, content bounds, visual language, and affected systems.
- Output
- Working definition
- Gate
- Unknowns named
- 03
Feasibility
Test technical, production, and content assumptions before commitment.
- Output
- Feasibility note
- Gate
- Risk accepted
- 04
Dependencies
Expose prerequisites, external decisions, hand-offs, and order of work.
- Output
- Dependency map
- Gate
- Owners visible
- 05
Production
Create and review discipline-specific implementation and content.
- Output
- Playable work
- Gate
- Definition met
- 06
Integration
Join code, content, assets, and rules inside the operating product.
- Output
- Integrated feature
- Gate
- Whole tested
- 07
Release
Move the agreed change into the live environment.
- Output
- Live change
- Gate
- Release state known
- 08
Observation
Read the live result and return necessary changes to definition.
- Output
- Revision input
- Gate
- Next action recorded
- Coordination
- Uncertainty is represented as work, not left inside private conversations.
- Definition
- Creative intent and user-facing behaviour precede discipline-specific task division.
- Live service
- Integration and release consequences are considered during definition, not appended at the end.
- Project direction
- Priorities, ownership, decisions, dependencies, and next actions stay inspectable.
Selected work
Cross-discipline feature delivery.
I joined the information each discipline needed around one shared feature definition. These examples show the work exchanged between disciplines without reproducing the private team structure.
| Lane | Intent + definition | Feasibility + dependencies | Production | Integration + release | Observation |
|---|---|---|---|---|---|
| Game design | Player outcome Rules and state | Rule tests System dependencies | Specification Tuning inputs | Whole-system play test Behaviour review | Read live behaviour Revise definition |
| Narrative | World intent Content scope | Continuity Content volume | Briefs and content Context for other lanes | In-product continuity Final content pass | Read comprehension Resolve dissonance |
| Art | Visual language Asset requirements | Scope and pipeline Technical constraints | Asset production Review passes | In-engine review Presentation state | Read legibility Correct visual gaps |
| Engineering | Current-system constraints Implementation questions | Risk, architecture Integration order | Implementation Technical validation | System integration Live-safety checks | Read operating state Route faults and change |
Process
Keeping decisions and ownership visible.
The process used small working documents that answered three questions: what changed, who must act, and where the current state can be found.
Outcome
What changed.
Delivered
- Older product systems moved through redesign inside the active service.
- New features moved through definition, production, integration, and release.
- Game design, narrative, art, and engineering were coordinated against shared priorities.
- Roadmaps, tasks, decisions, dependencies, and documentation formed the visible working system.
Kept private
- Retention, revenue, engagement, satisfaction, and delivery metrics.
- Exact internal workflow, release criteria, and project-specific timings.
- Proprietary architecture, feature behaviour, production schedules, and internal documents.
- Individual contributor attribution and the client's organisational structure.
- My contribution
- Project leadership across game design, narrative, art, and development; roadmap, task, and documentation management; specialist audio direction where required.
- Shown here
- Public project facts and a generalised production flow.
- Not shown
- Identifying product detail, internal documents, implementation, dates, metrics, and private team information.