Комментарии к статье
 | Зачастую случается так, что разработка игрового проекта ведется без использования каких-либо методов объектно-ориентированного проектирования, анализа и систематизации. В данной статье левел-дизайнер компании UDC Игорь Пасичный, обобщая свой опыт и практические навыки, предлагает вашему вниманию алгоритм по проектированию игровых сцен, который призван помочь избежать ошибок с самого начала и ускорить разработку игры. | |
|
|
Отправлено 06.12.2006 в 18:29
|
 |
> Перечитал. Т.е. алгоритмом четко фиксируется, что
> обратной связи от пунктов 6-10 на пункты 4-5 нет.
> А ты уверен, что это действительно так? Понимаешь
> - сама реализация идеи порой идею меняет.
> Справедливо и для частей идеи.
старый анекдот:
Профессор:
-товарищ студент, ваша схема не может работать!
Почему?
- у вас кран нарисован в закрытом положении.
Так и здесь, это методика, ее не нужно проганять в режиме дебега и ждать пока программ выдаст исключение. О гибкости каждый должен думать сам, да изменения могут быть на каждом шаге, если они целесообразны, так что не надо мне предписывать мертвый цикл:).
И вообще, есть желание делитесь опытом, осветите что и как лучше по вашому, по-моему, для этого и нужно обсуждение.
|
|
Отправлено 07.12.2006 в 09:35
|
|
Игорь Пасичный wrote:
> О гибкости каждый должен
думать сам, да изменения могут быть на каждом шаге, если они
целесообразны
Ok. Спасибо за продуманный перечень работ по левел дизайну. Как базовый набор - вполне хорошо.
> И вообще, есть желание делитесь опытом, осветите
> что и как лучше по вашому, по-моему, для этого и
> нужно обсуждение.
Я уже осветил свое мнение - процесс должен отталкиваться от особенностей и опыта имеющихся людей, которым с этим процессом работать. Плюс прочих ограничений. Сорри, что никакой формальной методикой это передать не могу. Только опыт.
|
|
Отправлено 07.12.2006 в 10:48
|
|
Игорь Пасичный 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
|
|
Классическое сетевое планирование работ по проекту, но с использованием веба…если используете какой-то проверенный софт, и он не написан чисто вами, дай ссылку, пожалуйста, посмотрю, хочу посмотреть его реализацию.
|
|
Отправлено 07.12.2006 в 13:05
|
|
Игорь Пасичный 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
|
|
Игорь Пасичный wrote:
> используете какой-то проверенный софт, и он не
> написан чисто вами, дай ссылку, пожалуйста,
> посмотрю, хочу посмотреть его реализацию.
p.s. Вообще конечно самая правильная идея - это встроить подобную систему прямо в редактор игры. Это даст массу бонусов - можно ссылаться на единцы контента, ассеты, объекты игрвых уровней, placeholder'ы (на уровне ядовито-зеленый флажок "а тут должен быть тот мост") прямо в тексте задач и уведомительных сообщениях гиперссылками. Т.е. в тексте задачи кликнул - камера редактора уже кажет тебе этот объект.
|
|
Отправлено 07.12.2006 в 14:38
|
|
Я конечно, понимаю, что ситуации, когда нужно что-то на лету менять, так или иначе возникают. Но приведенный вами пример, это перебор. Потому что ФАН должен продумываться не на стадии реализации, и, разумеется на стадии сборки, отладки прототипа. В самом крайнем, крайнем, подеркиваю, случае, если уж зазудело добавить функциональности на этапе production, дизайнер СНАЧАЛА берет консультации у ответственных за реализацию - во сколько обойдется его фан, а потом обосновывает руководителю проекта - зачем это нужно. Если убедит и соотношение цена/качество, покажется руководителю разумным - вперед и с песней.
|
|
Отправлено 07.12.2006 в 14:57
|
|
Dmitry Voronov wrote:
> Я конечно, понимаю, что ситуации, когда нужно
> что-то на лету менять, так или иначе возникают.
> Но приведенный вами пример, это перебор.
Все конторы слишком разные. Согласен - для кого-то это может быть перебор.
> Потому
> что ФАН должен продумываться не на стадии
> реализации, и, разумеется на стадии сборки,
> отладки прототипа.
Тут я не согласен.
1) Нельзя продумать все с точностью до мелочей на три года вперед. Есть конечно профи, но они скорее стратегическими решениями занимаются. Плюс есть базовый геймплей, а есть побочные вещи - тупой контент, элементы уровней. Уникальные моменты. То что делает игру не нудной и разнообразной. За это и боремся. Например в zuma - голая базовая идея геймплея и никакого контента (уровней). В rpg все с точностью до наоборот. Базовый геймплей конечно есть (rpg система) но вот квесты, ролики, npc, интерактивность sandbox мира - все это надо делать.
2) Мы боремся за скоращение времени разработки. Данный подход позволяет производить preproduction/production внахлест. Т.е. границы размываются - в предельном случае ускорение в два раза (т.е. WYSIWYG - то что сделал, тут же в игру и пойдет). на практике все конечно сильно хуже и зависит от инструментария. но тут все решаемо (пусть и дорого).
> В самом крайнем, крайнем,
> подеркиваю, случае, если уж зазудело добавить
> функциональности на этапе production, дизайнер
> СНАЧАЛА берет консультации у ответственных за
> реализацию - во сколько обойдется его фан, а
> потом обосновывает руководителю проекта - зачем
> это нужно. Если убедит и соотношение
> цена/качество, покажется руководителю разумным -
> вперед и с песней.
Смотрите формальный подход со статусом задач "предложен"/"открыт"/"отложен". Это оно.
|
|
Отправлено 11.12.2006 в 12:47
|
|
Dmitry Voronov wrote:
>
> Я конечно, понимаю, что ситуации, когда нужно
> что-то на лету менять, так или иначе возникают.
Ты возможно лучше даже Лехи знаешь, что скорее, как правило получается именно "на лету".
> Но приведенный вами пример, это перебор. Потому
Не перебор. реально работает и побеждает.
> что ФАН должен продумываться не на стадии
> реализации, и, разумеется на стадии сборки,
> отладки прототипа. В самом крайнем, крайнем,
> подеркиваю, случае, если уж зазудело добавить
> функциональности на этапе production, дизайнер
> СНАЧАЛА берет консультации у ответственных за
> реализацию - во сколько обойдется его фан, а
> потом обосновывает руководителю проекта - зачем
> это нужно. Если убедит и соотношение
> цена/качество, покажется руководителю разумным -
> вперед и с песней.
Именно такая схема более громоздкая и медленная, как следствие, в результате. Принцип "пушш, пушш ми бэби" работает гораздо быстрее и это уже не теория а жесткая практика. В сроки так и эдак закладывается "п..б". Впрочем как и в деньги:) Леха очень грамотно все разъяснил+потратил массу времени и байт за что ему респект большой должен быть от аудитории читающей:)
p.s. По моему, обсуждение статьи было интереснее самой статьи в несколько раз, в основном, благодаря Дмитрию и Алексею. Что не умаляет заслуг автора ни в коем случае.
|
- Подписчики [581]
- Черный список [2]
Вы можете читать группу, но не можете отвечать на сообщения и создавать новые темы.
Доступ для остальных:
| анонимы |
: могут читать |
| новые |
: полный доступ |
| постоянные |
: полный доступ |
|
