Tôi có thể sử dụng tính năng creep để lợi thế của tôi? [đóng cửa]

Tôi có thể sử dụng tính năng creep để lợi thế của tôi?

Mỗi khi tôi tạo mẫu cho một trò chơi, các tính năng sẽ vô tình được thêm vào. Điều này xảy ra hoặc thông qua sự trùng hợp ngẫu nhiên hoặc dễ dàng thêm vào dựa trên nội dung hiện có.

Nếu tôi biết thể loại của trò chơi, tôi có thể bắt đầu tạo ra các cơ chế cơ bản và thêm các tính năng khi chúng trở nên rõ ràng không?

Ví dụ: nếu tôi muốn tạo một nền tảng 2d trong vòng 6 tháng, tôi có thể bắt đầu chạy, nhảy, chụp, v.v. và thêm các cơ chế cốt lõi khi tôi vô tình tìm thấy chúng không? Hay đây là quá rủi ro của một khoản đầu tư thời gian mà không có kế hoạch định trước?

Logic của tôi đằng sau điều này là thiết kế sẽ có nhiều tiếng vang hơn. Các lựa chọn thiết kế sẽ dễ dàng được xây dựng hơn xung quanh những gì dễ thực hiện (theo thời gian).

Tóm lại, có gì sai khi xây dựng một trò chơi trước khi tôi thiết kế nó?

Đó là một câu hỏi thú vị. Chủ yếu là vì trả lời nó làm tăng tình trạng khó xử về sắc thái của màu xám so với màu đen và màu trắng.

Có gì sai khi xây dựng một trò chơi trước khi tôi thiết kế nó?

Nếu bạn nghĩ câu hỏi đó là loại có hoặc không, câu trả lời chỉ có thể là: có, có. Nếu câu trả lời có thể nhiều sắc thái hơn, thì nó thay đổi. Lý do: bạn không bao giờ nên xây dựng một trò chơi trước khi một số thiết kế. Nhưng bạn chắc chắn có thể lưu các phần của thiết kế cho sau này.

Điều đó có nghĩa là, tôi không nghĩ bạn nên xem vấn đề trong tay là làm hay không làm. Thay vào đó, nó là một cái gì đó mà bạn nên nghĩ về mức độ. Tính năng leo có thể là gốc rễ thứ hai của mọi tội lỗi liên quan đến phát triển trò chơi (thứ nhất, như Donald Knuth đã gây khó khăn cho chúng ta, đó là "tối ưu hóa sớm là gốc rễ của mọi tội lỗi" ). Tuy nhiên, theo kinh nghiệm của tôi, không nghĩ đến bất kỳ tính năng chính nào, tức là không có ít nhất một thiết kế cơ bản về nơi bạn muốn đi với cơ học cơ bản của mình, cũng không phải là một ý tưởng hay.

Lý do chính đầu tiên là nó rất hữu ích đối với tài nguyên (bao gồm cả thời gian là tài nguyên) để có một số kế hoạch hướng dẫn bạn máng - bởi vì việc đi vào ngõ cụt mọi lúc do cố gắng và lỗi quá mức có thể chỉ là lãng phí tài nguyên như phải bao gồm các tính năng không lường trước.

Lý do chính thứ hai, thiết kế trò chơi khôn ngoan, là sự gắn kết. Thiết kế trò chơi tốt có sự gắn kết về mặt khái niệm hoặc tính nhất quán nếu bạn muốn. Điều đó có nghĩa là, trò chơi tổng thể, lịch sử, cách thực hiện, thậm chí cả đồ họa, phải phù hợp với nhau một cách trơn tru nhất có thể. Rất khó có khả năng một thiết kế trò chơi sẽ đạt được điều tương tự nếu các tính năng chính được phát hiện khi đang di chuyển. Nếu không phải vì bất cứ điều gì khác, bởi vì trên đường đi có rất nhiều sự ngẫu nhiên: những thứ bạn sẽ bước vào có thể có những tác động rất khác nhau tùy thuộc vào thời điểm trong quá trình phát triển bạn đã tìm thấy chúng .

Tôi không có ý nói rằng bạn không nên làm những gì bạn nói. Tôi chỉ tuyên bố rằng bạn phải tìm một số dư.

Ví dụ: nếu tôi muốn tạo một nền tảng 2d trong vòng 6 tháng, tôi có thể bắt đầu chạy, nhảy, chụp, v.v. và thêm các cơ chế cốt lõi khi tôi vô tình tìm thấy chúng không? Hay đây là quá rủi ro của một khoản đầu tư thời gian mà không có kế hoạch định trước?

