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

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 Анализ требований не повлияет на дизайн программного обеспечения. Анализ требований полон бесполезной информации, которую разработчик игр вряд ли когда-либо использует (особенно наглядны диаграммы вариантов использования). Эта тема в значительной степени ориентирована на заинтересованные стороны и, следовательно, на корпоративную среду. Я согласен, что разработчик должен перечислить требования (функции), но это должно быть здравым смыслом. Разработка программного обеспечения - это совершенно отдельная тема, которую анализ требований едва затрагивает (во всяком случае, в университете)

— Рэй Дей,