Thiết kế lặp quy mô lớn

Thông thường trong phát triển trò chơi, phát triển tuyến tính ( mô hình thác nước ) bị thách thức với những trở ngại làm cạn kiệt sự tỉnh táo của lập trình viên (trò chơi hóa ra kinh khủng, không thể thiết kế lại). Nhập thiết kế lặp . Thiết kế lặp cho phép tạo mẫu của các khả năng khác nhau trong không gian chơi. Thật không may, nó có một bắt lớn . Ngay khi một dự án tăng kích thước, các vòng lặp trở nên tẻ nhạt kéo dài giết chết lợi thế chính: kết quả nhanh chóng.

Làm thế nào người ta có thể rút ngắn các lần lặp thiết kế cho các dự án quy mô lớn?

Tôi nghĩ rằng cơ sở hạ tầng tốt có thể giúp điều này. Một ví dụ là có một hệ thống dữ liệu đẹp, dễ sử dụng mà các kỹ sư có thể dễ dàng tiết lộ dữ liệu mới và các nhà thiết kế có thể nhanh chóng thay đổi dữ liệu và xem kết quả của họ. Một điều tốt nữa là có một ngôn ngữ kịch bản - như lua - mà các lập trình viên trò chơi, và thậm chí các nhà thiết kế, có thể sử dụng để nhanh chóng tạo ra những thứ nguyên mẫu.

Ngoài ra, có một đường dẫn nghệ thuật / tài sản đẹp, dễ sử dụng và dễ dàng đưa tài sản vào trò chơi.

Về cơ bản, loại bỏ những trở ngại cho những người làm công việc của họ và hợp lý hóa quy trình công việc của họ.

Thật không may, ngoài các giải pháp cho những thứ đó không thực sự tồn tại (ngay cả trong các công cụ trò chơi phổ biến, những vấn đề này thực sự không giải quyết được), điều đó có nghĩa là bạn sẽ phải đầu tư thời gian kỹ thuật để có được sự nhanh nhẹn này. Vì vậy, thật đáng buồn, câu trả lời là bạn phải dành thời gian để làm cho nó để bạn có thể làm việc nhanh chóng, đó là loại đánh bại mục đích. Một khi bạn dành thời gian mặc dù, mọi thứ trở nên tuyệt vời. Nếu bạn có thể sử dụng lại công việc của mình cho các dự án trong tương lai, cổ tức thậm chí còn tốt hơn.

Timeboxing có nghĩa là lặp đi lặp lại không lâu hơn

Bạn hỏi làm thế nào để rút ngắn số lần lặp. Nhưng điều đó ngụ ý rằng họ đang mất nhiều thời gian hơn, điều đó có nghĩa là bạn không áp dụng quyền anh thời gian. Trong bất kỳ lần lặp nào khi độ phức tạp bắt đầu nặng hơn (hoặc bạn có những thất bại khó chịu khác), bạn không thay đổi độ dài lặp. Thay vào đó, bạn bỏ qua phần bổ sung tăng dần mà bạn đã lên kế hoạch khi bắt đầu lặp lại. Một số phương pháp lặp lại đề nghị thực hiện đánh giá này ở giữa một lần lặp (trước khi quá muộn). Đọc thêm về những gì OpenUP gợi ý :

Quản lý mục tiêu Khi một nhóm bị tụt lại phía sau đáng kể hoặc xảy ra sự cố nghiêm trọng khiến nhóm không đạt được các mục tiêu lặp lại, có thể cần phải bỏ qua công việc để đảm bảo rằng nhóm cung cấp mức tăng sản phẩm hữu ích vào cuối vòng lặp, trong khi tối đa hóa giá trị các bên liên quan. Làm việc với nhóm và các bên liên quan để sửa đổi Kế hoạch lặp lại và, khi cần thiết, giảm sự nhấn mạnh vào các nhiệm vụ ít quan trọng hơn bằng cách hoãn chúng vào lần lặp tiếp theo. Trong những trường hợp hiếm hoi, nếu các mục tiêu lặp lại dường như không thể đáp ứng, nhóm có thể xem xét chấm dứt việc lặp lại hoặc cải tổ việc lặp lại thành một mục tiêu mới.

Nếu bạn nhìn vào biểu đồ đầu tiên, bạn có thể thấy rằng giá trị gia tăng sẽ ít hơn ở các lần lặp lại sau. Điều này có nghĩa là các lần lặp vẫn mất nhiều thời gian như trước đây, nhưng có thể có ít chức năng mới (tương đối) trong mỗi lần lặp.

Như bạn nói, thế mạnh của lặp đi lặp lại là giảm rủi ro bằng cách nhận phản hồi thường xuyên. Có vẻ như bạn đang nói về sự phức tạp của dự án đang làm bạn thất vọng về các lần lặp lại sau này? Tôi không đồng ý đây là điểm yếu của phép lặp. Đó là một điểm yếu của sự phức tạp được quản lý tồi.

Về mặt lý thuyết, bạn đặt các dự án rủi ro lớn nhất lên phía trước. Điều này có nghĩa là bạn có một dự án rất không ổn định, nhưng khi bạn quản lý các rủi ro lớn, nó được cho là sẽ ổn định. Sự phức tạp, tất nhiên, là một trong những rủi ro.

Ngôn ngữ kịch bản và quy trình tự động giúp giảm nguy cơ phức tạp, có thể được gọi là độ phức tạp "tình cờ" (và được thảo luận trong câu trả lời khác). Các dự án có tính lặp lại cao nhưng phức tạp (Chromium là một ví dụ điển hình, ngay cả khi đó không phải là một trò chơi) có rất nhiều cơ sở hạ tầng để quản lý sự phức tạp. Hãy xem https://www.chromium.org/developers để biết rất nhiều ví dụ về những điều như tư vấn mã hóa cho BuildBot .

Những gì con số này không thể hiện là sự ổn định của dự án, có thể trông giống như thế này:

Cho đến khi các rủi ro kỹ thuật được hiểu rõ, bạn đang xử lý các nguyên mẫu đơn giản