Làm thế nào để bạn quyết định khi danh sách tính năng của bạn đủ dài?

Tôi biết một chút về câu hỏi này nhưng tôi thấy rằng có khá nhiều ý kiến ​​đa dạng về chủ đề này?

Tôi biết từ góc độ người chơi rằng nhiều lựa chọn hơn hầu như luôn luôn tốt. Nhưng mặt khác, nếu nó có nhiều người chơi thì có nghĩa là độ phức tạp cao hơn (meta game) cho cả nhà phát triển cũng như người chơi.

Về sự phức tạp phát triển và hạn chế thời gian luôn đi đôi với nhau. Một cái khác sẽ là những hạn chế về tài nguyên và nền tảng. Sự phân nhánh kinh tế có thể có của việc giữ lại sau này đôi khi cũng là một lý do.

Vì vậy, từ những người có kinh nghiệm ở đây ngoài những điều trên khi các tính năng nên được cắt hoặc để phát hành sau?

Tôi muốn nói rằng đó là một quá trình hai bước đối với chúng tôi:

• Thiết lập mục tiêu của trò chơi.
• Xác định các tính năng giúp chúng tôi đạt được những mục tiêu này.

Danh sách tính năng đủ dài khi hai điểm đó khớp với nhau. Vì thế:

1. Thiết lập mục tiêu của chúng tôi - Tìm ra tất cả những điều mà chúng tôi muốn trò chơi thực hiện cho người chơi / người đánh giá / bất kỳ ai, sau đó nêu chúng một cách có thể đo lường được. Ví dụ: với bản mới nhất của chúng tôi ( xem vid thử nghiệm alpha tại đây ), chúng tôi muốn thực hiện những điều sau:

• Hình ảnh: Chúng tôi muốn mọi đánh giá đều đề cập rằng hình ảnh khác thường và gợi cảm, đặc biệt là cho một tiêu đề độc lập. Điều này rất quan trọng đối với chúng tôi bởi vì các game thủ thường sử dụng đôi mắt của họ như một thước đo nhanh về chất lượng (mặc dù, tất nhiên, đó chỉ là một trong số rất nhiều!), Và chúng tôi muốn điều đó thu hút họ.
• Thám hiểm: Chúng tôi cũng muốn thưởng cho mọi người vì đã khám phá trò chơi. Nói một cách chính xác, chúng tôi muốn một phần năm thời gian trò chơi của người chơi được dành để làm những việc nhỏ gọn bên ngoài lối chơi cốt lõi. Điều này rất quan trọng đối với chúng tôi bởi vì (IMO), phần lớn sự thú vị của một trò chơi nằm ngoài các lĩnh vực cốt lõi dự kiến ​​(chúng tôi nghĩ về cách nhấp vào các mảnh trong Starcraft khiến chúng tôi thích thú).
• Cộng đồng: Chúng tôi muốn mọi người nói với ít nhất một người bạn về trò chơi.

2. Xác định các tính năng giúp chúng tôi đạt được những mục tiêu đó - Những điều này gần như rơi tự nhiên ra khỏi những điều trên. Vì vậy, các tính năng tương ứng với các ví dụ trên có thể trông như thế này:

• Hình ảnh: Là một studio nhỏ, nếu chúng ta muốn hình ảnh gợi cảm, chúng ta không thể đối đầu với EA hay Sony về chủ nghĩa hiện thực. Vì vậy, để tiếp cận mục tiêu hình ảnh đáng chú ý, một trong những tính năng của trò chơi là tính thẩm mỹ siêu thực. (Từ điều này, chúng tôi có thể xác định những công cụ nào chúng tôi cần, v.v.)
• Thám hiểm: Tidbits hệ quả của hành động của trò chơi rơi ra khỏi điều này. Trong tiêu đề gần đây nhất của chúng tôi , chúng tôi đã bỏ một tài liệu tham khảo nhanh về tìm kiếm đáng ngờ của Ryo cho các thủy thủ ở Shenmue . Đó là một sự vứt bỏ ngớ ngẩn, nhưng mọi người thích và nói về nó!
• Cộng đồng: Chúng tôi đang tự hỏi mình tất cả các cách để làm cho một trò chơi đáng được đề cập đến một người bạn. Làm cho nó vui vẻ là số 1, tất nhiên. Nhưng chúng tôi cũng có thể thưởng cho người chơi một vật phẩm hoặc cấp độ đặc biệt nếu họ tweet về nó. Pokemon làm cho nó có giá trị trong khi có bạn bè chọn trò chơi - có một số sinh vật bạn chỉ có thể có được bằng cách giao tiếp với người khác.

