Đó là giá trị lập kế hoạch trước khi nhảy vào mã?

Tôi luôn nghĩ rằng lập kế hoạch là quan trọng cho một trò chơi. Nhưng tôi không biết ở điểm nào. Một số người bảo tôi viết mã thay vì lập kế hoạch nhưng tôi cảm thấy nó vẫn quan trọng bởi vì khi bạn ở trong mã bạn sẽ biết phải làm gì tiếp theo dễ dàng hơn. Tôi hiện đang làm việc trên một trò chơi sẽ có nhiều nội dung vì vậy tôi quyết định bắt đầu một tài liệu thiết kế giới thiệu nội dung và ở cấp độ phụ tôi đang làm bằng chứng về khái niệm để kiểm tra xem nó có thể được thực hiện hay không. Các phần của mỗi bằng chứng về khái niệm sau đó có thể được sử dụng sau này trong trò chơi thực.

EDIT: Tôi đang làm việc một mình trong dự án này.

Vì vậy, câu hỏi của tôi là: Có đáng lập kế hoạch trước khi nhảy vào mã? Tôi vẫn quan tâm để biết những gì người khác nói về điều này. Vì tôi vẫn nhận được một số thông báo nói rằng tôi nên viết mã thay vì suy nghĩ .. vậy ý ​​kiến ​​của bạn về điều này là gì?

Bạn đã nói hai điều thông minh trong câu hỏi của bạn:

1. "Mã thay vì suy nghĩ" - có cả một triết lý mô tả điều này: http://gettingreal.37signals.com/toc.php
2. "bằng chứng về khái niệm để kiểm tra xem nó có thể được thực hiện hay không" - Tôi đã thấy và có nhiều ý tưởng biến thành không thể hoặc cực kỳ khó thực hiện khi chúng gần hoàn thành. Đôi khi bạn không thể dự đoán được, bởi vì đó là môi trường lập trình của bạn (ngôn ngữ, thư viện, hiệu suất phần cứng) giới hạn bạn.

Đó là lý do tại sao tôi nói:

• thiết kế, nhưng đừng tạo ra một tài liệu thiết kế khổng lồ nếu bạn không tìm kiếm cộng tác viên hoặc nhà đầu tư, trừ khi điều đó thú vị với bạn và bạn coi đó là một bước thoát khỏi lập trình;
• luôn có trong tâm trí những gì bạn muốn đạt được; mỗi mô-đun nên có một đầu vào và đầu ra được thiết kế; bằng cách đó bạn có thể dễ dàng kiểm tra mô-đun, và không có cảm giác lang thang trong sương mù;
• hãy nhớ rằng dù sao bạn cũng thiết kế phần lớn thời gian, vì việc gõ mã chỉ chiếm khoảng 5% thời gian của bạn (ít nhất là gõ mã cuối cùng);
• lập trình không phải là một môn khoa học lý thuyết, thay vì kiểm tra xem một cái gì đó sẽ hoạt động trên một tờ giấy, bạn có thể chỉ cần viết mã và thử; sản phẩm cuối cùng chủ yếu là làm cho đầu vào của người dùng trở nên hoàn hảo, GUI trông đẹp mắt và xử lý các trường hợp đặc biệt - một thử nghiệm bẩn về ý tưởng có thể được thực hiện ngay lập tức;
• tạo danh sách việc cần làm nếu bạn sợ quên ý tưởng của mình
• nói chuyện với bạn bè về ý tưởng của bạn, vì họ sẽ ít nhiệt tình hơn và có thể có nhiều kinh nghiệm hơn trong một lĩnh vực; một khi tôi có ý tưởng giữ bí mật các thông số đơn vị (trong một trò chơi chiến lược), nhưng bạn tôi nói với tôi đó là một ý tưởng tồi, vì anh ấy đã chơi một trò chơi như thế này và đó là một trải nghiệm người dùng tồi tệ.

Có, nhưng chỉ một chút .

Đối với lập trình trò chơi, đặc biệt là lập trình trò chơi, điều cần thiết là phải có trường hợp sử dụng tốt trước khi viết bất kỳ mã nào. Ví dụ, người chơi phải làm gì, anh ta phải đi đâu và làm thế nào, anh ta tương tác với thế giới như thế nào, v.v ... Đây có thể là một bảng phân cảnh được phác thảo trên giấy, hoặc đi ra từ một cuộc thảo luận với bạn bè ... là một phần của thiết kế trò chơi , và sẽ thật ngu ngốc khi bắt đầu viết mã mà không có ý tưởng sơ bộ về cách trò chơi được cho là được chơi.

Nhưng các trò chơi phải được tạo ra lặp đi lặp lại . Bạn không thể tạo ra một thông số kỹ thuật lớn cho trò chơi của mình và hy vọng trò chơi sẽ trở nên thú vị. Bạn cần chơi thường xuyên để tìm hiểu những gì hoạt động, và những gì không, và tiếp tục lặp đi lặp lại. Chạy nhanh nhất có thể thực hiện, thiết kế trò chơi nhanh nhất có thể được kiểm tra, trò chơi tốt nhất vào cuối. Vì vậy, tốt hơn hết là bắt đầu mã hóa ASAP, từ một thiết kế trò chơi không chính thức, xem những gì được đưa ra và tiếp tục.

Một điều chắc chắn, khi bạn viết mã một mình, bạn không cần bất kỳ tài liệu hay phương pháp thiết kế phần mềm ưa thích nào, mã nguồn là thiết kế.

