( или, по крайней мере, не была лажей )

Демодизайн для начинающих

Введение

- Не делайте как делаю я, делайте, как я говорю

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

Заметьте, я не собираюсь кидаться на новичков с упреками. Мы все когда-то ими были, неопытность - это не то же самое, что глупость или тупость и т.д. Я, на самом деле, хороший и дружелюбный товарищ, так что, пожалуйста, не воспринимайте критику слишком строго. Отклики, флейм, критика, вопросы и прочее горячо приветствуются, вы можете (даже должны) послать мне e-mail по адресу mnurmika (at ) cc.hut.fi.

Кто я такой? Мое настоящее имя Martti Nurmikari, сейчас мне 22 года и я учусь в Технологическом институте в Хельсинки. На сцене я с 1995-го, хотя сам еще (пока) особенно много не сделал. В данный момент я являюсь кодером в Traction.

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

Итак, ближе к делу. Сначала мы поговорим о самой важной вещи:

Зачем делать демки

- Я делаю это по воле дьявола

Есть много причин, по которым люди интересуются сценой. Я был привлечен сюда, когда позаимствовал у своего друга CD с GUS-драйвером и обнаружил на нем Crystal Dreams II и Second Reality. Полагаю, многие начинали таким же образом: они видят демку и думают, что это здорово. В тот момент, когда я увидел CD2, я понял, что тоже хочу делать что-то подобное. Но какие бы причины у вас ни были, убедитесь, что они для вас ясны.

По моему мнению, в основе своей существует два типа групп. Первым типом является группа друзей, которые только что решили заниматься сценой. Большинство из этих групп довольно маленькие, вероятно, они не так талантливы как "супергруппы", но зато у них больше энтузиазма. Большинство демогрупп относится именно к этой категории. Вторым типом группы является супергруппа. Они часто бывают международными, у них очень талантливые члены, они очень уважаемы. В качестве примера можно упомянуть Haujobb, Farbrausch, Sunflower и им подобных (и все группы, в которых состоит Visualice ;))

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

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

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

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

Теперь без излишних церемоний приступим к делу.

Как добиться стабильной работы и хорошего поведения демы

- Хм, она же работает на МОЕМ компьютере!

Если вы хотите оказать (положительное) впечатление на зрителя, первым делом следует убедиться, что он действительно сможет посмотреть вашу работу. Вот несколько моментов, которые нужно постоянно держать в голове:

Думайте перед тем как пробовать

Пожалуйста, сделайте проверку тех вещей, которых может не оказаться, например, OpenGL-расширений или определенного железа. Тогда вы не будете выглядеть посмешищем в глазах людей, у которых нет этого наисовременнейшего оборудования. Лучше получить сообщение "извините, но нашей демке требуются вертексные шейдеры, которые у вас, похоже, отсутствуют", чем вернуться в Windows или лицезреть сплошной черный экран вместо демки. Убедитесь только, что ваши проверки действительно работают, я знаю, по крайней мере, две демки, которые жалуются на то, что мой компьютер не поддерживает мультитекстурирование (одна из них даже делает предположение о том, что я бедный, поскольку не могу приобрести нормальную видеокарту, причем дема 1999-го года). У меня всего лишь GeForce 2, однако я нисколько не сомневаюсь в том, что он способен выполнять мультитекстурирование.

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

Сообщения об ошибках

Одним из самых загадочных проявлений современного демокодинга является тот факт, что некоторые не помещают в свои работы сообщения об ошибках. Я могу понять это, если речь идет о 64k или 4k интрах, в которых важен размер кода, но как насчет демок и финальных версий интр? Ничто так не раздражает, как черный экран или падение Windows во всей красе без какой-либо информации о причинах ошибки или возможном решении проблемы. То, что первая версия вашего демо-движка свободно работает на вашей машине еще не означает, что вам не следует контролировать ошибки.

Кроме того, пишите сообщения об ошибках на английском. Зрителю будет мало пользы, если ваша дема вывалится с messagebox-ом, в котором говорится "przsyf placfz!!1" (поляки, без обид :))

Диалоги с конфигурацией

Пожалуйста, сделайте такой диалог. Я не желаю смотреть вашу демку на 640x480x16 бит. Или на 120 Гц, которые не поддерживает мой монитор.

DOS

Пожалуйста, больше никакого DOS. У нас 2004-й год. Или, если вам это необходимо, хотя бы убедитесь, что она работает под Win2k/XP, иначе многие не смогут ее посмотреть. К счастью, у нас теперь не так много работ под DOS, за исключением моей 4K-интры, но там был древний код для реального режима и я даже хотел ее зарелизить :) (pot kettle black...)

ESC

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

Переключение режима экрана

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

Требования к аппаратуре

Современные демки стремятся многого требовать от железа. Это, конечно, можно понять, поскольку у большинства народа есть быстрые процессоры и куча памяти, и я вовсе не против этого. Тем не менее, примите к сведению, что многие люди все еще используют карты класса GeForce 2. Если вы используете пиксельные и вертексные шейдеры для чего-то грандиозного вроде эффектов искривления, огня или воды, то пожалуйста. Если же вы используете их для закраски Гуро, подумайте, действительно ли они необходимы или добавьте опцию для остальных нас. Хотя я думаю, в ближайшее время все изменится, поскольку все больше и больше людей апгрейдит свое железо (если честно, я бедный студент и не могу позволить себе Geforce 4 :)). С другой стороны, хорошим примером превосходного использования шейдеров является Planet Risk от Andromeda Software Development. Если вы можете сделать вашу работу столь же достойной - тогда вперед!

