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

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

Зачастую случается так, что разработка игрового проекта ведется без использования каких-либо методов объектно-ориентированного проектирования, анализа и систематизации. В данной статье левел-дизайнер компании UDC Игорь Пасичный, обобщая свой опыт и практические навыки, предлагает вашему вниманию алгоритм по проектированию игровых сцен, который призван помочь избежать ошибок с самого начала и ускорить разработку игры.
0
Отправлено 06.12.2006 в 18:38
Отвечает на сообщение 167133
0
А вы что в эти метафоры вкладываете? Что это как бы два противоположных полюса деятельности? Физика и Лирика, условно говоря?
Отправлено 07.12.2006 в 09:35
Отвечает на сообщение 167163
0
Игорь Пасичный wrote:

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

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

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


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

> А вы что в эти метафоры вкладываете? Что это как
> бы два противоположных полюса деятельности?
> Физика и Лирика, условно говоря?

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

Естественно, в реальном процессе пресутствуют оба этих полюса.

Имхо, можно составить формальный перечень работ и обязанностей для команды (узлы графа). Можно составить даже набор микропроцессов (куски графа). А вот итерациями по переделке (перезапуску микропроцессов) придется руководить гибко на лету. "Сказали переделывать или видишь что ударное место надо сделать лучше - переделывай".
Отправлено 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
Отвечает на сообщение 167323
0
Классическое сетевое планирование работ по проекту, но с использованием веба…если используете какой-то проверенный софт, и он не написан чисто вами, дай ссылку, пожалуйста, посмотрю, хочу посмотреть его реализацию.
Отправлено 07.12.2006 в 13:05
Отвечает на сообщение 167386
0
Игорь Пасичный wrote:

> Классическое сетевое планирование работ по
> проекту, но с использованием веба

Ок, основную идею я донес - дальше подробности.
Отличие от классического - в деталях.
Во первых, классическое - оно скорее
1) ригидное
2) стратегическое
3) инициатор - менеджеры

Предложенный подход - подход о микропроцессах и тасках.
Он
1) динамичный
2) тактический
3) инициатор - рядовые творческие сотрудники, которые реализацией идеи саму идею трансформируют и улучшают.

Понять это может поможет слудующая деталь.
Заводятся workgroups, в каждой из которой назначаются leads.
Каждый таск может иметь состояния (набор состояний лучше откорректировать под свою ситуацию):
предложен/открыт/работа/решен/закрыт/отложен.

Предложен - это собственно процесс "кристализации". Когда создается скелет графа. Люди выбирают себе субподрядчиков, субподрядчики оценивают объемы работ. (Все это посреди процесса разработки, а не только на начальных этапах!)

Когда граф сформировался и все его таски влоть до листовых оценены по времени, статус задач из "предложен" можно перевести либо в "открыт", либо в "отложен". Т.е. когда lead "открывает" свою root задачу, открываются все задачи в подграфе, которые назначены данной workgroup. если есть задачи, зависящие от других workgroup - они не откроются, пока этого не сделает соответствующий lead. Т.е. это "одобрям" всех отделов. Задача может быть "отложена" - т.е. feature cut только что сгенерированной идеи.

Когда все подзадачи "открыты" - вся ветка автоматом переходит в статус "работа". "закрыт", "решен" - субподрядчик может только "решить" задачу. "закрыть" ее может только заказчик (или открыть заново, если решена не качественно - тут почти как в Mantis).

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

В общем я не в курсе - существует ли такой.
Конечно по ключевым словам Workflow, BPM, HIM есть много информации, но ничего конкретного из решений я пока не нашел.
Отправлено 07.12.2006 в 13:10
Отвечает на сообщение 167386
0
Игорь Пасичный wrote:

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

p.s. Вообще конечно самая правильная идея - это встроить подобную систему прямо в редактор игры. Это даст массу бонусов - можно ссылаться на единцы контента, ассеты, объекты игрвых уровней, placeholder'ы (на уровне ядовито-зеленый флажок "а тут должен быть тот мост") прямо в тексте задач и уведомительных сообщениях гиперссылками. Т.е. в тексте задачи кликнул - камера редактора уже кажет тебе этот объект.
Отправлено 07.12.2006 в 13:22
Отвечает на сообщение 167404
0
Спасибо.
Идея довольно интересная с редактором…можно сделать автоматическое документирования задач с приоритетом их решения.
Отправлено 07.12.2006 в 13:52
Отвечает на сообщение 167410
0
Игорь Пасичный wrote:
> Идея довольно интересная с редактором…можно
> сделать автоматическое документирования задач с
> приоритетом их решения.

