Образцы ТЗ для кодера. (2 стр)

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

ну и, на всякий, прочитать -
http://www.gamedev.ru/gamedesign/articles/?id=4277
http://www.dtf.ru/articles/read.php?id=37760

Xunter
Спасибо щас все почитаю

Xunter
> геймдизайнер должен уметь формализованно описывайть геймплей, фичи и т.д.
> про геймдизов способных проводить анализ требований я не слышал.

Рассмотрим две чисто теоретических ситуации. Первая: лид-дизайнер сообщает главному программисту: "Нам нужен поиск пути". Вторая: тот же дизайнер говорит: "Нам Нужен асинхронный поиск пути с учетом карты проходимости и разницы высот, с выдачей принципиальной возможности проходимости не более чем за 50мс и поиском пути между любыми точками трех тестовых карт не более чем за 300мс. Учитываются геометрические размеры объекта и коллизии. Учитывается возможность и радиус поворота юнита".

Внимание, вопрос - в каком из этих двух случаев получится более играбельный результат?

Аксиома о программистах: Программист всегда дизайнит неправильно.

Не перекладывайте свою работу на чужие плечи. Функционально задачу ставит геймдизайнер, а программист ее реализует. И это правильное разделение труда. Помните - программист думает абстракциями - алгоритмами, методами, фишками и пальцАми на RSDN. Задача геймдизайнера - поставить ему функционально четкую, определенную, проверяемую задачу.

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

Я много раз слышал фразу: "Ну откуда я знаю, как программисты сделают? Как сделают, так и будет работать". Как будет - понятно, см. аксиому. Такое заявление - роспись в собственной некомпетентности. Работа геймдизайнера и состоит в том, что он создает образ игры в голове, образ настолько красочный и звучный, что можно почувствовать все взаимосвязи, задачи и тонкости проекта. И сформулировать в диздоке словами все необходимые компоненты этого пока виртуального шедевра.

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

Соль
> "Нам нужен поиск пути"
а в ответ программист спросит, насколько этот поиск пути должен быть крут, отсюда первые ошибки плохого или радости хорошего проектирования (привет Вию)... и тут либо все хорошо, либо рефакторинг...
а если поставить задачу так
> Нам Нужен асинхронный поиск пути с учетом карты проходимости и разницы высот, с
> выдачей принципиальной возможности проходимости не более чем за 50мс и поиском
> пути между любыми точками трех тестовых карт не более чем за 300мс. Учитываются
> геометрические размеры объекта и коллизии. Учитывается возможность и радиус
> поворота юнита
то программист сядет делать даже если это идет в разрез с архитектурой, отсюда говнокод... говнокод на ранних стадиях намного хуже говнокода на поздних (его наличие неизбежно в принципе)...

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

Соль
> Это из тех ссылок которые ты мне дал.
и? это не ТЗ. будет плотный диалог лидов.
еще появятся пункты о принципиальности кратчайшего пути, об опциях типа избегания определенных зон, о том, что делать, когда кратчайшего пути не существует, когда на пути присутствуют динамические препятствия, о том, когда на конечной точке пути находится другой объект и т.д. и т.п.
из этого рождается описание фичи. про то - иерархический там поиск пути и вообще - каким образом он будет реализовываться - геймдиз не знает.
лид программист формирует из этого таски, выдает ТЗ специфические для программистов.
твой пост #2 превратиться в ТЗ на реализацию КА состояний персонажей, на тулзы для редактирования, или вообще(после обсуждения с ПМ-ом) на интеграцию с мидлварем типа http://www.havok.com/index.php?page=havok-behavior

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

Xunter
Спасибо,смысл понятен.
Pushkoff
Да это тоже проблема я в кодинге ничего не смыслю(

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