К счастью, эпоха Windows дала нам демо-продукцию, которая "ведет" себя в известной степени примерно. Сегодня малое количество работ имеет какие-то проблемы, так что те, кто помнит времена UniVBE и GUS, вероятно, довольны теперешним положением дел. Кстати, хотел бы сказать, что я восхищаюсь теми, кто пишет программы, не убиваемые с помощью ctrl+alt+del под Windows NT/2k... :) (Может быть, кто-нибудь напишет статью о том, как это делается? Это выше моих сил).

В качестве примера демки, которая здорово выглядит, но которую сложно заставить работать, я упомяну пользующуюся дурной репутацией Optic Nerve с Asm'93. Я слышал, что она действительно хорошо смотрится. Но я не уверен в этом, поскольку никогда не видел ее и не знаю кого-либо, кто может заставить ее работать. Навряд ли вы захотите, чтобы такое случилось с вами.

Утечки памяти и указатели

Самая обычная/раздражающая причина падения программы. Ваша демка отхапала 140 системных мегабайт и высвободила лишь 80, или ваши указатели стали указывать на что-то неверное. Если программа не упадет после выхода или во время исполнения, система непременно начнет еле-еле ворочаться и умрет после просмотра нескольких демок с такими гадостями. Поэтому обзаведитесь менеджером памяти и начните проверять использование памяти вашей программой. Мы крепко зарубили это себе на носу, поскольку парочка наших ранних демок грешила этим делом. Ситуаций с перезагрузкой компьютера после просмотра демы быть не должно.

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

Визуальный дизайн

- Я дальтоник и часто кушаю на завтрак ЛСД

Цвета

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

Четыре основных правила:

1) НИКОГДА НЕ ИСПОЛЬЗУЙТЕ ЧИСТЫЙ КРАСНЫЙ RGB-ТОН.
2) НИКОГДА НЕ ИСПОЛЬЗУЙТЕ ЧИСТЫЙ ЗЕЛЕНЫЙ RGB-ТОН.
3) НИКОГДА НЕ ИСПОЛЬЗУЙТЕ ЧИСТЫЙ СИНИЙ RGB-ТОН.
4) НИКОГДА НЕ ИСПОЛЬЗУЙТЕ ЧИСТЫЕ ТОНА КРАСНОГО, ЗЕЛЕНОГО И СИНЕГО В КОМБИНАЦИИ, ПОЭТОМУ НИКАКОГО ЧИСТОГО ПУРПУРНОГО ЦВЕТА, ЧИСТОГО ЖЕЛТОГО ИЛИ ЧИСТОГО СИНЕ-ЗЕЛЕНОГО.

Отныне мы будем называть эти цвета кодерскими цветами. Старайтесь всячески избегать их, если только они не нужны вам очень-очень сильно (трижды подумайте) - и даже в этом случае постарайтесь обойтись без них. К тому же они считаются отличительной чертой новичков, так как многие руководства используют их в демонстрационных целях - визуальный дизайн там не важен. Конечно, от них будет тошнить любого, кто станет смотреть вашу работу.

Если вы хотите, чтобы ваша демка была красной, зеленой или синей, ничто не должно вас удерживать, однако добавьте еще немного других цветов, это сразу сделает картинку более приятной для глаз. Вместо цветовых коэффициентов 1.0, 0.0, 0.0 используйте что-нибудь вроде 0.9, 0.2, 0.15.

Следующей вашей задачей будет отыскать картинку, которая вам нравится. Нет, я имею в виду не этих милых японских девочек на вашем хард-диске, а настоящие картины. Вроде живописи и тому подобного. Занимаясь кодерской/дизайнерской работой, нужно так относиться к визуальной составляющей, как если бы вы на самом деле писали картины. И верьте мне или нет, но здесь есть правила, которые ясно говорят, что вы должны делать и чего вам делать не следует. Я не художник, однако люблю посещать выставки и галереи живописи и осмелюсь сказать, что я кое-что понимаю в данном творчестве. Я предлагаю вам отправиться в местный художественный музей, не только чтобы развлечься, но и в образовательных целях (плюс к этому, вы сможете произвести впечатление на определенного типа девушек ;)). Многие скажут, что это скучное занятие, тогда попробуйте пойти один, а не с мамой - есть шанс что вам понравится.

Теперь, когда вы нашли картину, которая пришлась вам по душе, займитесь ее исследованиями. Лежат ли в ее основе кодерские цвета? Если так, то боюсь, ничем не могу вам помочь, могу только посоветовать продолжить ваши кодерско-математические занятия и оставить дизайн для других. Теперь подумайте, ПОЧЕМУ вам понравилась эта картина. Из-за освещения? Из-за использования цветов? Они холодные или теплые? Какие чувства вызывает у вас эта картина? Определите свои собственные предпочтения и подумайте, как вы могли бы применить похожие идеи в вашей демо-продукции.

Одно следует подчеркнуть особо: я отрицательно отношусь к радужной расцветке. Обычно это на самом деле кошмарно выглядит. Если только профессионалы не сделали это нарочно. К примеру, посмотрите 232 от Ainc. В ней использованы ЧРЕЗВЫЧАЙНО психоделичные цвета. Ко всему прочему, это очень-очень классная демка, я всем рекомендую ее скачать и посмотреть. Но присмотритесь внимательно, здесь у них тоже нет всей палитры солнечного спектра. Несмотря на то, что демка практически истекает кислотностью и глючными картинками, у нее продуманная цветовая схема. И хотя в ней есть кое-какие блики из чистых RGB-цветов, они не слишком выделяются.

Композиция

То, что я говорил о выборе цветов, подходит и для композиции. Определенно, имеет значение, в какое место на экране вы определите всю эту кухню. Чтобы это понять, просто представьте, на что будет похожа ваша любимая демка, если бы все эффекты работали в левой части экрана. И снова, смотрите и учитесь. Постарайтесь, чтобы это смотрелось живо. Вот простой и полезный совет: не помещайте эффекты, вращающиеся объекты и тому подобное точно в центр экрана. Если вы сделаете все верно, визуальный ряд получит некоторое разнообразие. Кроме того, чуть-чуть подвигайте объекты туда-сюда.

