***
Вот ведь зайдешь книжку спросить ....
***

Denis Beskov

Денис, благодарю Вас за потраченное время Мне даже стыдно несколько ...
но, верну Вас в свою "аллегорию".

1. Парень колотит свою первую в жизни будку для собаки.
2. Колотит не один, а с группой единомышленников.
3. Часть единомышленников уже взялась за забивание гвоздей и раскрашивание крыши под хохлому.
4. Всё остальное - обмер собаки, чертеж будки, закупка досок и инструмента, установка будки и поселение в ней собаки - парень берет на себя (звезду пока не выписываем, но в виду имеем)
"возникает попендопль."
5. Парень абсолютно справедливо сомневается в том, что осилит всё, что на себя взвалил.
6. Парень приходит и вполне адекватно просит посоветовать - что сделать чтобы уж если облажаться, то по минимуму.
"входят двое"
7. Первый говорит - "Парень, почитай вот этот документ по строительству, там например сказано, что стоит предусмотреть вентиляцию"
8. Второй говорит (не Парню, а Первому) - "А вот нифига, есть поновее документ и там сказано, что вентиляцию нужно не просто сверлить, а под углом с учетом розы ветров и диаметром так чтобы подлый шершень не пролез"
"внимание, правильный вопрос":
Это как-то отменило совет про то, что стоит почитать документ, в котором сказано, что нужна вентиляция в принципе ?


Кирилл Лебедев

Кирилл, обратите внимание на основной момент. У автора (по его словам) первый боевой проект.
ГОСТа на игровые проекты конечно нет, но ... опыта у автора - тоже если и есть, то по минимуму.

И кто сказал, что "игровой" проект у автора - последний ? Может в следующий раз он решит написать тарификатор для таксистов ?

Системные то знания нужно иметь.

Андрей, ещё раз — мобильная игра не является автоматизированной системой. Она является программным обеспечением, программным продуктом со своими существенными особенностями, отличающими её от других категорий программных продуктов.

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

Показатели назначения игры (количество игроков, увлекательность геймплея, доходность с одного участника и т.д.) не достигаются правильным определением состава функций, автоматизирующих деятельность и атрибутов её качества. Успех игры зависит не от правильного функционально-технического проектирования, а в большей степени от устройства «объекта автоматизации» — сценария игровой деятельности, который создаётся практически одновременно с самим приложением.

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

Единственное место, где может быть полезен ГОСТ 34 — при разработке бэкенда для системы, который будет представлять собой полноценную автоматизированную систему. И который опять же не нужен в полноценном объёме, если мы говорим про пилотирование новой игры, а не поддержку линейки игр, продуктового портфеля.

Давайте, в конце концов, посмотрим, что из основного состава ГОСТ 34.602 может хоть в принципе иметь какое-то отношение к мобильной игре:

2.6.1. В подразделе «Требования к системе в целом» указывают:

1. требования к структуре и функционированию системы; — в лучшем случае это геймплей + карта навигации + структура игрового мира. но как именно называние их таким образом поможет — не ясно
2. требования к численности и квалификации персонала системы и режиму его работы; — не применимо, у самой игры персонала нет
3. показатели назначения; — ну да, игра должна затягивать и приносить миллион долларов в месяц. но это не задание для программиста
4. требования к надежности; — хорошо описано в стандартах на софт
5. требования безопасности; — не применимо, если не считать ограничения на использование мельтешаших цветов и недопущение развития нервных расстройств, припадков эпилепсии и депривации сна. но чтобы это правильно сформулировать, нужно знать хоть что-то из эргономики, когнитивной психологии и социологии
6. требования к эргономике и технической эстетике; — даже ISO 9241/9126/25010 практически ничего не говорят о том, как задавать требования к графическому дизайну. я тоже не знаю
7. требования к транспортабельности для подвижных АС; — не применимо
8. требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы; — не применимо
9. требования к защите информации от несанкционированного доступа; — любой продакт с минимальным опытом игры не забудет, что аккаунт должен быть с паролем
10. требования по сохранности информации при авариях; — важный момент для промышленной версии игры
11. требования к защите от влияния внешних воздействий; — не применимо или нужно подходить очень творчески
12. требования к патентной чистоте; — важный момент в ряде случаев
13. требования по стандартизации и унификации; — есть в стандарте на софт
дополнительные требования.