Khi chúng tôi trải qua quá trình này, nó giúp chúng tôi xác định:

• Chúng tôi cần bao nhiêu để thực hiện cho một sản phẩm khả thi tối thiểu ( MVP ).
• Điều gì là quan trọng nhất, những gì có thể chờ đợi và những gì chúng ta có thể bỏ hoàn toàn.
• Khi chúng ta cuối cùng có tất cả các tính năng chúng ta cần.

Điều đáng chú ý là chúng ta không tuân thủ nghiêm ngặt các quy tắc này! Thường xuyên hơn không, một số điều thú vị khủng khiếp xuất hiện là kết quả của việc tạo mẫu giữa dự án và chỉ nói chung chung. Đặc biệt là đối với các trò chơi nhỏ như của chúng tôi.

Sự phức tạp không làm cho trò chơi của bạn vui vẻ.

Sự kết hợp đúng và cân bằng của các yếu tố chơi trò chơi nào. Người chơi phải được đẩy đến mức độ kỹ năng của họ và có được cảm giác làm chủ từ việc chinh phục các thử thách.

Danh sách tính năng của bạn sẽ thay đổi bất cứ khi nào bạn cảm thấy lối chơi hiện tại không thú vị. Những thay đổi này phải được thực hiện trong giới hạn ngân sách / thời gian của bạn. Hãy chắc chắn rằng bất kỳ thay đổi nào bạn tạo ra giá trị đáng kinh ngạc cho trò chơi của bạn.

Ngoài ra, nguyên mẫu sớm, đừng chỉ viết ra một danh sách tính năng khổng lồ và cho rằng tất cả sẽ rất vui khi được đặt cùng nhau.

Sự hoàn hảo đạt được, không phải khi không còn gì để thêm, mà là khi không còn gì để lấy đi.

- Antoine de Saint-Exupery

Khi thời gian và nỗ lực cần thiết để bao gồm chúng lớn hơn giá trị họ thêm vào trò chơi .

Ví dụ: nếu bạn đang tạo một trò chơi thể thao hoặc thứ gì đó mà người chơi có thể muốn thể hiện các kỹ năng của họ, thì nhiều người chơi là phải. Guitar Hero sẽ không giống như vậy nếu không có nó. Tuy nhiên, một trò chơi riêng lẻ, nơi bạn bắt đầu tự mình kết thúc, theo dõi một câu chuyện hoặc cốt truyện không cần nhiều người chơi. Hệ thống nhiều người chơi kém chất lượng trong Grand Theft Auto San Andreas là minh chứng cho điều đó (mặc dù công ty đó có lẽ đã không tìm thấy nhiều người chơi quá khó).

Ngoài ra, các tính năng không thực sự phù hợp với câu chuyện của trò chơi, chỉ có ở đó vì chúng có thể. Nếu nó không hoàn toàn cần thiết cho trò chơi, thì đó có lẽ là một dấu hiệu tốt cho thấy chúng có thể được đẩy lên bản phát hành sau nếu thời gian là một vấn đề.

Vấn đề là, các tính năng bổ sung không phải là yếu tố tinh túy của trò chơi. Một cốt truyện thú vị kết hợp với lối chơi thú vị là.

Mặc dù có một mức độ đa dạng về tính năng là rất lớn (có thể tạo ra vô số thứ ngẫu nhiên trong trò chơi GTA-ish, có vô số vũ khí và phụ kiện trong trò chơi RPG hoặc Call of Duty-ish, v.v.), Tôi nghĩ rằng trò chơi tối thiểu hơn tập trung chặt chẽ vào một vài tính năng cốt lõi có thể có hiệu quả cao.

Nhìn vào Portal, nó đã lấy một cơ chế cốt lõi của nó và thực sự xây dựng các câu đố của nó một cách hiệu quả mà không cần nhiều sự lộn xộn.