И что самое важное, просматривайте демки. Много демок. Начиная с продукции восьмидесятых годов и заканчивая работами с последних пати. Размышляйте, почему они хорошо выглядят (если это так). Постарайтесь избежать восклицаний вроде "боже мой, это же супер-маппед гипер-загогулина, да еще со сверкающими отражениями!!!" и взгляните на общую картину. Частенько вы сможете увидеть вещи, которые можно было бы улучшить. Для этого нужно только немного подумать.

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

Значение визуального ряда

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

Предположим, у вас есть код, который выполняет поворот и маппинг 3d-объектов. Ну, как обычно. Какие объекты вы собираетесь показывать? У всех есть искажающиеся плазменные шарики, поэтому они вряд ли вам подойдут. Шутки ради могли бы сгодиться Duck.3ds или chrome.3ds, но на большее с ними рассчитывать не приходится. Поэтому, поскольку вы кодер, вы выбираете... шарики с шипами в стиле Haujobb. Не такой уж плохой выбор, если они вписываются в ваш дизайн. Но что если вы выберете что-то привычное людям? Например, голову клоуна? Или Бетховена, как в новой деме Condense. Если вы хотите, чтобы народ застонал от изумления, гораздо надежнее закрутить Бетховена, а не какой-то "объект типа голова".

Продолжим наш пример. Предположим, вы улучшили вашу процедуру и добавили возможность морфинга из одного объекта в другой. К тому же, вы добавили код, позволяющий вам выдавливать колючки на поверхности объекта. Будучи сообразительным дизайнером, вы знаете, что вам следует показывать колючки не сразу, а только после того, как основной эффект какое-то время отработает. Ладно, вот вам упражнение. Как вы думаете, какая последовательность морфинга лучше?

A) Логотип вашей группы - куб - узел из тора - утка - Бетховен - самолет - шарик (появляются колючки) - загогулина в Haujobb-стиле - голова человека.

B) Логотип вашей группы - голова человека - бабочка - голова кошки - голова шипящей кошки - Альберт Эйнштейн - Джордж Буш - (появляются колючки) - Адольф Гитлер - скелет.

Подумайте.

Символы

Это развитие предыдущей идеи. Используйте то, что знакомо людям, используйте что-то, имеющее реальный смысл. В коллективном бессознательном людей есть то, что можно использовать в своих целях. Здесь уместно вспомнить крест, символ бога у Хинди, символ пацифистов, розу и пентаграмму. Они действительно имеют значение для людей. Только учтите, что если в своей демке вы изобразите пылающий крест, то можете оскорбить некоторых зрителей.

Окей, теперь у нас есть это, это и это, что дальше?

- Я чувствую, что на этот раз мы победим

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

Теперь у вас проблемы. Согласно демосценическим традициям, эффекты следует разместить друг за другом, фоном запустить музыку, а между эффектами показывать картинки. Это плохо. Почему? Потому что в этом случае нет цельности, и в результате это будет выглядеть паршиво. Если только ваши эффекты не сверх круты, хотя даже и в этом случае кое-какой дизайн не помешал бы.

Посмотрите любую хорошую демку. Действительно, подойдет любая демка, которую вы считаете очень хорошей. Что вы видите? Цельность. Два простых примера: Protozoa от Kewlers - очень органичная, в основном, в зеленых тонах, а вот Dreamchild от ASD полна мечтательности и в синих оттенках. А что там у вас? Мотоцикл, дракон и полуобнаженная тетенька. И дерево. Какая между всем этим связь? Никакой. Причем абсолютно. (Хотя можно себе представить парня, едущего на мотоцикле, он видит дракона, бросается в панику и съезжает с дороги, врезается в дерево, умирает и в итоге оказывается с обнаженной дамой на небесах. Но это не в счет).

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

Лучший способ делать что-либо - это сделать первоначальный вариант, потом организовать собрание и решить, чем вы хотите заняться. Хотите вы сделать техно-дему, или демку для релакса, или минималистичную анти-капиталистическую черно-белую демку с фоновым трип-хопом и серьезными воззваниями? Определитесь с этим и подумайте, что бы вы хотели увидеть в подобной демке.

Что делать не надо

- Что значит "эта вещь дерьмо и уже видена сто раз"?

Есть отдельные вещи, которые мне не нравятся. Это, по-большому счету, дело вкуса, так что не принимайте все за истину (как вы обычно и делаете :))

Сцены с объектами с пространственным мэппингом в центре и всякой всячиной, крутящейся вокруг них

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

Повторения

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

Сценическая поэзия

Если вы талантливый писатель, то тогда непременно запишите ваши глубокомысленные тексты и поместите в свою продукцию. Если нет, то или возьмите текст у кого-нибудь другого или молчите и не рыпайтесь ;)

Чтобы показать, насколько это может быть плохо, я дам два примера из жизни:

"постарайтесь понять нас
больше у вас не получится
всего одна попытка
со всей ясностью
параноидально
безумно

прямо над нами
крушенье
прямо сейчас разделились
здесь и сейчас"

хм... ну как?

и

"Смерти глотки
наши предки
по крови
не могли бы предвидеть
крушенье
тело разломано
душа пылает
и остаются
лишь образы"

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

Я иногда раздумываю, как было бы здорово иметь генератор сценической поэзии и использовать его в работах. Не нужно ни о чем думать, можно было бы даже сделать так, чтобы при каждом запуске выдавались разные тексты :) Есть одна интра австрийской группы 0x7a69.au, в которой есть такая штука. Интра называется pOetry, ее релиз состоялся на Asm'2k. Взгляните на нее, чтобы узреть действительно ПЛОХИЕ тексты.

Зубцы

