Тушим жаркие пожары
Наконец-то я закончил концепт демку своей новой игры и стало понятно... что ничего не понятно.
?дея новой игры пришла ко мне на кануне релиза последней части Зомботрона. ?, если честно, уже тогда, обигрывая идею в голове, я сомневался по поводу её интересности и возможной успешности в целом. Но что-то внутри меня говорило, что нужно попробовать сделать что-то подобное: вода и огонь — это достаточно увлекательные стихии, которые не менее увлекательно взаимодействуют друг с другом. Но каков должен быть гемплей игры, чтобы было интересно играть?
?гры про тушение пожаров мне доводилось видеть и раньше, но это были либо физические паззлы типа Sprinkle на iOS, либо не очень увлекательные платформеры типа Inferno Mildtown. В общем, основное сомнение заключалось именно в том, насколько увлекательно будет просто бегать и тушить пожары. А так же насколько можно улучшить эту механику таким образом, чтобы это было не просто интересно, но и по-настоящему захватывающим.
Впрочем, механику всегда можно как-то развить и обыграть, а вот получится ли технически сделать то, что я себе напридумывал!? ? это стало первоочередным вопросом. Поэтому я решил начать с технической части, чтобы понять - реально ли реализовать то безумие на Flash, которое я себе воображал.
Реалистичная вода
Первым делом необходимо было реализовать реалистичную физическую воду. В целом с этим особых проблем нет, так как в сети полно примеров, которые рассказывают, как можно легко и просто реализовать достаточно реалистичную воду с использованием обычных круглых физических тел, вот например Simulation Mudslime With Box2D.
Но лично для меня все это не годилось. Такая вода больше походит на какое-нибудь желе, так как очень страдает реалистичность симуляции. Да и слишком много такой воды не сделаешь, потому что для этого нужно большое количество динамических тел, а из-за этого сильно падает производительность. Ранее я уже слышал про партикловую воду (Particle Water), как наиболее реалистичную симуляцию. Партикловая вода состоит из мелких частиц, которые ловко взаимодействуют между собой, объединяясь в группы, легко разлепляясь и т.п.
?значально мне казалось, что все будет намного сложнее, но по факту математическая формула рассчета воды достаточно простая. Сейчас я не буду углубляться в процесс описания воды, и просто оставлю ссылку на туториал, который хорошо все объясняет Box2D Fluid Tutorial (XNA). Там же я нашел неплохой пример партикловой воды на основе физических тел Box2D (более реалистичная симуляция, чем просто физические круглые тела). Но, например, этот пример опять же упирается в лимиты производительности: JBox2D Liquid Demo.
В итоге воду реализовать оказалось не сложно, а вот имплементировать её в Box2D было по-сложнее. К слову, я так и не реализовал 100% взаимодействие с Box2D. Сделал только коллизию с физическим миром, а все остальное оставил на потом, так как помимо воды нужно было реализовать еще и огонь, а так же их взаимодействие друг с другом, не говоря уже об остальной игровой механике.
Конечно помимо самой физики воды нужно еще было сделать как-то и её рендер. Хотелось, конечно, сделать все это максимально реалистично, например как в Sprinkle. Но вот из-за ограничений Flash(аппаратную поддержку я пока по-прежнему не решаюсь использовать в своих проектах из-за скептического отношения спонсоров), пришлось реализовывать рендер воды так же, как это делают практически все, то есть через BitmapData.threshold, то есть практически так же, как это, например, сделано в уроке у Emanuele Feronato.
С рендером воды возникла только одна затыка — это блур (замыливание), который необходимо применять к отрисованным партиклам воды. Стандартный фильтр блура, как не крути — очень медленный и ничего с этим не поделать. Тут нужно было придумать свой очень простой и быстрый метод сглаживания, чтобы threshold отрабатывал свою задачу как надо. ? после короткого брэйншторма в голову пришла очень простая система реализации блура для воды: фактически нет никакого блура, есть один заранее замыленный спрайт партикла воды, который отрисовывается (отштамповывается) через очень быстрый copyPixels() на основе положения каждого партикла воды в общий BitmapData, к которому далее применяется быстрый threshold, а далее результат всех этих деяний уже выводится на экран. ? таким образом удалось сделать очень простой и быстрый рендер воды, которого на первых этапах разработки более, чем достаточно.
Реалистичный огонь
Далее осталось дело за не менее реалистичным огнем, с котороым я тоже повозился достаточно. Хотелось сделать огонь максимально реалистичным. Посмотрел так же множество примеров огня и способов их реализации, и остановился на своем любимом решении: огонь, состоящий из анимированных партиклов. Только в данном случае сами партиклы решил анимировать достаточно просто, без изысков: на заранее отрисованный спрайт партикла применялся Tint эффект, который перекрашивал спрайт из розового в желтый и далее постепенно уводил в красный, плюс к этому выполняется изменение прозрачности, масштабов и конечно же вращение — всего этого было достаточно, чтобы получить качественный эффект огня. Но как показали эксперементы всего 2-3 источника огня, для которых применяются все эти эффекты в реальном времени — опускали производительность игры до 5-10 fps практически на любой машине. А огня хотелось много, чтобы прям все было в пламени и дыму. Как же быть?
Да так же как и раньше! Оказалось что достаточно все закэшировать (растеризировать) все эти заранее заанимированные эффекты из клипов (Tint, вращение, изменение масштаба, изменение прозрачности и т.п.), в последовательность битмапов и рисовать их сверх быстрым copyPixels() — все это делается примерно таким вот способом. Только в моем случае я уже использую свой же Anthill для всех этих манипуляций. Таким образом на экране может быть до 2000 тысяч партиклов с разными анимациями и эффектами при условии, что они будут выводится на экран через copyPixels()! Конечно, чтобы сделать огонь более эффектным, ему не помешает установить режим отрисовки blendMode = add, тогда огонь будет по-настоящему огнем. Только в этом случае отрисовка будет уже выполнятся через метод draw(), что может немного притормозить игру на более слабых компьютерах, но все это решается опцией качества, которую игрок может сам переключать если считает, что игра у него тормозит.
В итоге, из всех этих экспериментов с водой и огнем получился такой вот результат:
Видео записано с экрана, потому что моя записывалка сильно висла и тормозила всю систему при попытке что-либо записать с экрана. К тому же видео с экрана намного лучше отражает то, как игра работает в реале, хоть при этом и страдает немного качество картинки (замыливание изображения и муар).
В общем, техническая демка получилась очень хорошей на мой взгляд и реально превзошла все мои ожидания. Сейчас в демке стоит ограничение на 5000 партиклов воды — это чуть больше половины экрана полностью залитого водой, и при этом нет никаких ограничений на количество источников огня. Пламя легко перекидывается с объекта на объект (только для горящих объектов), огонь тушится от воды, вода постепенно испаряется или впитывается. Ограничения на воду обусловлены только тем, что на моем компьютере iMac"24 от 2008 года (Core2Duo 2.4Ghz, 4Gb RAM) при достижении этого порога, игра начинает притормаживать. А в остальном мне кажется, что по геймплею и не понадобится такое огромное количество воды, как можно было бы еще сделать.
Геймплей
Так вот, возращаясь к теме геймплея, я опять встал перед вопросом, а стоит ли оно того — насколько интересно будет играть и все такое… При этом, за время разработки технической части, я решил отойти от темы классического тушения пожаров: приехал на вызов, залил все водой, вернулся на базу, прокачал скилы, купил плюшки, поехал опять на вызов. Нет, это все точно не то!
У меня родился небольшой сюжет, согласно которому небольшой городишка оказывается не просто в одном большом пажаре, но и в бесконечном количестве огненных монстров, которые не только поджигают, но и убивают все живое. Таким образом, герой становится не просто спасителем от огненной стихии, но и превращается в бестрашного воина, борющегося с адскими огненными существами, используя не только доступные инструменты в его арсенале, но и свою смекалку. То есть, проще говоря, геймплей должен быть максимально приближен к тому, что происходило в Зомботроне, только, вероятно без использования какого-либо огнестрельного оружия. Вот тут меня и гложат сомнения, а будет ли интересно игрокам после такого угарного экшена, как в зомботроне, работать типичной поливалкой!? :)
Да, я уже показал концепт некоторым спонсорам, и стоит отметить тот факт: концепт понравился, но вот этого оказалось не достаточно, чтобы оценить потенциал игры. В общем спонсоры будут рады посмотреть на более полноценную игру, прежде чем принимать какие-либо решения. Но это я так, для информации — чем более законеченная у вас на руках игра, тем проще выходить на переговоры со спонсорами ;)
А я в свою очередь, не смотря на все свои неопределенности все же решил еще немного поработать над игрой и сделать хотя бы 1-2 полноценных игровых уровня, чтобы рассеять все свои опасения по поводу геймплея, либо окончательно заброковать игровую механику. То есть, проще говоря, я как всегда не ищу простых путей. Хех.
Антон, я уже писал в твиттере, повторюсь тут — графическая составляющая уже приелась.
Создается такое впечатление, что все ваши игры — одно и то-же, только с некоторыми улучшениями. (При этом я не могу сказать, что игры плохие).
Может быть стоит поэксперемнитровать и с визуальным оформлением в этой игре?
Вконце видео пожарник чуть не превратился в водолаза :)
Безумно круто!!! Как по мне, можно не сомневаться) В грибнике ведь тоже просто грибы ходить собирать и всё, а как круто и душевно получилось)) Конечно, можно добавить орущую девушку в конце уровня, которую дядя пожарник героически спасает и ещё мир разрушающийся огнём, тем самым усложняя прохождение. Но вопрос, надо ли?))
@dizlv, если честно, то я не понял что вы имеете в виду. Общий графический стиль, цветовая гамма или оформление уровней? Под графической составляющей ведь можно понимать все что угодно и что конкретно вы хотели этим сказать — мне совершенно не понятно.
Ваш комментарий в твиттере я как-то пропустил и проверив сейчас — не смог его найти.
@flahhi, в этой игре изначально планировалась намного большая разрушаемость уровней чем это было, например, в Зомботроне. То есть намного больше всяких объектов с которыми можно будет взаимодействовать и постройки которые могут сгорать полностью или частично с последующим разрушением. То есть по факту если игрок не успевает добраться до какого-то места и потушить там пламя которое сжигает подходы и проходы — то уровень по праву можно считать заваленным.
Так же думал и о том что могут быть нейтральные герои которых надо выводить из опасности, но идеи с ними пока отложены т.к. долго и сложно реализуемо все. Время покажет что в итоге получится и получится ли вообще :)
@Ant.Karlov, и цветовая гамма, и стиль рисования объектов (например камни, ящики, деревья).
Про ахиреткутуру уровней ничего не могу сказать — они получаются интересными и свежими каждый раз.
Условно говоря, судя по этим скриншотам, создается впечатление, что это все тот-же Зомботрон, только с другим персонажем.
После просмотра видео сложилось впечатления что игра будет скучной. Антон, посмотри эту игру https://turbulenz.com/games/save-the-day/play, может возникнуть новые идеи как сделать игру интереснее
Антон, мне понравилась демка. Будет очень жаль, если такой труд не выльется (в данном случае буквально) в хорошую игру.
Возможно тебя заинтересует такая игра как sandbox на ios, или другие игры-песочницы. В любом случае желаю тебе удачи. Такое трудолюбие достойно уважения.
Проблема большинства игр Антона - малая динамичность. В этом плане самой лучшей игрой был и остаётся первый Mining Truck.
Антон, попробуй заставить себя буквально удвоить скорость всех объектов (в том числе гравитацию и прочие константы) - поначалу всё покажется слишком резким и неестественным (а также могут вылезти новые баги физического движка, которые придётся исправлять), но по мере разработки и полировки всё это загладится и станет столь же казуальным, как и в Зомботронах... только с динамикой!
Ох какую офигенную кровь можно сделать
Любопытно.
Огнеборцу наверное надо всяких инструментов надавать - топоры, багры, огнетушители, пенные пушки и прочие брандспойты.
А помимо горючего добра еще всяких чертей огненных и прочих саламандр, плюющихся огнем.
? выйдет замечательно, но так же, как и с тайм машиной зомботрона, на который забил в ярости, ибо из-за лагов пройти его тупо невозможно вооще никак. Наверное надо больше оптимизировать.
P.S. Черт, забыл, надо чтоб были корованы и их можно было грабить. Башка садовая, ну как же элементарное-то так тупо забывается :)
Выложи пожалуйста еще несколько В?ДЕО на которых ты рисуешь, ОЧЕНЬ ?НТЕРЕСНО смотреть и наслаждаться процессом!
А ящики почему не плавают? По геймплею возможно стоит добавить действительно опасные nps или там электричество, а так не увидел для игрока никакой опасности, разнообразить инвентарь разными типами огнетушителей, возможно физику воды и огня использовать для какой то другой темы для игры. К посту про караваны :) Может сразу еще кукурузу выращивать один черт поливать может... Вертолёты пожарные тушащие лес и поля с урожаем... Затопить кротовые норы... ?ли вообще огне борец злодей задумал остудить водой ядро планеты при этом задача игрока помешать ему... Антон прости за фонтан но может что то поможет придумать :)
@Андрей, во флеше большую динамичность крайне сложно сделать так как все упирается в производительность. Впрочем я попробую немного ускорить игровой процесс, если это получится и действительно пойдет на пользу.
@dizlv, спасибо за разяснения. Стиль рисования такой какой есть — ничего с этим уже поделать не могу. Мне нравится.
@Рома, спасибо за ссылку! Посмотрел, действительно довольно динамичненько и весело так :)
@?ван,
> А ящики почему не плавают?
Потому что набиты тяжелым содержимым типа гвоздей и гирь ;)
Про кукурузу и вертолеты порадовало. Прям, потопи караван!
Не хочется всех расстраивать, но песочница из этой игры точно не получится. Рассчитываю только на короткий и веселый геймплей без всяких наворотов.
@hakerlab, видео выложу, но сильно позже, скорее всего в начале следующего года только. Простите.
Буду ждать с нетерпением.
Под новый год, вот будет ПОДАРОК :)
?дея: Можешь оформить статью как новогодний подарок с видео для читателей.
Антон, по поводу вашего стиля: он уникален, да пусть особо гамма не меняется из игры в игру, но за то ваши игры можно отличить из тысячи, что-то вроде визитной карточки, так что мне понравилось.
круто, программная вода и огонь это очень круто! : )
О господи, мне страшно за свой компьютер...
А здесь есть порошковый тушитель? )
впечатляет какие чедеса можно творить в 2д
Антон, а что с паровозами? Там ведь уже были наработки, почему ты перешел на совсем новый проект?
? в итоге получилось опять желе:)
@Аноним, в отношении паровозов очень сложная и не однозначная история. Разработка сложна и непредсказуема, а успех и перспективность под большим вопросом. Поэтому из-за всех не однозначных моментов с ними — пока очень сложно вернуться к разработке этой игры.
@ReMind,
> ? в итоге получилось опять желе:)
Ничего подобного! Просто на видео в игре установлено 35fps. А при 60fps вода как вода, плюс повышенная динамика игры. Но к сожалению 60fps не потянут некоторые компьютеры, поэтому получается чуть-чуть слоу-мо на 35fps. Впрочем для любителей экстрима я сделаю скрытый переключатель на 60fps, на ваш страх и риск ;)
@Ant.Karlov,
Так а что если увеличить вес/притяжение частиц к земле? Вроде и на 35 FPS должно поживее выглядеть. Как раз добавило бы динамики о которой выше писали.
Конечно, по видео сложно судить, но лично меня как раз и отпугнул этот слоу-мо. Не чувствуется вес воды, если уже говорить о реалистичности:)
Ящики совсем не взаимодействуют с водой. Бросается в глаза что напором они не сталкиваются ( а простым касанием игрока - легко) и не плавают, хотя катятся неплохо. я думаю с темой огня и воды куда больше подойдет больше подойдут головоломки, что бы сначала пришлось подумать что и в какой последовательности делать, а потом бросаться на огнеборьбу.
@ReMind,
> Так а что если увеличить вес/притяжение частиц к земле?
Физика в моих играх (ну и вообще в играх с использованием Box2D) моделируется в условиях "сферического вакума", то есть по факту вес тел не влияет на их ускорение свободного падения (нет плотности воздуха).
В случае с водой, если сделать частицы более тяжелыми, то плотность воды возрастет и как правило понадобится вдвое больше частиц, что опять же скажется на производительности. Можно конечно настроить еще вязкость, но в итоге опять получится немного желе. Можно еще подшаманить шаг просчета чтобы частицы двигались быстрее, но велик риск что они будут пролетать сквозь физические тела небольшой толщины (к слову они и так проскакивают иногда), а если делать более точные расчеты, то опять страдает производительность... Такой вот замкнутый круг.
Представленная "вода" все-равно ближе к реалистичной модели воды, так как для её реализации не используются физические тела, что позволяет использовать очень много частиц, а следственно и более реалистичную симуляцию. А слоумо — это издержки достаточно медленного флеша и я уже не в силах что-то с этим поделать. Будь у меня мощь аппаратной поддержки, все бы было в разы проще!
> Не чувствуется вес воды, если уже говорить о реалистичности:)
Полного реализма так или иначе не получится. В игре это вода позиционируется как пена, так как в весьма маленьком балоне будет ощутимый запас ;) Я не претендую на симулятор пожарного или еще что-то. Моя цель создать красивую игру :)
@BolT, в самом тексте записи я не зря упомянул что интеграция воды с физ движком не полная. В представленном примере реализовано только одностороннее взаимодействие частиц с физическим миром.
Впрочем уже сейчас с уверенностью могу сказать что ящики и не будут плавать в воде (не факт что ящики могут плавать не смотря на то что они из дерева, ведь мы не знаем что внутри), в игре не планируется больших водоемов в которых прийдется барахтаться.
А вот некий импульс вода сможет передавать объектам, но небольшой, так как в игре вода позиционируется больше как пена. Ну и данную игру я представляю себе как экшен/головоломку, потому что игроку нужно будет не просто всех перемочить (в прямом и переносном смыслах), но и прийдется местами немножко подумать.
Антон, будет ли в ближайшее время добавлена в Anthill система обработки коллизий. Т.е. какая-нибудь примитивная, без физ. использования движка.
Очень часто в твоих играх элементы интерфейса работают намного медленнее, чем скорость с которой я готов ими действовать. Например, в моменты перехода между экранами меню у тебя воспроизводятся различные эффекты с кнопками прежде чем ими можно пользоваться. Это немного раздражает, потому что когда смотришь на это первый раз это красиво, но когда уже играешь и повторяешь эти действия с меню по 100 раз, то накапливается раздражение от этих медленных эффектов меню.
Может, я и не прав и мое мнение основывается на моих личных особенностях восприятия. Но когда я прочитал книгу Джеффа Раскина "?нтерфейс: новые направления в проектировании компьютерных систем", то увидел и теоретическое обоснование этой проблемы. Нельзя искусственно ограничивать скорость взаимодействия человека и интерфейса.
У меня все.
@helio,
> Антон, будет ли в ближайшее время добавлена в Anthill система обработки коллизий.
Не могу ничего конкретного сказать по этому поводу. Сейчас мне некогда заниматься подобной реализацией и особой необходимости в этом не вижу. Поэтому мало вероятно что буду работать над этим в ближайшее время.
@Gost001005, не видел, но автор спрашивал у меня разрешение по поводу использования этого грузовика и я ему его дал, о чем собственно и написано в описании этого трофея ;)
@Шота Геймдевелоповидзе, согласен с вашим высказыванием. Сам я стараюсь очень внимательно относится к юзабилити даже в том случае когда разрабатываю какие-то элементы интерфейса для закрытого использования.
Только вот в отношении анимаций в игровых меню я бы с вами поспорил. Все дело в том, что интерфейс должен быть быстрый и не раздражать медленными анимациями в том случае если мы говорим о каких-то функциональных программах с которыми приходится сталкиваться время от времени и выполнять какие-то действия. Это же правило следует применять и к играм где игроку приходится взаимодействовать с игрой исключительно через игровой интерфейс.
В моем случае, практически все игры представляют собой аркады где за 1-2 часа игрового времени игрок проводит за игровыми интерфейсами максимум 10% от всего игрового времени. Я считаю, что это не много, и анимации интерфейсов не должны раздражать.
Антон, предлагаю заменить огонь на мультяшный-рисованный, т.к. этот тут не вписывается.
Да и вообще, убрать огонь. Оставить воду.
Сделать на ее основе физ. пазл.
Выпустить на iPad.
Будет красиво.
Здравствуйте Антон.
Здесь работает эффект Half-Life там ящики всегда всплывали вот и рефлекс у некоторых, ассоциации они такие. Если дерево - то всплывает, металл тонет, сделайте дизайнерские вставки утяжеляющие ящик(например металлические перекрестия или болты по периметру) дабы избавиться от этой ассоциации.
НО, всплывающие ящики пригодились бы в дизайне головоломок, например: яма, в ней ящики, чтобы перейти на другую сторону надо затопить яму и по ящикам перепрыгнуть.
С Уважением.
былобы интересно добавить запас воды и насос для озер с водой
? ДОБАВ?ТЬ ОЗЕРА
?БО НЕХРЕН
Добавление озёр увеличит нагрузку...
@Uber-Japan,
Сразу скажи, что ты хочешь - симулятор нефтяной скважины. )
О Zombotron:
http://danieldefo.ru/forum/showthread.php?t=44211
Антон, скажи, как ты сделал сетку в Zombotron`е, когда работаешь с терминалом?
Это:
1) Большое изображение с сеткой?
2) Затайленное изображение с сеткой?
3) Линии в 1 пиксель, нарисованные на канве?
@Uber-Japan, сетка в терменале — это большое изображение нарисованное заранее в Photoshop :)
А я и то думаю, почему у меня фигня получается с 2-м и 3-м пунктом. )
Огромный выбор самых прикольных бесплатных игр с клиентом здесь: http://anidog.ru/igry-s-klientom
Антон, это не безумие на Flash... ЭТО СПАРТА ПО КОМПУ!!!
Отличная демка получилась!
Тоже в планах была игра про пожарника, но теперь пожалуй отложу её разработку :-)
18 Ноября 2013
— 15:34
#