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


9

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

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

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

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


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

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

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

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

Відповіді:


7

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

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

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


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

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

2

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

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


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

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

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

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

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

2

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

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


0

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

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

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

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

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

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

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


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

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

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

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

1
Аналіз вимог @PatrickB не вплине на те, як розробляється фрагмент програмного забезпечення. Аналіз вимог переповнений марною інформацією, яку розробник ігор навряд чи коли-небудь використає (використовуйте діаграми випадку, особливо прискіпливі). Це тема, яка в значній мірі орієнтована на зацікавлені сторони, а отже, і на корпоративне середовище. Я згоден, що розробник повинен перелічити вимоги (функції), але це має бути здоровим глуздом. Розробка програмного забезпечення - це абсолютно окрема тема, до якої аналіз вимог ледь зачіпається (в університеті все одно)
Рей Дей
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.