Сейчас, когда мы все используем полигональную аппаратную поддержку, вам может оказаться полезным отправиться в небольшое путешествие в прошлое. Пойдите отыщите демку с 3d-графикой времен 1994-1998 и запустите ее. Эти нефильтрованные полигоны выглядят ужасно, правда? Хорошая новость заключается в том, что с современной аппаратной акселерацией нам больше не нужно беспокоиться о подобных вещах... Так? Правильно?

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

glHint(GL_LINE_SMOOTH_HINT, GL_NICEST);
// скажите openGL, что вам требуются красивые линии, а не быстрые.
// Детали зависят от железа и драйвера

glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
// используйте GL_ONE если вам нужен аддитивный цвет

glEnable(GL_LINE_SMOOTH);
// волшебный бит

glEnable(GL_BLEND);
// AA-линии не получатся, пока вы не включите смешивание

glDisable(GL_TEXTURE_2D);
// просто обычные белые линии, благодарю вас.

glColor4f(1,1,1, alphavalue);
// убедитесь, что указали alpha-канал

glBegin(GL_LINES);

glVertex3f(vertex1.x, vertex1.y, vertex1.z);
// действительно, нужно использовать glVertex3fv(), или вертексный буфер

glVertex3f(vertex2.x, vertex2.y, vertex2.z);

glEnd();

Можете делать rip'n'paste и не благодарить меня. Правда, я настаиваю, чтобы вы именно так и поступили. Я ничего не знаю про Direct3D, однако, сомневаюсь, что там это намного сложнее сделать. Просто запомните, что рисование AA-линий медленнее простых, поэтому, если у вас гигантское количество линий (скажем, вы пишете один из имитаторов волосяного покрова), решение остается за вами.

В качестве простого примера отвратительных линий посмотрите работу Zoom 3, победившую на Asm'03. Да, в остальных отношениях она прекрасна, но эти линии просто... непривлекательны, вы не это хотите сказать?

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

Артефакты масштабирования

Пожалуйста, не делайте слишком большое увеличение. Особенно в том случае, если вы увеличиваете какой-нибудь логотип размером 160x100, так вот, не пытайтесь заполнить им весь экран. Никакой мипмэппинг, молитвы или магия не спасут вас от эффектов фильтрации, которые обычно портят картину. Повторяйте за мной, пожалуйста: они будут выглядеть плохо. Что касается текстов, используйте векторные шрифты, и данная проблема легко разрешится.

Кроме того, запомните, что "четные" коэффициенты масштабирования обычно выглядят лучше. Предположим, у вас есть картинка 64x64, и вы хотите чуть-чуть увеличить ее на экране. С размером 96x96 у вас это получится лучше, чем с 77x77. Современная билинейная фильтрация позволяет компенсировать подобный недостаток, так что теперь это, может быть, и не так важно, но все равно будьте начеку.

Битые блики

Удивительно, но это происходит сплошь и рядом. Посмотрите вашу демку в темной комнате на максимальной яркости экрана и вы, возможно, заметите, что ваши блики на самом деле не блики, а блоки. Если цветовое значение на границе вашего блика отличается от 0, в определенных световых условиях вы получите уродливые границы. Хотя дело легко поправимо (и не забудьте пнуть вашего художника за то что он подсунул вам плохие картинки). И пока вы занимаетесь исправлениями, возможно, сами откажетесь от бликов. Да, они могут быть прикольными, но сегодня эта тема СЛИШКОМ избита. Если вам во что бы то ни стало необходимы блики, то вместо использования статичных битмапов попробуйте выполнить анимацию бликов из полигонов или линий. Чтобы они работали быстро, используйте текстуры низкого разрешения вроде 64x64, 32x32 или даже 16x16. Если они будут двигаться, никто не заметит разницы.

Скованное движение

Когда вы прорабатываете движения камеры, убедитесь, что они получаются плавными. Простая линейная интерполяция от точки A до точки B по прямой обычно выглядит ужасно, тем не менее, она все еще встречается в современных работах. Научитесь пользоваться сплайнами или кривыми Безье, их не так трудно освоить. Вам даже не потребуется вникать в их математическую подоплеку, чтобы научиться использовать (хотя это, конечно, будет нелишне). Если вы пишете под OpenGL, познакомтесь с вашим новым другом по имени gluLookAt().

Совет: плавного перемещения можно добиться с помощью синусов и косинусов. К примеру, если у вас есть значение, линейно изменяющееся от 0 до 1, вы можете сделать так:

float newval = sin(interpolation_value * pi * 0.5f).

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

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

Плоскости отсечения

Вам ведь известно, что такое плоскость отсечения, не так ли? Если нет, то я вам объясню. Это такие плоскости в 3d-пространстве, которые определяют видимую для вас область. У вас их имеется пять (передняя, левая, правая, верхняя, нижняя) или шесть (эти пять и задняя плоскость). Теперь, если вы их плохо определите, фрагменты ваших объектов могут испариться прямо в воздухе. Смотрится это дело неважно. Особое внимание уделите фронтальной плоскости отсечения.

Движения камеры

Не двигайте камеру сквозь объекты если вам это не нужно. Если в вашей сцене есть пол, убедитесь, что камера не проходит сквозь него. Держите ее достаточно далеко от объектов, дабы избежать противных глюков с отсечением (смотрите выше). И помните, что если в вашей сцене или объектах есть кривые "фичи", то вы можете избавиться от них просто не направляя на них камеру. Обман? Возможно. Ну и что?

Мерзкие повороты

Если вы делаете показ объектов, то, вероятно, пишете это подобным образом:

for (i=0;ixpos, objects[i]->ypos, objects[i]->zpos);
objects[i]->render();
glPopMatrix();
}