Итого, из 13 основных разделов требований:
5 — не применимы
2 — типовые категории из серии капитана очевидность (да, должны быть функции. да, должен быть пароль)
4 — требуют недюжинного кругозора за рамками программной инженерии чтобы быть использованными
2 — хорошие подсказки

Смотрим дальше,

2.6.2. В подразделе «Требование к функциям (задачам)», выполняемым системой, приводят:

1) по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации;
при создании системы в две или более очереди - перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях;

2) временной регламент реализации каждой функции, задачи (или комплекса задач);
3) требования к качеству реализации каждой функции (задачи или комплекса задач), к форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов;
4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

Как это маппировать на игру? Я не понимаю.

2.6.3. В подразделе «Требования к видам обеспечения» в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другие видам обеспечения системы.

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

Разработчики игры должны следовать руководствам по разработке игр от держателя платформы. Но самостоятельно на низком уровне думать о зарядке/разрядке аккумулятора они не должны.

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

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

Denis Beskov

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

Автору рекомендуем не читать мой бред.

ГОСТ как шаблон для требований гораздо лучше, чем отсутствие всякого шаблона, но при разработке игры он мало поможет. Потому что создание всякой игры начинается с идеи (а лучше - системы идей), которые затем формализовано излагаются в виде концепт-документа. А вот ГОСТа для изложения концепции игры не существует.

ГОСТ 34 - для автоматизированных систем, а игра под определение АС не подходит.

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

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

Не,
Где уж нам уж до аэропортов то с банями. Курилку бы к аэропорту пристроить - и то хлеб.
Остановились на том, что проектируя детский велик, нужно брать ТУ на детский велик, и не в коемь случае не смотреть на ГОСТ на двухколесные средства передвижения очень лохматого года потому что есть другой ГОСТ на двухколесные средства передвижения чуть менее лохматого года, ибо только там про ксеноновые фары сказано.

В целом, резон в этом конечно же есть, я ж согласился. Причем без капли иронии.

Denis Beskov
Денис,
данный постинг написан в хорошем настроении и исключительно в качестве шутки (имеющей по определению долю шутки).
Очень прошу не принимать близко к сердцу

Андрей, ещё раз — мобильная игра не является автоматизированной системой. Она является программным обеспечением, программным продуктом со своими существенными особенностями, отличающими её от других категорий программных продуктов.

Я мало знаком с мобильными играми. Но разве сейчас не популярно мериться достижениями в них с приятелями? Или покупать какие-то внутриигровые ништяки за реальные деньги?

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

Вся смысловая риторика автоматизации как процесса замены участков человеческой деятельности автоматизированными и автоматическими функциями...

Применима. В данном случае имеет место замена экзистенциально досуга ("во поле березу заломати") досугом автоматизированным, виртуальным.

...с сокращением затрат (времени, усилий и/или стоимости) совершенно не применима к игре.

Сокращения затрат, к примеру, это совершенно необязательный атрибут автоматизации. Вместо него может фигурировать существенное увеличение обрабатываемых объемов данных, и/или же получение каких-то принципиально новых возможностей. Порой по принципу "мы за ценой не постоим".

Что касается применимости перечисленного к игре, склонен не согласиться. Виртуальное катание в танке обойдется дешевле, быстрее и легче, чем реальное.

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

А это никак к сути автоматизации не относится. Это уже ближе к маркетингу.

Единственное место, где может быть полезен ГОСТ 34 — при разработке бэкенда для системы, который будет представлять собой полноценную автоматизированную систему.

Именно. Если наша игра не имеет "бэкэнда" и является лишь загружаемым автономным приложением, тогда да - использовать 34 ГОСТ там полезно разве что тем, кто к нему привык. Насиловать непричастных не стоит. Но много ли сейчас таких (за исключением инди-энтузиастов)? Сомневаюсь. Все хотят копеечку.

Давайте, в конце концов, посмотрим, что из основного состава ГОСТ 34.602 может хоть в принципе иметь какое-то отношение к мобильной игре:

Давайте.

2.6.1. В подразделе «Требования к системе в целом» указывают:
1. требования к структуре и функционированию системы; — в лучшем случае это геймплей + карта навигации + структура игрового мира. но как именно называние их таким образом поможет — не ясно

Или же:
1. Подсистема управления навыками персонажа
2. Подсистема навигации на глобальной карте
3. Подсистема внебоевого перемещения на локальной карте
4. Подсистема боестолкновения
5. Подсистема НСИ (характеристики видов вооружения, брони, моделей техники и т.п.)
6. Подсистема расчета урона

