Là phân tích yêu cầu hữu ích trong phát triển trò chơi?

9

Tôi là một sinh viên kỹ thuật phần mềm với trọng tâm phát triển trò chơi. Làm thế nào lớn một phần của phân tích yêu cầu chơi trong phát triển trò chơi?

Tôi đang hỏi bởi vì tôi đang cố gắng quyết định có nên tham gia một lớp học về phân tích yêu cầu hay không. Dưới đây là một mô tả:

Một nghiên cứu chuyên sâu về nghiên cứu hiện tại và thực hành trong việc khơi gợi các yêu cầu, yêu cầu, phân tích, đặc tả yêu cầu, xác minh và xác nhận yêu cầu, và quản lý yêu cầu.

Loại kiến thức này sẽ hữu ích cho một nhà phát triển trò chơi độc lập? (Các lựa chọn thay thế là trí tuệ nhân tạo hoặc kiến trúc phần mềm.)

education software-engineering requirements

— Joey Green
nguồn

Để làm rõ, các lựa chọn thay thế của bạn là gì?

— ChrisE

Vâng, làm ơn cho biết thêm một chút về tình huống của bạn. Đây có phải là thứ gì đó để bổ sung vào khóa học cốt lõi của bạn hay bạn đang cố xác định xem RA có phải là một phần cốt lõi của bạn không?

— Jason Pineo

Có gì liên quan đến lớp kiến trúc phần mềm của bạn? Nếu nó thiên về thiết kế một hệ thống thì tôi chắc chắn sẽ khuyên bạn nên dùng nó. Phân tích yêu cầu bao gồm "Tôi không quan tâm đến cách tôi thực hiện, tôi muốn phần mềm của mình làm gì?" Thiết kế một hệ thống bao gồm "Tôi biết những gì tôi muốn làm, làm thế nào tôi có thể đạt được nó một cách hiệu quả nhất?"

— Ray Dey

Bất kỳ công cụ / kỹ thuật được áp dụng nào sẽ giúp bạn tránh Phân tích tê liệt sẽ hữu ích.

— Patrick Hughes

7

Phân tích yêu cầu sẽ vô cùng hữu ích, cho dù bạn là nhà phát triển độc lập hay bạn làm việc cho một công ty lớn. Phân tích yêu cầu cho phép bạn chia dự án của bạn thành các phần có thể quản lý được. Nó cho phép bạn ước tính thời gian dự án của bạn sẽ sử dụng và cân nhắc giá trị của một tính năng so với lịch trình phát triển mong muốn và nỗ lực cần thiết của bạn.

Nếu bạn ở trong một công ty game độc lập lớn hơn, nó sẽ giúp bạn hợp tác với các nhà phát triển và nhà sản xuất nội dung khác để đảm bảo mọi người luôn có việc phải làm và bạn có thể đạt được mục tiêu phát triển của mình. Nếu bạn đang làm việc cho một tập đoàn lớn, phân tích yêu cầu học tập sẽ khiến bạn trở thành một trong số ít các nhà phát triển tại cuộc họp, người thực sự có thể đưa ra ước tính thời gian thực tế cho một tính năng thay vì chỉ rút một số ra khỏi mông bạn.

Ngoài tất cả những điều đó, xác thực yêu cầu có thể bao gồm những thứ như kiểm tra đơn vị và xác minh các tính năng, điều này là vô giá đối với một nhà phát triển mà không có bộ phận QA lớn ở sau lưng.

— Gregory Avery-Weir
nguồn

+1 Mọi thứ được nói ở đây đều đúng, cũng như phần nào giải quyết ý tưởng rằng bạn có thể sẽ lập trình công ty cho đến khi bạn thực hiện nó trong bối cảnh độc lập.

— ChrisE

Làm thế nào nó có thể không hữu ích? Bạn phải phân tích bất cứ điều gì bạn làm theo cách có cấu trúc. Chỉ vì một số thuật ngữ mơ hồ không có nghĩa là không thể định lượng.

— johnny

2

Tôi nghĩ rằng lớp học này sẽ có từ 0 đến rất ít liên quan đến phát triển trò chơi. Chắc chắn các phương pháp bán chính thức hoặc chính thức mà bạn đề cập không được sử dụng theo kinh nghiệm của tôi.

Các trò chơi thường có những yêu cầu vô cùng trôi chảy, và thậm chí nếu có thể đầu tư thời gian và thực hành tốt nhất vào việc thu thập các yêu cầu, phần lớn những gì bạn kết thúc là những thuật ngữ vô nghĩa và mơ hồ đề cập đến niềm vui, nghiện ngập, đắm chìm, v.v. Rất hiếm khi bạn có các sản phẩm được xác định rõ ràng bởi vì, nhiều như chúng tôi muốn giả vờ làm phần mềm là kỹ thuật, nó thực sự là một nghề thủ công, với nhiều cách khác nhau mà các lập trình viên có thể tự thể hiện. Điều này tăng gấp đôi cho các trò chơi.