Một số người nói bạn nên viết mã thay vì suy nghĩ? Để viết mã, bạn cần biết những gì bạn muốn tạo, để biết những gì bạn muốn tạo trước tiên bạn cần nghĩ những gì bạn muốn có, ergo bạn cần phải suy nghĩ trước khi viết mã;).

Và nghiêm túc, có thể bạn không cần một kế hoạch chi tiết ngay từ đầu, nhưng có một phác thảo và / hoặc các mốc quan trọng luôn có lợi - cũng vì thái độ của bạn, khi bạn bỏ qua những việc đã làm, bạn sẽ được khuyến khích làm nhiều hơn công việc.

Cả mã hóa và lập kế hoạch là cần thiết. Kế hoạch đầu tiên, sau đó mã, nhưng không lập kế hoạch mọi thứ cùng một lúc. Lập kế hoạch cốt lõi, mã hóa nó, cập nhật kế hoạch của bạn khi cần thiết, sau đó lên kế hoạch cho các tính năng bổ sung cho khả năng chơi, đồ họa, âm thanh, họa tiết, v.v., điều này sẽ làm cho trò chơi bạn đang tạo trông đẹp hơn và nhìn tổng thể tốt hơn. Rõ ràng, bạn có thể chạy một chu kỳ như vậy hơn một lần, và tôi khuyên bạn nên đưa ra quyết định sẽ hỗ trợ nâng cấp nếu cần.

Bạn phải biết bạn đang đi đâu trước khi viết mã và viết / vẽ có thể là một cách tốt để cụ thể hóa những gì bạn muốn đạt được. Tôi nói vẽ vì vẽ sơ đồ, phác họa v.v ... cũng có thể giúp bạn rất nhiều. Bạn không cần phải tạo ra một tài liệu tuyệt vời được làm bằng Word hoặc bất cứ thứ gì, chỉ cần lấy một cây bút chì và một mảnh giấy (rất nhiều mảnh giấy?) Và vẽ, viết mọi thứ bạn có thể nghĩ về.

Đối với tôi, đó là một cách thực hành tốt để sử dụng bút chì và giấy tờ, nó giúp cụ thể hóa ý tưởng của bạn và cũng đặt ra nơi bạn muốn đến để tránh đi bất cứ đâu, khắc phục mục tiêu của bạn. Nó hoạt động cho tất cả mọi thứ cần phản xạ. Và rõ ràng trong rất nhiều lĩnh vực để viết ra trước khi thực hiện công việc thực tế.

Làm bất cứ điều gì làm việc cho bạn. Cá nhân, tôi lên kế hoạch cho mọi thứ ở một mức độ nhỏ, nhưng không có tài liệu thiết kế là những kế hoạch cực kỳ chi tiết trước khi tôi bắt đầu viết mã. Làm bất cứ điều gì là hiệu quả nhất cho bạn, đặc biệt là khi bạn làm việc một mình.

(Tôi cho rằng câu hỏi được đưa ra từ quan điểm thiết kế mã / kiến ​​trúc, chứ không phải thiết kế trò chơi, mặc dù câu trả lời ít nhất ở một mức độ nào đó áp dụng cho cả hai.)

Như đã nói, bạn cần cả hai, và bạn cần phải cân bằng nó. Cả việc quá mức và quá mức quy trình / cấu trúc mã của bạn có thể gây ra vấn đề. Thật khó để nói cân bằng đúng là gì, nhưng nhìn chung tôi thấy rằng tôi cần phải có ít nhất một ý tưởng mơ hồ về việc phần còn lại của mã sẽ kết hợp với những gì tôi đang lập trình vào lúc này và nghĩ về các vấn đề có thể xảy ra, mặt khác, tôi có xu hướng "mã hóa bản thân vào ngõ cụt" - rơi vào tình huống tôi nhận ra "được rồi, bây giờ nhờ cách tôi giải quyết vấn đề này, tôi đã tạo ra một vấn đề mới khiến toàn bộ giải pháp trước đây của tôi (hoặc thậm chí nhiều hơn, trong trường hợp xấu nhất ) vô ích ".

Nói chung, theo tôi, bạn có thể đánh giá đại khái xem bạn có cân bằng đúng hay không bằng cách suy nghĩ về các kịch bản "chuyện gì xảy ra" như trong "nếu sau này (khi mọi thứ được thực hiện đầy đủ trong mô hình tương tự như tôi đang sử dụng bây giờ) thì hãy tìm hiểu phần A cần hoạt động hơi khác một chút, điều đó có nghĩa là tôi phải làm lại hoàn toàn phần B kết nối với nó để thay đổi những thay đổi? ". Nếu thay đổi kiến ​​trúc ở một phần không yêu cầu bạn thay đổi nhiều hơn một hoặc hai phần khác và các thay đổi không xếp tầng (có nghĩa là đến lượt bạn cũng phải thay đổi các phần tiếp theo kết nối với phần B, và sau đó các phần kết nối với chúng, v.v.), mã được ngăn cách một cách tương đối tốt.

Nhưng thực sự, đây là điều bạn sẽ cảm nhận được sau khi có được một số kinh nghiệm. Đây là một phần lý do tại sao mọi người đưa ra lời khuyên đầu tiên cho gamedevs để mã đầu tiên một thứ gì đó được biết và dễ dàng (Breakout / Tetris / Snake) và thực hiện nó hoàn toàn, với tất cả các menu, âm thanh, hiệu ứng, mọi thứ để làm cho trò chơi hoàn thành - tốt hơn để thực hiện dự án nhỏ hơn và thực hiện nó (dù theo cách tốt hay xấu) chính xác sẽ giúp bạn cảm nhận được mức độ ảnh hưởng của các quyết định kiến ​​trúc khác nhau.