Làm thế nào để bạn chuẩn bị cho tính năng creep?

Làm thế nào tôi có thể chuẩn bị cho creep tính năng trong quá trình tiền sản xuất?

Tính năng creep là khi bạn đang trong giai đoạn sản xuất và quyết định "Sẽ thật tuyệt nếu đây là một tính năng!" Điều đó thêm n giờ vào thời gian phát triển không được tính đến, và trừ khi bạn là Blizzard, không có thời gian cho. Bạn không thể lường trước được nó là một tính năng hay trong quá trình tiền sản xuất, vì tính năng này chỉ được phát hiện trong quá trình sản xuất.

Tôi có thể làm gì trong quá trình tiền sản xuất để tính toán hoặc ngăn chặn hoặc chuẩn bị cho tính năng creep?

Tôi có nên cho phép tính năng creep và cắt các tính năng ít mong muốn hơn không? Hay điều này sẽ tạo ra một vấn đề vì kiến ​​trúc không được thiết kế cho các tính năng mới? Tôi có nên nói không có tính năng trừ khi chúng phù hợp với kiến ​​trúc hiện có?

Tôi biết đây là một câu hỏi rộng, nhưng tôi hy vọng nó không bị đóng cửa như vậy. Đây là một vấn đề lớn trong phát triển trò chơi, và nên được xem xét.

Trong khi tất nhiên không có quy tắc cứng khi nói đến tiền sản xuất, có rất nhiều phương pháp phỏng đoán để giúp đỡ. Một số tính năng creep là tự nhiên và cần thiết - không có kế hoạch nào tồn tại khi tiếp xúc lần đầu với thực tế và bạn có thể không biết điều gì sẽ "tuyệt" cho đến khi bạn nhìn thấy nó.

Đầu tiên, giai đoạn phát triển của bạn. Vẽ phác thảo của bạn vào một bản đồ đặc trưng, ​​và sau đó tìm cách để nhóm các tính năng của bạn thành các lần lặp có thể kiểm tra , mỗi lần có thời hạn . Khi bạn bắt đầu lặp lại, hãy chống lại việc thêm các tính năng mới vào nó. Tất cả các nhu cầu kỹ thuật không lường trước tất nhiên nên đi vào vòng lặp hiện tại, nhưng các ý tưởng mới cho các tính năng nên được đưa vào danh sách để xem xét trong tương lai. Sau đó, bạn có thể xem xét có nên thêm nó vào một lần lặp sau khi hoàn thành hiện tại hay không.

Điều này tuân theo phương pháp MoSCoW , theo đó bạn phân loại các tính năng như vậy:

• Phải có - các tính năng quan trọng để lặp lại hiện tại là ổn định , có thể nói là có thể kiểm tra được . Nếu phép lặp sẽ không hoạt động mà không có nó, thì đó là điều bắt buộc.
• Nên có các tính năng - các tính năng sẽ phải hoàn thành vào một lúc nào đó, nhưng nếu việc lặp đi lặp lại theo thời gian có thể được đẩy vào lần lặp tiếp theo . Những thứ được yêu cầu bởi một nhà xuất bản, ví dụ, có thể vào đây.
• Có thể có - các tính năng mà bạn nghĩ có thể quan trọng đối với lần lặp hiện tại nhưng có thể bị loại khỏi dự án. Đây là tất cả các tính năng đánh bóng quan trọng .
• Không có - các mục có khả năng cung cấp hồ sơ tồn đọng , các tính năng được xác định trong lần lặp này sẽ được xem xét cho các lần lặp lại sau.

Lý tưởng nhất là bạn muốn phát triển là một sàng lọc tiến bộ, không phải tất cả hoặc không có gì. Làm việc trong thời hạn cuối cùng, các tính năng ít quan trọng nhất phải được đẩy đến cuối cùng, vì vậy bất cứ điều gì bạn không nhận được sẽ là những thứ không thể cắt giảm. Đảm bảo ước tính thời gian mỗi tính năng sẽ phát triển và tinh chỉnh các ước tính đó khi bạn đi. Không bao giờ nén lịch trình để nhường chỗ cho nhiều tính năng hơn. Chống lại thời hạn đẩy (lặp hoặc cuối cùng) vào tương lai - thay vào đó hãy di chuyển hoặc cắt các tính năng, nếu có thể. Nếu bạn sắp đến hạn chót và trò chơi vẫn còn là một mớ hỗn độn không thể sửa chữa được, thì bạn biết rằng đã đến lúc phải đánh giá lại nghiêm túc các quyết định của mình và xem xét việc hủy bỏ dự án trước khi nó biến thành một hố thời gian / tiền bạc.

• Lập kế hoạch sử dụng một phần thời gian tiền sản xuất có sẵn của bạn cho bộ tính năng cơ bản.
• Các tính năng cơ bản phải là các tính năng có thưởng cao, có rủi ro thấp, vì vậy bạn không nên leo lên những tính năng đó
• Các tính năng cơ bản là tối thiểu và không thể thương lượng - chúng phải có mặt - nếu không, không có cơ sở vững chắc để làm việc và bạn sẽ bị đánh đố với sự nghi ngờ bản thân / "tôi nên thay thế hội chứng này"
• Hãy chắc chắn rằng các lần lặp đầu tiên của trò chơi của bạn đủ hấp dẫn để bạn có thể đủ khả năng leo lên. Một trò chơi cơ bản không gây ấn tượng sẽ không thể đi xa được, chứ đừng nói đến creep.
• Biết trước mức độ lợi nhuận của creep mà bạn có thể chi trả, vì vậy bạn có thể sử dụng mức ký quỹ đó một cách khôn ngoan.
• Sử dụng công nghệ được xây dựng trước, có tính khái quát cao như Unity và sử dụng nó theo quy tắc để cải thiện tính linh hoạt để tính năng creep không ảnh hưởng quá nhiều đến kiến ​​trúc hiện có
• Không xây dựng các hệ thống con phức tạp - phương pháp lập trình eXtreme phù hợp ở đây
• Có những người khác (nhà thiết kế & lập trình viên) có bộ não mà bạn có thể khai thác định kỳ để giúp bạn ưu tiên các tính năng mà bạn sẽ cho phép leo, có ai đó có kinh nghiệm xem xét mã của bạn làm điểm chính cho những câu hỏi này.
• Bạn vẫn sẽ phải hạn chế creep tính năng, vì vậy hãy liên tục ưu tiên và biết nơi để vẽ đường

Cuối cùng, đó không phải là điều tôi muốn đề xuất cho người mới bắt đầu, bởi vì bạn cần có khả năng đưa ra quyết định đúng đắn ở mọi giai đoạn và điều đó không dễ dàng ngay cả với những người có kinh nghiệm nhất. Nếu bạn không chắc chắn về những quyết định đúng đắn là gì, thì hãy có chính sách "không vượt quá điểm này".

Bạn cũng có thể thấy điểm đầu tiên và điểm về việc sử dụng công nghệ mà bạn biết rõ có nghĩa là bạn cần có kinh nghiệm đáng kể cả về tạo mẫu nhanh (ùn tắc trò chơi) và bộ công cụ đã chọn của bạn.