Войти
Уголок tool-программСтатьи

Китайский редактор уровней

Автор:

Некоторые соображения по поводу создания своего редактора уровней.

После появления самолетов возникла необходимость их уничтожения.

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

Что было не поздно, он поймет позже, когда после утверждения игры возникнет предложение переделать ее еще под 5 разных платформ с новой графикой, со спрайтами разного размера и с другим количеством кадров анимации. Также он поймет необходимость отделения блока работы с графикой и звуком в отдельную библиотеку, проигрывание эффектов по условиям и многое другое.

И на одной платформе, о которой он совсем не задумался, его ждет особый сюрприз. Та самая приставка, абсолютно никому не нужная и устаревшая десять лет назад, с убогой графикой, неинтересная с точки зрения, как программиста, так и аниматора с идеями сделать графику лучше, чем в фильме «Терминатор 2» с его 17 миллионами долларов только на 5 копий металлического дровосека, окажется самой распространенной и без версии под эту платформу игра, при всем своем великолепии красок, не принесет дохода совсем.

И в следующий раз он задумает сделать редактор.

Мы наш, мы новый…
Через тернии к звездам
Правило 80/20 и другие приключения Шурика
От слов – к делу
Первый блин – комом?
Сохранение данных.
И все вместе.

Мы наш, мы новый…

После осознания того факта, что дизайнер игр без редактора жалок, в следующем проекте этот редактор обязательно появится. И какой! А какой собственно? На этом этапе обычно рождаются два типа редакторов.

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

- Редактор содержит слишком мало функционала. В нем есть все основные (по мнению программиста функции), но нет одной - двух мелочей, тех самых, с которыми дизайнер просидит 90% времени при создании уровней игры, например подгонка 100 спрайтов на одном экране друг к другу.

- Редактор содержит слишком много функционала. В своем стремлении улучшить, глобализовать и усовершенствовать редактор программист заходит слишком далеко. 70% функционала

- Редактор не работает. Те самые 30% функционала редактора, с которыми дизайнер будет работать 90% времени попросту не работают. Или работают, но, так как это увидел программист, и мысль его потекла по тому руслу, куда дизайнер побоится заглянуть даже в танке с вертолетной поддержкой. Вроде бы функционал есть, но те 100 переменных которые надо настроить пугают своим количеством и неопределенностью. А к чему это все приведет? Мышление программиста глобально, он стремится сделать редактор, который позволил бы дизайнеру сделать все и на всякий случай даже больше, чтобы теперь уж точно дизайнер не смог пожаловаться на отсутствие «фич», но продукт получается слишком сложный и работать с ним невозможно.

Mister it’s all about nothing. В редакторе вроде что-то есть, но собрать на нем невозможно полностью даже самый простой уровень. Может быть забыли сделать сохранение. Или самое простое – расстановку стационарных элементов уровня. Или еще несколько мелочей. На фоне ярких «фич» все это кажется несущественным и неважным, и когда-нибудь это превратится в коммерческий продукт и будет продано отдельно и за баснословные деньги. Но сегодня он просто не работает. Без комментариев.

Через тернии к звездам

Итак – как же написать редактор для дизайнера? Ответ на этот вопрос, возможно, знает дизайнер. Если посмотреть на его уверенность в этом, можно успокоиться и просто выполнить все его просьбы. И… все счастливы?

Нет, поскольку дизайнер на самом деле не знает, что ему нужно. Все что он знает – это необходимость побыстрее приступить к самому дизайну, поскольку бумага уже заканчивается, а к проекту даже не приступали. В его голове уже ворох идей, которые рвутся и требуют воплощения. И на этом этапе его встречает сиамский близнец, плод совместного труда его и программиста, содержащий все заказанные «фичи», все придуманные программистом «фичи» и просто «фичи» на всякий случай, о причинах появления которых программист не может, по сути, сказать и слова. Сами появились.

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

Правило 80/20 и другие приключения Шурика

После зализывания ран и синяков программист и дизайнер, если они не поссорились окончательно, приступают к новому проекту. Рождена в муках новая идея, пора писать диздок и… создавать редактор? Кто чем займется и в какой последовательности? Единственно правильный ответ – сначала должен быть написан диздок, полностью, от и до, и участвовать в этом должны оба. И только после утверждения финальной версии документа программист имеет право приступить к редактору. А чем заняться дизайнеру? Тем же, писать редактор и тестировать его на каждом этапе. Дизайнеру на этом этапе необходимо включить свою фантазию на полную катушку и совсем забыть о том, что перед ним совсем не команда Microsoft, а один программист, самые сумасшедшие его идеи на практике могут быть осуществлены гораздо быстрее, чем отдельные, сугубо специализированные фичи для этого проекта, одна относительно сложная функция сможет заменить десять мелких. И даже в том случае, когда десять мелких в сумме займут меньше времени, выбрать нужно более сложную, и вот почему:

— ошибки, в каждой функции каждого программиста обязательно бывают ошибки, и исправление их в десяти разных местах существенно затормозит проект. Особенно с условием того, что программист думает, что если дизайнер жалуется на функцию А, то ошибку исправить надо именно в ней, а дизайнер наивно предполагает, что исправление в функции А приведет к исправлению функционала во всех остальных сходных местах. Чтобы этого не было, схожих функций быть не должно совсем, только одна, которая отвечает сразу за все действия. Тогда все инструменты будут стандартизированы и работать одинаково, одинаково правильно или одинаково неправильно, одинаково хорошо или одинаково плохо, одинаково сложно или одинаково просто, но одинаково.

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

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

— в следующем проекте выяснится, что старый редактор содержит массу необходимых функций и для нового проекта, и на их реализацию не было и не будет потрачено ни одного часа.

Страницы: 1 2 Следующая »

11 октября 2007

Комментарии [24]