Графический дизайн, арт игры, концепт, персонажи, текстуры, анимации, модели
GameDev.ru / Графический Дизайн / Статьи / Взаимодействие дизайнеров и программистов. Что требовать дизайнерам и как им облегчить свою жизнь.

Взаимодействие дизайнеров и программистов. Что требовать дизайнерам и как им облегчить свою жизнь.

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

Автор:

1. Введение.
3. То, что не любят дизайнеры.
3.5. Стандарты на данные.
4. Как помочь себе самому и защититься от лишних переживаний.

1. Введение.

Предупреждён — значит вооружён!
Предположительно советская пропаганда.

Статья эта посвящена, прежде всего, дизайнерам (моделлерам, текстурировщикам, аниматорам и другим представителям творческих направлений), которые  устраиваются на работу. Обычно это выглядит так – сидит человек, ковыряется в 3D Studio MAX или Maya у себя дома, достигает каких-то вершин, растёт так сказать. Друзья и знакомые хвалят его работы, и он решается попробовать применить свои навыки, например, на ниве игростроения. И тут возникают нешуточные конфликты, доходящие порой до непечатных слов и других неприятностей. Так что, чтобы вас не коснулась десница сия, просмотрите хотя бы те ситуации, о которых пойдёт речь в этой статье.

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

Практически вся статья ориентированна на людей, использующих 3D Studio MAX и начинающих работу в маленьких коллективах или небольших фирмах. Я более двух лет проработал в такой команде, хорошо знаю 3D Studio MAX, и вдоволь насмотрелся на то, как дизайнеры совершают маленькие ошибки, приводящие в последствии к большим проблемам.

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

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

Кое-какие слова, которые могут вызвать затруднение у тех, кто мало дела имел с играми:
•  Контент (content) — наполнение игры: уровни, персонажи, анимации, текстуры, звуки и т.д. Кстати, по-французски слово с таким написанием значит «довольный».
•  Лайтмап (lightmap) — карта освещённости, на ней нарисованы тени и круги света, которые потом наносятся на треугольники уровня.
•  Графический движок (graphics engine) — часть игровой программы, занимающаяся выводом картинки и всеми сопутствующими вещами.
•  Рендеринг (rendering) — процесс отрисовки картинки. Слово, конечно, знакомое. Я просто хотел сказать, что этот термин применим и к графическому движку – там тоже рисуется картинка.
•  Анимация (animation) — информация о движении одного или нескольких объектов. Иногда о движении части объекта. Например, информация о том, как движутся плечи, руки и голова при выстреле из пистолета. Просто люди иногда воспринимают этот термин как анимационный ролик, мультфильм, поэтому я комментирую – чтобы не было разночтений.
•  Дизайн-документ (design document), или еще его зовут «диздок» – это всеобъемлющее описание игры, содержащее сведения не только о глобальных вещах, вроде сценария, но и о таких конкретных, как «звук падения оловянной кружки на пол — похож на падение небольшого полого металлического предмета с характерным скрежетом».
•  Текстура (texture) — обычно в играх обозначает то, что дизайнеры привыкают называть «картой» (map). То есть это некоторое изображение, наносимое на поверхность. Понятие материала при этом остаётся неизменным – материал описывает свойства объекта по отражению, преломлению света и другие особенности поверхности. Материал включает в себя текстуры.
•  Запекание (baking) — обычно это слово применяется к технике, которую программисты зовут «отрисовка в текстуру». Суть запекания в том, что создаётся картинка для текстуры объекта, которая вбирает в себя раскраску всех его поверхностей и (/или) их освещение. Например, эта техника позволяет превратить процедурный материал в обычную текстуру.

И последнее. У меня по русскому языку была тройка. Так что я человек безграмотный, не пинайте уж сильно.

2.  То, за что не любят дизайнеров.

А за что их собственно не любить? Милые добрые люди, создающие внешний облик игры, которые зачастую нужнее и важнее всяких движкописателей, потому что они и только они вдыхают в килобайты кода жизнь. Но творческим натурам свойственна неорганизованность, от чего страдают все. Давайте, прежде всего, пробежимся по основным пунктам претензий.

2.1.  Структурирование контента.

Где у вас лежат текстуры? А где уровни? Модели объектов? Заготовки? Если у вас подобные вопросы вызывают сложности – вы еще не раз будете их испытывать.

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