Tôi sẽ bắt đầu bằng cách giới thiệu một sửa đổi nhỏ trong câu của bạn. Bằng cách thực hiện chạy, nhảy, chụp và vv, bạn đã thực hiện các cơ chế cốt lõi. Những gì bạn sẽ thêm khi đang di chuyển trong ví dụ của bạn là các tính năng chơi trò chơi cụ thể.

Không phải vì bạn biết trò chơi sẽ là một nền tảng 2D, mà việc chạy, nhảy hay bắn súng không thể thay đổi tùy thuộc vào thiết kế trò chơi. Người chơi của bạn có thể chạy trên tường không? Người chơi của bạn có thể nổi trong không khí khi nhảy không? Thậm chí, người chơi của bạn có thể bắn trong khi chạy không? Có phải người chơi của bạn chỉ bắn theo hướng tuyến tính hoặc thông qua một parabola? Những quyết định này có thể phụ thuộc rất nhiều vào tính năng trò chơi.

Nhưng tôi thấy quan điểm của bạn: những cơ chế này thường có một số phần khác nhau rất ít. Vì vậy, nếu bạn thực hiện một số thiết kế trò chơi và quyết định các tính năng cơ bản nhiều như chắc chắn phần nào cách chạy, nhảy, bắn, v.v. sẽ hoạt động, đó là một sự khởi đầu. Sau đó, bạn có thể đi cho các cơ chế và tiếp tục xây dựng trên chúng.

Tất nhiên sau đó bạn vẫn có thể tìm thấy một tính năng mới yêu cầu bạn thay đổi các cơ chế này - bất kể chúng cơ bản như thế nào. Nhưng chìa khóa ở đây là xác suất. Xác suất rằng điều này sẽ xảy ra quá thường xuyên sẽ nhỏ hơn nếu bạn ít nhất đã suy nghĩ về hậu quả của việc chạy, bắn, nhảy và vv cho những ý tưởng cơ bản bạn có cho trò chơi.

Cuối cùng, nếu bạn muốn đi theo con đường đó, tôi sẽ đề xuất như sau. Hãy nghĩ về nó như là một quá trình lặp đi lặp lại. Bạn làm một số tư duy thiết kế ban đầu, rộng. Bạn thực hiện những gì có vẻ cơ bản và "phổ quát" hơn trong trò chơi của mình, để nó thành công. Sau đó, bạn thực hiện một số tư duy thiết kế, đánh giá lại những gì bạn đã thực hiện và thực hiện thêm một số triển khai.

Khi thực hiện các dự án phức tạp như trò chơi, bạn thường không thể tạo ra tất cả các tính năng bạn muốn, vì bạn sắp hết thời gian / tiền bạc hoặc vì chúng không trở nên tốt như bạn mong đợi. Điều này được gọi là tính năng creep. Nhưng có một mặt trái của điều này; bạn cũng sẽ tìm thấy các tính năng mà bạn không nghĩ rằng mình cần, nhưng khi dự án hình thành nhu cầu của họ trở nên rõ ràng.

Đây là lý do tại sao mọi người xây dựng các nguyên mẫu - để họ có thể tìm hiểu những gì hoạt động và những gì không, vì vậy họ có thể cắt các tính năng không hoạt động , nhưng cũng để họ có thể tìm thấy các tính năng mới sẽ tuyệt vời . Nếu bạn không làm một trong những điều bạn không học , bạn đã làm sai.

Về cơ bản, đây là tình cảm được thể hiện trong một cuộc nói chuyện có tên Advanced Prototyping , của Chris Hecker và Chaim Gingold, bao gồm nhiều ví dụ từ công việc của họ trên Spore, nơi họ thường ngạc nhiên bởi những gì hoạt động và những gì không, đã đi xa hơn khi thiết kế lại toàn bộ hệ thống dựa trên phản hồi nguyên mẫu.

Một ví dụ khác là quy trình thiết kế cho Left 4 Dead ; Lúc đầu, trò chơi chỉ có những thây ma cơ bản, nhưng từ việc chơi với những người chơi có kinh nghiệm, các nhà thiết kế nhận thấy rằng những người chơi kết hợp với nhau rất hiệu quả và trò chơi quá dễ dàng, vì vậy họ đã thêm những thây ma đặc biệt để phá vỡ đội và giữ cho trò chơi trở nên thú vị.

