Чи корисний аналіз вимог при розробці ігор?

9

Я студент програмного забезпечення з фокусом на розробці гри. Наскільки велику роль відіграє аналіз вимог у розробці гри?

Я прошу, бо намагаюся вирішити, чи брати клас на аналіз вимог. Ось опис:

Поглиблене вивчення сучасних досліджень та практики щодо висування вимог, вимог, аналізу, специфікації вимог, перевірки та затвердження вимог та управління вимогами.

Чи корисний би такий тип знань незалежному розробнику ігор? (Альтернативою є штучний інтелект або архітектура програмного забезпечення.)

education software-engineering requirements

— Джої Грін
джерело

Для уточнення, які ваші альтернативи?

— ChrisE

Так, пролийте трохи більше світла на вашу ситуацію, будь ласка. Це щось, на додаток до вашої основної курсової роботи, чи ви намагаєтесь визначити, чи RA є частиною вашого основного?

— Джейсон Пінео

Що стосується вашого класу архітектури програмного забезпечення? Якщо це більше орієнтоване на розробку системи, то я б точно запропонував взяти це. Аналіз вимог складається з "Мені все одно, як я це роблю, що я хочу, щоб це робило моє програмне забезпечення?" Проектування системи складається з "Я знаю, що я хочу зробити, як я можу досягти її найбільш ефективним способом?"

— Рей Дей

Буде корисним будь-який застосований інструмент / техніка, яка допоможе вам уникнути паралічу аналізу.

— Патрік Хьюз

7

Аналіз вимог буде неймовірно корисним, незалежно від того, незалежний ви розробник чи працюєте у великій компанії. Аналіз вимог дозволяє розбити ваш проект на керовані шматки. Він дозволяє оцінити час, який ваш проект займе, і зважити значення функції відповідно до потрібного графіку розробки та необхідних зусиль.

Якщо ви перебуваєте в більшій компанії з інді-ігор, це допоможе вам співпрацювати з іншими розробниками та виробниками контенту, щоб переконатися, що кожен завжди має щось робити, і ви зможете досягти своїх цілей розвитку. Якщо ви працюєте у великій корпорації, аналіз вимог до навчання зробить вас одним з небагатьох розробників на зустрічі, який насправді може дати реалістичну оцінку часу для функції, а не просто витягнути число з дупи.

На додаток до всього цього, перевірка вимог може включати такі тести, як тестування одиниць та перевірка функцій, що є безцінним для розробника без великого відділу контролю якості на його спині.

— Григорій Евері-Вейр
джерело

+1 Все сказане тут є правильним, а також дещо вирішується ідея, що ви можете в кінцевому рахунку займатися корпоративним програмуванням, поки ви не зробите це на сцені Інді.

— ChrisE

Як це не може бути корисним? Ви повинні проаналізувати все, що ви робите, структуровано. Просто те, що деякі терміни розпливчасті, не означає, що їх неможливо оцінити.

— Johnny

2

Я думаю, що цей клас матиме між нулем і дуже малим значенням для розвитку ігор. Звичайно, в моєму досвіді не використовуються напівформальні чи формальні методи, які ви згадуєте.

Ігри, як правило, мають надзвичайно текучі вимоги, і навіть якби можна було вкласти час та найкращі практики для збирання вимог, багато чого з того, що ви закінчили б, є безглуздими і розпливчастими термінами, що стосуються розваг, звикання, занурення тощо. Дуже рідко у вас будуть дуже чітко визначені результати, тому що, наскільки ми хочемо робити вигляд, що створення програмного забезпечення - це інженерія, це насправді більше ремесло, враховуючи різноманітність різних способів, якими програмісти можуть виразити себе. Це іде вдвічі для ігор.

— Kylotan
джерело

Я сподіваюся, що "потреби в рідині" не є евфемізмом для "повзучості". : \ Я не погоджуюся з тим, що "багато" з того, що ви закінчились, - це безглузді і розпливчасті терміни, такі як "веселощі", "залежність" і т. Д. Вони являють собою нетехнічні вимоги, які є підмножиною справді продуманих вимог документ.

— PatrickB

2

Я думаю, що потреби в рідині, безумовно, є евфемізмом для повзучості функцій, але якщо ви хочете змагатись у роздрібній торгівлі та сприятливих умовах, вам потрібно прийняти функцію повзання з першого дня. Те, що ви можете дізнатись, збираючи та аналізуючи вимоги до традиційного «замовника програмного забезпечення», надто відрізняється від того, як потрібно працювати розважальне програмне забезпечення. Зокрема, у вас є одна головна проблема в тому, що ваш клієнт не є вашим кінцевим користувачем, і ще одна головна проблема в тому, що технічні вимоги не можна усунути, коли ви знаєте, що повзування функції неминуче.

— Kylotan

Я не вірю, що він сказав, що він конкурує або навіть робить товар, який продає. Дуже багато інді-ігор не розроблені для змагань з роздрібними іграми, вони зазвичай навіть не на тому ж ігровому полі, що й титри AAA. Чорт, Steam засуває всі інді-ігри у свою маленьку пісочницю, ймовірно, як ще одну попереджувальну етикетку. Коли ваш інді-розробник, ви, за визначенням, маєте контроль над тим, що хочете зробити. Якби ти не був тоді, ти був би партнером / вкладеним в нього, і тоді ти насправді не був би інді, чи не так? Так чи інакше, я, здається, не відчуваю повзучості в будь-яких іграх з хобі, над якими працюю. YMMV.

