э,у кого какие коментарии возникли?
забыл автор про пространственное мышление
Комментарии к статье
э,у кого какие коментарии возникли?
забыл автор про пространственное мышление
Хотелось бы увидеть список выпущенных игр, в которых автор использовал этот алгоритм.
Игорь, а сколько примерно человеко-часов в среднем занимает полный цикл производства одного уровня по данной схеме (скажем для Doom 3 продолжительностью 5-7 минут)? И если не сложно то желательно по каждой фазе. Заранее спасибо.
Поскольку свет и тень в лвлдизайне зачастую играет очень важную роль (впрочем, как и в архитектуре), имхо, есть смысл обратить внимание на освещение уровня намного раньше, хотя бы на тех же болванках. Зачастую это может быть описано в сценарии как необходимость (например стэлсы)
Народ, я смотрю, предлагает автору "забить" и делать по старинке - ваять уровни, а потом уж ГД думать, как их наполнять. Знаем такое, проходили. Может, Игорь и переусердствовал с методикой, но рациональное зерно есть. На ДТФ-е была когда-то статья левел-диза какой-то из игр по вселенной Star Wars - там была похожая схема создания, хоть и несколько упрощенная (но как знать, описал ли там автор все ньюансы?).
Вопрос о Думе не по адресу, мне кажется. Это к Кармаку.
> Народ, я смотрю, предлагает автору "забить" и
> делать по старинке - ваять уровни, а потом уж ГД > думать, как их наполнять. Знаем такое, проходили. Я не совсем понял кто этот самый народ, который предлагает "забить"? Меня, например, интересуют трудозатраты представленного технологического процесса. Других людей результат применения данного процесса. Хочется отметить, что только автор сей статьи может ответить на данные вопросы, т.к. он применял свою методику. > Может, Игорь и переусердствовал с методикой, но > рациональное зерно есть. На ДТФ-е была когда-то > статья левел-диза какой-то из игр по вселенной > Star Wars - там была похожая схема создания, хоть > и несколько упрощенная (но как знать, описал ли > там автор все ньюансы?). Ни кто и не говорит, что предложенная схема не будет работать или не улучшит качество выпускаемого продукта. Но если прирост качества от данной методики 10%, а прирост трудозатрат 200% от текущего пайплайна, то применение данной методики не рентабельно.
Юрий Бесараб wrote:
> > Вопрос о Думе не по адресу, мне кажется. Это к > Кармаку. Хорошо, я не совсем корректно выразился. Перефразирую: "Cкажем для игры типа Doom 3 продолжительностью 5-7 минут". Это сравнение необходимо для оценки объема работ и не более.
Много гипотетических данных нужно использовать для расчета:
- а сколько геймдизайнеров работает(описание и схемы можно составить, за один рабочий день)? - сколько моделеров? -сколько художников текстуровщиков? Если например разработка одной модели может занимать одну или две недели…это все текстуры, плюс меш( лоу, хай и еще для колижина, например ) Что позволяет редактор в котором сцена собирается? Саму сцену можно собрать за один два дня, если конечно не моделить все с нуля в Максе, например. Гипотетически недели 3 или месяц.
Конечно, все зависит от специфики жанра.
Игорь Пасичный wrote:
> > Много гипотетических данных нужно использовать > для расчета: > - а сколько геймдизайнеров работает(описание и > схемы можно составить, за один рабочий день)? - в человеко-часах > - сколько моделеров? - в человеко-часах > -сколько художников текстуровщиков? в человеко-часах Но вообще меня интересует объем работы гейм-дизайнеров. > Если например разработка одной модели может > занимать одну или две недели…это все > текстуры, плюс меш( лоу, хай и еще для колижина, > например ) > Что позволяет редактор в котором сцена > собирается? > Саму сцену можно собрать за один два дня, если > конечно не моделить все с нуля в Максе, > например. > Гипотетически недели 3 или месяц. Заранее спасибо за уточнение.
5 баллов,поэтому сначала надо решить какой уровен графики можна себе позволить на конкретном движке,кокой тип пространств,атмосферу,свет
Спасибо, Игорь, за интересную статью.
Используете ли вы указанные методы в работе над Heart of Eternity? И, если используете, то укажите список документов, достаточных для документирования дизайна уровней по вашей методике. Например, рис.2.2 - это реальный пример документации?
Для разработки схемы по типу рисунка 2.2 необходимо не более 30-40 минут, если использовать соответствующий пакет, а таких сейчас хватает. Конечно, все можно заменить на простые блоки, как в рисунке 2.1. Но иногда, геймдизайнер, точно указывает положение объектов в сцене, что связано с развитием сценария, при этом изображая их схематично,так что приходилось использовать.
Вполне достаточным будет следующий блок документов: техническое задание; текстовое описание уровня; структурные схемы; описание сценариев; скетчи, рисунки, фотографии; база данных текстур, материалов, моделей; документация по файлам, что где хранится с указанием версии. Bug и fix -листы.
тема актуальная, но много букв
есть пожелание - хотелось бы больше о личном опыте
Игорь, по Вашему опыту, каковы "узкие места" при подобной схеме работы?
Игорь Пасичный wrote:
> > Для разработки схемы по типу рисунка 2.2 > необходимо не более 30-40 минут, если > использовать соответствующий пакет, а таких > сейчас хватает. Эх, у нас уходит на рисунок такой много времени, правда размером немного побольше в раза три-четыре и объектами в десять раз, ну никак не три часа. :) Ведь при формировании такого рисунка, геймдизайнер рисует геймплей. Надо делать, думать, виртуально играть, утверждать со всеми кодер-арт-дезигнер-сценаристами фичи рисунка и много-много раз улучшать его и переделывать. Тут и три-четыре дня не будет много.
Я говорил про само выполнение схемы…а так, кончено, да здесь очень важен сам творческий фактор, и чем больше уровень и чем больше на нем предметов тем больше нужно времени на его проработку с точки зрения всех аспектов. Так, например, из экспериментально полученных данных, могу сказать. Что если делать ландшафт на котором, например, может находится около 300 объектов, и левел дизайнер в своем воображении видит сформированную картинку, то на расположение одного предмета нужно 2-3 минуты. Тогда на всю сцену коло 8-15 часов…может и стоить заменить на авто генерацию, но тогда не стоит ждать уникальности картинки.
“Узкие места” – скорее всего это, то что вы планируете реализовать в движке программно какую-то функцию, но данном этапе разработке вы еще не закончили, а сцена строится с учетом, что это работать будет, и на этапе тестирования, оставляется на потом. А потом просто приходится ее подгонять под нужный результат, так как что-то программно не реализовали. Хотя это касается по большей степени, не только метода, а планирования всего проекта в целом.
|
 Списки доступа
Права доступа
Вы можете читать группу, но не можете отвечать на сообщения и создавать новые темы.
Доступ для остальных:
|
Copyright © 2021 ООО "ДТФ.РУ". Все права защищены.
Воспроизведение материалов или их частей в любом виде и форме без письменного согласия запрещено.
Замечания и предложения отправляйте через форму обратной связи.