Я часто спотыкался о то, что дизайнеры любят называть рабочие файлы всякими именами вроде «мой новый уровень» или «кусок уровня». Быть может, это изначально и был всего лишь кусочек локации, но оставлять подобное название надолго не стоит – это очень раздражает. Особенно это начинает раздражать, когда такие вещи попадают в систему контроля версий (о ней чуть поздней) и набор уровней превращается в кашу. В идеале в дизайн-документе игры можно найти рекомендуемые префиксы или имена файлов, относящихся к каждой игровой локации. Если их там нет – обсудите этот вопрос с другими людьми, и выработайте какую-то систему именования.

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

Еще не стоит забывать о возможности локализации игры. Если где-то в игре на текстурах сделаны надписи, обязательно храните такую текстуру с несмешанными слоями (это если Вы используете Photoshop). Хорошо бы также выделять текстуры с надписями в отдельную папку, что бы потом их можно было легко обработать. Кроме того, не используйте в названии файлов русских букв – такие файлы отвратительно себя ведут на иноязычных версиях Windows.

И последнее, на что я хотел обратить внимание – программистам свойственно не учитывать всё. Часто под это определение попадают очевидные для других вещи – например, что в именах файлов могут быть пробелы. Если ваши текстуры почему-то не попадают в игру мистическим образом, посмотрите, не связаны ли они друг с другом наличием пробелов в имени.

2.2.  Именование объектов и текстур.

Итак, вы делаете уровень для игры. Сетка уровня состоит из множества блоков и деталей, каждая из которых несёт какой-то особенный смысл.

По умолчанию имя нового объекта состоит из слова Object и номера объекта, который выбирает MAX (это, конечно, относится только к сеткам и полигональным объектам). Не сочтите за труд поменять это название на что-то более естественное. Это значительно облегчает, например, поиск ошибок в сборке ресурсов для игры, когда необходимо выяснить, какой именно объект уровня вызывает ошибку.

Договоритесь с остальными дизайнерами проекта и называйте текстуры уникальными названиями. При этом старайтесь избегать совпадений названий текстур, даже если они имеют один формат - a.jpg или a.bmp могут быть преобразованы в какой-то собственный формат и расширение файла может потеряться.

2.3.  Соблюдение масштаба.

Перед началом работ над первой же моделью, спросите, каков должен быть масштаб этой модели, уточните, в каких именно единицах вам его сказали. Если у вас совсем маленькая команда и программист, с которым вы работаете, обескуражен последним вопросом, значит, он использует обобщённые единицы MAX’а.

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

2.4.  Пропажа контента и резервное копирование.

Все думают, что это с ними не произойдёт. Однако подлый пушной зверь подстерегает вас повсюду. Мы тоже думали, что с нами такого не случиться. Однако за последнюю пару недель у нас сдохло два винчестера. А кроме того, примерно месяц назад мы потеряли локацию. Не в том смысле «потеряли» - что у неё был нитевидный пульс и электрошок тут не помог, а в том, самом настоящем, смысле. Никто не знает где она. В общем, чтобы успеть по срокам нам пришлось её исключить из игры, и, слава богу, что она использовалась один раз, и исключение её не нанесло вреда сценарию. (* Я писал этот документ достаточно долго, и вот спустя месяц после написания этих слов локация была найдена).

Все программисты (спросите любого) знают, что резервное копирование это хорошо. Возможно, некоторые приобретали CDRW, что бы делать резервные копии своих работ. Но многие ли их делают в реальности?

Если у вас в проекте практикуется резервное копирование – присоединяйтесь. Если нет – покажите примером, что для вас не безразлична судьба проекта и собственные нервы. Потеряв пять минут в день, вы сэкономите массу времени в последствии. Некоторые, особенно дальновидные издатели, требуют от своих подопечных команд ежедневного резервного копирования и хранения копии вне офиса.

2.5.  Сохранение этапов создания контента.

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

Конечно, можно возразить, что локации должны строиться по дизайн-документу, но молодым игровым дизайнерам сложно «в голове» просчитать играбельность каждой локации в голове. Поэтому одним из вариантов работы над ними может стать создание прототипа локации. И пока игровой дизайнер не убедиться, что локация играется превосходно, не заниматься ни текстурированием, ни проработкой деталей.

Есть у 3D Studio неприятная особенность – иногда он портит файлы, с которыми вы работаете. Так что кроме истории изменений локации текущее состояние лучше хранить в 2х или 3х вариантах.