Опасайтесь страшного поворота 1,1,1. Он избитый и статичный. Опытный кодер заметит его за милю. Используйте синусы, десятичные числа, что-нибудь длинное, да подальше от 1, 1, 1. И привяжите свои повороты к таймеру. Даже если у вас медленный код, где-нибудь он заработает слишком быстро и потому окажется полным отстоем.

Не забывайте о частоте смены кадров

Это мое личное мнение, однако я предпочитаю более простые эффекты, работающие достаточно быстро, чем пожирателей CPU, ползущих на трех FPS. Сегодня популярна позиция типа "на компо-машине все будет замечательно работать" и, действительно, процессорная мощь дешева, но все-таки, хотя бы постарайтесь оптимизировать ваш код. Сейчас обычно не требуется вручную писать на ассемблере, поэтому все что вам нужно - это немного подумать. Вот несколько советов по оптимизации (по ним можно забить Hugi статьями, я подам вам только основные идеи):

1) Думайте и планируйте перед тем, как вы станете программировать.

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

3) Тот факт, что у вас есть аппаратный Z-буфер, еще не означает, что не стоит делать сортировку по глубине, выборку нелицевых граней и все то, чему учила вас мать. Quake 3 не дает аппаратуре сортировать всю сцену из двух миллионов полигонов, так почему вы должны это делать?

4) Алгоритмическая оптимизация лучше оптимизации кода. Даже если у вас есть лучшая из всех возможных кэш-оптимизированная и использующая SSE2 пузырьковая сортировка на чистом ассемблере, она все равно в пух и прах проиграет наброску быстрой сортировки, написанному на Visual Basic'е.

5) Помните о том, что вы пишете демку, а не научный проект. Писать код, который невозможно сопровождать - это плохо, и вам действительно следует побеспокоиться о багах, однако повторное использование не должно ставиться во главу угла. Как написал KB в своей замечательной статье, если вы пишете rotozoomer, то и пишите rotozoomer, а не texturemapper.

6) Изучайте как все работает. Под всем я имею в виду Windows, кэш, основные алгоритмы, используемые 3d-железом, математику для построения проективных матриц и т.д. Эти знания дадут вам возможность написать эффективный код. Даже несмотря на то, что аппаратная акселерация является нормой сегодняшнего дня, изучайте также программные методы. Это интересно, полезно для кругозора и частенько вознаграждается. Проведите время с Photoshop-ом, попробуйте написать трекерный модуль или mp3. Даже если результаты вашей деятельности будут ужасно выглядеть, полученные сведения позволят вам проще договориться с вашими художниками и музыкантами.

7) Используйте вертексные буферы и удаление треугольников (triangle strips) где только можно. Избегайте излишних смен состояния и прочего общения с 3d-железом.

8) Пишите сторонние вещи вроде утилит и игрушек. Они расширят ваш кругозор.

9) Не бойтесь просить помощи. Бывают высокомерные люди, которые станут смеяться над вами и оскорблять вас, но есть и такие, кто оказывает помощь, кто любит делиться знаниями.

10) Думайте и планируйте перед тем, как вы станете программировать.

Если вы неопытны или просто начинающий, не относитесь к этому слишком серьезно. Это придет к вам со временем. Главное, чтобы вам нравилось то, чем вы занимаетесь.

"Искусство"

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

Канонический, Правильный и Потому Чрезвычайно Священный Список Того, Что Не Является Эффектом

- Дешевенькое "мельничное" радиальное размытие
- Простые метаболы
- Простые сеточные plasmadistortionwobbler'ы, FD-туннели и FD-плоскости
- Шарики с пространственным мэппингом и мэппингом плазмы
- Крутящиеся 3D-объекты, собранные из бликов
- Сплайны и прочие кривые из бликов
- Простейшие наложения
- Статичные каркасные (wireframe) объекты
- Альфа-смешивание
- Все, что есть в обучалках NeHe

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

Это можно высказать одной фразой: "если вы не можете сделать это лучше, зачем делать это вообще?". Хотя, возможно, это звучит слишком сурово, ведь работа над базовыми эффектами даст вам знания и опыт для продвижения вперед. Базовые эффекты по-своему полезны, если вы будете относится к ним именно как к базовым эффектам.

Что надо делать

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

Посмотрите вокруг

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

Знайте свои пределы

Окей, вы новичок. Ваше имя не Smash Designs, Kewlers или Future Crew, стоит в этом признаться. Пытаясь прикинуться ими, вы приведете дело к катастрофе. Хорошие версии простых эффектов чаще всего лучше плохих версий продвинутых эффектов. Если кто-то сделал чумовой эффект, то делать что-то, что просто воспроизводит его, не означает, что у вас получился почти чумовой эффект. Обычно это выглядит как полная фигня.

Если ваш 3d-движок не так хорош как у Smash Designs, не делайте полетов по 3d. Если в вашем распоряжении только вращающиеся кубы, не занимайтесь стилем гоа-транс-психоделик-LSD-расцвеченным. Подумайте, что вы можете сделать из того что у вас есть, а затем сделайте это настолько хорошо, насколько это возможно.

Я могу дать вам пример: когда мы дизайнили нашу дебютную работу Viping, у нас были амбициозные планы. Настолько амбициозные, что команда "всех звезд" из Kewlers, Farbrausch и Smash Designs, вероятно, не смогла бы их реализовать. Очень неловко теперь читать записи по дизайну и смотреть демку, поскольку она превратилась в совершеннейшую кашу из всякой гадости. Не замахивайтесь на многое.

Не сдавайтесь

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

Что теперь?

- Что значит "еще не закончена?"

Итак, теперь у вас есть готовая идея и что-то вроде грубого наброска, время получить оценку со стороны. Если у вас есть друзья, а я надеюсь, что они есть, то спросите у них. Желательно узнать мнение друзей не-сценеров. Скажите им, чтобы они отметили те места, которые можно было бы улучшить. Чем меньше они знают о сцене и компьютерах, тем лучше, потому как они будут более объективны. Спрашивайте совета у тех, кто не загнан на чем-либо. Спросите девушек из своего класса. Если вы все еще живете с родителями, спросите маму. Вашей маме виднее. Затем обдумайте то, что было предложено и добавьте стоящие идеи.

