Мне вот в Go другое не нравится, то что он за меня неявно решает где выделить память
Есть такое. Я иногда юзаю отладочный вывод escape analysis, чтобы понять, в куче там будет аллокация слайса или на стеке. Но чаще всего безопасно хоть и на куче выделить, но реюзать память - тут никто жизнь не испортит. :D
А ещё всякие zero alloc алгоритмы можно много где придумать (тестировать через benchmark с репортом аллокаций). Я даже поиск пути сделал без аллокаций. :D
Эту драму и имел в виду, просто не хотел расписывать подробнее. В оригинале так:
Some of this stemmed from unforced errors on the part of Unity. They had just gone through a crisis of pricing that culminated in the resignation of their CEO and they seemed out of touch with indie developers
То есть, всё та же политика оплаты, но добавляет ещё смену CEO и отрыв от инди разработчиков. Оценить отрыв от инди-разрабов мне сложно, так как я не особо в теме Unity.
Расписывать не хотел, потому что может кому-то это всё - весомый момент, но для меня он таковым не выглядит, так как самую странную часть изменений они откатили. Я бы Unity со счетов не сбрасывал по этому критерию, и рад, что они тоже дали движку шанс. Уход CEO - вроде бы даже относительно нормальный исход, хотя я не знаю, кто его заменил. Но прошлый CEO как будто бы не особо хорошую репутацию имел.
We also migrated from Bevy for similar reasons. The Bevy upgrade cycle is absolutely caustic. They don't have any guardrails against what they break. Rust was fine. The problem was 100% Bevy.
Yes, it hasn't hit 1.0 yet. It's going to be unstable and things are goign to break. That's the point for now.
Всё ещё считаю, что люди слишком часто хотят обновлять версию движка. Это выглядит как портирование игры с Godot 3 на Godot 4 в процессе разработки игры. Иногда такое нужно, но не в каждой же игре.
Про моддинг:
The article definitely mentions one thing that Rust does not support well (at least for now): native modding, or the ability to code for the mod in the same language as the main game implementation. This has to do with Rust’s unstable ABI, and it will not improve in the near future.
Мне кажется, ABI важен, когда моддим с реверсом и патчингом бинаря, а если там подгрузка скриптов и/или ещё каких-то файлов с диска, то не особо и важно, что там с самим бинарём. Но, видимо, людям прямо хардкор до кишочков важен. Я бы не списывал моддинг со счетов только по этому, а то либо всё, либо ничего.
Про Rust:
Rust definitely has its strengths — but not in 95% of game development projects.
I've pondered a lot over whether Rust-the-language is a good fit for (indie) games at all. Rust excels in areas where correctness and reliability are required, but for games... I'm not sure it's important enough. Many of the most financially successful games in the last decade were quite buggy, but they shipped in time for lots of people to buy them.
Я думаю если Rust прямо любимый язык и по нему 5 лет экспертизы, то есть как минимум этот плюс, если сравнивать с "никогда не писал на C#".
Языку Go обычно предъявляют за GC, но как бы и ладно, с ним зато удобно и движкам типа Unity наличие GC в C# не мешает настолько сильно. А производительности пока хватает.
Вот я тоже не до конца понял, как будто бы тема не раскрыта. Сначала с радостью взяли Bevy из-за лучшего ECS на диком западе (и это правда), но потом выбросили ECS и зажили без тревоги. :D
В теории, у них есть выбор ECS и на Unity, даже больше одного, но ничего об этом не нашёл. Надо читать комменты на реддите, может, они прояснят. Upd: я нашёл, залетаем - https://www.reddit.com/r/rust/comments/1ka4g28/migrating_away_from_rust/ Я пособираю некоторые комменты и может добавлю в отдельном комменте тут цитаты.
У меня ноль коммерческого опыта с ECS, поэтому я отслеживаю чужие истории и читаю статейки для общего развития. Пока что комфортно на обычном подходе + идеи из data-oriented design (плоские объекты в массивах, без лишних указателей, всякое такое).
В целом, Ebitengine очень близок в этом плане к Bevy (минусы и слабые места). Хотя субъективно мне конечно хочется выделять более простой язык и меньшую одержимость движка на одной конкретной парадигме (ECS), но для большинства всё равно любой меинстримовый движок будет в среднем лучше.
(Сам я Bevy не юзал, поэтому и приходится лишь косвенно тему затрагивать)
Но разрыв от "нарисуй спрайт" до "современные методы отрисовки реалистичного окружения, анимаций и материалов с физикой" с каждым годом все больше.
Я со своей колокольни скажу, что не надо делать современную реалистичную графику и анимации, если вы разработчик инди-игр. Есть разные рынки игр, аудитории, стили и подходы. Undertale выстрелил с графикой, которую любой движок потянет и которую любой средней руки pixel artist потянет (пример наверное не лучший, но какой есть). Ну или baba is you - совсем графика уровня геймджема, но мы всё равно её любим.
Найти свой стиль может быть важнее, чем просто реализм выкрутить. Вот такое имхо.
Если попробовать продолжить список, есть ещё всякие RPG Maker игры, где часто очень простая графика, но игры на нём могут быть увлекательными и аудитория на них найдётся (некоторые на них ещё новелки делают, типа To The Moon). Говоря о визуальных новеллах, тоже жанр, где не так много фичей из меинстримовых движков могут быть жизненно необходимы.
Изначально, когда её для себя открыл, это был PSP, там есть адаптированная версия игры - Carnage Heart EXA (по-моему, она лучше, чем порт). Очень годная игра, хоть и ощущаешь сюжетку как туториал на ~30 часов. :D
А недавно играл на Steam Deck, через эмулятор. :) Без проблем запустилось.
Я могу из своих любимых игр добавить Carnage Heart, там роботов программируешь. Но я сразу замечу, что там не низкоуровневое программирование, так что возможно не совсем в тему.
Сам я работаю над игрой NebuLeet, где программируешь кораблики в космосе. Я планирую на днях попробовать описать принципы визуального языка, что там используется. Наверное будет полезнее, если сравню с тем же Carnage Heart.
Выглядит там это примерно так:
Ещё немного игр из моих референсов:
Human Resource Machine - вот тут ощущается как низкоуровневое, потому что кодим почти на ассемблере
7 Billion Humans - это сиквел HRM, тут уже более высокий уровень, со всякими if'ами
Смысл интринсиков в том, что они часто мапятся на 1-2 машинные инструкции. В процессорах серии x86-64 (Intel, AMD64, ...) есть инструкция BSF, и, скорее всего, её вычисление будет быстрее, чем несколько операций выше. Когда дело касается низкоуровневых оптимизаций, всё же лучше использовать доступные для железа возможности.
Вот примерно такой машинный код (в виде ассемблера) будет для вашего решения:
mov rdx, rdi
xor ecx, ecx
neg rdx
and rdx, rdi
test edx, 4278255360
sete cl
xor eax, eax
test edx, 4294901760
sete al
sal eax, 4
lea eax, [rax+rcx*8]
xor ecx, ecx
test edx, 4042322160
sete cl
lea eax, [rax+rcx*4]
xor ecx, ecx
test edx, 3435973836
sete cl
and edx, 2863311530
lea eax, [rax+rcx*2]
cmp rdx, 1
adc eax, 0
cdqe
ret
И вот такой для интринсика (x86-64):
xor eax, eax
rep bsf eax, edi
ret
И для ARM тоже будет работать:
rbit r0, r0
movs r1, #0
clz r0, r0
bx lr
Это просто пример. Но вы сами можете проверить в godbolt. Главное не забыть передать условные -O3 и прочее.
Гипотетическую разницу в производительности посчитать можно через таблицы Агнера. Например, можно просуммировать latency первого и второго вариантов, а потом сравнить. BSF - не самая дешёвая операция (плюс там rep), но против нескольких других инструкций она будет выигрывать (в теории).
Можно эмпирически на какой-то машине побенчмаркать и разницу нащупать. Здесь стоит быть осторожным и не намерить шум.
Без логов из консоли тяжело понять, что там пошло не так. Вообще в браузере я тестил только в Firefox и Chromium. Я точно знаю, что в Safari репортили очень низкую производительность. Это скорее к эффективности и особенностям wasm-движка в браузере, чем к Ebitengine, насколько я понимаю.
Я использую эту библиотеку (ссылка на онлайн демо): https://ebitenui.github.io/ Вроде бы ещё другие варианты есть, но этот для интерфейсов средней сложности подходит (хотя порог входа там высокий). Я планирую сделать обёртку над этой либой, чтобы как раз для прототипов и для начинающих.
Она работает на Linux, Windows, MacOS, Android и в браузере (wasm). Игра релизнулась в стиме и там есть интеграция (ачивки и всё такое). Под Steam Deck тоже линуксовые билды легко запускаются.
Под десктопы всё без проблем - обычная кросс-компиляция Go, как мы привыкли. Под wasm - аналогично. Под Андроид сложнее, так как нужно будет использовать gomobile, но в целом это не rocket science.
Ebitengine заявляет поддержку и других платформ. Например, Nintendo и iOS (возможно ещё какие-то есть, полный список на сайте движка), но я их ни разу не пробовал.
Исходники игры открыты, можно найти по ссылке выше. Там правда используются немного другие версии библиотек, я для серии туториалов специально из своего фреймворка выносил всё в аккуратные модули, чтобы другие могли ими воспользоваться.
Сложно определить, где нужно подробнее описывать, а где можно и сразу код показать. Так как это серия статей, которую я вполне вероятно буду немного обновлять по мере расширения, обратная связь может помочь улучшить этот материал и упростить изучение будущим читателям.
Есть русскоязычное сообщество разработки игр на Go в телеграме: https://t.me/go_gamedev Если хочется в формате чата пообсуждать тему, то подключайтесь.
Ааа, вот оно как. Я пропустил момент с исчезновением Zachtronics...
Надо погуглить историю, интересны детали.
Есть такое. Я иногда юзаю отладочный вывод escape analysis, чтобы понять, в куче там будет аллокация слайса или на стеке. Но чаще всего безопасно хоть и на куче выделить, но реюзать память - тут никто жизнь не испортит. :D
А ещё всякие zero alloc алгоритмы можно много где придумать (тестировать через benchmark с репортом аллокаций). Я даже поиск пути сделал без аллокаций. :D
Эту драму и имел в виду, просто не хотел расписывать подробнее.
В оригинале так:
То есть, всё та же политика оплаты, но добавляет ещё смену CEO и отрыв от инди разработчиков. Оценить отрыв от инди-разрабов мне сложно, так как я не особо в теме Unity.
Расписывать не хотел, потому что может кому-то это всё - весомый момент, но для меня он таковым не выглядит, так как самую странную часть изменений они откатили. Я бы Unity со счетов не сбрасывал по этому критерию, и рад, что они тоже дали движку шанс. Уход CEO - вроде бы даже относительно нормальный исход, хотя я не знаю, кто его заменил. Но прошлый CEO как будто бы не особо хорошую репутацию имел.
Не нашёл ничего про ECS, поэтому свой коммент там оставил. Но нашёл что-то другое.
Собрал несколько цитат с реддита
Апдейты Bevy:
Всё ещё считаю, что люди слишком часто хотят обновлять версию движка. Это выглядит как портирование игры с Godot 3 на Godot 4 в процессе разработки игры. Иногда такое нужно, но не в каждой же игре.
Про моддинг:
Мне кажется, ABI важен, когда моддим с реверсом и патчингом бинаря, а если там подгрузка скриптов и/или ещё каких-то файлов с диска, то не особо и важно, что там с самим бинарём. Но, видимо, людям прямо хардкор до кишочков важен. Я бы не списывал моддинг со счетов только по этому, а то либо всё, либо ничего.
Про Rust:
Я думаю если Rust прямо любимый язык и по нему 5 лет экспертизы, то есть как минимум этот плюс, если сравнивать с "никогда не писал на C#".
Языку Go обычно предъявляют за GC, но как бы и ладно, с ним зато удобно и движкам типа Unity наличие GC в C# не мешает настолько сильно. А производительности пока хватает.
Вот я тоже не до конца понял, как будто бы тема не раскрыта. Сначала с радостью взяли Bevy из-за лучшего ECS на диком западе (и это правда), но потом выбросили ECS и зажили без тревоги. :D
В теории, у них есть выбор ECS и на Unity, даже больше одного, но ничего об этом не нашёл. Надо читать комменты на реддите, может, они прояснят.
Upd: я нашёл, залетаем - https://www.reddit.com/r/rust/comments/1ka4g28/migrating_away_from_rust/
Я пособираю некоторые комменты и может добавлю в отдельном комменте тут цитаты.
У меня ноль коммерческого опыта с ECS, поэтому я отслеживаю чужие истории и читаю статейки для общего развития. Пока что комфортно на обычном подходе + идеи из data-oriented design (плоские объекты в массивах, без лишних указателей, всякое такое).
В целом, Ebitengine очень близок в этом плане к Bevy (минусы и слабые места). Хотя субъективно мне конечно хочется выделять более простой язык и меньшую одержимость движка на одной конкретной парадигме (ECS), но для большинства всё равно любой меинстримовый движок будет в среднем лучше.
(Сам я Bevy не юзал, поэтому и приходится лишь косвенно тему затрагивать)
Я со своей колокольни скажу, что не надо делать современную реалистичную графику и анимации, если вы разработчик инди-игр. Есть разные рынки игр, аудитории, стили и подходы. Undertale выстрелил с графикой, которую любой движок потянет и которую любой средней руки pixel artist потянет (пример наверное не лучший, но какой есть). Ну или baba is you - совсем графика уровня геймджема, но мы всё равно её любим.
Найти свой стиль может быть важнее, чем просто реализм выкрутить. Вот такое имхо.
Если попробовать продолжить список, есть ещё всякие RPG Maker игры, где часто очень простая графика, но игры на нём могут быть увлекательными и аудитория на них найдётся (некоторые на них ещё новелки делают, типа To The Moon). Говоря о визуальных новеллах, тоже жанр, где не так много фичей из меинстримовых движков могут быть жизненно необходимы.
Изначально, когда её для себя открыл, это был PSP, там есть адаптированная версия игры - Carnage Heart EXA (по-моему, она лучше, чем порт). Очень годная игра, хоть и ощущаешь сюжетку как туториал на ~30 часов. :D
А недавно играл на Steam Deck, через эмулятор. :)
Без проблем запустилось.
Я могу из своих любимых игр добавить Carnage Heart, там роботов программируешь.
Но я сразу замечу, что там не низкоуровневое программирование, так что возможно не совсем в тему.
Сам я работаю над игрой NebuLeet, где программируешь кораблики в космосе. Я планирую на днях попробовать описать принципы визуального языка, что там используется. Наверное будет полезнее, если сравню с тем же Carnage Heart.
Выглядит там это примерно так:
Ещё немного игр из моих референсов:
Human Resource Machine - вот тут ощущается как низкоуровневое, потому что кодим почти на ассемблере
7 Billion Humans - это сиквел HRM, тут уже более высокий уровень, со всякими if'ами
Мне в целом интересно, а можно ли посты юзать как что-то вроде девлога для разрабатываемой игры? :D
Кажется, условный dtf или даже stopgame (авторские блоги) для этого больше подходят.
3д игрушки делают, но вроде бы это скорее хаки.
Я как минимум эту игрушку знаю: https://github.com/pixelmek-3d/pixelmek-3d
Смысл интринсиков в том, что они часто мапятся на 1-2 машинные инструкции. В процессорах серии x86-64 (Intel, AMD64, ...) есть инструкция BSF, и, скорее всего, её вычисление будет быстрее, чем несколько операций выше. Когда дело касается низкоуровневых оптимизаций, всё же лучше использовать доступные для железа возможности.
Вот примерно такой машинный код (в виде ассемблера) будет для вашего решения:
И вот такой для интринсика (x86-64):
И для ARM тоже будет работать:
Это просто пример. Но вы сами можете проверить в godbolt. Главное не забыть передать условные
-O3и прочее.Гипотетическую разницу в производительности посчитать можно через таблицы Агнера. Например, можно просуммировать latency первого и второго вариантов, а потом сравнить. BSF - не самая дешёвая операция (плюс там rep), но против нескольких других инструкций она будет выигрывать (в теории).
Можно эмпирически на какой-то машине побенчмаркать и разницу нащупать. Здесь стоит быть осторожным и не намерить шум.
https://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Other-Builtins.html
ctrl+f
__builtin_ctzСкорее всего это.
Без логов из консоли тяжело понять, что там пошло не так.
Вообще в браузере я тестил только в Firefox и Chromium.
Я точно знаю, что в Safari репортили очень низкую производительность.
Это скорее к эффективности и особенностям wasm-движка в браузере, чем к Ebitengine, насколько я понимаю.
Я использую эту библиотеку (ссылка на онлайн демо):
https://ebitenui.github.io/
Вроде бы ещё другие варианты есть, но этот для интерфейсов средней сложности подходит (хотя порог входа там высокий).
Я планирую сделать обёртку над этой либой, чтобы как раз для прототипов и для начинающих.
Да. Как пример - моя игра Roboden.
Она работает на Linux, Windows, MacOS, Android и в браузере (wasm).
Игра релизнулась в стиме и там есть интеграция (ачивки и всё такое).
Под Steam Deck тоже линуксовые билды легко запускаются.
Под десктопы всё без проблем - обычная кросс-компиляция Go, как мы привыкли. Под wasm - аналогично. Под Андроид сложнее, так как нужно будет использовать gomobile, но в целом это не rocket science.
Ebitengine заявляет поддержку и других платформ. Например, Nintendo и iOS (возможно ещё какие-то есть, полный список на сайте движка), но я их ни разу не пробовал.
Исходники игры открыты, можно найти по ссылке выше.
Там правда используются немного другие версии библиотек, я для серии туториалов специально из своего фреймворка выносил всё в аккуратные модули, чтобы другие могли ими воспользоваться.
Вышла следующая статья в серии:
https://habr.com/ru/articles/799497/
Сложно определить, где нужно подробнее описывать, а где можно и сразу код показать. Так как это серия статей, которую я вполне вероятно буду немного обновлять по мере расширения, обратная связь может помочь улучшить этот материал и упростить изучение будущим читателям.
Пишите в комментариях или мне в личку.
Не знаю, достаточно ли эта игра будет сложна для вас, но вот я сделал игру на Ebitengine:
https://store.steampowered.com/app/2416030/Roboden/
Она есть на гитбахе:
https://github.com/quasilyte/roboden-game/
Запускается на Android, в браузере, на Linux/Windows/MacOS (в Steam).
Есть русскоязычное сообщество разработки игр на Go в телеграме:
https://t.me/go_gamedev
Если хочется в формате чата пообсуждать тему, то подключайтесь.