Кстати, о порче файлов и о версиях 3D Studio MAX. Иногда можно прочитать то, что обычным способом не читается так: создаёте новый файл, и затем выполняете смешивание (merge file в меню file) с испорченным или файлом из новой версии.

2.6.  Использование систем контроля версий (VSS).

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

Есть множество разных вариантов систем контроля версий. Например, мы используем сейчас Visual Source Safe. Разобраться с ним нашим дизайнерам было несложно, однако некоторые проблемы возникали. Но самая серьёзная проблема была впереди. Когда размер данных превысил половину гигабайта, каждый забор новой версии становился потерей кучи времени. Сейчас объём уровней и текстур стремительно приближается к гигабайтной отметке и проблема времени работы с хранилищем файлов становиться всё острее.

В качестве альтернативы я бы предложил, например CVS в паре с TortoiseCVS. CVS умеет выполнять все необходимые действия, работает как в локальной сети, так и через Интернет (так что если вы захотите или вынуждены работать удалённо – то тут проблем не будет), и, кроме всего прочего, у TortoiseCVS простой и понятный интерфейс. Кроме того, это избавляет от необходимости дизайнерам работать в среде Visual Studio, что для них, в общем-то, противоестественно.

Говорят Subversion лучше работает с бинарными файлами, да и Microsoft на месте не стоит… В общем, выбирайте решение под свои нужды.

2.7.  Определение приоритетов и сроков исполнения.

Обычно программистский принцип планирования можно свести к разбиению задачи на участки, каждый из которых можно сделать за день. С графическим дизайном всё несколько сложнее и проще одновременно. Сложнее, потому что внутри каждого крупного задания (например, локации) часто приходиться возвращаться к, уже казалось бы, выполненным вещам, потому что находятся новые решения, которые хочется воплотить в жизнь. Проще, потому что результат можно «пощупать» — по крайней мере, бегло оценить в редакторе.

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

2.8.  Определение стоимости работы при работе вне коллектива.

Маленькое замечание о цене труда. Если вам сложно оценить, сколько будет стоить та или иная работа (а обычно заказчик требует такой оценки) – прикиньте время, которое на неё будет израсходовано, и пересчитайте это время на подневную зарплату. Например, если вы хотели бы получать 1000$ в месяц, то это значит что цена рабочего дня – 40$ (я грубо взял 25 рабочих дней в месяце). Рабочий день состоит из 8-и часов, что соответствует 5$ в час. Например, вы, как outsourcer или freelancer (кому как больше нравится), берётесь сделать текстуру. Это займёт по вашим расчётам 5 часов. Значит цена такой текстуре – 25$. Если Вы чувствуете себя не уверенно, и совесть не позволяет заламывать такую цену – подумайте, что именно столько бы вы получили, упорно работая в офисе, так что имеете полное право на соответствующее вознаграждение.

Причина, по которой я затрагиваю такую тему, проста. Человек, который не может внятно ответить на вопрос стоимости работы, вызывает ощущение непрофессионализма. Это может вообще очень пагубно сказаться на отношении к вам.

2.9.  Утверждение эскизов или прототипов.

Как я уже говорил, утверждай или не утверждай эскизы на уровень, всё равно окажется, что его надо подправить. Поэтому работу над уровнем хорошо начинать с прототипа уровня. Примитивная геометрия, передающая структуру закоулков и комнат, оттекстуренная нейтральной текстурой (например, клеточками) – самое то. На такой геометрии уже можно играть, для неё быстро рассчитываются лайтмапы, если вы их используете. И вообще, она приятна в работе, так как не тормозит в редакторе.

Кроме того, может быть полезным сделать наброски элементов уровня — например, кусочка улицы, дверного проема или других элементов. Но если вы сразу начнёте делать из этих кусочков полноценный уровень, вы можете почувствовать внутренний конфликт между навязанными решениями и собственными дизайнерскими идеями. Я часто видел, как дизайнеры из лучших побуждений делали части уровня не совсем так, как этого от них хотели. И потом оказывалось, что где-то на локации должен быть бар, но вот где он — никто точно сказать не может. В общем, что бы избежать подобных проблем, всегда поэтапно согласовывайте свою работу с тем, кто её будет использовать.

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

16 сентября 2004

#3D Studio MAX, #коммуникация

2001—2017 © GameDev.ru — Разработка игр