Сценарии, диз-доки, вселенные

В общем и целом хочу обсудить создание сценариев, диз-доков, проработок вселенных - естественно для игр =)
Меня интересуют основные аспекты в общих чертах, а то есть основное содержание того или иного вида работы, порядок изложение материала(обычно он свободный, но хотелось бы знать приветствуемый), на чем надо\стоит акцентировать внимание, слабые места и то что не должно входить...
(это пока только те вопросы которые возникли в момент написания)
не нужно писать что четкого ответа дать никто не может - это я прекрасно понимаю; так же не надо писать что тема бесполезна - она полезна будет по крайне мере для меня; 3-е не маловажное... меньше флуда - больше мозгов !
вроде все...
Ответы пишите с пометками (обсуждение ведется по 3 видам работы)

жду ваших мнений.
__

Последняя правка: пн, 20/06/2011 - 10:01
Submitted by nPocTou on

Комментарии

Пример диздока от 1С.
Поиск от Google.
P.S. Будет троллинг на эту тему - закроем.

Submitted by MaxImuS on
Совета дать не могу, но могу рассказать про собственное видение сути данного вотроса.

Основываясь на банальном DLC (http://ru.wikipedia.org/wiki/Цикл_разработки_программного_обеспечения) изходя из таких параметров как:
  • целевая аудитория
  • тип предложения услуги
  • жанр
  • логистические фишки
    вытекает сам себе диздок.


честно говоря, носителю идеи игры , как главе проекта, нельзя обойтись без эскизов "скриншотов" основных аспектов игры с комментариями. Углубляясь в технические детали для уже существующих жанров игр, проще всего ориентироваться на уже существующие успешные фирмы по разарботке игр, а именно на их подход. Чтобы вы поняли, о чём я говорю, сравните глубину вселенной, стиль геймплея, и качество баланса Daiblo 2 LOD и TES: Oblivion / Morrowind.

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

Основные подводные камни на которые я натыкался:
  1. смена жанра игры из-за неправильно оцененной мощности команды. Мы бы её не потянули при таком финансвом положении. Раскрылся сей камень после применения глубинного подхода ко вселенной, причём это был основой параметр.
  2. подстройка под художников и конфликтация точек зрения. Здесь ясно, что с одной стороны, руководитель, который и выстраивает основы правил игры по собственному лору видит одно, а художник другое. С другой стороны, если художник применяет непсредственное участвие в создании лора, то его работа будет делаться быстрее и качественннее.
  3. большое количесвто внитриигровых переменных. Для синглплеера ограничением идёт лишь производительность проца, а вот для мультиплеера дело обстоит куда сложнее. И этот пукт надо рассматривать ещё на этапе постановки задачи. Скажем, в онлайн-игре большое количесвто внитриигровых переменных чревато экспонециальным ростом усреднённого значения кол-ва запросов к серверу.
  4. моральный дух. Если его не поддерживать, то никакая игра не будет доделана до конца. Примеров просто завалом. Как выход: либо это фильм, близкий по духу, сериал, рисунок, рассказ. Ничем нельзя брезговать. Если не поддерживать моральный дух, то я просто могу дать гарантию, что ХЕР ваша команда когда-нибудь сделает игру. Им мало 1 промывки мозгов при привлечении в проект. Промывка им нужна постоянно.

вот это как бы основное. Статистический баланс лучше всего делать в самом конце. Есть столько Маткад и Матлаб подобных прог, и всяких для математического моделирования, для такого рода анлизов, но и нельзя принебрегать собственной разработкой ПО для баланса, хоть на Basic'e. Но лучше C++ какой, либо такой, который знает большинство из команды.

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

Всё остальное зависит от качеств главы предприятия данного, а именно его предпринимательских способностей, юридической и экономической и в сфере разработки ПО грамотности, а также (при составлении диздока) четко, кратко по возможности, понятно и простым языком доносить все идеи игры до конечного... э-э.. адресата, ну там, художника, кодера оболочки, аниматора и т.д.
Submitted by kodex on

Начни с сеттинга. Дальше уже от него начинаешь писать.

Submitted by Renegade on

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

Submitted by Rebel on
Вот кстати нашел интересное мнение от нашего соотечественника по ГДД:http://dtf.ru/blog/read.php?id=58090

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

Submitted by Rebel on

Как много я уже перечитал споров по поводу диздока... Мнений тьма, все не упомнишь. Соглашаешься с первым попавшимся на глаза (более менее причесанным) и в путь Smile Я вообще стал пофигистом в этой теме - меня не волнует как должен выглядеть диздок, это не моя задача. Молодым командам или одиночкам, только начинающим делать свои игры - не пишите вы эти диздоки (если вы конечно кроме того, как текст в ворде набирать, ничего полезного для своего же проекта сделать не можете (или толкнуть пару идей за пивом)) - пустая трата времени. Пусть этим занимаются большие дядьки с большими планами в карманах. Вы же просто придумайте игру и на недельку вперед набрасывайте план, что вы должны реально сделать. Если делать, как уже упоминалось, больше ничего не умеете - ну, блин, возьмите вы какой-нибудь конструктор игр (где все за два клика делается), натаскайте из тырнета арта (продавать же вы его не будете, чисто для временных внутренних нужд), склепайте прототип (за тех же два клика), посмотрите, похоже ли это приблизительно вообще на то, что вы хотели увидеть в итоге. Вот после этого и начинайте искать себе вольно рабочих в команду - ни один кодер или художник, которого вы соблазните себе в команду, не будет читать тот бред, который вы уместили на 20 и больше страницах - им нужно четкое тз! Вот имея на руках худо-бедно калеченный прототип игры вашей мечты можно начинать состовлять тз для исполнителей (даже можно это делать вместе с ними).

P.S. Виталя, пользуясь случаем, передаю тебе Прывет Hi

Submitted by MaxImuS on

Макс, и тебе привет, жаль, давно не получалось пересечься Meeting

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

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

Если кто-нибудь хочет со мной поспорить, то для начала ознакомьтесь со статьей по ссылке двумя постами выше, там подробно все описывается I here

Submitted by Rebel on
Кроме геймдиза реально никто и не читает до конца, или читают через строчку. Эти 50-200 страниц написаны только для себя, геймдиза. Инвестору нужно показывать очень обрезанный и переделанный вариант.

И вообще, о чем тут спорить? Чисто распальцовка в теме идет, смотрите я знаю как это работает и что это такое Smile

Submitted by DJ_Psych on

GameDev.by