Комментарии к статье
 | Зачастую случается так, что разработка игрового проекта ведется без использования каких-либо методов объектно-ориентированного проектирования, анализа и систематизации. В данной статье левел-дизайнер компании UDC Игорь Пасичный, обобщая свой опыт и практические навыки, предлагает вашему вниманию алгоритм по проектированию игровых сцен, который призван помочь избежать ошибок с самого начала и ускорить разработку игры. | |
|
|
Отправлено 06.12.2006 в 17:25
|
 |
Игорь Пасичный wrote:
> Совсем нет, перечитай 4 и 5 пункт алгоритма.
Перечитал. Т.е. алгоритмом четко фиксируется, что обратной связи от пунктов 6-10 на пункты 4-5 нет. А ты уверен, что это действительно так? Понимаешь - сама реализация идеи порой идею меняет. Справедливо и для частей идеи.
> По-моему, лучше, здесь удостоверится на
> прототипе, например, персонаж может бегать по
> стенам и потолку, что это будет работать или нет
> с точки зрения всех аспектов геймплея, то есть
> может стоить изменить прототип сцены или
> переделать саму фишку. Или лучше потратить кучу
> времени на готовую сцену, а потом окажется, что
> задумка не работает, приехали, сцена, посреди
> сюжетной ветки, начинаем переделывать
Кто-же спорит! Конечно лучше - на кубиках все отладить а потом залить зараз готовым контентом. Но не все так идеально.
|
|
Отправлено 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 в 14:38
|
|
Я конечно, понимаю, что ситуации, когда нужно что-то на лету менять, так или иначе возникают. Но приведенный вами пример, это перебор. Потому что ФАН должен продумываться не на стадии реализации, и, разумеется на стадии сборки, отладки прототипа. В самом крайнем, крайнем, подеркиваю, случае, если уж зазудело добавить функциональности на этапе production, дизайнер СНАЧАЛА берет консультации у ответственных за реализацию - во сколько обойдется его фан, а потом обосновывает руководителю проекта - зачем это нужно. Если убедит и соотношение цена/качество, покажется руководителю разумным - вперед и с песней.
|
- Подписчики [581]
- Черный список [2]
Вы можете читать группу, но не можете отвечать на сообщения и создавать новые темы.
Доступ для остальных:
| анонимы |
: могут читать |
| новые |
: полный доступ |
| постоянные |
: полный доступ |
|
