(Текст записи скрыт. Показать...)
Gamedesign
(Текст записи скрыт. Показать...) Как ни смешно, зачастую заключается втом, что он является человеком игрющим, а те, кто работают по его дизайн-документу довольно-таки часто являются не играющими людьми. В чем проблема, спросите вы? Поясню - человек, описывающий для художникак комнату никогда не напишет: "а в корзине лежат КРАСНЫЕ помидоры", ибо все знаю что такое помидоры. А вот если человек не видел этих помидор, то на выходе в корзине будет лежать что-то непотребное не только по цвету, но и по виду. Вот так и с гейм-дизайнером - для него многие вещи настолько очевидны, что ему даже в голову не может прийти их описывать, а потом хватается за голову, когда от другой части команды начинают приходить фидбэки и просьбы "разьяснить"... или еще лучше - приходить что-то сделаное так, как представились эти самые помидоры...
Да, программеры хотят чтобы им так всё расписали, чтоб можно было всё одним спинным мозгом, на автоматизме всё делать, без всякого напряжения ума. Выход один: делать такие инструменты, высокоуровневые редакторы, чтобы дизайнер сам всё делал.
Просто даже в подготовке т.н. программистов есть два направления: собственно, кодер и так называемый "постановщик задач". Первому выдаётся готовый алгоритм - и он его воплощает в код нужного языка, учитывая нюансы языка, операционной системы, "железа" и прочего. Второй - это тот, кто из туманных "ну, надо чтоб было то и это, но не было вон того" формулирует конкретные алгоритмы и условия для первого. Второму знать конкретный язык програмирования вообще необязательно.
В норме, программист не должен совмещать оба направления при работе над проектом. Если находится готовый и, что самое главное, умеющий хорошо совместить - считайте, вам несказанно повезло. А вообще - либо вы выполняете работу второго сами, либо нанимаете дополнительного сотрудника, который и будет заниматься составлением алгоритмов.
Это не то что бы совсем правда. Скорее совсем не.
Определенные перекосы - они есть конечно. Но вот что бы так в явном виде - дичь какая... ИМХО, вы банально путаете специализацию. Да и поинт Артема - он в другом.
Елена Ткач
27.02.2008 15:39
Денис Подлужный
01.03.2008 05:07
Не надо алгоритмов, не обязательно их. Дайте хотя бы вменяемые use-cases.
Елена Ткач
27.02.2008 15:44
Артем Романко
27.02.2008 16:25
Sergey Zhulin
27.02.2008 16:51
Елена Ткач
27.02.2008 17:34
В ветке ещё 8
сообщений
Ренат Хамзин wrote:
> > Да, программеры хотят чтобы им так всё расписали, чтоб можно > было всё одним спинным мозгом, на автоматизме всё делать, без > всякого напряжения ума. Выход один: делать такие инструменты, > высокоуровневые редакторы, чтобы дизайнер сам всё делал. Программеры хотят, чтобы им все так расписали, чтобы им не приходилось выполнять работу ещё и геймдизайнера - своей хватает выше крыши. Тулсет проблемы не решает(хотя полезен).
> Да, программеры хотят чтобы им так всё расписали, чтоб можно было всё одним спинным мозгом, на автоматизме всё делать, без всякого напряжения ума. Выход один: делать такие инструменты, высокоуровневые редакторы, чтобы дизайнер сам всё делал.
А можно и не работать с такими программерами. Потому что не все программеры одинаково полезны. Сферический он, конечно, хочет все на уровне машинистки офиса №3 делать. Но есть вменяемые, которые и картинку не гнушаются нарисовать. И скриптик зафигачить. И это (скажу страшное) ПРАВИЛЬНО! Смотрю на последние продвинутые casual-игры. Такие вещи нереально делать только дизайнеру (всё упрется в него и затянется на неприемлемые сроки). Нужна команда где художник понимает почему рисовать надо сразу же сочетая с фоном который будет в игре, а программер не ленится три раза запустить игру чтобы настроить правильный и адекватный вывод очков после уровня. А не "цифра выводится тестовым шрифтом и хорошо, а настроит кто-нибудь потом". В общем я убежден, что игры делать это как играть в рок-банде. Если барабанщик барабанит только как ему на бумажке напишут, а гитарист играет блюз, когда солист орет гроулингом, то нифига не выйдет. Работать надо. Осознанно прилагать усилия в одну сторону. Всем. =]
Антон Михайлов wrote:
> > В общем я убежден, что игры делать это как играть в рок-банде. > Если барабанщик барабанит только как ему на бумажке напишут Живо вспоминается кинофильм "Мы из джаза" и в особенности эпизод про "импровизацию" на саксофоне. :-)))
Помидоры вполне могут быть и желтого цвета. А еще можно насобирать в корзинку зелененьких, еще невызревших плодов и тож пустить их в засолку.
Максим Вахитов wrote:
> > Помидоры вполне могут быть и желтого цвета. А еще можно > насобирать в корзинку зелененьких, еще невызревших плодов и тож > пустить их в засолку. могут. но вы только что подтвердили написанное мной. Ибо если я напишу "в корзине лежали желтые помидоры" то это будет именно уточнением. А у нас зачастую (в игровой индустрии), у многих нет именно значений по умолчанию - т.е. люди не знают что такое помидоры.
Онли ИМХО: Расхождение результата с описанием КРАСНЫХ помидоров прямо пропорционально удаленности геймдизайнера от остальной команды.
Просто каждый в команде должен видеть результат общего дела и не отстраняться от общего поректа в своем личном ТЗ.
Надо заставлять всех играть в игры. принудительно. не обращая внимания на стоны и крики. :)
Вообще, имхо, если человек работает в девелопменте и НЕ играет в игры - это плохо. ибо не на что оглянуться при разработке той или иной фичи, кроме тз и воображения. а с тз и воображением могут быть проблемы. как в примере с помидорами. Лично мне не хочется писать в ТЗ, что мол: помидор - это сферический овошь, слегка приплюснутый сверху, с гладкой кожицей, обычно красного цвета, но может быть желтым и зеленым в зависимости от стадии спелости, размеры спелого помидора бывают разные но обычно не больше кулака среднестатистического человека и не меньше вишни. Я лучше напишу: гугл "помидор" -> Картинки.
> Надо заставлять всех играть в игры. принудительно. не обращая
> внимания на стоны и крики. :) > > Вообще, имхо, если человек работает в девелопменте и НЕ играет в > игры - это плохо. +1. Если человек пишет то, что использует сам всегда будет выше качеством. В этом смысле очень удобно, когда пишешь например инструмент для разработчика, как делается например в моей бывшей компании JetBrains, там пишут Идею с помощью самой Идеи. Вот, и всегда гораздо тяжелее писать то, чем не пользуешься, например я очень люблю играть в ролевики в морги разные и тактико-стратегические игрушки и вовсе не играю в казуальные, но приходится сейчас писать казуальные вещи, так вот маято это, трудно писать то, чем не пользуешься. На продумывание геймплея уходит в разы больше врермени...
*пожимает плечами* Согласен, такая проблема существует. Но в этом как раз и есть профессионализм геймдиза. Не только придумать, но и описать так, чтобы было понятно и человеку далекому от индустрии. Да, приходится в среднем на треть больше времени на документацию тратить - но это неизбежное зло :). И опыт работы со специалистами (в частности, с программистами), которые не работали на игровых проектах очень ценен. Да, больше тратится времени и нервов. Но зато после это ты можешь объяснить что угодно и кому угодно :).
Артем Романко wrote:
> Вот так и с гейм-дизайнером - для него многие вещи настолько > очевидны, что ему даже в голову не может прийти их описывать Согласен, есть такая проблема. Хотя, следует отметить, встречается не только у гейм-дизайнеров. В общем случае - чем менее профессионален работник, тем хуже он формулирует задачу или специфическую концепцию. По понятным причинам у гейм-дизайнеров это более всего заметно. Вообще, признаки профессионала довольно метко описаны здесь: http://www.umopit.ru/texts/professional.htm
На самом деле, программист в любом случае при выдаче яичницы вместо помидора покажет свою непрофессиональность.
Это следует из признака профессионала. А именно из: "Не начинает дела без полного согласования с заказчиком всех нюансов ожидаемого результата."
> "Не начинает дела без полного согласования с заказчиком всех
> нюансов ожидаемого результата." ну полного согласования может и не быть. Потому что после первой же итерации ТЗ может быть изменено. Мы, например, стараемся просто писать так, чтобы любые изменения в диздоке, не требовали больших изменений. А сколько бы ни было попыток все устаканить на весь цикл производства ничего не вышло. По этой причине используем короткие итерации длиной не более недели, а лучше 2-3 дня. Типа XP.
отвечу сразу всем:
Дело не в том, что геймдизайнеру приходится тратить лишнее время на составление документации, чтобы аниматоры не делали зомби легкоатлетом, магия сопровождалась спецэфектами и т.д. а в том, что в индустрии царит тотальная безграмотность игровая. Зачастую люди, причем сидящие уже не на первом игровом проекте не знают элементарных вещей, которые уже давно являются стандартом де-факто в играх. А потратить свое время - легко. Только почему-то гейм-дизайнеров заставляют тратить время, чтобы уточнять, что "помидор это овощь такой-то формы, имеющий такие-то и такие-то цвета, в заивисмости от своей спелости, а спелость, в свою очередь, можно охарактеризовать как время, которое происходит после того как из цветка появляется овощь и начинает расти", а всех остальных фиг допросишся. Признайтесь многие ли из програмистов, работающих на своем движке могут предоставить гейм-дизайнеру ВСЮ хелповую информацию по движку и его спецификациям, скриптам, возможностям, нюансам?
и я всем отвечу:
"Не надо алгоритмов, не обязательно их. Дайте хотя бы вменяемые use-cases." Более того, "алгоритм от геймдизайнера" - запретить, ибо это не более чем заблуждение геймдизайнера о программе. "Первому выдаётся готовый алгоритм - и он его воплощает в код нужного языка" Далеко от реальности. У меня во всяком случае если бы был чистый кодер для набора алгоритмов - он бы сидел без работы, бо чистых алгоритмов в проекте ничтожно мало, и большую их часть можно за 15 мин найти в гугле. И если этот кодер через 5 минут задает "архитектурные" вопросы типа как назвать функцию и это считается нормально - тогда "кодер" это просто матерное слово какое-то. "многие ли из програмистов, работающих на своем движке могут предоставить гейм-дизайнеру ВСЮ хелповую информацию по движку" А что с этим реально есть какая-то проблема? не надо на программистов сваливать :) Я знаю 2 проблемы: 1) перегрузка программиста который мог бы написать документацию. 2) а во многих ли командах есть отдел (хоть 1 человек) ответственный за внедрение документации? Чтобы проверял что фактические техпроцессы соответствуют технологии, что любая операция делается только оптимальным образом, т.е. каждый конечный текстурщик правильно работает с документацией?
специально еще раз поясняю.
если в диздоке написано: в игре будут помидоры. То очень странно получать вопросы: а что такое помидоры, какого они цвета и формы. Или вам надо приводить примеры из гейм-дева, аналогии никто не может провести? Как я вижу по этому треду, проблема гораздо глубже, чем мне даже казалось вначале.
Хм... допустим, в диздоке написано "помидоры"... И таки исполнитель, помятуя о летних каникулах на деревне у бабушки, лепит эдакие багровые овощи размером с голову младенца. Увидев сие, геймдизайнер обалдевает с вопросом "ты где видел таких мутантов?". Исполнитель точно излагает где видел. И даже приводит фото с этими помидорами в доказательство. Хотя изначально дизайнер вообще имелл в виду томаты-чери, ибо речь идёт о пасте карбонара к примеру... (я надеюсь не слишком метафоричен?)...
Вот и получается что проблема куда глубже, чем неиграющий исполнитель.
Артем Романко wrote:
> Как я вижу по этому треду, проблема гораздо глубже, чем мне даже > казалось вначале. Да, по треду видно, что основная проблема геймдизайнера - не в помидорах.
> Да, по треду видно, что основная проблема геймдизайнера - не в
> помидорах. ага, где-то между помидорами :)
Петр Прохоренко wrote:
> Да, по треду видно, что основная проблема геймдизайнера - не в > помидорах. согласен. проблема в тех людях, которые на фразу в диздоке: "у нас в игре будут орки" будут заставлять давать художникам точное описание орков, на фразу "город выполнен в готическом стиле" заставлять его описывать готический стиль, на фразу "на карте присутствует туман войны" писать что такое туман войны, и какого он цвета, на задачу аниматорам "сделать анимацию зомби (список анимация прилагается)" писать: "зомби, мля. не легко атлеты, не надо брать клипы от главного героя и присобачивать их к полуразложившемуся трупу" но, как видно из треда, всех такая ситуация устраивает. и не надо говорить что "у нас такого нет" я очень много общался лично с разработчиками из самых разных студий.
Петр Прохоренко
27.02.2008 18:14
Артем Романко
27.02.2008 18:18
Kirill Yudintsev
27.02.2008 19:51
Peter Porai-Koshits
28.02.2008 01:59
Peter Porai-Koshits
28.02.2008 01:54
Петр Прохоренко
28.02.2008 14:13
В ветке ещё 1
сообщение
Kirill Yudintsev
27.02.2008 19:48
Артем Романко
27.02.2008 20:30
Андрей Плахов
27.02.2008 21:49
В ветке ещё 27
сообщений
Елена Ткач
27.02.2008 22:01
Kirill Yudintsev
28.02.2008 00:35
Peter Porai-Koshits
28.02.2008 01:39
Dmitry Voronov
28.02.2008 05:59
Петр Прохоренко wrote:
> > Артем Романко wrote: > > > Как я вижу по этому треду, проблема гораздо глубже, чем мне > даже > > казалось вначале. > > Да, по треду видно, что основная проблема геймдизайнера - не в > помидорах. +1
Неизмеримо глубже.
Артем, для начала, Вам стоит научиться четко формулировать свои мысли. Тогда окружающие смогут сразу понять, что именно Вы желаете сообщить и десяток дополнительных пояснений не потребуется.
:)) А есть еще предложение (используется у нас):
1) Описать в ГДД все нюансы игры - врят ли получится. Хотя бы потому, что объем для разовой работы - очень большой. У ГДД цель другая. И масштаб. 2) Писать спецификации на фичи - занятие очень полезное. Прежде, чем фичу делать - взять отвественных за нее, и пусть они все _подробно_ обсудят. И, желательно, задокументируют. А то часто бывает, что ГД видит по-одному, художник - по другому, а программист - хочет, как сделать легче. Заодно, получаем еще и бесплатные test-cases для тестировщиков. Только делать это надо перед реализацией, а не во время написания ГДД. Кстати, про готический стиль, красные помидоры и т.п.: концепт- и production- скетчи еще никто не отменял :)
Ilya Pshenichniy wrote:
> 2) Писать спецификации на фичи - занятие очень полезное. Прежде, > чем фичу делать - взять отвественных за нее, и пусть они все > _подробно_ обсудят. И, желательно, задокументируют. А то часто > бывает, что ГД видит по-одному, художник - по другому, а > программист - хочет, как сделать легче. Заодно, получаем еще и > бесплатные test-cases для тестировщиков. Только делать это надо > перед реализацией, а не во время написания ГДД. А вы не сталкивались с ситуацией, когда на момент обсуждения проекта уже требуют полный ГДД? Я сталкивался, слава богу хоть в этом направлении пошли хорошие подвижки.
Ilya Pshenichniy
27.02.2008 22:15
Петр Прохоренко
28.02.2008 14:51
Ilya Pshenichniy
28.02.2008 21:38
Артем Романко wrote:
> > если в диздоке написано: в игре будут помидоры. То очень странно > получать вопросы: а что такое помидоры, какого они цвета и формы. > Или вам надо приводить примеры из гейм-дева, аналогии никто не > может провести? Вот пример из жизни : В диздоке написано: "В игре будут танки". Ну кто ж танков-то не видел - гусеницы, башня, пушка. Более того, есть уже несколько танчиков, которые отвечают представлениям большинства об этих самых танчиках. Но в процессе разработки оказывается, что вот есть танчик, у которого пушка не может стрелять прямо вперед, она слегка вбок стрелять может, танчик вообще по ходу своего движения стрелять не может. А вот есть еще танчик, у которого башня сзади стоит и вперед не поворачивается, и стрелять он может только назад. И тут хоть играй в игры, хоть не играй, но такие вот помидоры не предусмотришь.
Алексей Приходько wrote:
> > Вот пример из жизни : > > В диздоке написано: "В игре будут танки". Ну кто ж танков-то не > видел - гусеницы, башня, пушка. Более того, есть уже несколько > танчиков, которые отвечают представлениям большинства об этих > самых танчиках. Но в процессе разработки оказывается, что вот > есть танчик, у которого пушка не может стрелять прямо вперед, она > слегка вбок стрелять может, танчик вообще по ходу своего движения > стрелять не может. А вот есть еще танчик, у которого башня сзади > стоит и вперед не поворачивается, и стрелять он может только > назад. И тут хоть играй в игры, хоть не играй, но такие вот > помидоры не предусмотришь. ладно, раз вы не понимаете утрирований: в диздоке написано: "в игре будут присутствовать танки: T34-85, Pz IV, Mouse". И если человек после этого просит обьяснить что такое танк, это будет как нормально? или - управление юнитами происходит стандартными для РТС средствами: кликание по юниту, обведение юнитов рамкой, запоминание выделеных юнитов на hotkey и потом возвращение к ним, путем нажатия hotkey-а" вам задают вопрос - а рамка, которой выделяются юниты должна быть видимой для игрока?
Kirill Yudintsev
27.02.2008 19:57
Артем Романко
27.02.2008 20:36
Kirill Yudintsev
28.02.2008 00:36
Акжол Абдулин
27.02.2008 20:06
Максим Кирьянов
27.02.2008 20:57
Алексей Приходько
27.02.2008 22:03
> В чем проблема, спросите вы?
> Поясню - человек, описывающий для художникак комнату никогда не > напишет: "а в корзине лежат КРАСНЫЕ помидоры", ибо все знаю что > такое помидоры. А вот если человек не видел этих помидор, то на > выходе в корзине будет лежать что-то непотребное не только по > цвету, но и по виду. Проблема в том, что помидоры (и это знают и видели все!) Очень часто бывают: a) Зеленые, для дозревания б) Ярко-желтые помидоры (опять же, видел каждый) в) Красные помидоры г) Оранжевые помидоры Бывают даже зеленые помидоры с красным боком =) Я понимаю, что помидоры были приведены для аналогии. Но! Этот контр-пример показывает, что даже с помидорами элементарно попадаем впросак. Что уж тут говорить обо всем остальном? Профессионала своего дела отличает забота о мелочах. Прописать геймдизайнеру одно прилагательное не должно быть сложно. личное субъективное: Гейм-дизайнером должен становиться только тот человек, который сам хоть раз пытался создать свою игру. Сам. А не просто с бухты-барахты, откуда-то пришел и давай создавать игровые продукты потому что он мнит себя дизайнером. да еще гейм. =) Вот тогда ему в полной мере раскроется ценность детальных описаний и любовь к мелочам.
Алексей "Alex Raider" Астафьев wrote:
> > > В чем проблема, спросите вы? > > > Поясню - человек, описывающий для художникак комнату никогда не > > > напишет: "а в корзине лежат КРАСНЫЕ помидоры", ибо все знаю что > > такое помидоры. А вот если человек не видел этих помидор, то на > > выходе в корзине будет лежать что-то непотребное не только по > > цвету, но и по виду. > Проблема в том, что помидоры (и это знают и видели все!) У меня в примере написано: "А если человек не видел этих помидор?" Более того, как бы вы не умничали с тем, как выглядят помидоры, однако попроси любого человека, описать помидор, и он его опишет красным - это первое, что приходит на ум, ибо является т.н. "стандартом". и вот этих стандартов многие не знают. более того, не знают вообще а что за офощь такой - помидор.
Любят же гейм-дизайнеры писать о:
1. Никто не любит и не ценит ГД 2. Никто не понимает гениальных замыслов ГД Меж тем насчет анимаций зомби: http://bash.org.ru/quote/394670 >обсуждения фильма Я легенда с Уиллом Смитом > >LuckyBaks: И зомби... неправдоподобно быстрые >Caterpillar: Я дико извиняюсь... А какие они на самом деле? Почему команда должна мыслить теми же стереотипами, что и ГД? Почему ГД должен мыслить стереотипами? Почему ГД должен экономить время на том, чтобы у команды было общее виденье проекта?
Ярослав Кравцов wrote:
> > Любят же гейм-дизайнеры писать о: > > 1. Никто не любит и не ценит ГД > 2. Никто не понимает гениальных замыслов ГД > Я тут такого не писал. Если это ваши выводы, так и пишите: "после прочтения сего, у меня возникло впечатление..." > > >LuckyBaks: И зомби... неправдоподобно быстрые > >Caterpillar: Я дико извиняюсь... А какие они на самом деле? Вам смешно? А вообще-то не очень. Ибо до этого фильма существовал стереотип. И люди действительно интересуются почему в этом фильме зомби отличаются от стереотипа. > Почему команда должна мыслить теми же стереотипами, что и ГД? > Почему ГД должен мыслить стереотипами? Почему ГД должен экономить > время на том, чтобы у команды было общее виденье проекта? Извините, но, есть вещи которые известны всем, кто в теме. Как уже правильно замечено выше: "если не написано, что помидор синий, квадратный и летает", то он должен быть круглым и красным. И еще у вас совершенно неправильно понимание ситуации - речь идет не о "гениальных" идеях гейм-дизайнера, а об очевидных вещах, потяных каждому игроку, и каждому отслеживающему игровые проекты.
Артем Романко wrote:
> > Извините, но, есть вещи которые известны всем, кто в теме. Как > уже правильно замечено выше: "если не написано, что помидор > синий, квадратный и летает", то он должен быть круглым и красным. Ну вот хорошо, мой стереотип танка - железная хрень с двумя гусеницами и башней с пушкой. Танк может разворачиваться на месте, башня может вращаться на 360 градусов, пушка может подниматься и стрелять. Я тебя удивлю (ничего, что я на ты ?), но для 90% людей танк "твердо ассоциируется именно с этими элементами". В дд не написано обратное, поэтому считаем, что он "круглый и красный". К чему это приводит, я написал выше. Или вот другой пример - в дд написано "в игре есть самолеты, в игре есть бомбы". Ну самолеты понятно, бомбы понятно. В дд даже написано что бомбы могут подвешиваться к крыльям, к фюзеляжу или висеть в бомболюке. Но в процессе реализации выясняется, что есть такая бомба, которая сама является самолетом и подвешивается к другим самолетам. И она даже упоминается в списке бомб и управляемых ракет (да, управляемые ракеты учтены и работают) под именем "Ohka" (да, 90% людей не знают, что такое "Ohka", хотя и слыхали слово "камикадзе"). Рушится стереотип и вместе с этим добавляются хаки в код, которые в свою очередь плодят баги.
Артем Романко
27.02.2008 22:22
Алексей Приходько
27.02.2008 23:16
Артем Романко
27.02.2008 23:28
В ветке ещё 4
сообщения
Ярослав Кравцов wrote:
> > Любят же гейм-дизайнеры писать о: > 1. Никто не любит и не ценит ГД > 2. Никто не понимает гениальных замыслов ГД > Ярик, не передергивай. Речь не про гениальные замыслы, не про то что бы с дизайнеров сняли часть работы. Речь идет о том о чем когда то "кричал" Дима Бурковский. тут - http://dtf.ru/blog/read.php?id=48741
Максим Кирьянов wrote:
> Ярик, не передергивай. Речь не про гениальные замыслы, не про то > что бы с дизайнеров сняли часть работы. Речь идет о том о чем > когда то "кричал" Дима Бурковский. > тут - http://dtf.ru/blog/read.php?id=48741 Кстати да, об этом и был спичь. Как-то эту тему я пропустил - не заходил на dtf долго. Да, если у кого-то возникло впечатление, что тема была создана "для пантоваться" или "для срача", то спешу вас уверить, что я вообще был уверен, что она будет обделена вниманием, ибо общаясь с различными гейм-дизайнерами, продюсераами, руководителями компаний считал, что проблема хорошо известна, и пост был по сути просто завершающим этапом нашего с ними обсуждения, шедшего не один день... Жаль, что некоторые люди не видят проблемы там, где, ИМХО, она есть. ИМХО в этом и состоит кризис индустрии (в этой проблеме), как написал Дима Бурковский до меня. За сим прошу извинить меня тех, кого я ненороком обидел своими высказываниями - честное слово не хотел.
Kirill Yudintsev
28.02.2008 00:46
Максим Кирьянов wrote:
> > Ярослав Кравцов wrote: > > > > Любят же гейм-дизайнеры писать о: > > 1. Никто не любит и не ценит ГД > > 2. Никто не понимает гениальных замыслов ГД > > > Ярик, не передергивай. Речь не про гениальные замыслы, не про то > что бы с дизайнеров сняли часть работы. Речь идет о том о чем > когда то "кричал" Дима Бурковский. > тут - http://dtf.ru/blog/read.php?id=48741 В любом случае это пост о том, что геймдизайнера не понимают, т.е. #2 :о) А вообще я так и не увидел ни одного реального рабочего примера, показывающего как плохо делать игры не разбираясь в них. При этом в индустрии полно примеров, когда под "подразумеваемым" понимаются разные вещи, что приводит в результате к переделкам.
Максим Кирьянов
27.02.2008 22:30
Ярослав Кравцов
28.02.2008 14:08
Короче, действительно, тред неожиданным образом выявил основную проблему гейм-дизайнера, да.
Прочитал все посты вроде бы. Знакомая ситуация.
Однако все считаю что в ГДД есть смысл писать что-то более подробно. Это как в MMORPG одно из правил, "все что может быть использовано неправильно, будет именно так и использовано". Так и ГДД все что может быть не правильно понято, будет понято не правильно. Поэтому когда ГДД пишется, лучше сразу прикинуть, если точно уверен, что хотя бы 1 человек может понять написанное по своему и отличному от видения дизайнера, то лучше потратить абзац текста и написать более подробно. Конечно это не призыв доходить до маразма аля описания цвета огурца. Вот кстати пример с готическим стилем, ну да есть там ранний поздний и все такое, но помоему это вопрос явно не ферст ГДД. Взять тот же God of War там концептов и моделей персонажей ГГ было больше 10 штук. Но вот я не уверен что прямо всех 10 вариантов в ГДД были описаны. Есть вещи которые не могут быть описаны сразу и они проявляются в ходе совместной работы Лид-Артиста и Лид-Диза. В поднятом вопросе, есть другая сторона связанная с непосредственной разработкой, порой достают вопросы которые по идее должен знать человек делающий игру заданного жанра. Это вот как Артем привел пример с незнанием что такое мана и заклинание людей делающих фэнтези PRG. Времени тратится уйма на это вот все разжевывание.
а это уже вопрос организации процесса.
программисты ведь не с потолка берутся. либо команда набирается под конкретную игру, либо игра делается устоявшейся командой. для первого случая имеет смысл интересоваться тем, знает ли человек, который будет делать игру, вообще о таких играх и их строении и, если не знает, а нужно, чтоб знал - либо не нанимать, либо тратить время на обучение. Приведу пример, не связанный с геймдевом: если я, допустим, нанимаю админа-безопасника для работы с сетью, состоящей из МАКов, а он никогда продуктов эпла в глаза не видел, и об особенностях эпловского софта и архитектура понятия не имеет - встаёт вопрос, почему я нанимаю его, а не ищу того, кто умеет. Или, если он супер-пупер крутой, известный и модный и мне его во что бы то ни стало нужно заиметь - я потрачу некоторое время и некоторую сумму на то, чтоб его познакомить с системой, благо, если он действительно крут - научится быстро и работать будет продуктивно. противоположная ситуация: команда есть, а захотелось делать новую игру, того жанра, с которым команда не знакома. Ситуация аналогична ситуации, если, имея админскую команду, не знакомую с маками, мы решаем приобрести парочку маков и включить их в офисную сеть. Первый вопрос, который стоит задать: а оно мне надо? Может, стоит продолжить всё-таки работать с тем, что знакомо? Если всё-таки решаем, что кровь из носу - так надо - значит, одновременно с покупкой и за пару месяцев до того, как эти самые компы надо включить в общую сеть для стабильной работы, берём админов и отправляем их учиться работать с маками. либо берём главного админа, и отправляем учиться его - если он способен сам быстро обучить остальных. ситуация в геймдеве ничем не отличается. если вы считаете, что знание какого-то жанра игры необходимо дял сотрудника на какой-то должности - либо обучите этого сотрудника, либо наймите другого. В чём проблема-то? если это вообще проблема - то проблема не геймдизайнера, а неграмотного подбора кадров. только ещё вопрос, кого подобрали неграмотно - команду или геймдиза.
Это вопрос организации производственного процесса, в силу особенностей, времени на обучение всех нет, предполагается что команда самообучается процессе разработке, а не ждет пинка под зад.
(Описанный ваме также актуально, но вот просто не для мен ибо по другому все). Просто вот кто-то иногда не хочет самообучатся. А положение тем хуже чем дальше, ибо если целью стоит снизить стоимость и время разработки, а человек тормозит этот процесс, тем что ни сам не хочет учиться и других напрягает вопросами "какого цвета огурец", то это уже не является хорошим посылам. Не ну конечно можно расстаться с человеком, принять меры, просто я не об этом писал, а том что ситуации разные бывают. Их решение есть, но любое решение требует времени. А насчет того чтобы нанять другого, в силу некоторой специфики, жанры одной команды могут сильно разница, примеров в нашем геймдеве просто уйма (аля делаем пошаговую стратегию и следующим проектом команда делает гонки). Может в это и есть "проблема". > если это вообще проблема - то проблема не геймдизайнера, а > неграмотного подбора кадров. только ещё вопрос, кого подобрали > неграмотно - команду или геймдиза. Не понял не много причем тут гейм-дизайнер, то есть вы реально считаете что гейм-дизайнер должен каждому в команде подойти и расказать или написать трактат "Какого цвета огурец?". И если он этого не делает то он плохой гейм-диз и гнать его надо. Допустим даже если привести пример про ману и заклинания, ну допустим человек не знает, что это такое, опять же не причина писать трактаты, основы фэнтези вселенных. Как максимум это дать линки человек где прочитать чтобы узнать, а вообще он сам должен спросить, но явно не доставать гей-диза постоянно ну расскажи что это такое, а почему и зачем ( Все что отличается от базовых вещей, описано в ГДД, все остальное есть в интернете, для RPG например crpg.ru а если интересуют вселенные mirf.ru)
Елена Ткач
28.02.2008 13:25
Артем Романко
28.02.2008 13:29
Артем Романко
28.02.2008 13:32
Сергей Азаров
28.02.2008 13:55
Dmitry Voronov
28.02.2008 14:02
Сергей Азаров
28.02.2008 14:09
В ветке ещё 5
сообщений
> Вот так и с гейм-дизайнером - для него многие вещи настолько
> очевидны, что ему даже в голову не может прийти их описывать, > а потом хватается за голову, когда от другой части команды > начинают приходить фидбэки и просьбы "разьяснить"... или > еще лучше - приходить что-то сделаное так, как представились > эти самые помидоры... Все верно. И пока не будет успешного случая моментального клонирования человека, так оно и останется. Единственное, что хотелось бы уточнить, что гейм-дизайнер проектирует все же не просто некую абстрактную игру, а игру компьютерную, которая по определению создается художниками, звукоинженерами и программистами. То есть, оторванность команды от головы гейм-дизайнера подразумевается по определению его рода работы. Цель работы гейм-дизайнера и заключается в том, чтобы донести игру из своей головы всяким тупым программистам-художникам, которые уже донесут ее публике. Все что расплескается по дороге - неизбежные потери, которые лучше компенсировать, чем минимизировать. С другой стороны, профессионализм программиста подразумевает знакомство с предметной областью. Чем лучше он понимает гейм-дизайнера - тем лучше всему проекту. Наверное именно потому командный опыт важнее суммы личного. В плохих командах ищут виноватого и им, конечно же, оказывается диздок, потому что это единственный причастный предмет, который ничего не скажет в свою защиту. В хороших же - программист думает как бы лучше реализовать ту или иную фичу, а гейм-дизайнер - какую бы эффектную фичу придумать, чтобы ее было удобно реализовывать. Это как на традиционной японской попойке: никто сам себе не наливает, только друг-другу, а в итоге все пьяные идут захватывать Корею.
Артем Романко wrote:
> > Комментарии к блогу персоны Артем Романко > > Как ни смешно, зачастую заключается втом, что он является > человеком игрющим, а те, кто работают по его дизайн-документу > довольно-таки часто являются не играющими людьми. > > В чем проблема, спросите вы? > ИМХО диздок, как любой другой текст пишется для конкретной целевой аудитории (команды, заказчика и т.д.) и должен быть ей понятен. Как автор этого добьется - уже его проблемы. ЗЫ: Помидоры должны быть маринованные в банке. Так они намного эффективнее в качестве оружия. Кроме того банка – является единообразным интерфейсом между персонажем и помидорами. Игрок сможет использовать в качестве оружия маринованные помидоры различных сортов: от чери до бычьего сердца, - помещенные в одинаковые банки. А также, игрок сможет развить способность разбивать банки. И употреблять рассол для восстановления здоровья и маны, а стеклянное горлышко банки использовать как альтернативное оружие ближнего боя.
Забавно читать всё вышенаписанное))
Может проблема всего - это проблема коммуникации? Проблема от того, что каждый(программист<-->гд, гд<-->лиды и прочее) пытается каждого подавить, пригнуть к земле, то есть конкурирует там, где надо кооперироваться. Пусть неявно, пусть неосознанно, но как говорит один мой знакомый: не признавая, что ты конкурируешь - ты создаёшь конфликт там где его нет, то есть на пустом мете. Кстати а вы умеете признавать свои ошибки\недочёты? Умеете ли об этом сказать это? Если да, и если в команде лиды именно из таких людей - это идеальная команда. А все эти примеры про доки, помидоры, танчики и етс, опять сводятся в локальные посерушки гд с программистами, словно речь идёт о чести и достоинстве всей профессии или индустрии, или это война на последние трусы:-)
Евгений Захарчук wrote:
> > А все эти примеры про доки, помидоры, танчики и етс, опять > сводятся в локальные посерушки гд с программистами, словно речь > идёт о чести и достоинстве всей профессии или индустрии, или это > война на последние трусы:-) Я не программист, и геймдизайнер редко. Речь шла о том, что должно быть нормой в работе геймдизайнера. А подобные вашему обобщения - хамство, между прочим. И смайлик не помогает. Читайте еще раз диалог, если ничего не поняли.
Евгений Захарчук
29.02.2008 15:39
Kirill Yudintsev
29.02.2008 17:07
Евгений Захарчук
29.02.2008 18:03
В ветке ещё 1
сообщение
Re: Не основная проблема гейм-дизайнера
Вот свежий пример - программист РПГ в ответ на просьбу расписать на что сейчас влияют параметры чара, спрашивает что такое чар... Да, проблема есть, но я бы не назвал ее основной.
|
Списки доступа
Права доступа
Вы можете читать группу, но не можете отвечать на сообщения и создавать новые темы.
Доступ для остальных:
|
Copyright © 2021 ООО "ДТФ.РУ". Все права защищены.
Воспроизведение материалов или их частей в любом виде и форме без письменного согласия запрещено.
Замечания и предложения отправляйте через форму обратной связи.