— PatrickB

1

Я не думаю, що незалежність зазвичай означає «ігри з хобі», це зазвичай означає «маленька компанія, яка не покладається на фінансування видавців». Таким чином, ситуація з вашим клієнтом / клієнтом може бути простішою, ніж я запропонував вище, але ви можете бути, навіть, більш сприйнятливими до ринкових сил. Але в кінці робочого дня найбільш офіційний аналіз вимог виявиться непростим, тому що визначити, що таке "бізнес-потреба" щодо гри, надзвичайно важко. Ігри суттєво відрізняються від іншого програмного забезпечення в цьому плані, і тому я покірно пропоную інші способи конкретизації програмного забезпечення більш доречні.

— Кілотан

Які ще способи?

— Johnny

2

Аналіз вимог значно більше орієнтований на корпоративне програмне забезпечення, з формальними каналами комунікації та подібними речами, мало що для інді-розробника не існуватиме. Це не дуже корисно для ігор, оскільки багато вимог не можуть бути офіційно перевірені або перевірені. Якщо у вас є панель інструментів, і ви говорите: "Натиснувши на цю кнопку, слід випустити меню з XYZ на ній", ви можете платити комусь практично нічого, щоб натиснути кнопку і подивитися, що відбувається. Ваша гра весела? Це зовсім інший чайник з рибою.

RA може бути корисним для визначення, чи функціонує гра; але коли мова йде про такі речі, як рівновага, перейграність та інші фактори, що визначають кінцевий фактор забави гри, перевірити їх складно або неможливо. Отже, в кінцевому рахунку, це залежить від того, чи збираєтесь ви на відмінну реалізацію існуючої ідеї; чи шукаєте ви успіху в новій геймплеї чи ні.

— DeadMG
джерело

0

Пропустити це.

Яку сферу розвитку ігор ви зацікавили? Я припускаю, що програміст, але ...

Дизайнер: Вони багато пишуть. Ціла партія. Зазвичай існує дизайн-документ, який повідомляє бачення дизайнерів, але для всіх інших, крім виробника чи видавця, ви зазвичай отримуєте інформацію від самого дизайнера.

Програміст: Ведучий визначає технічні вимоги, які сильно залежатимуть від платформи та активів. Ви дізнаєтесь, як це зробити, працюючи зі своїм керівником на роботі.

Художник: Знову його головний артист разом із головним програмістом, який зазвичай встановлює вимоги до арт-активів. Вчіться на роботі.

Аналіз вимог, як, наприклад, курс, який вони, швидше за все, викладають, корисний для великих корпорацій, які намагаються виправдати витрачені гроші та для аутсорсингу. І це часто робиться тим, хто колись кодував і, можливо, з тих пір забув. колоти

Якщо ви плануєте поїхати в Інді, візьміть предмет бізнесу / бухгалтерського обліку / управління. Вам це знадобиться, щоб вижити, а не заграти. Щасти.

— bkersten
джерело

Я також би припустив програміста, оскільки він позначив його програмістом;)

— Комуністична качка

1

-1 Отже, ви не лише пропустили те, що людина позначила це програмістами, але й пропустили, що це було для розвитку інді, що одразу означало б, що у них не буде технологічного приводу для навчання. Аналіз вимог є корисним - навіть коли не виконуються повноцінні системні характеристики - навчитися втручатися у правильний спосіб мислення для аналізу проблем. Крім того, практика письмової роботи завжди буде корисною, якщо виникне потреба зробити крок до видавця. Ваша порада, відверто кажучи, не звертається до цільової аудиторії і не дає корисного розуміння цієї теми.

— ChrisE

-1 Домовились. Досить шаленого програмного забезпечення, яке не робить того, що потрібно людям, і достатньо інді-ігор, які страждають від жахливих конструкцій, які не вирішують технічних проблем і перетворюються на нескінченні переписування та неопубліковані ігри. Формальні методи - це формальність, яку інді-ігри можуть явно не проходити, але, маючи передумови, це призводить до менталітету «стоп і думай», а не до «коду і виправлення», який є надто поширеним. Кодери - це десяток, але все ж якісне програмне забезпечення таке рідкісне. Ви займаєтесь математикою.

— PatrickB

1

Ха-ха-ха. Весь розвиток ігор, особливо інді, полягає в тому, щоб бути гнучким і повторювати основну ідею. Аналіз вимог не може нічого запропонувати і здебільшого є важким процесом. Тому я узагальнив свою відповідь. Якщо вони планують пройти інді, маючи мережу напівдосвідчених розробників та художників, важко обійтися. Тож або вам потрібно бути генієм у всіх сферах розвитку ігор та бізнесу, або ви знайдете наставників, а-ла-лідерів тощо. Намагайтеся не бути настільки чутливими хлопцями.

— bkersten

1

Аналіз вимог @PatrickB не вплине на те, як розробляється фрагмент програмного забезпечення. Аналіз вимог переповнений марною інформацією, яку розробник ігор навряд чи коли-небудь використає (використовуйте діаграми випадку, особливо прискіпливі). Це тема, яка в значній мірі орієнтована на зацікавлені сторони, а отже, і на корпоративне середовище. Я згоден, що розробник повинен перелічити вимоги (функції), але це має бути здоровим глуздом. Розробка програмного забезпечення - це абсолютно окрема тема, до якої аналіз вимог ледь зачіпається (в університеті все одно)

— Рей Дей