— Kylotan
nguồn

Tôi hy vọng "yêu cầu chất lỏng" không phải là một uyển ngữ cho "tính năng creep". : \ Tôi không đồng ý rằng "nhiều" những gì bạn kết thúc là những thuật ngữ vô nghĩa và mơ hồ như "vui vẻ", "nghiện", v.v. tài liệu.

— PatrickB

2

Tôi nghĩ rằng các yêu cầu về chất lỏng chắc chắn là một uyển ngữ cho tính năng creep, nhưng nếu bạn muốn cạnh tranh trong một môi trường bán lẻ và điều khiển, bạn cần chấp nhận tính năng creep từ ngày đầu tiên. Loại điều mà bạn có thể học bằng cách thu thập và phân tích các yêu cầu cho một 'khách hàng phần mềm' truyền thống quá khác biệt so với cách phần mềm giải trí cần hoạt động. Cụ thể, bạn có một vấn đề lớn là khách hàng của bạn không phải là người dùng cuối của bạn và một vấn đề lớn khác trong đó là các yêu cầu kỹ thuật không thể được xác định khi bạn biết rằng tính năng creep là không thể tránh khỏi.

— Kylotan

Tôi không tin anh ấy nói rằng anh ấy cạnh tranh hoặc thậm chí làm một sản phẩm bán. Rất nhiều game độc lập không được thiết kế để cạnh tranh với các game bán lẻ, chúng thường không thậm chí trên cùng một sân chơi với các tựa game AAA. Địa ngục, Steam đẩy tất cả các trò chơi độc lập vào hộp cát nhỏ của riêng chúng, có lẽ giống như một nhãn cảnh báo. Khi một nhà phát triển độc lập, theo định nghĩa, bạn có quyền kiểm soát những gì bạn muốn làm. Nếu sau đó bạn không được hợp tác / đầu tư và bạn sẽ không thực sự độc lập thì phải không? Dù bằng cách nào, tôi dường như không tìm thấy tính năng leo trèo trong bất kỳ trò chơi sở thích nào tôi làm việc. YMMV.

— PatrickB

1

Tôi không nghĩ độc lập thường có nghĩa là 'trò chơi sở thích', thông thường có nghĩa là 'công ty nhỏ không phụ thuộc vào tài trợ của nhà xuất bản'. Như vậy, tình hình khách hàng / khách hàng của bạn có thể đơn giản hơn tôi đã đề xuất ở trên, nhưng bạn có thể dễ bị ảnh hưởng hơn bởi các lực lượng thị trường. Nhưng vào cuối ngày, hầu hết các phân tích yêu cầu chính thức sẽ được đưa ra bởi vì rất khó để đủ điều kiện "nhu cầu kinh doanh" là gì trong trò chơi. Các trò chơi khác biệt đáng kể so với các phần mềm khác về vấn đề này và do đó tôi sẽ khiêm tốn đề xuất rằng các cách khác để chỉ định phần mềm có liên quan hơn.

— Kylotan

Những cách khác là gì?

— johnny

2

Phân tích yêu cầu chủ yếu nhắm vào phần mềm doanh nghiệp, với các kênh truyền thông chính thức và loại điều đó, ít có gì sẽ tồn tại cho một nhà phát triển độc lập. Nó không hữu ích cho các trò chơi vì nhiều yêu cầu không thể được kiểm tra hoặc xác minh chính thức. Nếu bạn có một thanh công cụ và bạn nói, "Nhấp vào nút này sẽ thả xuống một menu có XYZ trên đó", thì bạn có thể trả tiền cho ai đó hầu như không có gì để nhấp vào nút và xem điều gì sẽ xảy ra. Trò chơi của bạn có vui không? Đó là một ấm cá hoàn toàn khác.

RA có thể hữu ích để xác định nếu các chức năng trò chơi; nhưng khi nói đến những thứ như sự cân bằng, khả năng chơi lại và các yếu tố khác quyết định yếu tố thú vị cuối cùng của trò chơi, thì thật khó hoặc không thể kiểm tra chúng. Vì vậy, cuối cùng, nó phụ thuộc vào việc bạn có thực hiện xuất sắc ý tưởng hiện có hay không; hoặc có hay không bạn đang tìm kiếm thành công trong trò chơi tiểu thuyết.

— DeadMG
nguồn

0

Bỏ qua nó.

Lĩnh vực phát triển trò chơi nào bạn quan tâm? Tôi đang giả sử lập trình viên nhưng ...