Tất nhiên, điều này không có nghĩa là bạn nên xây dựng trò chơi của mình mà không cần thiết kế trước . Bạn nên chắc chắn rằng cốt lõi của trò chơi của bạn là thú vị trước khi tiếp tục, bởi vì đó thường là phần khó nhất khi tạo ra một trò chơi.

Tôi sẽ nói có, đi cho nó. Nhưng lên kế hoạch một số tính năng / lớp phổ biến trước thời hạn để có sự gắn kết giữa mỗi thành phần mới.

Unity được biết đến với cách tiếp cận thành phần để phát triển trò chơi và sẽ cho phép hình thức phát triển này dễ dàng. Nếu bạn không sử dụng Unity, bạn có thể sao chép cách tiếp cận bán thành phần. Tôi không quen thuộc với các công cụ trò chơi khác.

Các đối tượng trò chơi Unity đều có một thành phần biến đổi. Điều này nói lên vị trí, góc quay và tỷ lệ của đối tượng. Vì vậy, tạo một lớp 'biến đổi' chung để giữ các giá trị này, cộng với một tham chiếu đến đối tượng trò chơi thực tế có thể.

Lấy một thành phần 'Jump', ví dụ. Có tất cả logic làm việc với lớp biến đổi của đối tượng trò chơi để thực hiện thao tác vị trí. (Hoặc công cụ của bạn sẽ có một lớp được xây dựng tương tự.) Bạn có thể đính kèm lớp 'Jump' này vào bất kỳ đối tượng nào và lớp sẽ làm động vị trí biến đổi khi một hành động được kích hoạt (Jump.PerformJump () hoặc bất cứ điều gì). Lớp Jump không phải biết bất cứ điều gì về chủ sở hữu của nó (hoặc, ít nhất, thông tin tối thiểu).

Bây giờ bạn có thể vui vẻ tạo ra một tấn các thành phần, sau đó gắn chúng vào các đối tượng trò chơi, kết hợp chúng trên một đối tượng, v.v. Ví dụ: Run, Jump, Crouch, MoveTile, FireWeapon (chỉ định sprite 'đạn' và hành vi để thực hiện một thành phần chung), v.v.

Làm cho mỗi thành phần chung chung nhất có thể để cho phép sử dụng / biến thể nhiều lần. Đối với FireWeapon, bạn có thể chỉ định sprite đạn, tốc độ, sát thương, v.v. Bạn có thể cố gắng làm cho các thuộc tính đó được chuẩn hóa, để tốc độ và sát thương được chỉ định trong khoảng từ 0 đến 1. Sau đó chia tỷ lệ cho các giá trị tối đa của trò chơi. Bằng cách này, bạn chỉ lo lắng về sự khác biệt tương đối giữa các vũ khí. Ngoài ra, điều này thích ứng với các cài đặt toàn cầu, chẳng hạn như khó khăn trong đó độ khó cao hơn có sát thương tối đa cao hơn, v.v.

Trước khi bạn biết điều đó, bạn có một kho các thành phần để cắm và bây giờ bạn có thể nhanh chóng phát triển cho bất kỳ loại trò chơi nào.

Tóm tắt: hầu hết thời gian bạn không thể có một bước thiết kế duy nhất theo sau một bước mã hóa duy nhất. Bạn sẽ phải thay thế chúng. Theo nguyên tắc chung, hãy cố gắng tôn trọng những gì đã được thiết kế (không phải những gì đã được mã hóa).

Về việc không có thiết kế ban đầu (chỉ là bản phác thảo hoặc hình ảnh tinh thần): nếu bạn không có thiết kế thì bạn không có thiết kế. Bạn phải làm một cái gì đó để đi kèm với một. Nhưng miễn là bạn bắt đầu xây dựng một cái, hãy cố gắng tôn trọng nó, đừng đi kèm với cái mới mỗi lần.

Thử nghiệm và nhận các tính năng ngẫu nhiên có thể có hoặc không có hại. Nó thậm chí có thể có lợi hoặc không thể tránh khỏi. Ví dụ: bạn biết rằng bạn muốn hỗ trợ nhảy (nhiều game nhập vai 3D / 2D không cho phép nhảy). Sao bạn biết được? Bởi vì bạn tưởng tượng một bản đồ trò chơi đòi hỏi phải nhảy để sắp xếp một chướng ngại vật? Vì vậy, việc thực hiện bước nhảy là đủ tốt miễn là nó cho phép người chơi sắp xếp chướng ngại vật đó hoặc nó phải tuân thủ một số đặc điểm như độ cao tối đa có thể đạt được, có thể được tăng cường bởi các vật phẩm hoặc đối tượng trò chơi trong bản đồ, vật lý phải bao gồm tăng tốc hoặc nảy ( Khi Mario nhảy vào một kẻ thù Anh ta có được sự thúc đẩy để nâng cao trở lại và điều đó rất quan trọng đối với trò chơi)?

