Без логов из консоли тяжело понять, что там пошло не так. Вообще в браузере я тестил только в 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 Если хочется в формате чата пообсуждать тему, то подключайтесь.
У меня возникли некоторые неожиданные проблемы, из-за чего следующая часть отложилась. Материал уже есть, но нужно ещё придумать, в каком порядке вводить новые библиотеки, так как иначе там очень резкий скачок в сложности получается. Мне гораздо привычнее каждую библиотеку отдельно рассматривать в деталях, а не делать туториал, где за одну статью мы подключаем 5 новых пакетов.
Мне нравится язык, я его хорошо знаю. А быть при формировании геймдева в Go мне интереснее, чем быть очередным пользователем Unity или Godot. Для хобби мне важно наслаждаться процессом. :)
Если собирать через TinyGo, то размеры будут в разы меньше, в том числе для wasm-сборок под браузер.
Тем не менее, моя самая завершённая игра под wasm без каких-либо трюков(1) и альтернативных компиляторов занимает в архиве с wasm и ресурсами около 9.4MB. Это довольно легко скачивается и раздаётся на itch.io; часть ассетов можно докачивать во время старта игры, показывая крутилку.
Для десктопов размеры (без архивов) размеры примерно 20MB.
На мобилках размер при установке через Google Play тоже около 20MB (time to download ~15s).
Я пока тестировал только Windows, Linux, MacOS, Android и wasm (под браузер) билды. Ebitengine поддерживает ещё и ios, и некоторые консоли (switch и что-то ещё, на страничке проекта есть полный список). На Steam Deck при наличии линуксового билда будет запускаться он, а иначе виндовый через Proton.
(1) Если только не называть трюком то, что я использую XM-музыку, а не OGG. Так треки весят по 100-400kb вместо 3-6mb на штуку.
А если серьёзно, это всё WIP, но я сделал на Ebitengine больше одной игры, поэтому в целом я знаю, что делаю. :)
Игру делаю параллельно написанию статьи, чтобы все повествования были синхронизированы. После выхода всех статей может запишу это всё в виде видео-уроков.
Вроде бы в некоторых редких случаях PNG весит меньше, чем JPG, поэтому видимо неплохой тактиков будет брать в каждом случае то, что занимает меньше байтиков.
Я пишу статьи в markdown и вставляю через старый редактор.
И вот там хабр вырезает почти любые теги и я не находил списка что он поддерживает, а что - нет. Перебирать все теги довольно утомительно, а про abbr я, если честно, даже не знал. Я всегда делал tooltip через title у span.
Так что вот, узнал что-то новое. Теперь буду юзать в новых статьях!
Я не с упрёком, но мне честно больно читать такие комментарии. Вы не поверите, но я старался, писав её. Я нашёл набор достаточно универсальных приёмов, которые можно использовать для более оптимальных библиотек поиска пути, которые очень редко используются. На это есть свои причины: мои трюки работают из-за введений ограничений. Но это же тоже здорово, когда можно найти такие ограничения, которые открывают портал в дополнительные оптимизации.
И да, даже на вашем любимом асме их можно применить и будет буст по сравнению с более прямолинейным подходом.
Я постараюсь описать, почему же статья вообще не про ограниченность Go, а про более фундаментальные вещи. Но это имеет смысл только если вы действительно хотите понять, какой посыл был в статье (как его воспринимать уже ваше дело). Дальше по пунктам.
Есть сотни способов представить матрицу проходимости и я показал один из них, который достаточно компактный и простой в реализации. В статье ещё есть ссылка на "страничный" подход и на Morton space-filling curve. Это всё потому, что да, иногда в либах используют и менее компактные, и менее эффективные структуры. Это не вина Go, на любом языке люди готовы везде воткнуть hashmap или обычный 2D array.
В 99% библиотек путь возвращается как набор точек, а не как value-объект из дельт. Этот принцип можно применить в любом языке и выигрыш будет везде.
Аналогично с generations map (ссылка есть в статье). Я вообще пока не нашёл, чтобы где-то применяли эту структуру. Чаще всего используют просто map. Кто-то берёт sparse map, но он тоже не оптимален.
Бакетная очередь приоритетов с битовой маской тоже не самая частая структура. У неё есть несколько вариаций, но используют её крайне редко в том числе из-за её ограничений. Но в задаче поиска пути её применить можно и буст ощутимый. Это тоже в любом языке будет работать, где у нас есть доступ к интринсикам или функциям типа "верни индекс первого ненулевого бита" (в Go есть такой интринсик, в C/C++ и подавно, а на асме можно напрямую инструкции вызвать, которые я в статье упомянул).
Я в целом на эту тему уже несколько недель убил (сравнения, своя библиотека, статьи и доклады), поэтому в ближайшом времени точно не буду ещё глубже уходить. Мне же для игрушки это нужно было, следовательно делать игрушки важнее, чем посвятить свою жизнь задаче поиска путей. :D
Выбор библиотек на Go был не очень хорош, поэтому пришлось своё писать. Результаты сейчас достаточно удовлетворительны.
Так что я был бы очень признателен, если бы кто-то принял эстафету.
Без логов из консоли тяжело понять, что там пошло не так.
Вообще в браузере я тестил только в 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
Если хочется в формате чата пообсуждать тему, то подключайтесь.
У меня возникли некоторые неожиданные проблемы, из-за чего следующая часть отложилась.
Материал уже есть, но нужно ещё придумать, в каком порядке вводить новые библиотеки, так как иначе там очень резкий скачок в сложности получается.
Мне гораздо привычнее каждую библиотеку отдельно рассматривать в деталях, а не делать туториал, где за одну статью мы подключаем 5 новых пакетов.
Каких-то рациональных причин нет.
Мне нравится язык, я его хорошо знаю. А быть при формировании геймдева в Go мне интереснее, чем быть очередным пользователем Unity или Godot. Для хобби мне важно наслаждаться процессом. :)
Я в своих статьях чаще всего буду использовать собственные либы как зависимости, иногда оборачивая другие библиотеки для удобства.
Это не значит, что они - самые лучшие. Они просто для меня самые привычные. :D
Посмотреть некоторые хорошие альтернативы можно здесь:
https://github.com/sedyh/awesome-ebitengine
Если собирать через TinyGo, то размеры будут в разы меньше, в том числе для wasm-сборок под браузер.
Тем не менее, моя самая завершённая игра под wasm без каких-либо трюков(1) и альтернативных компиляторов занимает в архиве с wasm и ресурсами около 9.4MB. Это довольно легко скачивается и раздаётся на itch.io; часть ассетов можно докачивать во время старта игры, показывая крутилку.
Для десктопов размеры (без архивов) размеры примерно 20MB.
На мобилках размер при установке через Google Play тоже около 20MB (time to download ~15s).
Я пока тестировал только Windows, Linux, MacOS, Android и wasm (под браузер) билды. Ebitengine поддерживает ещё и ios, и некоторые консоли (switch и что-то ещё, на страничке проекта есть полный список). На Steam Deck при наличии линуксового билда будет запускаться он, а иначе виндовый через Proton.
(1) Если только не называть трюком то, что я использую XM-музыку, а не OGG. Так треки весят по 100-400kb вместо 3-6mb на штуку.
Осталось всего лишь дорисовать сову.
А если серьёзно, это всё WIP, но я сделал на Ebitengine больше одной игры, поэтому в целом я знаю, что делаю. :)
Игру делаю параллельно написанию статьи, чтобы все повествования были синхронизированы. После выхода всех статей может запишу это всё в виде видео-уроков.
Вроде бы в некоторых редких случаях PNG весит меньше, чем JPG, поэтому видимо неплохой тактиков будет брать в каждом случае то, что занимает меньше байтиков.
Я пишу статьи в markdown и вставляю через старый редактор.
И вот там хабр вырезает почти любые теги и я не находил списка что он поддерживает, а что - нет. Перебирать все теги довольно утомительно, а про abbr я, если честно, даже не знал. Я всегда делал tooltip через title у span.
Так что вот, узнал что-то новое. Теперь буду юзать в новых статьях!
Заменил на abbr, но в некоторых местах, по ощущениям, стало едва заметно, что у текста есть декоратор. Хотя в среднем выглядит лучше.
А тут пойди ещё пойми, какие теги хабр разрешает, а какие вырезает. Про abbr не знал, сейчас попробую.
Нашёл эту статью благодаря твоему посту в gamedev_suffering. :D
Мне самому только дай повод за оптимизации сесть. :D
Так что понимаю.
А вы статью то читали? :)
Я не с упрёком, но мне честно больно читать такие комментарии. Вы не поверите, но я старался, писав её. Я нашёл набор достаточно универсальных приёмов, которые можно использовать для более оптимальных библиотек поиска пути, которые очень редко используются. На это есть свои причины: мои трюки работают из-за введений ограничений. Но это же тоже здорово, когда можно найти такие ограничения, которые открывают портал в дополнительные оптимизации.
И да, даже на вашем любимом асме их можно применить и будет буст по сравнению с более прямолинейным подходом.
Я постараюсь описать, почему же статья вообще не про ограниченность Go, а про более фундаментальные вещи. Но это имеет смысл только если вы действительно хотите понять, какой посыл был в статье (как его воспринимать уже ваше дело). Дальше по пунктам.
Есть сотни способов представить матрицу проходимости и я показал один из них, который достаточно компактный и простой в реализации. В статье ещё есть ссылка на "страничный" подход и на Morton space-filling curve. Это всё потому, что да, иногда в либах используют и менее компактные, и менее эффективные структуры. Это не вина Go, на любом языке люди готовы везде воткнуть hashmap или обычный 2D array.
В 99% библиотек путь возвращается как набор точек, а не как value-объект из дельт. Этот принцип можно применить в любом языке и выигрыш будет везде.
Аналогично с generations map (ссылка есть в статье). Я вообще пока не нашёл, чтобы где-то применяли эту структуру. Чаще всего используют просто map. Кто-то берёт sparse map, но он тоже не оптимален.
Бакетная очередь приоритетов с битовой маской тоже не самая частая структура. У неё есть несколько вариаций, но используют её крайне редко в том числе из-за её ограничений. Но в задаче поиска пути её применить можно и буст ощутимый. Это тоже в любом языке будет работать, где у нас есть доступ к интринсикам или функциям типа "верни индекс первого ненулевого бита" (в Go есть такой интринсик, в C/C++ и подавно, а на асме можно напрямую инструкции вызвать, которые я в статье упомянул).
О таком раньше не слышал, спасибо.
Я в целом на эту тему уже несколько недель убил (сравнения, своя библиотека, статьи и доклады), поэтому в ближайшом времени точно не буду ещё глубже уходить. Мне же для игрушки это нужно было, следовательно делать игрушки важнее, чем посвятить свою жизнь задаче поиска путей. :D
Выбор библиотек на Go был не очень хорош, поэтому пришлось своё писать. Результаты сейчас достаточно удовлетворительны.
Так что я был бы очень признателен, если бы кто-то принял эстафету.