Как составлять диздок?

[EvilOkta]

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

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

Что по-идее должен включать в себя образцовый диздок, помимо вышеперечисленного? Я выделил еще:
- Блок ИИ
- Система анимаций объектов
- Список объектов и их функций, внешний вид, эскизы
- формулы взаимодействия игровых единиц друг с другом (совместно с блоком ИИ)
- ход игрового процесса.
- и т.д.


Тема свободная, в обсуждении привествуются все. Вэлком!

[DStalk]

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

[moka]

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

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

[SBJoker]

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

Например:
после запуска игры я сразу увидел проявляющийся по центру экрана логотип "НубГеймс", он показывался всего на 3 секунды, но его можно было "скипнуть" кликом мыши или нажатием на любую кнопку. Далее появился логотип игры...."

[EvilOkta]

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

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

[moka]

Сообщение от EvilOkta

moka что ты имеешь ввиду под итерацией в даном контексте?

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

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

Итерация - повторение, пройти снова, пересмотреть.

[EvilOkta]

Сообщение от jimon

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

Это для выработки стиля и атмосферы игры самое то!

moka теперь понял )) от простого к сложному с постоянными добавлениями.

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

Сообщение от EvilOkta

Это для выработки стиля и атмосферы игры самое то!)

это для выработки UX и поиска завтыков

[moka]

Сообщение от EvilOkta

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

Всё равно рисовать. Ты же не научишься если не будешь рисовать.
Если для лично себя - главное идею передать, даже если это убого.

Сообщение от jimon

это для выработки UX и поиска завтыков

В web'е такой подход часто используется.

Симулируются несколько типов пользователей с разной мотивацией и источниками (страницами), и далее их путь достижения целей.
Важно понять какая мотивация у пользователя и намерения, далее адаптировать UI под максимальное удобство достижения этих целей.
UX

[radiobutton]

http://www.helloworld.ru/texts/comp/other/oop/index.htm

[tormoz]

[EvilOkta]

кто-нибудь практикует классификатор скриптов и методов?
Я заметил что чем дальше продвигается разработка, тем сложнее отслеживать связи между объектами, скриптами, методами, событиями, ключевыми свойствами классов.
Думаю завести таблицу с описаниями всего этого добра, типа класификатора, для того чтобы понимать что с чем взаимодействует.
Если что забывается или теряется, то можно заглянуть в классификатор и понять связи.
Кто-нибудь делал что-то подобное? Или поделитесь своими мыслями как прослеживать все это добро при большом количестве скриптов и взаимодействий между ними

[pax]

Я обычно пользуюсь такими командами как Find Usages и Go To Declaration. Поиск зависимостей того или иного мембера решарпер выполняет очень неплохо.

[EvilOkta]

Сообщение от pax

Я обычно пользуюсь такими командами как Find Usages и Go To Declaration. Поиск зависимостей того или иного мембера решарпер выполняет очень неплохо.

они в Monodevelop есть? Или это какие-то надстройки?