Полезен ли анализ требований при разработке игр?

9

Я студент-программист, специализирующийся на разработке игр. Насколько большую роль играет анализ требований в разработке игр?

Я спрашиваю, потому что я пытаюсь решить, стоит ли брать урок по анализу требований. Вот описание:

Углубленное изучение текущих исследований и практики в области выявления требований, требований, анализа, спецификации требований, проверки и подтверждения требований и управления требованиями.

Будет ли этот тип знаний полезен для независимого разработчика игр? (Альтернативы - искусственный интеллект или программная архитектура.)

education software-engineering requirements Джои Грин
источник
Чтобы уточнить, каковы ваши альтернативы?
ChrisE
Да, пролите немного света на вашу ситуацию, пожалуйста. Это что-то, что можно взять в дополнение к вашей основной курсовой работе или вы пытаетесь определить, является ли RA частью вашего ядра?
Джейсон Пинео
Что входит в ваш класс архитектуры программного обеспечения? Если это больше ориентировано на разработку системы, то я бы определенно предложил принять это. Анализ требований состоит из «Мне все равно, как я это делаю, что я хочу, чтобы мое программное обеспечение делало?» Проектирование системы состоит из «Я знаю, что я хочу сделать, как я могу добиться этого наиболее эффективным способом?»
Рэй Дей,
Любой применяемый инструмент / техника, которая поможет вам избежать паралича анализа, будет полезна.
Патрик Хьюз

Ответы:

7

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

Если вы работаете в более крупной компании, специализирующейся на независимых играх, это поможет вам работать вместе с другими разработчиками и производителями контента, чтобы убедиться, что у всех всегда есть чем заняться, и вы можете достичь своих целей разработки. Если вы работаете в большой корпорации, анализ требований к обучению сделает вас одним из немногих разработчиков на собрании, которые действительно могут дать реалистичную оценку времени для функции вместо того, чтобы просто вытащить число из своей задницы.

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

Грегори Эйвери-Вейр
источник
+1 Все, что здесь сказано, правильно, а также в некоторой степени относится к идее, что вы можете в конечном итоге заняться корпоративным программированием, пока не добьетесь успеха на инди-сцене.
ChrisE
Как это может быть не полезно? Вы должны анализировать все, что вы делаете, структурированным способом. Тот факт, что некоторые термины являются расплывчатыми, не означает, что их невозможно определить количественно.
Джонни
2

Я думаю, что этот класс будет иметь нулевую и очень небольшую значимость для разработки игр. Конечно, полуформальные или формальные методы, которые вы упоминаете, не используются в моем опыте.

Игры, как правило, предъявляют невероятно гибкие требования, и даже если бы можно было потратить время и лучшие практики на сбор требований, большая часть того, что вы в итоге получили, - это бессмысленные и расплывчатые термины, относящиеся к веселью, зависимости, погружению и так далее. Очень редко у вас будут очень четко определенные результаты, потому что, несмотря на то, что нам нравится притворяться, что разработка программного обеспечения - это разработка, на самом деле это больше ремесло, учитывая разнообразие способов, которыми программисты могут выразить себя. Это удваивается для игр.

Kylotan
источник
Я надеюсь, что «текучие требования» не являются эвфемизмом для «ползучести». : \ Я не согласен с тем, что «многое» из того, что вы в итоге получите, является бессмысленными и расплывчатыми терминами, такими как «веселье», «зависимость» и т. Д. Они представляют собой нетехнические требования, которые являются подмножеством действительно продуманных требований. документ.
PatrickB
2
Я думаю, что текучие требования, безусловно, являются эвфемизмом для ползучести функций, но если вы хотите конкурировать в розничной и нестабильной среде, вы должны принять ползучесть функций с первого дня. То, чему вы можете научиться, собирая и анализируя требования для традиционного «покупателя программного обеспечения», слишком отличается от того, как должно работать развлекательное программное обеспечение. В частности, у вас есть одна серьезная проблема в том, что ваш клиент не является вашим конечным пользователем, и еще одна серьезная проблема в том, что технические требования не могут быть определены, если вы знаете, что переползание функций неизбежно.
Килотан
Я не верю, что он сказал, что он конкурирует или даже делает продукт, который продает. Многие инди-игры не предназначены для конкуренции с розничными играми, они обычно даже не находятся на том же игровом поле, что и игры AAA. Черт, Steam запихивает все инди-игры в свою маленькую песочницу, вероятно, в качестве предупредительного ярлыка. Когда вы независимый разработчик, вы, по определению, имеете контроль над тем, что вы хотите сделать. Если бы вы этого не сделали, вы были бы партнером / инвестором, и вы не были бы тогда инди, не так ли? В любом случае, мне не кажется, что в каких-то увлекательных играх я работаю. YMMV.
PatrickB
1
Я не думаю, что независимость обычно означает «хобби игры», это обычно означает «небольшая компания, не зависящая от финансирования издательства». Таким образом, ситуация с вашим клиентом / клиентом может быть проще, чем я предлагал выше, но вы можете быть даже более восприимчивыми к рыночным силам. Но, в конце концов, самый формальный анализ требований будет коротким, потому что невероятно сложно определить, что такое «бизнес-потребность» с точки зрения игры. Игры существенно отличаются от других программ в этом отношении, и поэтому я бы скромно предположил, что другие способы определения программного обеспечения более актуальны.
Kylotan
Каковы другие способы?
Джонни
2

