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

Question

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

Answer 1

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

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

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

Brenda Brathwaite имеет хорошее blog entry по этому вопросу, которое может оказаться полезным. Существует полу-недавний article от gamedev.net по этому вопросу.

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

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

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

Answer 6

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

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

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

В очень широком смысле, это как правило, в следующей последовательности:

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