Hầu hết prototype thất bại vì một lý do nhàm chán: không ai thống nhất chúng để làm gì. Một bản build được tạo ra, mọi người chơi, ý kiến được trao đổi, và quyết định tiếp tục dựa trên sự hào hứng. Sáu tháng sau số liệu đến và sự hào hứng đã biến mất.
Chúng tôi chạy prototype trên một pipeline cố định khoảng bốn đến năm tuần, và tuần đầu không liên quan đến Unity. Đây là lịch trình, lý do đằng sau, và framework chúng tôi xây trên đó đóng góp gì ở mỗi bước.
Tuần 0: Câu hỏi
Trước khi xây bất cứ thứ gì, chúng tôi viết một brief một trang với bốn phần:
- Giả thuyết. "Cơ chế sắp xếp trên băng chuyền một chạm sẽ giữ chân người chơi puzzle casual ít nhất bằng các game sort dạng bàn của chúng tôi."
- Đối tượng và tham chiếu. Game này dành cho ai và họ đang chơi game live nào hôm nay.
- Chỉ số và ngưỡng. Chúng tôi sẽ đo gì (thường là D1, D3, độ dài phiên và tín hiệu CPI sớm) và con số dưới đó chúng tôi dừng.
- Góc creative. Game này sẽ trông thế nào trong một video dọc ba giây. Nếu không mô tả được, ý tưởng chưa sẵn sàng.
Trang này là hợp đồng cho prototype. Nó ngăn phình phạm vi, và biến cuộc họp go / kill thành so sánh với con số đã thống nhất thay vì tranh luận.
Tuần 1: Thiết lập framework và tương tác cốt lõi
Vì mọi game đều bắt đầu trên CMZ Puzzle Framework, tuần một không dành cho menu, hệ thống lưu hay hạ tầng analytics. Những thứ đó có sẵn. Thời gian kỹ thuật dành cho tương tác cốt lõi: một thao tác người chơi lặp lại nghìn lần. Với sort dạng bàn là di chuyển khối; với game băng chuyền là một chạm thả viên bi; với puzzle mũi tên là cú trượt.
Cuối tuần, tương tác phải cảm thấy tốt trên thiết bị — không phải trong editor — với art tạm. Nếu không tốt với art tạm, art đẹp hơn cũng không cứu được.
Song song, design tạo 20–30 level đầu với công cụ solver, để độ khó được định hình từ đầu thay vì đoán sau.
Tuần 2: Một vòng lặp hoàn chỉnh
Tuần hai biến tương tác thành vòng lặp: chọn level, trạng thái thắng thua, booster đầu tiên, progression cơ bản và các tính năng meta mặc định của framework bật qua cấu hình. Tracking đã live vì framework tự động phát sự kiện level, kinh tế và phiên.
Đây cũng là lúc chúng tôi tạo bản build quay đầu tiên — phiên bản với điều khiển debug cho đội creative quay footage gameplay sạch. Test creative có thể bắt đầu trước khi game đẹp, và tín hiệu CPI sớm đáng giá hơn một trailer bóng bẩy.
Tuần 3: Biến nó thành một game
Với vòng lặp hoạt động, tuần ba dành cho những thứ người chơi nhớ: chủ đề, cảm giác khi dọn, cơ chế mới đầu tiên, onboarding. Art thay thế bản tạm cho các đối tượng cốt lõi. Âm thanh và haptic được thêm vào. 60–80 level đầu được tinh chỉnh.
Design kiểm tra hình dạng chương so với kế hoạch: đỉnh đầu rơi vào đâu, yếu tố mới đầu tiên đến khi nào, phiên đầu kết thúc thế nào. Producer review taxonomy sự kiện để chắc mọi câu hỏi trong brief có thể trả lời từ dữ liệu sẽ có.
Tuần 4: Bản build test và báo cáo
Bản build lên thị trường test trên Google Play qua internal hoặc open testing track, và UA chạy test creative nhỏ. Từ đây pipeline là bài tập đo lường:
- Cohort retention (D1, D3, và D7 nếu cửa sổ cho phép).
- Số phiên và độ dài theo ngày.
- Funnel theo level cho hai chương đầu.
- CPI creative và click-to-install.
Chúng tôi cho báo cáo hai tuần dữ liệu khi có thể, đó là lý do lịch đôi khi kéo dài đến năm tuần. Cuối cùng có một kết quả một trang đối chiếu với brief một trang.
Cuộc họp go / kill
Cuộc họp có ba kết quả khả dĩ, quyết định trước:
- Go. Số liệu vượt ngưỡng; game chuyển sang sản xuất với phạm vi xác định cho soft launch.
- Iterate. Một hai chỉ số gần ngưỡng và dữ liệu chỉ ra nguyên nhân cụ thể (một level, một bước onboarding, một creative). Thêm một sprint, thêm một báo cáo, rồi quyết định cuối cùng.
- Kill. Dưới ngưỡng không có cách sửa rõ ràng. Cơ chế vào thư viện của framework — code, level và bài học không lãng phí; phần lớn trong hơn 25 prototype của chúng tôi nằm ở đó — và đội chuyển sang brief tiếp theo.
Kỷ luật nằm ở kết quả thứ ba. Kill một prototype đội yêu thích là khó; kill một prototype trượt con số mọi người đã đồng ý trước chỉ là buồn.
Framework đóng góp gì
Đáng nói rõ vì sao lịch là bốn đến năm tuần thay vì ba tháng:
- Progression, phần thưởng, sự kiện, streak, bảng xếp hạng là cấu hình, không phải tính năng cần xây.
- Vị trí quảng cáo và IAP tồn tại và báo cáo từ bản build đầu.
- Analytics — taxonomy sự kiện, dashboard cohort, funnel level — được thừa hưởng.
- Công cụ level với solver và kiểm định dùng chung.
- Pipeline build cho iOS và Android sẵn sàng.
Đội prototype dành các tuần cho cơ chế, level và cảm giác. Đó chính là mục đích.
Áp dụng với publisher
Khi prototype cho hoặc cùng publisher, brief được viết chung và ngưỡng đến từ benchmark danh mục của publisher. Bản build quay đến đội creative của publisher sớm, và báo cáo là tài liệu chung. Cấu trúc đó là cách đáng tin cậy nhất chúng tôi biết để giữ một hợp tác prototype trung thực cho cả hai bên.
Chúng tôi prototype ý tưởng puzzle mới trên pipeline này cho danh mục của mình và cho đối tác. Bắt đầu trao đổi.