Если у вас есть хороший художник, дайте ему полный контроль над всей демкой. Или, по крайней мере, дайте ему право вето по части предпринимаемых вами дизайнерских действий. Поверьте мне, вы от этого только выиграете. Он потому и художник, что знает, что будет выглядеть хорошо, он не просто фабрика по производству текстур или тот, кто заполнит недостающие 15 секунд демки. А если он просто друг и не так силен в рисовании и создании текстур, тогда найдите другого. Это окупится.

Зал славы

- Обожаю рок'н'рол

На моем жестком диске есть отдельная директория под названием Зал Демо-славы. Здесь я держу свои любимые демки, и полагаю, было бы неплохо подробно пройтись по некоторым из них. Учтите, что все это мое собственное мнение, с которым вы можете быть согласны или нет. У меня также есть Зал Позора, в котором я храню работы, которые есть совершеннейшая и полная лажа, но я думаю, что более полезно будет посмотреть на хорошие демки вместо плохих (по крайней мере, публично :)). Я отобрал парочку демок и предлагаю вам посмотреть на них.

Сначала пример того, чего делать не следует:

Feed your Machine от Faktory - Asm'03

В своем info-файле они заявляют: "дизайн: uttumuttu & rawhed, мы супер!! и приносим свои извинения!! и требуется по-настоящему крутой дизайнер!!". Я принял это в качестве признания того, что их дизайн - лажа, значит эта демка играет по-честному :) Я особенно заостряю на этом внимание, поскольку даже несмотря на то что я собираюсь сказать, мне действительно очень-очень нравится эта работа и я ценю ее код и музыку. Вот почему я все равно держу ее в Зале Славы вместе с несколькими десятками других работ. Из сотен, которые обитают на моем винте.

Первым делом вас приветствует загрузочная картинка с человеком, пьющим пиво. Обычно это является плохим знаком, но поскольку я знаю что эти кодеры делали ранее, то просто уверен что на этот раз все в порядке. Хотя должен заметить, что Fosters - это не самое лучшее пиво. И это не мое субъективное мнение, так что спорить бесполезно :)

В качестве первого эффекта видим 2D-эффект с дымом. Не какой-нибудь там ваш заурядный огонь, а действительно классный эффект. Слегка низковато разрешение, всплывают артефакты фильтрации, однако решение частных дифференциальных уравнений в реальном времени - это не быстро, поэтому никаких претензий. Потом поверх дыма появляется прикольный логотип Faktory, выполненный в современной манере. Пока никаких проблем, да и музыка, похоже, звучит очень достойно.

Однако сразу после этого с разных сторон экрана появляются прозрачные зеленые полигоны. И не просто какие-то там зеленые, а очень, очень по кодерски зеленые. Это напоминает анализатор спектра, но полной уверенности в этом нет, поскольку длится это на экране очень недолго. Так или иначе, хорошее впечатление, которое у нас было до этого, изрядно подпортилось.

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

После столкновений видим что-то типа туннеля/зумера. Никогда раньше не видел подобного эффекта, он выглядит здорово. Я не уверен, нельзя ли было использовать какой-то другой цвет в качестве основного (не оранжевый), но не беда - потерпим. Хотя текстуру можно было бы сделать поярче, в целом получается довольно темно.

После зумера у нас пол с кодерски зеленой фрактальной плазмой (или perlin-noise). Поскольку это демка с 3d-акселерацией, снова видно эффекты фильтрации, что вызывает отрицательные эмоции. Потом на пол падает фигурка человека. Его (ее) движения очень реалистичны, вероятно, было сделано что-то вроде имитации физики костей. После этого он встает и уходит прочь.

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

Теперь подходим к одной из самых ужасных частей демки. На фоне видим эффект искажения битмапа, с красной текстурой. Я не знаю что это такое, но я думаю, что 3d-плазма с envy-мэппингом. Впереди человечек, стоя на площадке он танцует под музыку. Человечек собран из шариков или наггетсов, его движения довольно реалистичны. Однако при виде этой сцены хочется заорать: "кодерский дизайн!". Человечек не текстурирован. Красная текстура не подходит для эффекта на фоне. У плоскости пола есть глюки с отсечением, которые проявляются при движении камеры. Человечек хорошо анимирован, но кого это теперь волнует?

Итак, нас терзали кричащим красным, тусклым оранжевым, кодерским зеленым и серым. Без переходов.

Потом мы видим еще одну имитацию столкновений со следующими объектами: черепа, конусы и узлы из торов. Собственно, эта сцена говорит обо всем. Код, похоже, очень хорош. Очень-очень хорош. Но что это такое? Вижу ли я пикселы от блочной фильтрации? Это потому, что все это рендерится на текстуру, а потом помещается на экран с простым эффектом искажения по типу плазмы.

Зачем? Господи боже, зачем? Не было никакой необходимости делать искажение битмапа. Это натуральный пример кодерского мышления: "давайте еще и это добавим". Это ничего не дает эффекту, просто делает небольшую волну. Вау. Теперь я действительно впечатлен. Нет, правда, но только из-за столкновений, а не искажения. И, пожалуйста, удержите меня от оценки цветов. Они не так уж плохи, однако совершенно не сочетаются друг с другом.

Эффект длится всего ничего, и затем мы проваливаемся.. в нечто. Я не знаю что это такое, что-то вроде фокусов с уравнениями имитации частиц жидкости (с сингулярностями)? По-моему, этот кусочек очень удачный. Он оригинален, выглядит мило, цвета не кодерские, что-то вроде мягкого синего. Приятно. Опять видим зеленые полигоны, но это не сильно портит впечатление от эффекта.

