Comments 187
Если я не ошибаюсь, то эту статью я видел здесь: https://m.pikabu.ru/story/dodelal_igru_rabotayushchuyu_na_videokarte_5552510
Там тоже нет технических деталей.
Кстати, почему вас беспокоят минусы к случайно оставленным комментариям? Вам же за них ничего не снимается.
Но зачем делать сплошной объект состоящий из множества частиц? Почему сплошное тело на частицы не разбивать при взрывах и прочих взаимодействиях?
Это был экспермент с чистыми частицами, я не хотел усложнять, а хотел проверить практичность метода. Если бы я начал делать такую игру с моим сегодняшним опытом, я бы скорее всего взялся именно за гибрид.
В инете можно найти демки, а так же исходники для Unreal Engine.
Рассматривались ли OpenGL/opencl в качестве платформы?
P.S. Понятно, что проблемы с портабельностью могут быть большие, но если удастся портировать на Линукс — будет здорово!
Похоже, что автор просто поставил туда старую советскую песню, которая ему нравится, вместо того, чтобы найти или купить более атмосферную инструменталку.
Это «Несбыточный свой путь (ария Милиневского)» из техно-оперы В.Аргонова «2032. Легенда о несбывшемся грядущем» http://argonov.ru/2032.html
Мне вот нравится Deep Purple, но я не буду озвучивать ими хоррор. Потому что полностью разрушат атмосферу.
А отдельно от игры послушать Аргонова/ComplexNumbers всем рекомендую!
Ваша первая GIF занимает 8.5 МБ. Ее можно превратить в 800 КБ видеофайл в контейнере mp4 с видео, сжатым кодеком H.264:
files.catbox.moe/js61z9.mp4
files.catbox.moe/5hyavn.mp4
А третья 16-мегабайтная — в 1.8 МБ:
files.catbox.moe/a3k7ar.mp4
Плюс к тому: с видеофайлом у меня есть выбор, могу нажать «Play», могу и проигнорировать. Гифка же начинает жрать мой трафик сразу, причём за счёт КПДВ даже с главной страницы
Если на гоге нет игры, я лучше пойду на торренты, чем воспользуюсь стимовским клиентом.
1. Без клиента игру запустить нельзя.
2. Тормозной.
3. Странный, неудобный интерфейс. Случайно переключился в другой режим, потом не мог найти, как вернуться обратно.
4. Автообновления. Каждый, с.а, раз запускаются обновления. Я просто хочу поиграть, почему надо пользователя заставлять ждать, пока ваш клиент изволит обновиться? И это не одна и не две минуты.
5. Однажды я купил Call of Duty. В магазине, на дисках, лицензионный. Пришел и начал играть. А нет, не начал. COD привязан к стиму. После запуска инсталлятора стим начал выкачивать игру ПОЛНОСТЬЮ со своих серверов по очень небыстрому соединению. С дисков не было установлено ни одного байта. Вот зачем так делать? Зачем раздражать пользователя?
В противовес этому, на GOG:
1. Зашел на сайт, заплатил, скачал, установил. У игры есть exe, который можно запустить. Нет клиентов, нет обновлений, нет проблем.
2. Все игры хранятся у меня и принадлежат мне, а не стиму. Я свободно могу переносить их на новый компьютер без необходимости выкачивать все заново.
Нет, пользоваться стимом должно стать моветоном. Лучше перечислить деньги разработчику и получить от него нормальный дистрибутив. Беда в том, что разработчики предпочитают размещаться исключительно на этой платформе и standalone-сайтов у большинства из них нет.
2. Не без этого.
3. Не представляю как можно случайно включить Big Picture.
4. Хотите просто поиграть — есть автономный режим. В нем стим не качает ничего вообще.
5. Это вопрос к тому, кто диск делал. Стим-то тут причем?
По поводу переноса — на стиме тоже можно переносить игры без выкачивания заново.
- В автономном режиме не работают моды.
Был неприятно удивлен, будучи в загран. командировке.
2 — Все относительно, это вы еще PlayStation Store не пользовались.
3 — Вкусовщина.
4 — У меня только проверка обновлений, на пару секунд. Может вы подписались на бету что у вас каждый раз обновления?
Беда в том, что разработчики предпочитают размещаться исключительно на этой платформе и standalone-сайтов у большинства из них нет.
Ох уж эти разработчики (издатели) не хотят чтобы их игру покупало полтора геймера. Хотят чтобы пользователи получали форум, CDN, облачное хранилище, торговую площадку, возможность оплачивать внутриигровые покупки из кошелька.
Ну не знаю. Если шариться по интерфейсу и не находить, где переключается в другой режим — это не вкусовщина, а, скорее, вопрос юзабилити.
Кто-то же додумался сделать так, чтобы меню открывалось по клику на пиктограмме, которой везде обозначают отключение питания.
> Ох уж эти разработчики (издатели) не хотят
Правильно, не хотят лишних движений делать. Кто мешает зарегистрироваться и на других площадках? По логике, от этого доход должен вырасти. Но лень.
Поддерживать сто тыщ пятьсот площадок — геморой еще тот.
В стиме — удобный стимворкс, удобный контроль апдейтов, удобные настройки магазина. И всё это приправлено 99% продаж.
ДОбавлять еще сто магазинов с кривыми инструментами, ради одного процента? Ну большая компания может на это пойти. А инди нет. Потому что этот один процент даже заморочек с оформлением документов не окупит.
И всё это приправлено 99% продаж.Порядка 50%. GoG — да, только 10%, но с учётом того, что игр там меньше для конкретной игры можно получить увеличение продаж на 20-30% легко, если одновременно начать продавать.
Ну, или Стим, если очень хочется поддержать разработчика, который выкладывается только в нем.
P.S.
К стати, игрушка классная, но компанию я не осилил :)
Как я понял по роликам на ютубе, в Scorched eath физика намного более примитивная и ещё более далёкая от реальности чем даже желейный сабж
сделать иначе, обойдясь парой десятков боксов и чуть чуть частиц
Очень интересно посмотреть и на это тоже, особенно для объектов вроде https://i.imgur.com/qcGOQgW.gif
То что на вашей гифке — вы думаете, если в энгри бёрдс добавить возможность перебивать снарядом блоки на несколько и добавить «гнущиеся» (и ломающиеся при перенапряжении) блоки, то выйдет непохоже?
Навскидку я не могу предложить как нарезать на блоки сплошной «утёс» в который долбимся сбоку, а потом оно падает (первая гифка в статье) Но всё равно, я бы пошёл по пути термеха с динамически меняющимся приближением объектов примитивами. Так что у меня бы с начала не гнулось, а потом сразу ломалось ;)
Правда у меня есть важное отличие от автора статьи — он написал игру, а я — нет. Так что ясно, кого стоит больше слушать.
Навскидку я не могу предложить как нарезать на блоки сплошной «утёс» в который долбимся сбоку
Просто: утей это один объект. При попадании разрезаем на два. Так везде это обычно и работает.
А так — достаточно уникальное и интересное решение.
А мне видится вариант, при котором с ходу и не заметишь, что не разрушенные куски — это не симуляция, а один объект. Если сделать с хорошим сопроматом и современными алгоритмами разбиения объектов на куски, то можно получить те же возможности, что есть при чистой симуляции на чистицах, но решить существующие у этого метода проблемы. Например, вся материя не будет похожа на желе, будут твёрдые стенки. Или за счёт уменьшения числа активных частиц можно будет расширить число потенциальных игроков.
Но с другой стороны, гибрид сложней программировать. Например, в каменты в ветке про мою игру на реддите приходил один из разработчиков Red Faction и говорил, что они страшно задолбались с разрушаемостью.
В общем, у каждого подхода есть достоинства и недостатки. Но если грезить об идеальном универсальном физическом движке для 2д-игр, то гибрид кажется более плодотворным подходом.
Хотя, я исхожу из своего нынешнего опыта с игрой. Может, если пойти дальше в разработке варианта с частицами, то и там можно прийти к идеальному универсальному движку.
Во времена IBM PC-AT 286 вы в подобное могли играть если только на каком-нибудь Крее в НАСА или в Министерстве Обороны...
Как-то «Обычные» движки больше распеарены.
А свой движок я выложил в ассет стор. Он пока платный, но скоро сделаю бесплатным, он скорее хорош как туториал, потому что слишком специфичен для мой конкретной задачи. К примеру, в нём нет ни следа взаимодействия со статичным объектами, так что не просто будет его встроить в другую игру в качестве источника частиц. Но я откомментил важные вещи, так что будет такой пример для новичков.
А готовые движки наверное тут действительно плохо подходят, т.к. нужно делать очень сильную кастомизацию под проект, иначе все действительно будет медленно. Возможно поэтому воксельные движки пока и не сильно распространены.
Поэтому считаю статьи на такую тему важнее даже чем готовый движок. Если все таки найдете время — то почитал бы.
Потому что игра конечно классная, но зачем здесь откровенно пустая статья, да еще нарушающая правила хабра по поводу дублирования материала?
Не плохо, если разрабочик использует хабр как промо для своего продкута, но не плохо бы еще и какую-то полезную и интересную инфу в статью запихать, если это платный продукт. Кроме как «я сделал».
Очень рад за вас, что вы это сделали! Даже в прошлую версию играть было довольно увлекательно.
Думаю каждый пиксель у вас наделен состоянием, которое обновляется дальше исходя из состояния его и соседних. И тогда это можно делать пиксельным шейдером, в том числе и на openGL.
Думаю каждый пиксель у вас наделен состоянием, которое обновляется дальше исходя из состояния его и соседних. И тогда это можно делать пиксельным шейдером, в том числе и на openGL.Зачем предполагать, если можно посомтреть прошлые статьи автора?
Напоминает древнюю досовскую игру для двух игроков, где нужно было стрелять из пушки по замку противника. И замки так же «попиксельно» взрывались и рассыпались. Т.к. игра пошаговая, то и на видюхе забацать можно :) Там помимо физики разрушения была физика полёта ядра в зависимости от силы и направления ветра. Название не помню, даже сейчас бы поиграл…
Но отзывы я почитал и управление мышью добавил, просто оно не включено по умолчанию, его в опциях надо ставить.
А для существующих отзывов можно добавлять комментарии? Вы можете им написать про настройки, возможно они изменят оценку.
А для существующих отзывов я пишу ответы, предлагаю попробовать исправленную версию, но, похоже, у стима нет оповещения об ответах на отзывы, так что люди не возвращаются.
А насчёт многомерных массивов — это две разные особенности: одна связана с интерфейсом с видеопамятью а вторая — с привычкой. Сейчас мы в видеопамять передаём одномерный массив, на стороне видеопамяти — это одномерный буффер. А работа с массивами любой размерности — это вопрос перехода с привычных циклов на множество потоков.
Вот я и думаю: если использовать такую видеокарту для игр (хоть она и стоит 3k$, но мы же оптимистично смотрим в будущее), будут ли тензорные ядра простаивать без дела? Можно ведь рисовать картинку за счёт GPU-ядер а считать физику за счёт TPU-ядер — там их на 110 TeraFLOPS (только не знаю, это отдельно для TPU, или вместе с CUDA).
Как вы именно профелировали и дебажили эти вычислительные шейдеры и командные буферы?
И очень бы хотелось бы увидеть аналитику устройств, которые поддерживают вашу игру.
Может запилишь редактор юнитов и уровней? Было бы круто, конечно, если бы еще и воркшоп подкрутил… Но это уже я много чего хочу.
Последняя версия работает на всех картах, которые поддерживают DX11/12, а не только на картих nVidia через CUDA.
Есть тесная «официальная» интеграция с UE4. Для Unity есть сторонние плагины типа этого.
Ну и FleX совершенно бесплатен, да.
The problem lies in SPH method's inability to do surface tension effects very well as well as maintain fluid incompressibility and energy conservation when there aren't too many substeps used. In general you need about 5-10x more substeps to achieve the same level of incompressibility using SPH than with the Position Based Fluids (PBF) method.
Есть, конечно, работы, в которых описываются способы решить проблему симуляции несжимаемых жидкостей с помощью SPH, например, Divergence-FreeSPH, но я сталкивался с такими реализациями (не то, чтобы у меня прям такой богатый опыт...)
А вообще в своих экспериментах я много-много раз убеждался в том, что SPH не просто так списывают со счетов в пользу того же FLIP. Просто это очень старый метод.
PBF считает столкновения между частицами честно. В этом его сила и слабость, т.к., обычно, в PBF-солвере у частиц одинаковый радиус. Т.е. океан не симулируешь, ибо частицы на поверхности должны чем-то поддерживаться. А вот у FLIP такой проблемы нет, но он уже не годится для мелких точных симуляций, где PBF на коне. Но, опять-таки, у PBF свои проблемы, вроде потерь энергии при взаимодействии частиц (бывают такие, что требуется вносить дополнительно, чтобы симуляция не затухала слишком быстро). Зато стабильность и возможность смены фаз веществ (это же просто куча частиц, с ними можно что угодно делать на ходу). Ну и параллелится хорошо, отсюда и целый particle-based FleX появился.
Короче, все зависит от задач, но к SPH я добровольно не вернусь в своих задачах по симуляции жидкостей.
Я просто недавно видел очень неплохие результаты по SPH на CFD-weekend, к примеру.
Вот ещё сходу ссылка на кандидатскую работу с SPH: docplayer.ru/63025692-Chislennyy-metod-sph-ispolzuyushchiy-sootnosheniya-raspada-razryvov-i-ego-primenenie-v-mehanike-deformiruemyh-geterogennyh-sred.html
P.S. сам я ни игровыми движками, ни частицами не занимаюсь — у меня в основном гиперзвуковое обтекание газом (в т.ч. с химией) и методы конечного объёма или DG. Просто интересно, что ещё в мире происходит.
Согласен, что туториалов не хватает. Захотелось самому написать свод
Доделал игру, работающую на видеокарте