Только учти что документация - пассивна. Всплывающие мессаджи (аля "вам 11 личных сообщений") - активны, если в них встроены гиперссылки ответного действия. Т.е. одно дело если lead просматривает списки "предложенных" задач иногда, а другое - когда lead'у при входе в систему появляется всплывающее окно от сотрудника "открой прдложенную задачу [ссылка на задачу] с кнопками/гиперссылками [открыть][отложить][напомнить через ... часов]. Т.е. основной смысл - это сообщения, которыми сотрудники и система побуждают друг друга к действию.
Отправлено 07.12.2006 в 14:38
Отвечает на сообщение 167323
0
Я конечно, понимаю, что ситуации, когда нужно что-то на лету менять, так или иначе возникают. Но приведенный вами пример, это перебор. Потому что ФАН должен продумываться не на стадии реализации, и, разумеется на стадии сборки, отладки прототипа. В самом крайнем, крайнем, подеркиваю, случае, если уж зазудело добавить функциональности на этапе production, дизайнер СНАЧАЛА берет консультации у ответственных за реализацию - во сколько обойдется его фан, а потом обосновывает руководителю проекта  - зачем это нужно. Если убедит и соотношение цена/качество, покажется руководителю разумным - вперед и с песней.
Отправлено 07.12.2006 в 14:57
Отвечает на сообщение 167471
0
Dmitry Voronov wrote:

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

Все конторы слишком разные. Согласен - для кого-то это может быть перебор.

> Потому
> что ФАН должен продумываться не на стадии
> реализации, и, разумеется на стадии сборки,
> отладки прототипа.

Тут я не согласен.

1) Нельзя продумать все с точностью до мелочей на три года вперед. Есть конечно профи, но они скорее стратегическими решениями занимаются. Плюс есть базовый геймплей, а есть побочные вещи - тупой контент, элементы уровней. Уникальные моменты. То что делает игру не нудной и разнообразной. За это и боремся. Например в zuma - голая базовая идея геймплея и никакого контента (уровней). В rpg все с точностью до наоборот. Базовый геймплей конечно есть (rpg система) но вот квесты, ролики, npc, интерактивность sandbox мира - все это надо делать.

2) Мы боремся за скоращение времени разработки. Данный подход позволяет производить preproduction/production внахлест. Т.е. границы размываются - в предельном случае ускорение в два раза (т.е. WYSIWYG - то что сделал, тут же в игру и пойдет). на практике все конечно сильно хуже и зависит от инструментария. но тут все решаемо (пусть и дорого).

> В самом крайнем, крайнем,
> подеркиваю, случае, если уж зазудело добавить
> функциональности на этапе production, дизайнер
> СНАЧАЛА берет консультации у ответственных за
> реализацию - во сколько обойдется его фан, а
> потом обосновывает руководителю проекта  - зачем
> это нужно. Если убедит и соотношение
> цена/качество, покажется руководителю разумным -
> вперед и с песней.

Смотрите формальный подход со статусом задач "предложен"/"открыт"/"отложен". Это оно.
Отправлено 08.12.2006 в 18:01
Отвечает на сообщение 165979
0
Написал немного об используемом мною инструменте для создания 3д скетча уровня (SketchUp):

http://dtf.ru/blog/read.php?id=43522

Надеюсь, будет полезно кому-нибудь.
Отправлено 11.12.2006 в 12:47
Отвечает на сообщение 167471
0
Dmitry Voronov wrote:
>
> Я конечно, понимаю, что ситуации, когда нужно
> что-то на лету менять, так или иначе возникают.


Ты возможно лучше даже Лехи знаешь, что скорее, как правило получается именно "на лету".

> Но приведенный вами пример, это перебор. Потому


Не перебор. реально работает и побеждает.

> что ФАН должен продумываться не на стадии
> реализации, и, разумеется на стадии сборки,
> отладки прототипа. В самом крайнем, крайнем,
> подеркиваю, случае, если уж зазудело добавить
> функциональности на этапе production, дизайнер
> СНАЧАЛА берет консультации у ответственных за
> реализацию - во сколько обойдется его фан, а
> потом обосновывает руководителю проекта  - зачем
> это нужно. Если убедит и соотношение
> цена/качество, покажется руководителю разумным -
> вперед и с песней.

Именно такая схема более громоздкая и медленная, как следствие, в результате. Принцип "пушш, пушш ми бэби" работает гораздо быстрее и это уже не теория а жесткая практика. В сроки так и эдак закладывается "п..б". Впрочем как и в деньги:) Леха очень грамотно все разъяснил+потратил массу времени и байт за что ему респект большой должен быть от аудитории читающей:)
p.s. По моему, обсуждение статьи было интереснее самой статьи в несколько раз, в основном, благодаря Дмитрию и Алексею. Что не умаляет заслуг автора ни в коем случае.
« Пред | 1 | 2 | 3 | 4 | След »
Comments
Списки доступа
  • Подписчики [581]
  • Черный список [2]
Права доступа
Вы можете читать группу, но не можете отвечать на сообщения и создавать новые темы.
Доступ для остальных:
анонимы : могут читать
новые : полный доступ
постоянные : полный доступ
Показывать
сообщений
на страницу

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

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

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

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