Теперь у нас снова крутится сцена со столкновениями. Это прямо нарушает правило "не показывать одни и те же вещи". Правда, поскольку первая демонстрация длилась лишь несколько секунд, можно на это взглянуть еще раз. Теперь объекты двигаются чуть больше, это хорошо. Все еще напрягает искажение/рендеринг в текстуру, особенно в тот момент, когда на нижней границе экрана перекидываются текстурные координаты. И обратите внимание: в этой сцене на самом деле два блика! Их действительно сложно обнаружить, но они там есть.

В этой сцене есть серьезные проблемы с дизайном. Я хотел бы представить свою точку зрения по поводу того, как сделать ее лучше. Первым делом, избавиться от искажения. НИЧЕГО это эффекту не дает, уберите его, чтобы появились блочные пикселы. Затем займитесь цветами и выберите приятную цветовую схему. Скажем, зеленую, с серым и каким-нибудь еще цветом. Проведите различие между объектами, используя различные оттенки выбранного цвета (не разные цвета!). Уделите внимание фону.

Теперь вам стоит пораскинуть мозгами. У вас есть этот замечательный замут с обработкой столкновений. Как использовать его по полной? Первым делом следует переработать камеру, сейчас это слишком скучно. Ваша камера смотрит на сцену сверху вниз. Это, конечно, хорошо, но что если прицепить камеру к одному из объектов, чтобы получить другой угол обзора? Поместите ее на череп и запустите в него коробкой, так чтобы она отскакивала и улетала прочь. Или поместите камеру на пол, чтобы на него падала груда коробок. Сделайте пролет камеры, чтобы в особенные моменты она просвистывала мимо объектов. Это здорово оживит сцену и окажет впечатление на зрителя.

Вот теперь нас угощают по полной. Решение уравнений Навье-Стокса в реальном времени (для всех тех, кто не является поклонником математики - эффект дыма). Когда я увидал такую штуку на ASM, то едва не обмочился. Все кто был тогда со мной (еще три кодера и художник) просто остолбенели. Я не верил своим глазам. Это ТАК здорово выглядело. Даже сочетание кодерского пурпура на полу и зеленого дыма не смогло ранить меня чересчур сильно. Мое почтение Uttumuttu за такую работу :) Только одно замечание: почему не сглажены края бокса? Они выглядели бы гораздо лучше. Хотя на это можно закрыть глаза - эффект и правда слишком хорош :)

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

После картинки видим искажения битмапа с морфингом 3d-объектов. Объекты те же самые, что мы уже видели в сцене со столкновениями: коробка, конус, тор и т.д. Сначала взглянем на фон. Им является самый обычный эффект аддитивного туннеля, нет вопросов. Текстура не на мой вкус, но ничего, потерпим. Бесит интерполяционная каша в центре туннелей. Почему не выполнили шейдинг (до черного цвета)? Это моментально улучшит дело, я думаю, с такими кодерскими талантами это не составило бы труда сделать :)

Потом у нас 3d-объекты, они на переднем плане. Серого цвета, что хорошо. Они с пространственным мэппингом - тоже недурно. Крутятся с хорошей скоростью - прекрасно! А вот плохо то, что была упущена возможность. Морфинг объектов - это нам сегодня пара пустяков, но там есть одна вещь, которая совершенно меня сразила. Череп - это прикольно, эту штуку надо показывать. Но вы С ТРУДОМ ЗАМЕТИТЕ, что он, этот череп, здесь есть. Почему? Потому что он не глядит в камеру :(

Под занавес появляется отличный эффект. Экран неожиданно становится белым, и камера медленно наезжает на собаку. Собака не слишком хорошо анимирована, но шерсть сделана удачно и сплошной белый фон представляет отличное пространство для эффекта. Кроме того, этой части идеально подходит музыка. Я думаю, это доказывает, что простота частенько оказывается наилучшим выбором. И когда собака скрывается из виду, мы видим финальный логотип с названием демки. Этим она и завершается.

Если говорить коротко, потрясающий код, но ужасный, ужасный дизайн. Больно видеть работу, которая могла бы быть намного лучше. Вместо этого ее создатели решили, что ее содержанием станет демонстрация их кодерских способностей. Она все еще в моем Зале Славы, поскольку в душе я кодер, и она вызывает во мне приятные ощущения. Она такая неуклюже милая ;)

Обратите внимание, я прочитал отчет Rawhed'а о пати и полностью осознаю тот факт, что их группа британо-финская, что немного затрудняет общение и планирование дизайна. Вот почему вы должны делать эти вещи заранее (иначе будут плохие последствия вроде получения 12-го места или торжественной порки в Hugi :)) Я также понимаю, что у людей может не быть достаточно большого количества времени на демомейкинг, они просто хотят выпустить что-нибудь на солидной пати, даже притом что работа может оказаться незаконченной. Пожалуйста, тоже на здоровье, хотя это больно задевает мои глаза ;)

Теперь давайте посмотрим на великолепный пример того, что нужно делать:

Dreamchild от ASD - Asm'03

Должен сказать, что здесь я буду не объективным, ведь я просто обожаю эту демку. Здесь так много эффектов, которые можно обсуждать отдельно, что я лишь сделаю общие замечания и укажу несколько примеров. Но сперва я бы хотел сказать вам, что несмотря на то, что многие демки имеют незатейливую музыку и все равно являются хорошими, именно музыка ОПРЕДЕЛЯЕТ эту работу. Она ТАК здорово подходит к видеоряду. Не могу поверить, что некоторым на pouet.net не понравились гитары. Есть всего два демо-трека, которые когда-либо составляли мой winamp-плейлист: саундтрек Dope от Jugi/Complex и этот.

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