Tôi nghĩ rằng việc nghiêm ngặt trong việc giữ danh sách tính năng ở mức tối thiểu nhất có thể và thực sự tìm ra một vài tính năng cốt lõi cho phép một dự án khả thi hơn và thường là trải nghiệm thú vị hơn (nếu Portal thêm các yếu tố RPG và trình tự lái xe và làm chậm và bất kỳ tính năng thú vị nào khác ", Liệu nó có tốt như vậy không? Liệu các cơ chế cốt lõi có được đánh bóng như vậy không?).

Bây giờ, với tư cách là một nhà phát triển độc lập, tôi chắc chắn thiên vị, nhưng tôi nghĩ rằng thường thì "ít hơn" trong các tính năng, và mặc dù có thứ gì đó có thể hay hoặc phổ biến vào lúc này, nếu nó không làm cho trải nghiệm tổng thể tốt hơn đáng kể nên cắt

Tôi đã tìm thấy từ kinh nghiệm cá nhân của mình rằng tốt nhất là tránh thêm các tính năng mới ngoài dự kiến ​​càng sớm càng tốt.

Từ quan điểm thiết kế, một tính năng đã được thêm vào trong thời điểm này "sẽ không tốt nếu có tính năng x" sẽ thêm rất nhiều thời gian phát triển, có thể không tích hợp tốt với mã và có thể không hoàn toàn phù hợp với phần còn lại của thiết kế của bạn.

Trong trường hợp xấu nhất, một dự án có nhiều khoảnh khắc này có thể cảm thấy như một sự kết hợp các tính năng lộn xộn, bị hack cùng nhau, điều thực sự đáng lẽ phải dành nhiều thời gian hơn cho chúng trong giai đoạn thiết kế và kết quả là trông kém chuyên nghiệp hơn.

Theo nguyên tắc chung, tôi cố gắng tuân theo các quy tắc sau:

• Nếu một tính năng mới xuất hiện sớm trong dự án, hãy dành thời gian quay lại giai đoạn thiết kế và thực sự xem tính năng này có thể hoạt động như thế nào với sản phẩm của bạn trong khi vẫn phù hợp với phần còn lại của thiết kế.

• Nếu dự án đang tiến gần hơn để phát hành, hãy xem xét lập danh sách các tính năng để thêm vào phiên bản mới.

• Nếu bạn thấy rằng có rất nhiều tính năng tiếp tục phát triển mà bạn thực sự muốn triển khai, có lẽ bạn nên xem xét quay lại thiết kế và xem tại sao những tính năng mới này chưa được xem xét trước đó, có thể do thiếu nỗ lực trong giai đoạn thiết kế.

Rõ ràng điều này phù hợp với một số dự án tốt hơn các dự án khác, nhưng thực sự nếu bạn có một tính năng đến muộn trong dự án, bạn có thể sẽ ổn nếu không có nó, ít nhất là cho đến khi bạn bắt đầu làm việc trên một phiên bản mới.

Giữ danh sách ngắn, nhanh nhẹn

Không xây dựng danh sách tính năng nào cả, hoặc nếu bạn làm, hãy xây dựng chúng rất ngắn, chỉ đáng giá trong vài tuần phát triển.

Phát triển theo phong cách nhanh nhẹn - bắt đầu với một vài tính năng quan trọng nhất, thử nghiệm, dựa trên những gì hoạt động và những gì không, sau đó suy nghĩ xem có đáng để thêm một số tính năng không (bạn sẽ có thể đánh giá chúng tốt hơn rất nhiều nếu bạn đã có một số kinh nghiệm với lối chơi cơ bản).

Cách đánh giá tính năng cá nhân

Ngoài ra, tôi đồng ý với tiêu chí bennybdbc, "Khi thời gian và nỗ lực cần thiết để bao gồm chúng lớn hơn giá trị họ thêm vào trò chơi."

Điều đó nói rằng, bạn cũng cần xem xét thế giới "bên ngoài":

• bạn đang hết tiền hoặc hết thời gian được đưa ra bởi một hợp đồng?
• bạn đang chạy ra khỏi không gian phương tiện xuất bản (DVD đầy đủ)
• bạn đang chạy ra khỏi không gian hiệu suất (các tính năng mới sẽ khiến trò chơi chạy quá chậm)?
• một trò chơi cạnh tranh sắp được công bố?

Các vấn đề thực tế đơn giản như thế cũng cần được xem xét, trừ khi bạn đang phát triển trò chơi chỉ để cho bạn vui.

Khi bạn hết giấy để viết nó lên.

Giới hạn xác định sẽ là kích thước phương tiện truyền thông; chẳng hạn, bạn không thể phù hợp với 10GB tính năng trên DVD 4,7 GB.

Bạn cũng không muốn có quá nhiều tính năng để làm quá tải trò chơi. Cách tốt nhất là tự hỏi 'điều này sẽ mang lại niềm vui đáng kể cho người chơi phải không? nó sẽ ăn vào thời gian phát triển của chúng ta quá nhiều? điều này thậm chí có thể?