Thiết kế một trò chơi - Bắt đầu từ đâu? [đóng cửa]

Một người bạn của tôi và tôi đang lên kế hoạch cho một trò chơi cùng nhau để làm việc trong thời gian rảnh. Đây không phải là một trò chơi rộng rãi, nhưng nó cũng không phải là một trò chơi đơn giản.

Anh ấy đang nghiên cứu câu chuyện đằng sau trò chơi trong khi tôi đang nghiên cứu về đồ họa và mã.

Tôi thực sự không biết bắt đầu từ đâu với trò chơi. Chúng tôi biết loại trò chơi cơ bản sẽ là gì và nó sẽ được chơi như thế nào, nhưng tôi đang gặp khó khăn trong việc thực sự biết bắt đầu từ đâu.

Tôi đã mở Xcode nhưng tôi thậm chí không biết mình nên thiết kế cái gì trước tiên.

Một số lời khuyên cho khối nhà văn này là gì? Đâu là một nơi tốt để bắt đầu với một trò chơi? Tôi có nên thiết kế tất cả đồ họa và bố cục trước khi chạm vào Xcode không? Tôi có nên lập trình những điều tôi biết trước tiên tôi sẽ gặp khó khăn trước khi tiếp cận những thứ dễ dàng không?

Bắt đầu bằng cách nhận được một cái gì đó và có thể chơi được. Đừng dành hơn một giờ cho đồ họa, chỉ hiển thị trò chơi với các phần giữ chỗ rác. Các trò chơi không có các yêu cầu khách quan để xây dựng: yêu cầu chính là nó thú vị và đánh giá xem một trò chơi có vui hay không yêu cầu chơi nó; do đó, thiết kế trò chơi nên tuân theo cách tiếp cận lặp lại . (Tôi khuyên Tom Wujec về thử thách marshmallow như một định hướng về thiết kế lặp.

Tạo một cái gì đó trên giấy, và ý tôi là tạo ra một bảng mô phỏng và các mảnh cắt ra. Đặt quy tắc và chơi trò chơi của bạn trên mô hình giấy. Sử dụng điều đó để chia thiết kế mã của bạn thành các bộ tính năng và mô-đun mà bạn có thể làm việc. Quá trình này sẽ giúp bạn của bạn thiết kế câu chuyện và cách trò chơi cũng vậy.

Bạn có thể bị cám dỗ để viết các tính năng bổ sung vào mã của bạn, tránh điều đó. Bạn đang tạo mẫu để xem những gì sẽ làm việc.

Khi bạn có một phần nhỏ và chạy, bạn nên làm việc lặp đi lặp lại và ở mỗi lần lặp lại chỉ có thêm một tính năng chạy. Khi một cái gì đó không chơi tốt trở lại và thay đổi tính năng. Tiếp tục lặp lại và thay đổi.

Ý tưởng cơ bản là có tầm nhìn dài hạn dựa trên mô hình giấy của bạn, và từ đó, một loạt các mục tiêu ngắn hạn sẽ thực hiện để đưa bạn đến nơi bạn muốn đến một lúc và không bị căng thẳng " omg tôi phải làm gì tiếp theo? "

Đánh giá yêu cầu của bạn đầu tiên. Mã hóa mà không có kế hoạch tạo ra rất nhiều chất thải sau này.

Các chức năng trò chơi cần phải làm gì? Những khuôn khổ nào bạn cần để làm cho công việc đó? Các yếu tố có thể được mượn từ các khung hiện có là gì và bạn cần gì để tự viết?

Trước khi mở Xcode, trước tiên bạn có thể thực hiện cắt giấy và chạy qua tất cả các giao diện và hộp thoại trò chơi. Điều này sẽ cung cấp cho bạn một số ý tưởng về những gì bạn cần tạo trong Trình tạo giao diện.

Tiếp theo, làm thế nào để mọi thứ tương tác? Các phong cách tương tác khác nhau cần thiết là gì? Điều đó sẽ cung cấp cho bạn một số ý tưởng về cách các bộ điều khiển cần được phân chia, bắt đầu và dừng lại.

Đừng lên kế hoạch cho đến chết, nhưng xác định rõ yêu cầu của bạn và ngay khi bạn có thể chia dự án thành các mảnh có kích thước cắn (30 phút-1 giờ), bạn đã sẵn sàng bắt đầu viết mã.

Nhìn vào 2 ngày, 2 tuần hoặc tệ hơn, các nhiệm vụ có giá trị 2 tháng tham gia vào phản ứng chiến đấu hoặc chuyến bay. Chia nó thành từng miếng nhỏ đủ để bạn có thể cắn từng miếng một cách liên tục mà không bị nghẹn, và tôi đoán là bạn sẽ biết chính xác nên bắt đầu cắn cái nào và tiếp theo là cắn tiếp theo.

Nếu trò chơi được cho là phù hợp với một thể loại hiện có, hoặc nó tương tự như một trò chơi khác, chỉ cần cố gắng tạo ra một sự bắt chước thô sơ, đơn giản của trò chơi đó hoặc làm một ví dụ "điển hình" của thể loại này. Nếu bạn không phải là một lập trình viên giỏi, hãy làm theo hướng dẫn sẽ hướng dẫn bạn thực hiện một trò chơi tương tự như trò chơi của bạn.

Sau một thời gian, bạn sẽ tự nhiên cảm thấy sự thôi thúc "phân kỳ" khỏi mô hình của bạn và bắt đầu chơi trò chơi theo hướng riêng của bạn. Từ đó, con đường xuống dốc của việc thêm một tính năng ở đó, sửa lỗi ở đây và nói chung là cải thiện từng bước nhỏ.

Nếu có một khái niệm nào đó là duy nhất cho trò chơi của bạn, bạn cũng có thể bắt đầu bằng cách xây dựng bản trình diễn đơn giản nhất về khái niệm đó. Ngoài ra còn có tùy chọn đơn giản là xây dựng trò chơi của bạn xung quanh khái niệm đó.

Làm những điều cung cấp cho bạn một nguyên mẫu có thể chơi càng sớm càng tốt.

1-2 tuần đầu tiên bạn có thể không thể ước tính tốt, vì bạn chưa quen với động cơ. Vì vậy, trong tuần đầu tiên, có lẽ thật lãng phí thời gian để ước tính. Nhưng hãy lưu ý thời gian bạn dành cho công cụ, vì vậy bạn có một số kinh nghiệm bạn có thể dựa trên ước tính đầu tiên của mình. Sau thời gian đó bắt đầu lên kế hoạch, ước tính và đặt ưu tiên!

Ba điều tôi đã học được từ 6 tháng qua khi tôi là một phần của dự án trò chơi không thành công (tôi được trả tiền để trở thành nhà phát triển logic trò chơi):

1. Đừng thay đổi kế hoạch của bạn mỗi ngày! Rõ ràng là một điều tốt để đi một con đường nhanh nhẹn, nhưng nếu bạn kết thúc việc thay đổi mục tiêu của mình mỗi ngày, rõ ràng có điều gì đó không ổn.
2. Theo dõi thời gian bạn dành cho công việc của bạn. So sánh thời gian ước tính và hiệu quả. Lúc đầu, bạn có thể sẽ nhận thấy một sự khác biệt lớn, nhưng theo thời gian, bạn sẽ có thể ước tính tốt hơn.
3. Hãy ước tính khi thiết lập các ưu tiên.

Quan trọng: Thỉnh thoảng hãy nhìn lại dự án và xem điều gì đã diễn ra tốt đẹp và điều gì đã xảy ra. Tôi đoán bạn có thể xác định những phần mà bạn đã dành quá nhiều thời gian cho những thứ không cần thiết. Hãy cố gắng để những thứ như vậy ra lần sau. (Ví dụ: Nếu bạn làm việc trên một tiện ích mà người chơi của bạn có thể sử dụng 1 hoặc 2 lần trong trò chơi trong 2 giây, đừng dành cả tháng cho việc triển khai.)

Nếu bạn không biết cách thiết kế dự án đúng cách, tôi khuyên bạn nên đọc chương 1 của Bruce Eckel's Thinking in C ++ (cuốn sách miễn phí), có một phần có tên là "Phân tích và thiết kế". Đó là một giới thiệu tốt.

Hãy chắc chắn kiểm tra Suy nghĩ của Bruce Eckel trong C ++ Tập 2 .