С точки зрения кода здесь есть цельность, хорошие эффекты, но ничего сверхвыдающегося. Среди эффектов стоит отметить туннели в середине демки, они одни из самых лучших что я видел. Мне еще понравились сверкающие феи и вращающиеся блестящие штуки в greetings. Хотя должен сказать, что раз я пишу эту статью, мне нужно было просмотреть эту демку много раз. Я заметил, что она, кажется, съедает 50 мегабайт памяти при каждом запуске, спустя несколько запусков мои 256 мег быстро закончились, и я должен был перезагружаться.

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

Многие демы содержат все вышеперечисленное: хороший код, великолепную музыку и продуманный дизайн. Что действительно отличает Dreamchild от всех остальных, делая ее особенной, так это продуманная идея. В этом она совершенно отличается от всех работ, которые я когда-либо видел. Идея, если выражаться коротко, - это мечта. Как будто мечта - это ребенок, которого вы растите (отсюда и название).

В самом начале демы вы видите угасающий мир. Изображение становится как бы "широкоэкранным", вы засыпаете. Ваши ресницы пропадают (да, милые сглаженные кривые - это ресницы) и вы просыпаетесь в лимбо между миром грез и реальным миром. Заметьте, мы снова видим обычный экран. Теперь внимание. Внутри додекаэдра рождается ребенок, в какой-то жидкости. Его глаза сверкают. Скроллеры сообщают: "я сплю?". Ваш ребенок, ваша мечта только что родилась. Потом лимбо исчезает, и начинается настоящая демо/мечта, текст говорит "я никто иной как ты". И в этом заключен весь смысл. Вы живете в своих снах.

Чуть позже, в части с папоротниками (хороший штрих) вы видите ребенка грез, задувающего спичку. "Ответ, что носится в моем разуме, воспламенишь мое сердце?". Он уже слегка подрос, это уже не ребенок. После этого мы снова видим додекаэдр, но на этот раз их много, они вложены друг в друга. Внутри додекаэдров образы. Осьминоги, сиящий свет, неясные и размытые предметы на фоне. Штука с кольцами, в центре которой свет. Экраны разделяются, видно фей, голову и солнце. Заметьте, вы все еще внутри додекаэдров, в которых рождается новое. Ребенок грез все еще молод. Затем появляется сцена с затмением, и вы взмываете словно ракета. В этом месте идеальная синхронизация с музыкой.

Обратите внимание на слова: "Ты шепчущие сумерки. Ты забывчиво, но ты есть прощение души. Ты невинность, которую мне никогда не вернуть". Есть еще, но к сожалению, я не могу разобрать что там говорится. Если у кого-нибудь есть полный текст, я бы очень хотел взглянуть на него.

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

Деревья мира грез увядяют и медленно уходят под воду. Отметьте марионеточные ниточки. Мы стали восстанавливать контроль за нашими мыслями после полного всевластия грез и потому загубили деревья. Мечта уже стала взрослой. В последней сцене мы стремительно вылетаем из мира грез. Снова погружаемся в сон и просыпаемся в обычном мире. И на этом все грезы заканчиваются.

Может быть, глупо судить о демках таким образом? Возможно. В конце концов, есть масса людей, которые полагают, что дема - это только код и ничего больше. Может быть, все это получилось непреднамеренно, и ASD просто соединили отдельные вещи, которые приятно выглядели, но теперь, после двадцати с лишним ее просмотров, я здорово в этом сомневаюсь. И даже если так, это не имеет никакого значения. Важно то, что она пробуждает во мне мысли и чувства. Образы. Демки Kewlers имеют приятный визуальный ряд, особенно потрясающе выглядит (и звучит) A Significant Deformation Near the Cranium, но они и близко не подобрались до такого уровня содержания.

Вы читали "Песочный человек" Нила Гэймана? Если нет, то вы должны это сделать. Это прекрасные и глубокие рассказы, представленные в виде книги комиксов. Кто-то скажет: "что тут такого - обычная книжка с комиксами". Один из них, отличный пересказ "Сна в летнюю ночь" Шекспира, даже взял награду Хьюго за лучший рассказ. В заключении к "Brief Lives" Питер Страуб писал: "если это не литература, то ничто не литература". Я скажу то же самое: если Dreamchild от ASD не искусство, то ничто не искусство. Если вы, ребята из ASD, сейчас читаете это, я хотел бы поблагодарить вас за то, что вы делаете мир лучше. Кроме того, я благодарю вас за создание Planet Risk - самой красивой демки в мире. Хотя в ней и нет единства темы с Dreamchild, это удивительное достижение в плане кода, и это абсолютно точно самая красивая демка, которую я когда-либо видел.

К несчастью, у меня есть ощущение, что демосцена не очень-то восприимчива к подобным вещам. Сценеры - это по большей части компьютерные фанаты, а компьютерные фанаты обычно не склонны к поэзии. Досадно, ибо нам нужно больше таких работ. Когда я знакомлю людей со сценой, первым делом я показываю им Dreamchild. Мой друг назвал ее "сопливой" после того, как я показал ему кое-что от Kewlers. Но такая сопливость - это ХОРОШО. Можете меня в этом цитировать.

Послесловие

Все хорошее когда-нибудь заканчивается, мне пора закругляться. Желаю удачи, я буду рад увидеть очередную вашу работу. Если эта статья оказалась вам полезной, пожалуйста, черкните мне отклик, чтобы я знал, что не впустую потратил этот вечер :)

Хотя я и не могу сделать всех вас хорошими кодерами/художниками/дизайнерами, я могу гарантировать, что если вы последуете моим советам, реакцией на вашу первую работу будет скорее что-то типа "хмм.. интересно, у них есть потенциал", а не "черт, ну и дерьмо, где тут ESC???". По крайней мере, от меня вы услышите такое.

Будьте внимательны и удачи!

Автор: Preacher/Traction
Перевод: Невидимка
Hugi #30