Nếu bạn đã có thể trả lời những câu hỏi đó thì tài liệu thiết kế của bạn (tưởng tượng hoặc thực tế) rất đầy đủ. Nếu bạn không thể trả lời những điều đó, thì thiết kế của bạn không đầy đủ. Trong trường hợp này, bạn sẽ phải quay lại làm việc trong thiết kế hoặc thực hiện thử nghiệm để lấp đầy các khoảng trống. Các cơ hội có thể rất mở hoặc rất hạn chế. Nếu một số cấp độ trò chơi của bạn sẽ gặp trở ngại và bạn chỉ cần nhảy cho chúng thì có rất nhiều tự do để quyết định độ cao tối đa có thể đạt được hoặc tốc độ, có thể bạn quyết định giả vờ có một động cơ vật lý bắt đầu tất cả chỉ để cải thiện hình ảnh của hoạt hình nhảy nhưng bạn không cần nó cho bất cứ điều gì khác. (Trong nhiều trò chơi RPG 2D, bạn không thể nhảy khi muốn, nhưng miễn là có một lỗ gạch duy nhất trên bản đồ, cố gắng tự động bước vào nó sẽ kích hoạt một cú nhảy xuống sàn gạch bên cạnh lát gạch)

Tôi hiểu rằng bạn có thể đi mã mà không cần thiết kế hoàn chỉnh miễn là bạn tôn trọng những gì đã được quyết định. Ngoài ra, có thể không thể tránh khỏi trong một số tình huống vì vũ trụ trò chơi có thể được xây dựng từ nhiều quá trình tư duy khác nhau. Ví dụ: trò chơi bài: Tôi biết tôi muốn các lá bài có Tấn công và Phòng thủ, một số lượng thẻ nhất định trong bảng tại một thời điểm nhất định và người chơi trong lượt của mình có thể chọn thẻ nào tấn công thẻ nào khác. Nó có thể trông giống như một thiết kế đã hoàn thiện, nhưng sau đó là sự cân bằng của trò chơi, chỉ có thể thông qua nhiều mô phỏng. Sau nhiều lần mô phỏng, tôi quyết định rằng một thẻ với Attack 10 bị áp đảo, tôi có thể xóa nó khỏi trò chơi nhưng tôi thích nó quá nhiều nên tôi sẽ làm một cái gì đó khác, Tôi sẽ tạo một quy tắc mới nói rằng nếu người chơi tấn công bằng thẻ như vậy thì không thể tấn công bằng thẻ khác trong lượt đó. Bây giờ tôi có một quy tắc mới làm phong phú thêm cơ chế trò chơi, nhưng áp dụng nó vào một thẻ duy nhất trông lạ (như hack bẩn), tôi nhận ra Nó trông lạ và sau đó tôi quyết định tạo ra một bộ thẻ mới có số lượng cao nhưng quy tắc giới hạn mới áp dụng cho họ. Bây giờ tôi có một cơ chế trò chơi phức tạp hơn, được xây dựng trên bản gốc đơn giản hơn, theo ý kiến ​​của tôi, tôi đã biến nó thành lợi thế của mình để tạo ra một trò chơi tốt hơn.

Bây giờ, một điều về ví dụ cuối cùng đó, trong ví dụ đề xuất của trò chơi bài, thẻ mới có thể dẫn đến tài sản mới (tăng chi phí, tăng thời gian). Nhưng tôi nghĩ là một ví dụ tốt về việc để những cơ hội bạn chỉ nhìn thấy khi mã hóa ảnh hưởng đến quyết định thiết kế của bạn một cách tốt.

Tôi không nghĩ rằng hầu hết các trò chơi chúng tôi chơi đều được thiết kế hoàn chỉnh trước khi mã hóa, tôi chắc chắn rằng họ phải đưa ra quyết định khó khăn để tuân thủ các mốc thời gian và vì vậy.

Khi ai đó đang trả tiền cho tất cả: giải thích, thương lượng.