Конкурс для геймдизайнеров "Бумага всё стерпит?!" (этап 1) (8 стр)

Участникам: пример хорошего диздока

Кодзима
> Ваша идея конкурса  "(Геймдизайн + реализация)" неверная в своём основании и априори будет терпеть фиаско ИМХО.
Она очень успешна! Я получил столько фидбэка для своей идеи, сколько не получал нигде и никогда. У меня, можно сказать, произошло смещение точки сборки: я смог увидеть свою идею чужими глазами, смог увидеть её недостатки и слабые стороны. А это дало понимание того, куда мне теперь двигаться и в каком месте прилагать усилия, чтобы сделать диздок лучше!

Sorrownorth
> Скорее тут люди учатся писать диздоки
Ясно, но я думаю, что если учиться писать диздоки подобным образом, то приобретуться неверные навыки. Потому что написание диздока и его реализации это две неотъемлемые части.
Если просто писать диздок без реализации никакого полезного для себя опыта вынести не получится, а получится приобретать одни лишь заблуждения.
Я конечно ни на чём не настаиваю и пишу лишь своё скромное мнение.

Кодзима
> Потому что написание диздока и его реализации это две неотъемлемые части.

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

Я только благодаря литературным конкурсам научился прилично писать. Люди тут и учатся делать игры.

Кодзима
> Получается у вас какое-то местное лобби из программистов.
можно сказать и так. Мне очень понравилась идея: https://gamedev.ru/projects/forum/?id=201751&page=562&m=5854732#m8427 но судя по дальнейшему обсуждению заинтересовавшиеся были но никто кроме меня проводить его не хотел.
А так - да, это не конкурс геймдизайнеров в чистом виде, но это конкурс где могли поучаствовать геймдизайнеры (в широком смысле этого слова).

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

aliskda
> Она очень успешна!
Это всё здорово, я совсем не против конкурса, просто мне показалось, что конкурс не совсем оправдывает своё название с технической точки зрения, то есть это конкурс скорее игровых сценариев нежели диздоков. Потому что, если удалить геймдизайнера на уровне реализации, то это будет не диздок, а скорее сценарий, так как реализовываться будет совсем другим человеком. И этот программист - разработчик взявшийся за реализацию будет лишь вдохновляться диздоком, разрабатывать свою игру по мотивам диздока геймдизайнера.
Вообще диздок нужен лишь для общего ввода в суть игры остальных участников разработки.А как игру реализовать знает лишь геймдизайнер написавший этот диздок.
Просто название конкурса немного спутывает профессии. А конкретно профессию игрового сценариста и геймдизайнера. Я только об этом и хотел сообщить.

kipar
> А так - да, это не конкурс геймдизайнеров в чистом виде, но это конкурс где
> могли поучаствовать геймдизайнеры (в широком смысле этого слова).

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

Кодзима
> Потому что, если удалить геймдизайнера на уровне реализации, то это будет не
> диздок, а скорее сценарий, так как реализовываться будет совсем другим
> человеком.

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

А геймдизайнеры в проект не меняются никогда, а он сам не меняется в процессе разработки и не дополняется.

Sorrownorth
> Создавать механики будет программист,
Создавать механики это работа геймдизайнера. Программист лишь должен писать код (скрипты, ИИ, БД и проч.) по ТЗ геймдизайнера.

Кодзима
> Программист лишь должен писать код (скрипты, ИИ, БД и проч.) по ТЗ
> геймдизайнера.
>
>

Интересно как ты создаешь механики, если просто описываешь их в своем ТЗ.

Sorrownorth
> Интересно как ты создаешь механики, если просто описываешь их в своем ТЗ.
Механики можно описать в диздоке, если это важно для общего понимания игры.
Вообще диздок нужен лишь для того, чтобы все участники разработки игры понимали, что они будут делать и что у них должно получиться на выходе.
Программист, художник, музыкант и прочие участники по диздоку работать не смогут. Они работают по ТЗ. ТЗ создаёт геймдизайнер, который собственно и делает игру, как вроде режиссёра, который снимает фильм.
Для реализации какой-то игровой механики требуются не только программисты, но и другие участники. Допустим, в игре Марио, механику роста(метаморфозы) когда ГГ берёт гриб, одного программиста будет недостаточно, нужен и художник и музыкант. Чтобы сделать соответствующую анимацию и озвучить её.