Nhà thiết kế: Họ viết rất nhiều. Toàn bộ rất nhiều. Thường có một tài liệu thiết kế truyền đạt tầm nhìn của nhà thiết kế nhưng đối với mọi người khác ngoại trừ nhà sản xuất hoặc nhà xuất bản, thông thường bạn sẽ nhận được thông tin từ chính nhà thiết kế.

Lập trình viên: Khách hàng tiềm năng xác định các yêu cầu kỹ thuật sẽ phụ thuộc rất nhiều vào nền tảng và đường ống tài sản. Bạn sẽ học cách làm điều này khi bạn làm việc với sự dẫn dắt của bạn trong công việc.

Nghệ sĩ: Một lần nữa, nghệ sĩ chính của nó cùng với lập trình viên chính, người thường đặt ra các yêu cầu cho tài sản nghệ thuật. Học hỏi trong công việc.

Phân tích yêu cầu, giống như khóa học mà nhiều khả năng họ sẽ giảng dạy, rất hữu ích cho các tập đoàn lớn đang cố gắng biện minh cho việc chi tiền và cho gia công phần mềm. Và nó thường được thực hiện bởi một người đã từng mã hóa và có thể đã bị lãng quên. cú đâm

Nếu bạn có kế hoạch đi indie, hãy tham gia một môn học kinh doanh / kế toán / quản lý. Bạn sẽ cần nó để tồn tại và không bị vặn. Chúc may mắn.

— người bán hàng
nguồn

Tôi cũng sẽ giả sử lập trình viên, vì anh ta đã gắn thẻ cho lập trình viên;)

— Vịt Cộng sản

1

-1 Vì vậy, bạn không chỉ bỏ lỡ rằng người đã gắn thẻ nó cho các lập trình viên, mà bạn còn nhớ rằng đó là để phát triển độc lập, điều này sẽ ngay lập tức ngụ ý rằng sẽ không có một công nghệ dẫn đầu để học hỏi. Phân tích yêu cầu là hữu ích - ngay cả khi không thực hiện đầy đủ thông số kỹ thuật hệ thống - học cách suy nghĩ chính xác để phân tích vấn đề. Ngoài ra, thực tiễn bằng văn bản sẽ luôn hữu ích nếu có nhu cầu để tạo ra một cú ném cho nhà xuất bản. Lời khuyên của bạn, thẳng thắn, không giải quyết đối tượng mục tiêu cũng như không cung cấp bất kỳ cái nhìn sâu sắc hữu ích về chủ đề này.

— ChrisE

-1 Đồng ý. Có đủ phần mềm nhảm nhí ngoài kia không làm được những gì mọi người cần và đủ các trò chơi độc lập chịu các thiết kế khủng khiếp không giải quyết được các vấn đề kỹ thuật và chuyển thành các bản viết lại vô tận và các trò chơi chưa phát hành. Các phương thức chính thức là một hình thức mà các trò chơi độc lập có thể không đi qua một cách rõ ràng, nhưng có nền tảng sẽ dẫn đến một suy nghĩ "dừng lại và suy nghĩ" thay vì "mã và sửa lỗi" vốn quá phổ biến. Coders là một tá, và phần mềm chất lượng rất hiếm. Bạn làm toán.

— PatrickB

1

Ha ha ha. Tất cả sự phát triển trò chơi, đặc biệt là indie, là về sự nhanh nhẹn và lặp đi lặp lại trên một ý tưởng cốt lõi. Phân tích yêu cầu không có gì để cung cấp và phần lớn là một quá trình nặng nề phía trước. Vì vậy, tôi khái quát câu trả lời của tôi. Nếu họ có kế hoạch đi indie có một mạng lưới các nhà phát triển và nghệ sĩ bán kinh nghiệm sẽ khó có thể làm được nếu không có. Vì vậy, hoặc bạn cần trở thành một thiên tài trong tất cả các lĩnh vực phát triển và kinh doanh trò chơi hoặc bạn tìm được những người cố vấn, một người dẫn đầu về công nghệ, v.v ... Hãy cố gắng đừng trở nên quá nhạy cảm.

— bkersten

1

@PatrickB Phân tích yêu cầu sẽ không ảnh hưởng đến cách một phần mềm được thiết kế. Phân tích yêu cầu có đầy đủ các thông tin vô dụng mà một nhà phát triển trò chơi hầu như không bao giờ sử dụng (sử dụng sơ đồ trường hợp đặc biệt là mùa xuân để tâm trí). Đây là một chủ đề hướng đến các bên liên quan và môi trường công ty. Tôi đồng ý rằng nhà phát triển nên liệt kê các yêu cầu (tính năng) nhưng đó là lẽ thường. Thiết kế một phần mềm là một chủ đề hoàn toàn riêng biệt mà phân tích yêu cầu hầu như không chạm tới (dù sao ở trường đại học)

— Ray Dey