Требования к игре

Question

Я пишу игру для iPhone и пытаюсь написать некоторые документы с требованиями. Я никогда не писал требований раньше, поэтому получил книгу «Требования к программному обеспечению». Я еще не закончил, но я предвижу некоторые проблемы, поскольку эта книга нацелена на бизнес. Мой главный вопрос - я единственный, кто связан с этой игрой, и я чувствую, что основной целью документа с требованиями должно быть выработать как можно больше концептуальных идей о том, как работает игра, прежде чем я углублюсь в дизайн или конструирование. Есть ли у кого-нибудь предложения о том, как мне это изложить, если я все же попытаюсь подражать шаблону, представленному в книге, где это имеет смысл, или, поскольку я являюсь единственным разработчиком и владельцем продукта, я должен просто придерживаться концепций игры?

Answer 1

Вы правы, что традиционные документы SRS не очень хорошо соответствуют документации по играм. У игр вместо этого есть общий Документ Проекта Игры. Обычно он создается до начала какой-либо работы над игрой, и его часто редактируют по мере того, как процесс разработки направлен на то, чтобы сохранить намеченный конечный результат и особенности игры.

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

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

Бренда Братвейт имеет хорошую запись в блоге на эту тему, которая может оказаться для вас полезной. На эту тему также есть недавняя статья от gamedev.net.

Answer 2

[Бедный Джейкоб, вы только что прочитали книгу по этой теме, и в совокупности SO-сообщество пишет для вас еще одну, наряду с дополнительными ссылками и, возможно, с расходящимися взглядами ;-)]

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

Будучи «командой одного», особенно важно и несколько парадоксально, чтобы вы попытались формализовать требования . Однако вместо того, чтобы уделять слишком много внимания форме , вы можете найти подход Agile к разработке (и, следовательно, к сбору требований) более подходящим. Что касается требований, одним из основных преимуществ этого подхода является гибкость, то есть понимание того, что, хотя они должны быть формализованы (с ограниченным временем / усилием), необходимо разрешить изменение требований (в определенных пределах) в рамках итеративного процесса. на производство целевого продукта.

В общих чертах это обычно происходит следующим образом:

• напишите " пользовательских историй ", это отдельные "карты" (да, физические карты, скажем, 4 дюйма на 5 дюймов, хороши, потому что вы можете затем перемещаться затем сортировать их и т. д.)
• каждая история рассказывает определенную функцию приложения, в данном случае игру, с точки зрения конечного пользователя . Вы можете / должны начать все карточки с «Как пользователь, мне нужна игра, чтобы ...», а затем с определенной функцией, например «... показать мой высокий балл на той же странице, что и глобальные высокие баллы». сохраняется [потому что… здесь необязательные причины, по которым пользователь может захотеть эту функцию].
• просмотрите каждый рассказ и присвойте приблизительную оценку времени , потраченного на его реализацию
• просмотрите каждую историю и присвойте уровень приоритета (масштаб может отличаться, но что-то простое, например, «Должно быть в версии 1.0», «Должно быть, в конце концов, обязательно», «Было бы неплохо иметь "и" может быть, приятно иметь ... ")
• организовать релизы , исходя из того, что вы можете сделать в течение, скажем, максимум 2 или 3 недели. Если определенная функция займет слишком много времени, запланируйте ее на более поздний выпуск.
• реализовать функции, назначенные текущей версии
• итерация в этом цикле выпуска, рассмотрение требований по мере необходимости, для определения относительной важности функций, а также необходимости новых функций, как и в случае с предоставленной информацией с помощью [неполных / несовершенных] промежуточных выпусков.

Answer 3

Вот только общий подход ...

1. Укрепите концепцию ... сначала напишите на простом английском языке (например: игра от первого лица. Вы убиваете зомби и охотитесь за сокровищами.)

2. Возьмите блокнот и карандаш и нарисуйте общий ход игры и основные экраны, с которыми пользователи столкнутся ... главное меню, экран настроек, помощь и т. Д. Убедитесь, что это имеет смысл. *

3. Перейдите на сайт, подобный mockingbird и создайте подробные каркасы для своих экранов ...

4. Распечатайте их и сделайте несколько бумажных прототипов ... т.е. поместите распечатку перед собой и «нажмите» на кнопку ... затем откройте соответствующий экран ... затем нажмите на другую кнопку и т. д.

5. Как только это станет понятным, вы можете попытаться начать кодировать вашу игру.

Answer 4

Книги, подобные той, которую вы описываете, ориентированы на другую аудиторию, но в представленных общих понятиях есть ценность. Полностью разработанные документы с требованиями не так часто встречаются, как вы думаете. Не позволяйте никому думать, что вы «плохой разработчик» из-за отсутствия самых подробных требований.

Документы с требованиями могут быть более важными, если вам необходимо сообщить требования со-разработчику.

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

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

Answer 5

Просто предложение ... Зарегистрируйтесь на Сайтах Google и создайте личный сайт с документацией по игре, требованиями, техническими аспектами, рабочим журналом и т. Д ... Вы можете поделиться им с избранными людьми, и он всегда сохраняет история редактирования.

Мне нравится больше, чем вики, потому что он более структурирован и прост в использовании.

Answer 6

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