Кодзима
> Напишу мнение геймдизайнера.
> Ваша идея конкурса  "(Геймдизайн + реализация)" неверная в своём основании и априори будет терпеть фиаско ИМХО.
> Вы берёте и удаляете геймдизайнера в самом начале. Это всё равно если бы вы вызвали специалистов, например сантехника. Сантехник пришёл бы открутил какую-нибудь трубу, а вы бы взяли и выгнали бы его на этом этапе. А потом, когда затопило бы соседей снизу, обвинили сантехника в некомпетентности и даже советовали бы затопленным соседям подавать иск в суд на выгнанного вами сантехника. Что согласитесь как-то нехорошо. Надеюсь выбранные мной художественные образы всем понятны.

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

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

Кодзима
> Вообще диздок нужен лишь для того, чтобы все участники разработки игры
> понимали, что они будут делать и что у них должно получиться на выходе.
Кодзима
> Программист, художник, музыкант и прочие участники по диздоку работать не
> смогут.

Если ты пишешь ГДД так же как выражаешь здесь мысли, то рекомендую задуматься о своей квалификации

Samaritan
> К сожалению вы приводите не верную аналогию и как следствие делаете ошибочные
> выводы.
> Гейм дизайнер это инженер который составил схему труб и указал какую нужно
> заменить.
Если геймдизайнер указал какую трубу нужно заменить, о это уже не диздок, а ТЗ. А ТЗ может даваться только во время разработки игры, а никак не перед разработкой и всем участникам. Зачем, например программисту читать ТЗ для музыканта, он всё равно ничего не понимает в музыке. Поэтому в диздоке пишется в общем и для всех, в диздоке не пишут ТЗ.
Если в диздоке писать ТЗ у участников будет каша в голове, от терминов из чужих профессий.

Sorrownorth
> Если ты пишешь ГДД так же как выражаешь здесь мысли, то рекомендую задуматься о
> своей квалификации
А что собственно не понятно?
Диздок пишут, чтобы всю команду, участвующую в разработке, ввести в понимание, что они собственно будут делать, какую игру создавать. Иначе, если бы ГД сразу бы начал раздавать ТЗ, возникало бы недопонимание между ГД и командой. ГД приходилось бы самому и каждому объяснять, что за игру он задумал. Поэтому проще написать диздок, чем одно и тоже повторять каждому участнику разработки.

Samaritan
> Но лино мне больше нравиться такая аналогия :
> Первый этап конкурса представляет собой задачу, в которой попросили
> спроектировать палатку из нескольких палок и мотка ткани, так что бы ее мог
> собрать даже ребенок.
> А вот какой ребенок справился с палаткой лучше, покажет второй этап конкурса.
> =)
По вашему выходит, что геймдизайнер участвующих в конкурсе, должен был написать диздок и ТЗ для программиста. А остальное брать уже готовое из ассетов.
В этом случает всё равно игру должен был бы собирать ГД.  Получается что ГД, создав диздок и ТЗ передал бы эстафету программисту, который бы на втором этапе взял бы на себя обязанности и программиста и ГД.

Кодзима
> Если геймдизайнер указал какую трубу нужно заменить, о это уже не диздок, а ТЗ. А ТЗ может даваться только во время разработки игры, а никак не перед разработкой и всем участникам. Зачем, например программисту читать ТЗ для музыканта, он всё равно ничего не понимает в музыке. Поэтому в диздоке пишется в общем и для всех, в диздоке не пишут ТЗ.
> Если в диздоке писать ТЗ у участников будет каша в голове, от терминов из чужих профессий.

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

Кодзима
> В этом случает всё равно игру должен был бы собирать ГД.
Из чего это следует? Собирать игру может много кто, смотря что под этим понимать и какая задача стоит.

Кодзима
> Получается что ГД, создав диздок и ТЗ передал бы эстафету программисту, который бы на втором этапе взял бы на себя обязанности и программиста и ГД.
Программист на втором этапе действительно от части берет на себя задачу ГД, и помимо заполнения пробелов он даже может привнести что-то от себя - это прямо прописано в правилах конкурса:
kipar
> 1. Задание. Сделать игры соответствующую выданному документу (описанию игры), улучшив и дополнив его по своему вкусу (ориентируйтесь на критерий оценки (2.1)).

Вторая порция отзывов