Комментарии к статье

Системный подход к дизайну уровней

Зачастую случается так, что разработка игрового проекта ведется без использования каких-либо методов объектно-ориентированного проектирования, анализа и систематизации. В данной статье левел-дизайнер компании UDC Игорь Пасичный, обобщая свой опыт и практические навыки, предлагает вашему вниманию алгоритм по проектированию игровых сцен, который призван помочь избежать ошибок с самого начала и ускорить разработку игры.
0
Отправлено 06.12.2006 в 13:34
Отвечает на сообщение 166899
0
> Ох. Я просто заметил что термины и структура
> однонаправленная (без итераций) напоминает мне
> Мне вообще части никакими не видятся. Я за
> итеративно-инкрементный процесс c минимизацией
> стоимости переделки и внесения изменений. Как в

Совсем нет, перечитай 4 и 5 пункт алгоритма.  По-моему, лучше, здесь удостоверится на прототипе, например, персонаж может бегать по стенам и потолку, что это будет работать или нет с точки зрения всех аспектов геймплея,  то есть может стоить изменить прототип сцены  или переделать саму фишку. Или лучше потратить кучу времени на готовую сцену, а потом окажется, что задумка не работает, приехали, сцена, посреди сюжетной ветки, начинаем переделывать…
Отправлено 06.12.2006 в 17:25
Отвечает на сообщение 167032
0
Игорь Пасичный wrote:
> Совсем нет, перечитай 4 и 5 пункт алгоритма.

Перечитал. Т.е. алгоритмом четко фиксируется, что обратной связи от пунктов 6-10 на пункты 4-5 нет. А ты уверен, что это действительно так? Понимаешь - сама реализация идеи порой идею меняет. Справедливо и для частей идеи.

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

Кто-же спорит! Конечно лучше - на кубиках все отладить а потом залить зараз готовым контентом. Но не все так идеально.
Отправлено 06.12.2006 в 18:29
Отвечает на сообщение 167134
0
> Перечитал. Т.е. алгоритмом четко фиксируется, что
> обратной связи от пунктов 6-10 на пункты 4-5 нет.
> А ты уверен, что это действительно так? Понимаешь
> - сама реализация идеи порой идею меняет.
> Справедливо и для частей идеи.

старый анекдот:
Профессор:
-товарищ студент, ваша схема не может работать!
Почему?
- у вас кран нарисован в закрытом положении.
Так и здесь, это методика, ее не нужно проганять в режиме дебега и ждать пока программ выдаст исключение. О гибкости каждый должен думать сам, да изменения могут быть на каждом шаге, если они целесообразны, так что не надо мне предписывать мертвый цикл:).
И вообще, есть желание делитесь опытом, осветите что и как лучше по вашому, по-моему, для этого и нужно обсуждение.
Отправлено 07.12.2006 в 09:35
Отвечает на сообщение 167163
0
Игорь Пасичный wrote:

> О гибкости каждый должен

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

> И вообще, есть желание делитесь опытом, осветите
> что и как лучше по вашому, по-моему, для этого и
> нужно обсуждение.


Я уже осветил свое мнение - процесс должен отталкиваться от особенностей и опыта имеющихся людей, которым с этим процессом работать. Плюс прочих ограничений. Сорри, что никакой формальной методикой это передать не могу. Только опыт.
Отправлено 07.12.2006 в 10:48
Отвечает на сообщение 167163
0
Игорь Пасичный wrote:

> И вообще, есть желание делитесь опытом, осветите
> что и как лучше по вашому, по-моему, для этого и
> нужно обсуждение.

Пришли мысли. Делюсь.

Во первых, замечу, что бесполезно формально организовывать процесс в рамках одной специальности.

Вообще типично эпизод рабочего дня выглядит так:
Левел дизайнеру в процессе реализацации побочного квеста (и связанных с ним игровых скриптов/событий/роликов) удается найти золотую жилку. Он видит что получается фан. Но можно еще круче ("Только надо чтобы падал не один колобок, а вываливалось их десять! И чтобы стенка под их весом трескалась и они проваливались!"). Трезво оценив ситуацию, геймдизайнер понимает что ему не хватает:
A) одного нового вида триггеров.
B) шести скриптовых функций у двух типов объектов.
C) небольшого изменения в колижн геометрии домика.
Т.к. "кто за что отвечает" (перечень работ и обязанностей) известно всей команде, то геймдизайнер с A и B пойдет к программистам, с C пойдет к человеку из отдела арта.
Lead программист знает, как поделить A и B между программистами. Он сразу же видит, что реализация одной из запрашиваемых скриптовых функций потребует незначительного изменения физической системы, т.е. задачу B будут решать уже два человека - программист скриптового хоста и физик.
Таким образом у B появляется подзадача D.

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

   A
  /
fun--B--D
  \
   C

Узлы графа зависемостей - задачи. Терминальные элементы (листья) - недробимые задачи, которые решаются одним человеком. У каждой задачи есть минимальное, среднее и максимально прогнозируемое время выполнения.
У каждого человека есть очередь из работ с приоритетами (priority queue).

Для автоматизации управления всем этим юзаем готовую тулзу, либо пишем свое web приложение:

У каждого человека там явно показана очередь работ, отсортированная сверху вниз. Каждый человек может добавлять новую root работу и, используя перечень обязанностей, добавлять работы в очередь дургим людям (субподрядчикам). Если кто-то помечает подзадачу как сделанную, автоматом высылается email людям, которые от этой подзадачи зависят.
Насчет приоритетов - самый простой вариант, когда приоритет подзадач равен приоритету корневой задачи. Но лучше когда есть еще один уровень косвенности - коэффициенты важности для подзадач, которыми могут управлять менеджеры.
Т.е. менеджер может в online spin контролом пощелкать приоритет задачи и тут же смотреть визуализацию графика сетевых работ.

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

Бюрократия: стремится к нулю при условии ненавязчивой организации web-интерфейса. Эффективность максимальна: push ("толкай") модель. Разве что e-mail можно пролюбить - но это решается административными мерами.
Игорь Пасичный  07.12.2006 12:33
Alexey Baskakov  07.12.2006 13:05
Alexey Baskakov  07.12.2006 13:10
Игорь Пасичный  07.12.2006 13:22
В ветке ещё 1 сообщение
Dmitry Voronov  07.12.2006 14:38
Alexey Baskakov  07.12.2006 14:57
Alexey Vlasov  11.12.2006 12:47
Comments
Списки доступа
  • Подписчики [581]
  • Черный список [2]
Права доступа
Вы можете читать группу, но не можете отвечать на сообщения и создавать новые темы.
Доступ для остальных:
анонимы : могут читать
новые : полный доступ
постоянные : полный доступ

Copyright © 2021 ООО "ДТФ.РУ". Все права защищены.

Воспроизведение материалов или их частей в любом виде и форме без письменного согласия запрещено.

Замечания и предложения отправляйте через форму обратной связи.

Пользовательское соглашение