В то время как ещё не вышедшие новые герои обрастают хейтерами («о нет, мобильная графика»), безусловными фанатами («давно жду, дайте две») и пессимистично‑настроенной публикой («не вывезут, у них из опыта только Iratus») — в Olden Era оказалась упущена другая возможность развития серии. А именно — боёвка в стиле Disciples 1/2.
Различные принципы, которые должен понимать разработчик, чтобы повысить производительность игры. Многое из перечисленного касается не только движка Godot.
Нейросеть Hunyan3D-2, генерирующая 3D модели по 2D картинкам, от компании Tencent появилась недавно в открытом доступе. Ее рабочая версия в виде «3D студии» существует, но доступна только владельцам китайских мобильных номером (или если у вас есть WeChat). Но также она выложена в виде исходных кодов ее уже «запилили» для использования с ComfyUI. Этот туториал поможет установить враппер модели под Windows 11.
..или Blender в Godot 🤔 в общем не суть)
История от Miguel de Icaza про встраиваемый игровой движок.
Много лет назад, работая в Xamarin, где мы создавали кроссплатформенные библиотеки для мобильных разработчиков, мы хотели предложить нашим пользователям возможности 2D и 3D игр в виде добавления 2D или 3D контента в их мобильные приложения.
Для 2D мы создали и разработали множество библиотек, вдохновленных Cocos2D.
С 3D ситуация была сложнее. Мы финансировали несколько библиотек в течение нескольких лет, вносили свой вклад в другие, но ничего не вышло (история этого заслуживает отдельного поста).
Примерно в 2013 году мы огляделись вокруг, и на тот момент у нас было два претендента: один — встраиваемый движок с множеством симпатичных функций, но не очень хорошей поддержкой пользовательского интерфейса под названием Urho, а второй — Godot, который имел отличную IDE, но не поддерживал встраивание.
В то время я связался с Juan, чтобы обсудить, можно ли превратить Godot в такой движок. Хотя я обычно веду подробные записи всех своих встреч, эти записи, к сожалению, пропали в результате приобретения Microsoft, но из того, что я помню, Juan сказал мне: «Godot — это не то, что вы ищете» в двух измерениях, не было никаких ближайших планов по превращению его во встраиваемую библиотеку, и он не был таким продвинутым, как Urho, поэтому он рекомендовал мне выбрать Urho.
Нейронные сети в играх можно использовать не только для генерации картинок, звука и простыней текста. И даже не для того, чтобы предугадывать желания игрока. А что, если применить их для того, для чего они изначально задумывались – интеллектуального поведения и принятия решений?
Начнём с малого: допустим, мы создаем NPC, которые умеют собирать предметы по заданным правилам. Наша цель: создать «крафтовый» интеллект, т.е. такой интеллект, который выбирает, что будет делать NPC из предметов в его инвентаре. Такую штуку можно попробовать реализовать с помощью конченных конечных автоматов, поведенческих деревьев (behaviour tree) или ещё как-нибудь. Но, когда рецептов много, ингредиенты пересекаются, а потребности NPC меняются, такое дерево очень быстро разрастется до трудноподдерживаемого состояния. А если у нас вдруг что-то поменялось в технологической схеме?
В статье мы кратко опишем нейросетевой подход к этой задаче и полученные результаты.
Я автор настольной игры о программируемых роботах «Битва Големов». Игры, обучающей детей от 6–7 лет. И я хочу рассказать, почему даже 6 простых команд, которые «понимают» роботы, стали для меня головной болью, как я решал проблемы игровой механики и почему в итоге правила игры «распухли» до 16 страниц, но это не страшно.
В мире видеоигр эмуляторы стали настоящей находкой для поклонников классических проектов. PPSSPP — один из самых популярных эмуляторов для PlayStation Portable (PSP), который позволяет нам вновь окунуться в атмосферу любимых игр, но уже на современных устройствах. Однако чтобы играть без сбоев и лагов, нужно убедиться, что код эмулятора хорошо написан.
Итак, теперь у нас есть первая приблизительная оценка видимости листьев из порталов, хранящаяся в массиве mightsee каждого портала. Вычислять, что именно видно через последовательность порталов, сложно, поэтому мы вместо этих вычислений используем «консервативную» оценку. Она ни за что не скроет лист, который должен оставаться видимым.
«Это просто задача отсечения»
Свет внезапно выключается. Вы сидите в огромном конференц-зале. Кто-то включает проектор. На экране сам Майкл Абраш! Похоже, это знаменитый доклад Quake Postmortem с GDC 1997.
Он говорит о порталах.
Мы берём плоскости отсечения, ограничивающие максимальный объём видимого, и отсекаем их по всё более дальним порталам, пока они не пропадут.
Градиентное текстурирование — это методика оптимизации 3D-текстурирования, в первую очередь предназначенная для мобильных видеоигр. В ней используются текстурные карты низкого разрешения и градиентные цвета, позволяющие снизить ресурсную нагрузку на игровые без ущерба качеству графики. Благодаря применению градиентов в низкополигональных 3D-моделях симулируются такие эффекты, как освещение, тени и глубина, позволяя избавиться от необходимости в текстурах высокого разрешения, потребляющих больше ресурсов.
Эта методика обеспечивает эффективный баланс между производительностью и визуальным качеством, оптимизирует время загрузки и улучшает игровой процесс. Кроме того, она позволяет гибко менять цветовые палитры и может адаптироваться под разные 3D-модели, снижая размеры файлов и оптимизируя использование памяти.
C и C++ не имеют встроенной сборки мусора, поэтому разработчик сам решает, как и когда выделять и освобождать память. Мы, конечно, можем покивать в сторону STL, сокрытия аллокаций в контейнерах, но от этого они никуда не денутся. Просто если раньше приходилось думать про выделенный кусок памяти, понимать, как он скажется на времени фрейма, помнить, что его надо удалить (а может, не надо и стоит оставить на следующий фрейм), то теперь всё заворачивается в сахарные контейнеры и разработку в стиле STL-blin-vse-sterpit. STL-то может и стерпит, и даже как-то будет ворочаться, однако не стоит полагаться исключительно на системный аллокатор, бездумно вызывая new или malloc для каждого запроса памяти. Вы ведь понимаете, что std::vector посреди цикла или горячей функции — это плохая идея?
Кроме того, такая практика приводит к ожидаемым проблемам с производительностью даже в обычных приложениях, чего уж говорить про высоконагруженные системы или игры, которые претендуют на что-то быстрее 20 фреймов в секунду.
Пытаться оптимизировать код, который использует системные аллокаторы, — всё равно что сгребать листья в кучу ветреным днём: куча, конечно, сгребается, но постоянно приходится махать грабельками, чтобы она оставалась на одном месте. Даже если выделения памяти происходят последовательно, друг за другом, вот прям без всяких перерывов, нет гарантии, что эти участки будут расположены хотя бы близко друг к другу. В результате при обработке таких данных процессору приходится прыгать по разным участкам памяти, теряя такты просто на поиск данных вместо того, чтобы работать с ними.
Я отнюдь не призываю вас встать на путь ручного управления памятью, ибо он будет усеян ловушками, граблями и чреват утечками. Но разработчик в итоге оказывается перед выбором: либо довериться системному аллокатору и столкнуться с проблемами вроде размазанного перфа, когда вроде и код написан правильно, модно и молодежно, но отчего-то работает небыстро, либо взять всё в свои руки, создавая собственные механизмы выделения и освобождения ресурсов.
Ребята из HFT, Database, Automotive и Embedded-систем наверняка могут рассказать немало интересных историй про оптимизацию new/delete. Давайте я расскажу немного про разные аллокаторы в играх?
Должен признать, у меня есть некая особая любовь к классическому DOOM. Несмотря на то, что игре уже 31 год, в нее все еще весело играть самому (хотя и выходит у меня так себе) или просто смотреть на то, как другие в нее играют (вот в этом я показываю себя лучше); и поскольку исходный код игры открыт, ей можно наслаждаться на любой современной платформе — ПК, смартфон, камера, осциллоскоп — да и вообще на любой вещи, которая придет вам в голову. В результате чего, благодаря ряду обстоятельств, я оказался меинтейнером нескольких связанных с DOOM пакетов в Fedora Linux.
Итак, за несколько месяцев до нового релиза, проект Fedora Linux осуществляет массовую сборку всех пакетов. Это имеет несколько преимуществ — позволяет убедиться в совместимости ABI, обновить статически линкуемые зависимости, использовать новые оптимизации компилятора и так далее. Как бы то ни было, с приближением релиза Fedora Linux 42 в середине апреля, пришло время для массовой пересборки, и как часто бывает, не все пакеты выжили. Одним из пакетов, которые не удалось собрать оказался chocolate-doom.
Мы не удивим наших читателей тем фактом, что на сегодняшний день сфера видеоигр является наиболее динамично развивающейся и перспективной в индустрии развлечений. Гейминг-экспансия приобрела поистине планетарные масштабы благодаря смещению акцента с монопользовательской версии на многопользовательскую, чему способствовало развитие сервисов прямых трансляций, потоковых и кроссплатформенных игр с возможностью онлайн-общения, превратив тем самым игры в полноценные сообщества по интересам и платформы для общения и заработка пользователей со всего мира. По прогнозам аналитиков выручка на игровом рынке в 2025 году достигнет $522,5 млрд, а число игроков — более 3,3 млрд.
Итак, мне удалось дойти до этого момента, и эмулятор начинает писать в неправильную область PPU, что конечно же портит всё выполнение.
Приветствую тебя. Ты, наверное, уже задался вопросом, какой нездоровый на голову человек будет влезать в такие долги при нынешней экономической ситуации в стране, да и в мире в целом. На что он вообще надеется, делая визуальную новеллу, да ещё в пиксель-арте и в советском сеттинге по детским страшилкам? Он что, совсем больной? В целом вопросы справедливы и, возможно, даже диагноз верный. Но давайте взглянем чуточку назад и найдём причинно-следственные связи для столь отчаянного, на первый взгляд, поступка.
Из новостей: разработчики MiSide про 1% с продаж игры, SDL 3, продажи Balatro превысили 5 миллионов копий, экспериментальная поддержка C# в Defold, динамическая разрушаемость с помощью Havok Physics.
Из интересностей: почему на создание Judas Кена Левина ушло 10 лет, как создаются бойцы Super Smash Bros, загадка дыры.
- Чем чревато брать float или double в качестве типа данных для хранения позиций объектов?
- Как это может повлиять на наличие багов в игре и ошибки синхронизации сетевой игры или реплеев?
Об этом вы узнаете в этом гайде с наглядными гифками и пруфом на C++
У меня за плечами несколько лет работы в IT, но в сферах, связанных с геймдевом, я никогда не работал. Но это не помешало мне поучаствовать в Tech Jam от Facepunch для ещё не вышедшей s&box. О том, как это было (и обо всех провалах в процессе), я и решил написать.
В этом проекте я хотел ответить на вопрос: возможно ли написать игру на Java для Sega Mega Drive/Genesis. Не хочу раскрывать спойлеры, но ответом будет «да».
Несколько лет назад я повстречал проект Java Grinder, который позволяет писать код для различных ретро процессоров на Java, в том числе для Sega Mega Drive. По сути, он интерпретирует байт-код из файлов .class, полученных после компиляции, в код на Ассемблере 68K. Если файлу класса нужны другие файлы классов, то они тоже считываются и обрабатываются. Все вызовы методов API записываются в выходном коде, либо как встроенный ассемблерный код, либо как вызовы предварительно написанных функций, выполняющих свою задачу.
