(Окончание, начало в №35)
Итак, на чём же мы закончили предыдущий материал? Практически сделали работоспособную игрушку. И сейчас стоит ключевой вопрос завершающего этапа, а именно - распространение и получение прибыли. Для этого нужна предварительная доработка: многоязыковая поддержка, шрифты и т.д.
На самом деле наш проект был мал и лёгок, к тому же он производился по шаблонному заданию. Но всё же есть одно ключевое и почти что главное правило современной торговли: товар стоит ровно столько, сколько за него готовы заплатить. Поэтому, будь вы хоть семи пядей во лбу и создайте на флэше аналог "Старкрафта", на постсоветском пространстве именно с флэшевыми казуальными играми ситуация несколько удручающая, хотя... уже есть несколько попыток создания сетевых ресурсов по распространению именно казуальных игр. Они почти всегда предлагают два варианта сотрудничества с авторами (разработчиками), а именно: предлагают определённую фиксированную сумму за полную передачу авторских прав на продукт и самого продукта, и второй вариант - предлагают партнёрство, в рамках которого вы будете получать определенный процент от каждой проданной копии. Язык программирования, как и среда, в которой игрушка была создана, принципиального значения не имеют.
Наши с вами гонки в том простом виде, в каком мы его сделали, прибыли не смогут принести. То есть нужна более качественная проработка интерфейса, создание множества уровней сложности и так далее. Это целый пласт работы.
Причём стоит отметить, что в развитых капиталистических странах казуальные игры - отдельный и весьма прибыльный рынок. Поэтому, если вы создаёте игру, то его нужно учитывать в первую очередь. И в данном случае очень приветствуется, когда вы выпускаете сразу несколько версий для разных языков, например, самых популярных: английского, испанского, немецкого, французского, итальянского и португальского. Для этого в непростых случаях вам помогут переводчики.
Что касается особенностей именно такого подхода... все интерфейсные элементы, содержащие имена, названия, документацию и т.п., должны создаваться исходя из многоязыковой поддержки. Поэтому сразу будет введено два ограничения:
- Шрифты. Практически во всех компьютерах в разных языковых системах обязательно есть Arial, Times New Roman и, возможно, Courier. Другие шрифты использовать не нужно.
- Все названия, имена и т.п. для разных языковых стандартов выносятся в отдельный XML-файл (или в разные XML-файлы, все зависит от того, как вы решите), причём всё хранится в кодах Unicode. Именно из этого файла(ов) происходит чтение и перевод из юникода в текст, что позволит получить языковую независимость. Мало того, иногда вариант с XML не совсем приемлем, поэтому часто можно встретить другой подход, когда для каждого языка выпускается отдельная версия с юникодом внутри основного(ых) файлов ActionScript.
Кстати, в нашем примере с гангстерами и инопланетянами в качестве основы мы взяли версию языка 2.0 не только потому, что она более проста в освоении. Вопрос ещё стоит о возможности переноса игры на мобильные устройства, а там применяется как раз разновидность 2.0 (а именно - Flash Lite 2.x ActionScript Language).
То есть, для превращения проекта в полноценный продукт, способный принести прибыль, нужно повозиться с различного рода локализациями и даже, мало того, учитывать их, как только вы начали движение.
"Словашки"
Игра "Гангстеры vs инопланетяне" будет иметь низкую стоимость, и возможности получения прибыли от неё малы. Сколько разных гонок есть сейчас во всех видах? Главное, это завлечь идеей, причём не только ей самой, но и заставить игрока проводить часы за вашим продуктом. Как уникальный пример тривиальной идеи могу назвать знакомый многим владельцам мобильников "предсказатель удачи". Реализация проста - виртуально подкидывается монета, выпадает в случайном режиме или орёл, или решка. Саму игру отдельно никто не купит, но если она встроена в мобильный телефон, то в ряде случаев является интересным приложением (для тех, кто полагается на случайности).
На сегодня я предложу вам другой проект, уже коммерческий и конкурентоспособный. То есть, он рассчитывался профессиональным образом с предварительным изучением спроса на рынке и так далее. Хотя основная идея принадлежит мне, вы можете использовать её по своему усмотрению, то есть и зарабатывать на ней деньги в том числе. Потому как на реализацию всех моих идей и замыслов у вашего покорного слуги, если честно, просто нет времени. Итак, делаем проект... Работаем с начальными фазами...
"Словашки", "Пароль
"Рыба-меч"", Swordfish...
Это всё предварительные названия для этой игры. Причём, если "Словашки" подразумевают что-то простое, то "Пароль "Рыба-меч" уже нечто шпионское, следовательно, это повлияет и на оформление. С названиями можно экспериментировать долго. Оформляем первоначальную идею...
Жанр: казуальная, логическая головоломка.
Описание: уникальная головоломка с составлением слов по правилам пятнашек. Вам необходимо собрать в строки предложенные слова из имеющихся букв.
Цели: пройти все уровни. Самый легкий предусматривает доску 3х3, самый трудный - 6х6.
Дополнительные усложнения: для некоторых уровней одна или две клетки являются закрытыми и статичными, они активизируются, если игроку удалось собрать строку из загаданного слова. Второе усложнение заключается в том, что последнее слово не выдается, и пользователю необходимо найти его самостоятельно.
Сложность: от легкой до самой сложной.
Платформы: PC, мобильные телефоны.
Языки: русский, английский, немецкий, испанский, французский, итальянский.
На рисунке представлено нечто типа общей схемы и раскадровки главного окна одновременно.
Ход реализации
Как вы понимаете, во флэше можно представлять фишки с буквами как объекты классов MovieClip или Button. Но этот ход мыслей будет не верным. Если вы будете так делать изначально, то, в конце концов, соорудите такую громоздкую модель, от которой может поехать крыша. Как быть в случаях, когда на экране сразу четыре-пять-десять букв "А"? Там, кстати, вскроется весьма весёлая проблема флэша, и такую задачу простыми методами решить не удастся. Получится единственный вариант - громоздкий каркас. Второй вопрос: как будет происходить выявление, что слово найдено?
Поэтому нас будут интересовать не фишки, а, наоборот, поля, на которых они виртуально расположены. Фишки на самом деле будут фикцией, обманом. То есть, при изменении позиции курсора мыши (свойства ч) и нажатия на кнопку при необходимости подгружаются изображения, буквы, все запланированно изменяется.
То есть, сетка у нас будет самым верхним слоем, причём на квадраты мы будем её делить чисто программно. Под квадратами находятся простые текстовые элементы, главное необходимое свойство которых для нас это Text, в котором мы будем отображать не что иное, как буквы (по одной для каждого квадрата). Под буквами расположим некие геометрические фигуры-картинки, которые будут служить для нас фоном. Их можно сделать с красивой градиентной заливкой, и даже сложными по структуре, и каждый сохранить как отдельный MovieClip. Главное свойство всех этих элементов - видимость. То есть, если над ними есть буква, то он виден, если нет - исчезает. Заметьте, что проще весь этот каскад сооружать в одном слое (Layer 1).
Дальнейшая реализация не представляет собой ничего сложного, только нужно понимать, опять же, два ключевых момента:
- Не пытайтесь делать из проекта суперпереростка. То есть, если мы говорим о простой логической игре, то не нужно туда внедрять навороченную анимацию и т.п. Главные требования - простота и надёжность. Ну и, конечно, симпатично должно быть, спартанский интерфейс не для игр. Тот момент, что фишки у нас не будут смещаться анимационно, во-первых, упростит само программирование по указанному методу решения общей задачи, во-вторых, не забывайте о звуке, запишите небольшой фрагмент с шумовым эффектом Доплера, и всё будет уже не "переключаться", а "ездить" или "плавно смещаться" в восприятии пользователя.
- Изначально программирование под ActionScript рассматривалось разработчиками как небольшая дополнительная функция флэша, после сам пакет стал активно использоваться для Web, поэтому язык был несколько преобразован и достроен для интернет-технологий. Таким образом, вы не встретите таких событий для обработки, как двойной щелчок мышью (оно также не используется практически во всех веб-приложениях), в AS 2.0 есть только события onMouseDown, onMouseMove, onMouseUp и onMouseWheel. Заметьте, что на данном этапе даже не важно, какая из кнопок мыши нажимается, хотя для нашего случая подходит более чем.
Второй пункт стоит дорасшифровать... Если вы всё же решили делать более полноценную реализацию с громоздким каркасом из MovieClip'ов или Button'ов (второе более вероятно), среди событий для этих классов вы можете найти onDragOut, onDragOver и onReleaseOutside, что позволяет реализовать режим переноса указателем мыши (drag'n'drop). Но фишки у нас смещаются только по вертикали и горизонтали при условии наличия там свободной ячейки, поэтому drag'n'drop не нужен вообще. Для игрового процесса на компьютере понадобится только мышь с её одной кнопкой, в простоте - сила!
Теперь немного о внутренней структуре. Не сложно догадаться, что доска 3х3 будет подразумевать восемь виртуальных фишек, а по существу - два слова, состоящих из трёх букв и одно - из двух. Теперь уже есть о чём подумать вам, хотя на самом деле всё очень просто.
- Вы создаёте виртуальный каталог со множеством слов, из них нужно сделать подбор в случайном режиме. Это раз!
- Далее идут простейшие операции со строками. Все слова вы разбиваете по буквам, после чего, опять же, в случайном режиме разбрасываете эти буквы по текстовым полям.
- Делаете модуль анализа, в рамках которого выявляется, какие из загаданных слов были собраны.
И не забывайте о том, что в будущем грозят разноязычные локализации, поэтому подготовьтесь к тому, что символы будут обозначаться внутри программы (или библиотек-словарей) в юникодах.
Каждый запрограммированный уровень можно сохранять как swf-файл, после чего сформировать общее интерфейсное окно, в рамках которого все swf-файлы будут подгружаться при переходе от уровня к уровню. Можно использовать и множество других методов, включая директивы # include с импортированием AS-файлов, и так далее. То есть, уровневые переходы, как они будут происходить, вы должны продумать изначально.
Распространение
Когда программа полностью готова, предусмотрите trial-разновидность (с ограничениями). Особых систем защиты для казуальных игр не требуется. Для реализации trial можно поставить внутренний счётчик на время использования либо ограничитель для перехода на следующий уровень. Если вы работаете по партнёрской схеме, и интернет-магазин (или сеть магазинов) получает деньги от пользователей, генерирует код активации и отсылает им, то... это значит, что данный модуль активации/отключения trial-защиты с вложенным алгоритмом вам пришлют. Иначе придётся таковой делать самостоятельно.
Впрочем, есть множество схем получения денег/предоставления паролей. Например, некоторые дают на бесплатное скачивание просто ограниченные версии, а в случае оплаты дают временные ссылки на получение полных.
То есть, самое главное - зацепиться, а дальше помаленьку бизнес должен пойти. Конечно, с очередным клоном тетриса дела будут обстоять гораздо туже, а вот новые и лёгкие идеи принимаются на ура.
В завершение
В третьей завершающей части этой серии материалов ваш покорный слуга не стал приводить ни одной строчки кода, к тому же дал абсолютную свободу выбора по технологическому решению реализации - все необходимые методы и технологии описаны в Help'e и книгах.
Только одно замечание к некоторым программам начинающих, которые мне пришлось увидеть: не вставляйте слежение за событиями клавиатуры и мыши внутрь циклов, функций, оcнованных на SetInterval(), это сильно загромождает внутренние расчёты, к тому же такой стиль программирования может привести к неприятным последствиям в дальнейшем.
Например, недавно я тестировал игру, так там в главном меню при вводе имени после нажатия кнопки клавиатуры буква, ей соответствующая, появляется многократно и сразу, при этом сам процессор "трещит по швам" и тут сразу очевидна суть проблемы. Достаточно просто привязаться к частоте смены кадров, и то, даже это является излишним, но... по-другому никак.
Кристофер,
christopher@tut.by