Một ý tưởng game có thể hấp dẫn trong pitch nhưng vẫn rất khó chơi khi đưa vào build. Cơ chế tưởng đơn giản có thể kéo theo art, UI, economy, content và backend ngoài dự kiến. Vì vậy, quy trình phát triển game tốt không cố biến ý tưởng ban đầu thành sản phẩm nguyên vẹn bằng một kế hoạch tuyến tính. Nó liên tục chuyển assumption thành bản chơi được, đưa cho người dùng thử và dùng bằng chứng để quyết định bước tiếp.
Trả lời ngắn: Quy trình phát triển game thường đi qua discovery, concept và product definition, prototype, pre-production, vertical slice, production, QA/optimization, release readiness và iteration. Các giai đoạn có thể chồng lấn, nhưng mỗi giai đoạn cần một câu hỏi rủi ro, một đầu ra có thể kiểm tra và một decision gate. Full-cycle không có nghĩa làm mọi thứ ngay từ đầu; nó có nghĩa giữ tính liên tục từ ý tưởng đến vận hành.
Discovery không phải buổi brainstorm tự do. Nó làm rõ người chơi, mục tiêu sản phẩm, ràng buộc và giả thuyết rủi ro nhất.
Các câu hỏi:
Đầu ra không cần là deck dài. Một product brief tốt có one-line promise, audience, core experience, constraints, success criteria, risk register và danh sách assumption cần test.
Gate: Có một vấn đề/trải nghiệm đủ rõ để đầu tư vào concept, hay team vẫn đang ghép nhiều ý tưởng chưa có thesis?
Ở đây, ý tưởng được chuyển thành hệ thống có thể thảo luận: core loop, meta loop, progression, content structure, economy hypothesis, art direction và technical shape.
Một concept package có thể gồm:
Framework Mechanics–Dynamics–Aesthetics có thể giúp team nối rule được thiết kế với hành vi phát sinh và cảm giác người chơi. Nó không phải template bắt buộc, nhưng nhắc rằng cùng một mechanic có thể tạo dynamics khác khi kết hợp.
Gate: Team có thể mô tả trải nghiệm bằng hành vi người chơi hay vẫn chỉ bằng danh sách feature?
Prototype trả lời một câu hỏi: mechanic có tạo ra hành vi/cảm giác dự kiến không? Nó có thể dùng placeholder art, UI thô và code không tối ưu, miễn là đủ để test hypothesis.
Ví dụ câu hỏi:
Không nên nhồi backend, shop, nhiều level và polish vào prototype nếu chúng không phục vụ câu hỏi. Mỗi ngày thêm polish trước khi biết loop có đáng giữ là một ngày tăng sunk cost.
Đầu ra: playable build, test script, observation, issue list và quyết định. “Prototype hoàn thành” chỉ có nghĩa khi câu hỏi đã được trả lời.
Gate: Continue mechanic, modify, test alternative hay stop?
Sau khi core concept có tín hiệu, pre-production xác định scope và pipeline.
Khóa rule, parameter, content grammar, progression, economy model và level-design template ở mức đủ cho production.
Đi từ concept đến asset có spec: style, topology, animation, VFX, UI kit, naming, export, performance budget.
Kiến trúc gameplay, data, save, backend, analytics, build pipeline, platform integration và tool cho content.
Player journey, information architecture, HUD, menu, onboarding, feedback và accessibility.
Backlog, dependency, owner, definition of done, risk burndown và vendor handoff nếu có.
Đầu ra quan trọng nhất là pipeline có thể lặp. Nếu làm một level mất bao lâu vẫn chưa rõ, estimate 100 level chỉ tạo ra độ chính xác giả.
Gate: Scope có thể sản xuất với nguồn lực hiện có không? Bottleneck nằm ở design, content, art, code, QA hay tool?
Vertical slice là một lát nhỏ có mức chất lượng gần mục tiêu, kết nối gameplay, art, UI, audio, tech và pipeline. Nó không nhất thiết là MVP và không cần nhiều nội dung.
Vertical slice cần chứng minh:
Sai lầm phổ biến là biến vertical slice thành trailer có một đường đi duy nhất, khó tái sử dụng. Một slice đẹp nhưng được làm bằng “heroics” ngoài pipeline không chứng minh production readiness.
Gate: Chất lượng và pipeline có đủ để mở production? Scope cần cắt hay công cụ cần đầu tư?
Production không phải lúc ngừng thử nghiệm, nhưng thay đổi cần được quản lý bằng impact.
Các stream:
Mỗi feature cần definition of done gồm functionality, UX, art/audio, analytics, error state, performance, localization, QA và documentation cần thiết. Nếu “done” chỉ là code chạy trên máy developer, phần việc còn lại bị đẩy về cuối.
Change control không nhằm giữ design bất biến. Nó giúp team biết thay đổi ảnh hưởng asset, save data, UI, economy, QA, localization và roadmap thế nào.
Gate định kỳ: Feature còn phục vụ thesis không? Cost-to-complete và risk có thay đổi? Nên giữ, cắt, thay hoặc hoãn?
Playtest trả lời trải nghiệm; QA xác nhận hành vi theo yêu cầu; profiling tìm bottleneck kỹ thuật. Ba hoạt động liên quan nhưng không thay thế nhau.
Unity khuyến nghị profiling trên target device vì kết quả trong Editor chỉ là xấp xỉ. Cùng logic đó, UX cũng cần được kiểm tra trên màn hình, touch target và session thật.
Đầu ra: issue có severity, reproduction, owner, build, evidence và verification. Feedback mơ hồ như “chưa fun” cần được chuyển thành observation cụ thể trước khi sửa.
Trước phát hành, team kết nối product, technical, store, data, compliance, growth và operations. Build không chỉ “feature complete” mà còn cần review access, metadata, crash monitoring, payment, support, rollout và rollback.
Một game có thể chọn:
Mỗi hình thức có mục tiêu và ngưỡng khác nhau. Release không phải kết thúc pipeline; nó đưa game vào vòng dữ liệu thật.
Sau launch, roadmap cần phản hồi cohort, feedback, economy, incident và content capacity. Đừng biến mọi phản hồi thành feature request. Phân loại:
Ưu tiên dựa trên impact, confidence, effort và fit với thesis. Dùng config/feature flag khi phù hợp, với guardrail và default an toàn.
GDD hữu ích khi giúp người khác xây, test và ra quyết định. Nó nên chứa rule, state, flow, parameter, reference, rationale và open question; không cần trở thành tiểu thuyết.
Tách:
Source of truth cần version, owner và trạng thái. Tài liệu không cập nhật có thể nguy hiểm hơn thiếu tài liệu.
Một team game cần điểm giao đều đặn:
Handoff không phải ném tài liệu qua team khác. Người nhận cần hiểu goal, constraint, acceptance và cách phản hồi.
Theo định hướng Game Studio, SAVA kết nối gameplay, art, UI/UX, optimization và iteration trong cùng quy trình. Tùy nhu cầu, engagement có thể bắt đầu từ prototype/MVP, full-cycle, co-development hoặc dedicated team. Trước khi cam kết scope, cần discovery để khóa objective, build state, IP, dependency, timeline hypothesis và decision gate.
SAVA ở vai trò đồng hành hiện thực hóa ý tưởng; sản phẩm và người chơi vẫn là trung tâm. Không nên cam kết chi phí, timeline hoặc outcome khi chưa có brief và technical assessment.
Không có timeline chung. Thể loại, content, platform, art, online features, team, quality bar và approval tạo khác biệt. Estimate chỉ có cơ sở hơn sau prototype/pre-production.
Không. Prototype kiểm tra rủi ro/cơ chế với độ hoàn thiện thấp; vertical slice chứng minh chất lượng tích hợp và pipeline gần mục tiêu.
Cần đủ để thống nhất hypothesis, rule và scope của phần sắp xây. GDD nên cập nhật theo test; viết quá chi tiết cho phần chưa được chứng minh tạo lãng phí.
Khi feature không phục vụ thesis, effort/dependency vượt giá trị, không có bằng chứng, hoặc làm rủi ro release tăng quá mức.
Có thể, tùy phạm vi hợp tác. Cần xác nhận rõ store, publishing, LiveOps, support và ownership trong hợp đồng/scope.
Primary CTA: Gửi concept, build hiện có và mục tiêu sản phẩm để cùng SAVA META xác định giai đoạn, rủi ro và lát phát triển đầu tiên.
Bài viết liên quan