И взаимосвязи этих подсистем - что и зачем передается из одной в другую.

2. требования к численности и квалификации персонала системы и режиму его работы; — не применимо, у самой игры персонала нет

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

3. показатели назначения; — ну да, игра должна затягивать и приносить миллион долларов в месяц. но это не задание для программиста

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

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

Это про бэкэнд. Чтобы инженера током не ударило, сервером не зашибло, в кондиционер не затянуло.

6. требования к эргономике и технической эстетике; — даже ISO 9241/9126/25010 практически ничего не говорят о том, как задавать требования к графическому дизайну. я тоже не знаю

А вот сюда уже про эпилепсию игроков. Как именно про нее писать - разумеется, ГОСТ 34 не указ.
И много про эргономику бэкэнда. У нас же вроде и по юзабилити недавно какой-то переводной ГОСТ вышел. Им можно воспользоваться, при желании.

7. требования к транспортабельности для подвижных АС; — не применимо

Да. Пункт достаточно редко используется. Не так уж часто встречаются мобильные АС . По крайней мере, в мирной сфере.

8. требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы; — не применимо

Бэкэнд в полный рост.

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

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

11. требования к защите от влияния внешних воздействий; — не применимо или нужно подходить очень творчески

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

13. требования по стандартизации и унификации; — есть в стандарте на софт

Да, можно взять оттуда, дабы не изобретать велосипед.

Смотрим дальше,
Как это маппировать на игру? Я не понимаю.

Например, функции:
1. Управления инвентарем персонажа
2. Вооружения персональным оружием (например, взятие наизготовку штурмовой винтовки)
3. Вооружения тяжелым оружием (за зенитное орудие усесться, например)
и т.п.
Там будет и качество, и время выполнения, и одновременность выполнения (нельзя одновременно приготовиться использовать АК47 и зенитку). В "перечень и критерии отказов" можно поместить возможные варианты недопустимого с точки зрения игровой механики поведения игрока и реакцию АС на него. Например, сообщение "Зачем ты схватился за АК внутри танка?" - и отказ функции "вооружение персональным оружием".

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

Смотря что мы называем "игрой". В том контексте, в котором я писал выше (с бэкэндом) - всё будет.

Не совсем понятно, что подразумевалось под "раскрываются в геймплее" например, по отношению к математическому обеспечению. На примере алгоритмов расчета урона при попадании различными видами боеприпасов в различные игровые объекты. Алгоритмы в ТЗ могут быть достаточно сложные (или наоборот), а до игрока в геймплее или мануалах может доводиться их аппроксимация в тех форме и объеме, которые задуманы игровым дизайнером для того, чтобы игрокам было интересно.

Алгоритмы в ТЗ могут быть достаточно сложные (или наоборот), а до игрока в геймплее или мануалах может доводиться их аппроксимация в тех форме и объеме, которые задуманы игровым дизайнером для того, чтобы игрокам было интересно.

При разработке игры ТЗ (в том понимании, в котором оно есть в ГОСТ) не пишется. А пишутся: CDD (Concept Design Document) -> GDD (Game Design Document) -> TDD (Technical Design Document). Алгоритмы никогда не пишутся в CDD и GDD - вместо этого геймдизайнер может описать конкретные ситуации, на примере которых видно, как должна себя вести игра в целом или конкретный ИИ. Т.е. описываются характерные ситуации. Алгоритмы могут быть описаны в TDD, но и то - вряд ли детально. По большей части, TDD служит в качестве перечня технических задач с указанием их оценки.

При разработке игры ТЗ (в том понимании, в котором оно есть в ГОСТ) не пишется. А пишутся...

Не понял, что Вы хотели сказать. Что разработку игры можно сопровождать разным набором документов (например, перечисленных), в зависимости от личных/отраслевых привязанностей и предпочтений? Даже не сомневаюсь.

Не понял, что Вы хотели сказать. Что разработку игры можно сопровождать разным набором документов (например, перечисленных), в зависимости от личных/отраслевых привязанностей и предпочтений? Даже не сомневаюсь.

Личные привязанности я бы здесь исключил. Более правильно, на мой взгляд, использовать словосочетание "отраслевые стандарты". Но дело не только в названии, но и в содержании документов, в их авторах (а они - разные) и тем, кому эти документы адресованы.