Комментарии к статье
А вы что в эти метафоры вкладываете? Что это как бы два противоположных полюса деятельности? Физика и Лирика, условно говоря?
Игорь Пасичный wrote:
> О гибкости каждый должен думать сам, да изменения могут быть на каждом шаге, если они целесообразны Ok. Спасибо за продуманный перечень работ по левел дизайну. Как базовый набор - вполне хорошо. > И вообще, есть желание делитесь опытом, осветите > что и как лучше по вашому, по-моему, для этого и > нужно обсуждение. Я уже осветил свое мнение - процесс должен отталкиваться от особенностей и опыта имеющихся людей, которым с этим процессом работать. Плюс прочих ограничений. Сорри, что никакой формальной методикой это передать не могу. Только опыт.
Dmitry Voronov wrote:
> А вы что в эти метафоры вкладываете? Что это как > бы два противоположных полюса деятельности? > Физика и Лирика, условно говоря? Design vs. Production - это две крайности, характерезующие процесс разработки. Истина как всегда в гибкости и балансировании между ними. Production - это предсказуемый жесткий серийный процесс. Design - куча итераций в разработке частей и куча итераций в интеграции этих частей. Поиск золотой жилы там, где это решает. Естественно, в реальном процессе пресутствуют оба этих полюса. Имхо, можно составить формальный перечень работ и обязанностей для команды (узлы графа). Можно составить даже набор микропроцессов (куски графа). А вот итерациями по переделке (перезапуску микропроцессов) придется руководить гибко на лету. "Сказали переделывать или видишь что ударное место надо сделать лучше - переделывай".
Игорь Пасичный 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 можно пролюбить - но это решается административными мерами.
Классическое сетевое планирование работ по проекту, но с использованием веба…если используете какой-то проверенный софт, и он не написан чисто вами, дай ссылку, пожалуйста, посмотрю, хочу посмотреть его реализацию.
Игорь Пасичный wrote:
> Классическое сетевое планирование работ по > проекту, но с использованием веба Ок, основную идею я донес - дальше подробности. Отличие от классического - в деталях. Во первых, классическое - оно скорее 1) ригидное 2) стратегическое 3) инициатор - менеджеры Предложенный подход - подход о микропроцессах и тасках. Он 1) динамичный 2) тактический 3) инициатор - рядовые творческие сотрудники, которые реализацией идеи саму идею трансформируют и улучшают. Понять это может поможет слудующая деталь. Заводятся workgroups, в каждой из которой назначаются leads. Каждый таск может иметь состояния (набор состояний лучше откорректировать под свою ситуацию): предложен/открыт/работа/решен/закрыт/отложен. Предложен - это собственно процесс "кристализации". Когда создается скелет графа. Люди выбирают себе субподрядчиков, субподрядчики оценивают объемы работ. (Все это посреди процесса разработки, а не только на начальных этапах!) Когда граф сформировался и все его таски влоть до листовых оценены по времени, статус задач из "предложен" можно перевести либо в "открыт", либо в "отложен". Т.е. когда lead "открывает" свою root задачу, открываются все задачи в подграфе, которые назначены данной workgroup. если есть задачи, зависящие от других workgroup - они не откроются, пока этого не сделает соответствующий lead. Т.е. это "одобрям" всех отделов. Задача может быть "отложена" - т.е. feature cut только что сгенерированной идеи. Когда все подзадачи "открыты" - вся ветка автоматом переходит в статус "работа". "закрыт", "решен" - субподрядчик может только "решить" задачу. "закрыть" ее может только заказчик (или открыть заново, если решена не качественно - тут почти как в Mantis). > если используете какой-то проверенный софт, и он не > написан чисто вами, дай ссылку, пожалуйста, > посмотрю, хочу посмотреть его реализацию. В общем я не в курсе - существует ли такой. Конечно по ключевым словам Workflow, BPM, HIM есть много информации, но ничего конкретного из решений я пока не нашел.
Игорь Пасичный wrote:
> используете какой-то проверенный софт, и он не > написан чисто вами, дай ссылку, пожалуйста, > посмотрю, хочу посмотреть его реализацию. p.s. Вообще конечно самая правильная идея - это встроить подобную систему прямо в редактор игры. Это даст массу бонусов - можно ссылаться на единцы контента, ассеты, объекты игрвых уровней, placeholder'ы (на уровне ядовито-зеленый флажок "а тут должен быть тот мост") прямо в тексте задач и уведомительных сообщениях гиперссылками. Т.е. в тексте задачи кликнул - камера редактора уже кажет тебе этот объект.
Спасибо.
Идея довольно интересная с редактором…можно сделать автоматическое документирования задач с приоритетом их решения.
Игорь Пасичный wrote:
> Идея довольно интересная с редактором…можно > сделать автоматическое документирования задач с > приоритетом их решения. Только учти что документация - пассивна. Всплывающие мессаджи (аля "вам 11 личных сообщений") - активны, если в них встроены гиперссылки ответного действия. Т.е. одно дело если lead просматривает списки "предложенных" задач иногда, а другое - когда lead'у при входе в систему появляется всплывающее окно от сотрудника "открой прдложенную задачу [ссылка на задачу] с кнопками/гиперссылками [открыть][отложить][напомнить через ... часов]. Т.е. основной смысл - это сообщения, которыми сотрудники и система побуждают друг друга к действию.
Я конечно, понимаю, что ситуации, когда нужно что-то на лету менять, так или иначе возникают. Но приведенный вами пример, это перебор. Потому что ФАН должен продумываться не на стадии реализации, и, разумеется на стадии сборки, отладки прототипа. В самом крайнем, крайнем, подеркиваю, случае, если уж зазудело добавить функциональности на этапе production, дизайнер СНАЧАЛА берет консультации у ответственных за реализацию - во сколько обойдется его фан, а потом обосновывает руководителю проекта - зачем это нужно. Если убедит и соотношение цена/качество, покажется руководителю разумным - вперед и с песней.
Dmitry Voronov wrote:
> Я конечно, понимаю, что ситуации, когда нужно > что-то на лету менять, так или иначе возникают. > Но приведенный вами пример, это перебор. Все конторы слишком разные. Согласен - для кого-то это может быть перебор. > Потому > что ФАН должен продумываться не на стадии > реализации, и, разумеется на стадии сборки, > отладки прототипа. Тут я не согласен. 1) Нельзя продумать все с точностью до мелочей на три года вперед. Есть конечно профи, но они скорее стратегическими решениями занимаются. Плюс есть базовый геймплей, а есть побочные вещи - тупой контент, элементы уровней. Уникальные моменты. То что делает игру не нудной и разнообразной. За это и боремся. Например в zuma - голая базовая идея геймплея и никакого контента (уровней). В rpg все с точностью до наоборот. Базовый геймплей конечно есть (rpg система) но вот квесты, ролики, npc, интерактивность sandbox мира - все это надо делать. 2) Мы боремся за скоращение времени разработки. Данный подход позволяет производить preproduction/production внахлест. Т.е. границы размываются - в предельном случае ускорение в два раза (т.е. WYSIWYG - то что сделал, тут же в игру и пойдет). на практике все конечно сильно хуже и зависит от инструментария. но тут все решаемо (пусть и дорого). > В самом крайнем, крайнем, > подеркиваю, случае, если уж зазудело добавить > функциональности на этапе production, дизайнер > СНАЧАЛА берет консультации у ответственных за > реализацию - во сколько обойдется его фан, а > потом обосновывает руководителю проекта - зачем > это нужно. Если убедит и соотношение > цена/качество, покажется руководителю разумным - > вперед и с песней. Смотрите формальный подход со статусом задач "предложен"/"открыт"/"отложен". Это оно.
Написал немного об используемом мною инструменте для создания 3д скетча уровня (SketchUp):
http://dtf.ru/blog/read.php?id=43522 Надеюсь, будет полезно кому-нибудь.
+1
Dmitry Voronov wrote:
> > Я конечно, понимаю, что ситуации, когда нужно > что-то на лету менять, так или иначе возникают. Ты возможно лучше даже Лехи знаешь, что скорее, как правило получается именно "на лету". > Но приведенный вами пример, это перебор. Потому Не перебор. реально работает и побеждает. > что ФАН должен продумываться не на стадии > реализации, и, разумеется на стадии сборки, > отладки прототипа. В самом крайнем, крайнем, > подеркиваю, случае, если уж зазудело добавить > функциональности на этапе production, дизайнер > СНАЧАЛА берет консультации у ответственных за > реализацию - во сколько обойдется его фан, а > потом обосновывает руководителю проекта - зачем > это нужно. Если убедит и соотношение > цена/качество, покажется руководителю разумным - > вперед и с песней. Именно такая схема более громоздкая и медленная, как следствие, в результате. Принцип "пушш, пушш ми бэби" работает гораздо быстрее и это уже не теория а жесткая практика. В сроки так и эдак закладывается "п..б". Впрочем как и в деньги:) Леха очень грамотно все разъяснил+потратил массу времени и байт за что ему респект большой должен быть от аудитории читающей:) p.s. По моему, обсуждение статьи было интереснее самой статьи в несколько раз, в основном, благодаря Дмитрию и Алексею. Что не умаляет заслуг автора ни в коем случае. |
 Списки доступа
Права доступа
Вы можете читать группу, но не можете отвечать на сообщения и создавать новые темы.
Доступ для остальных:
|
Copyright © 2021 ООО "ДТФ.РУ". Все права защищены.
Воспроизведение материалов или их частей в любом виде и форме без письменного согласия запрещено.
Замечания и предложения отправляйте через форму обратной связи.
