28 июня 2011

Конкурс: небольшие продвижения

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

Графика
Итак, в последнее время я немного поработал над графикой. Теперь самый первый уровень выглядит вот так:


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

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


Но осталось еще довольно много: круги, кнопки, рычаги, двери и т.д. Я решил так: что не успею сделать - то и не войдет в итоговую версию игры.

Диалоги и меню
Недавно все же сел и набросал в FireWorks'е первый диалог для игры. Посидел еще немного и вставил его в сам проект, выглядит это чудо вот так:



Нужно будет обязательно собраться с силами и создать еще You failed или что-то подобное... Ну и меню я совсем не трогал, это еще впереди. Кстати, с дизайном главного меню я пока совсем не определился, вещь очень важная, ведь игрок видит меню первым делом, при старте игры. Именно поэтому и не хочется ляпать "как попало", посмотрим, позволит ли время подойти в этому вопросу обдуманно.

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

Планы
А вот и сам список того, что нужно бы сделать для игры в порядке убывания важности:
  • создать и внедрить кнопки, видимые во время игры: Restart, Menu, Sound on/off
  • сделать диалог "You failed", прописать условие его появления
  • набросать Главное Меню, пока хотя бы в FireWorks'е
  • создать еще 10 уровней, пока можно подсматривать и брать идеи из чужих игр, адаптируя их под собственный стиль игры
Приблизительно вот такой список дел. По мере сил и возможностей, буду стараться выполнять одно за другим. В общем наводнил журнал текущими скриншотами, что не может не радовать. 
Кстати, демонстрировать WIP - довольно интересное занятие, подстегивающее работать над проектом в несколько раз быстрее.

Сообщения, схожие по тематике:

13 коммент.:

  1. Смотрю, у тебя уже, по рамкам конкурса, все готово)

    Интересно, нарушится ли традиция "Л. участвует - Л. выигрывает"?.. ))

    ОтветитьУдалить
  2. Симпатично выглядит. На HUD спрайтах?

    ОтветитьУдалить
  3. perfect daemon, не, работы еще навалом! а вообще конкурс - это фан и сильный стимулятор! это главное ;)...

    Марцелл, благодарю! менюшка - hud-спрайты, все остальное - обычные спрайты... оставил обычные для того, чтобы можно было быстро менять положение всего уровня (hud-спрайты не учитывают матрицу родителя). Да и физику проще прикрутить, когда позиция в физ. мире соответствует позиции в граф. мире))

    ОтветитьУдалить
  4. Ну обычные спрайты, я это имел ввиду конечно, попутал немного. Надо будет после конкурса заняться нормальным гуи, хрен с ним, что там все через glbegin\end будет, сойдет. Быть может удастся сделать даже универсальный гуи-менеджер для всех проектов. Так понравилась формула
    ui = xml + script, что бросать такое уже рука не поднимается=))

    ОтветитьУдалить
  5. Марцелл, супер! мы с тобой мыслим в одном направлении! лично я тоже считаю, что гуи можно спокойно делать на glbegin/end, главное - опрятный результат и удобство создания! я уже давно замыслил переделать всю свою систему гуи на скрипты, но пока не подворачивалось времени и необходимости для того, чтобы плотно заняться этим :( в общем, буду следить за твоими результатами! glscene сильно нуждается в удобном и мощном гуи!

    ОтветитьУдалить
  6. L, Марцелл
    Можно и на glBegin/end. Но это не самая большая проблема при отрисовке гуя. Переделать deprecated glBegin/end в VBO/IB и шейдеры недолго - 3-4 часа для основы и пара дней точки.

    Главная проблема - минимизация переключений стэйтов текстур и числа DIP-ов (батчей) на отрисовку. На мобильных платформах дип очень критичен. Есть несколько путей:
    1. Самый простой, вывод в лоб. Надо отрендерить строку текста, панельку с текстом и скроллбар. И мы рендерим их в порядке, котором они идут, меняя при рендере очередного элемента стэйты, текстуры и шейдеры.
    2. Способ получше - используем сортировку графа по материалам (текстура+шейдер), и выводим пачками, минимизирую переключения.
    3. Брутальный, при изменении гуя, рендерим его в текстуру (весь или кусками через стенсил, кто как любит) и выводим скринквад. Результат, конечно хорош - один дип с 4 вершинами, и одно переключение шейдера и текстуры. Но подготовка - очень дорогой процесс.

    И это не говоря уже обо всяческих способах быстрого рендера текста (запекание надписи в одну текстуру, вывод за один дип всех одинаковых символов и прочее).

    Так что glBegin/end - это, имхо, цвяточки :)

    ОтветитьУдалить
  7. perfect daemon, в данный момент я бы не заморачивался на оптимизацию по дипам... без шуток, текущий мой гуи несравнимо меньше кушает ресурсов, чем тот же рендер игровых объектов. да и собрать из-под сцены под мобильные платформы - задача почище всяких игр... так что сцену я бы позиционировал только на PC ну и возможно на Mac... а там отрисовка даже трех десятков кнопок - дело простое...
    мне кажется первым делом нужно сделать гуи легким в использовании - скрипты, редактор, возможно xml... много анимации, эффектов, плавные переходы. как это будет готово - можно и обратиться к экспертам рендера, чтобы понять, что именно можно оптимизировать)).. если же задумываться об этом с самого начала - можно и завязнуть на этом этапе, так и не получив ничего на выходе.

    ОтветитьУдалить
  8. Этот комментарий был удален автором.

    ОтветитьУдалить
  9. Я тут подумал немного. Надо учесть, что к ГУИ можно отнести помимо всего прочего: курсоры, рамки для выделения чего-либо, всплывающий над объектами сцены текст, и, собственно, шрифты. И это, наверное, не полный перечень=)

    ОтветитьУдалить
  10. К тому же следует учесть, что положение, размер элементов следует конфигурировать под какое-то определенное, дефолтное, разрешение, и при смене оного производить изменение вышеописанныз параметров. Плюс ко всему, сюда же следует отнести звуки нажатия\отжатия кнопок и т.п.

    ОтветитьУдалить
  11. Марцелл, по поводу отнесения объектов к гуи - спорный вопрос, нужно ли всякие всплывающие подсказки и рамки относить к гуи или лучше определить их как "игровой объект"...
    по поводу разрешения - полностью согласен! нужно понятие layout'а и хранить позицию только как относительное значение, учитывая разрешение...

    ОтветитьУдалить
  12. Lampogolovii, что ты имеешь ввиду под layout? Я к тому, что надо все прописать под одно разрешение (1024х768 пойдет, да?), а дальше просто домножать на коэффициент. Я вот, правда, не знаю как поведет себя все это на нестандартных экранах. Все до ноутбука не дотянусь, чтобы потестить.

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

    ОтветитьУдалить