Анализ требований в большей степени нацелен на корпоративное программное обеспечение с формальными каналами связи и тому подобным, практически ничего не будет существовать для независимого разработчика. Это не очень полезно для игр, потому что многие требования не могут быть формально проверены или проверены. Если у вас есть панель инструментов и вы говорите: «При нажатии на эту кнопку должно появиться меню с XYZ на нем», то вы можете практически ничего не платить, чтобы нажать кнопку и посмотреть, что произойдет. Ваша игра веселая? Это совсем другой чайник рыбы.

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

DeadMG
источник
0

Пропусти это.

В какую область разработки игр вы заинтересованы? Я предполагаю, программист, но ...

Дизайнер: Они много пишут. Много. Обычно существует документ дизайна, который передает видение дизайнера, но для всех остальных, кроме продюсера или издателя, вы обычно получаете информацию от дизайнера.

Программист: Ведущий определяет технические требования, которые будут сильно зависеть от платформы и конвейера активов. Вы узнаете, как это сделать, работая со своим лидером на работе.

Художник: Опять его ведущий художник вместе с ведущим программистом, который обычно устанавливает требования к художественным активам. Учись на работе.

Анализ требований, как и курс, который они, скорее всего, будут преподавать, полезен для крупных корпораций, пытающихся оправдать расходы и аутсорсинг. И это часто делается кем-то, кто когда-то закодировал и, возможно, с тех пор забыл. удар ножом

Если вы планируете заняться независимым бизнесом, возьмите тему бизнеса / бухгалтерского учета / управления. Вам это нужно, чтобы выжить, а не облажаться. Удачи.

bkersten
источник
Я также предположил бы программиста, так как он отметил его программистом;)
Коммунистическая Утка
1
-1 Итак, вы не только пропустили, что человек пометил это для программистов, вы также пропустили, что это было для инди-разработки, что сразу означало бы, что не будет технического лидерства, которому можно учиться. Анализ требований полезен - даже когда не выполняются полные системные спецификации - для обучения правильному мышлению и анализу проблем. Кроме того, письменная практика всегда будет полезна, если возникнет необходимость сделать предложение издателю. Откровенно говоря, ваш совет не затрагивает целевую аудиторию и не дает полезной информации по теме.
ChrisE
-1 Договорились. Достаточно дрянного программного обеспечения, которое не делает то, что нужно людям, и достаточно инди-игр, которые страдают от ужасных дизайнов, которые не решают технические проблемы и превращаются в бесконечные переписывания и неизданные игры. Формальные методы - это формальность, через которую инди-игры могут и не проходить явным образом, но наличие фона действительно приводит к мышлению «остановись и думай», а не к «кодируй и исправляй», что слишком распространено. Кодеров - десятка, но качественное программное обеспечение встречается так редко. Вы делаете математику.
PatrickB
1
Ха ха ха Вся разработка игр, особенно инди, заключается в том, чтобы быть гибким и повторять основную идею. Анализ требований ничего не может предложить и по большей части является тяжелым процессом. Поэтому я обобщил свой ответ. Если они планируют стать инди, имея сеть полу-опытных разработчиков и художников, будет трудно обойтись. Так что либо вы должны быть гением во всех областях разработки игр и бизнеса, либо вы найдете наставников, технических лидеров и т. Д. Постарайтесь не быть такими чувствительными парнями.
bkersten
1
@PatrickB Анализ требований не повлияет на дизайн программного обеспечения. Анализ требований полон бесполезной информации, которую разработчик игр вряд ли когда-либо использует (особенно наглядны диаграммы вариантов использования). Эта тема в значительной степени ориентирована на заинтересованные стороны и, следовательно, на корпоративную среду. Я согласен, что разработчик должен перечислить требования (функции), но это должно быть здравым смыслом. Разработка программного обеспечения - это совершенно отдельная тема, которую анализ требований едва затрагивает (во всяком случае, в университете)
Рэй Дей,