Комментарии 14
И ни одного скрина? Даже в репозиториях.
Справедливо.
Вот скрины из игры про ракету
Драконья игра - это скорее демонстрация кода, в визуальном плане она пока не очень (графики нет).
Это чистый Golang? Без JS и прочего мусора?
Да. На последнем скрине звёздное небо - это шэйдер на Ebitengine Kage.
Хорошее начинание. Если будет свободное время, попробую на Андроид поставить)
В репозитории поглядел бегло, и сразу в глаза попалась java-подобная конструкция https://github.com/a1emax/youngine/blob/3fb8c3ce78aa0838e81e8c5c87b205bdb3118ec2/asset/mapper.go#L23
Как будет время, попробуйте интерфейсы вынести, иначе может в скором времени получиться «комок грязи», не поддающийся рефакторингу.
Кроме описания либы с примерами использования отдельных компонентов, не увидел ничего интересного по теме статьи, а хотелось бы. И в частности, раскрыть такие темы, как удобство и возможности, преимущества перед, скажем, qt. И в целом, в чем преимущество именно го?
У меня не было цели сравнивать технологии. Тем не менее, вкратце расскажу, почему я выбрал именно такой подход (всё это, разумеется, субъективно).
Почему Go:
Сочетание просты и близости к системному уровню, если это необходимо (вплоть до ассемблера) - и прототипировать крайне легко, и глубокой оптимизации не мешают никакие VM. Погружение и в язык при обучении, и в конкретную задачу при решении очень плавное - и законченное что ли.
Самодостаточность - для многих задач всё необходимое доступно либо из коробки, либо с GitHub через go get. В данном случае мне пришлось дополнительно установить Android SDK - он всегда и везде необходим для сборки под андроид. А в остальном даже кросс-компиляция просто работает.
Распространённость в серверной разработке (тут Go давно как минимум играет на равных) - общая кодовая база для сервера и клиента выглядит как очень удобная и востребованная возможность.
Первые два аспекта относятся и к Ebitengine. Youngine я также старался строить держа их в уме. Кроме того, я поставил во главу угла модульность, расширяемость и единообразие.
Например, часто обработка ввода реализуется как часть системы событий, данной свыше и прибитой гвоздями к GUI - собственная реализация где-то возможна, где-то нет, но если возможна, то оказывается параллельной основной парадигме. Я же отделил её, сделал абстрактной и разбил на отдельные элементы, следующие общему протоколу. Это позволяет использовать и стандартные элементы, и дополнительные (скажем, из библиотеки разработчика между его проектами), и специфичные для проекта, при этом оставаясь в одной парадигме. Допустим, можно в одном и том же виджете использовать и стандартные тач-жесты, которые уже реализованы, и специальные, которые вы придумали и реализовали самостоятельно. Или сделать action-систему, как в Godot, и совместить её с клавиатурными шорткатами, реализованными отдельно.
На данный момент не только Youngine, но и вся игровая/прикладная экосистема Go однозначно уступают по возможностям, комьюнити, документации и примерам таким мастодонтам, как Unity, Godot, Qt и прочим, прошедшим долгий путь. Но я вижу смысл развивать Go в этом направлении и для меня существующие инструменты (в том числе, созданные собственноручно) достаточно удобны, чтобы двигаться дальше.
Получается, "просто я так хочу"? Не интересно читать про сравнение в других областях с другими, не интересно читать про базовые плюсы го - они и так хорошо известны, интересно именно про гуи, где го откровенно слаб. Если с "мастодонтами" типа Qt не сравнимо, то как насчёт fyne, gioui? "Для меня удобно" - это не аргумент. Надо бы пример компоновки, где будут хорошо видны плюсы в сравнении с существующими инструментами.
не интересно читать про базовые плюсы го - они и так хорошо известны
Тогда зачем вы спрашиваете про язык?
Насколько я понимаю, вы хотите увидеть обзорную статью, в которой бы разбирались существующие решения для GUI, формулировались бы их преимущества и недостатки и делался бы объективный и однозначный вывод, что лучше применять. У меня такой нет. Я лишь описал созданные мной инструменты и вкратце - как я пришёл к их созданию и на какой базе решил их строить. То, что давно существуют развитые технологии типа Unity, Qt и так далее, мне известно - но я хотел попробовать именно Go, в котором вижу потенциал в этой несвойственной ему пока нише. Почему именно Go - я написал в предыдущем комментарии.
Что касается Fyne и Gio, то, коль скоро возник такой вопрос, напишу чуть больше про причины, по которым я от них отказался в пользу Ebitengine и собственной разработки. Опять же вкратце - поскольку это комментарий, а не статья. К слову, я совершенно не исключаю, что упустил какие-то возможности - я ориентировался на документацию, в которой что-то может быть не описано, а что-то хорошо спрятано)
Fyne
Сходу декларируется зависимость от Cgo. В Ebitengine доступна как минимум кросс-компиляция под Windows, где pure Go - остальные платформы, надеюсь, со временем тоже подтянутся. Youngine же plaform agnostic, хотя без Ebitengine всё равно ничего не получится (по крайней мере, сейчас).
Для Android собирается сразу APK. Я отношу это к минусам, поскольку это не позволяет дополнять проект нативно и тем более делать его частью другого проекта. Экспорт в Android Studio не просто так существует, например, в Unity.
Обработка ввода построена на событиях. Для GUI стандартные события - благо, но реализация на них специфического ввода равносильна созданию собственной параллельной системы. Скажем, я не особо придумал, как сделать жесты для навыков, не собирая их скрупулёзно по обработчикам тачей.
Нет поддержки шэйдеров ни в каком виде. Что-то подобное скриншотам выше я бы на Fyne просто не смог реализовать.
Я не нашёл способа повернуть изображение) Про 2D-трансформации есть issue.
Gio
Это immediate mode - у него есть свои особенности. В частности, для игр рекомендуется отделять сложную графику (грубо говоря, отображение игрового мира) от собственно GUI, поскольку иначе перерисовка будет требоваться постоянно из-за анимаций (это даже лишает концепцию смысла, как по мне, поскольку нельзя перерисовать только часть экрана). Если же игровое отображение не полноэкранное в фиксированном разрешении, а встроено в интерфейс и подстраивается под разные экраны, требуется отдельная нетривиальная логика его размещения. И это далеко не единственное, что требует внимания (например, определённый импакт оказывают повсеместные очереди).
Для Android собирается сразу APK.
Обработка ввода построена на событиях (а больше в immediate mode никак и не сделать).
Нет поддержки шэйдеров. Хотя внутри шэйдеры вполне используются...
Примеры изобилуют горутинами и обращениями к пакету time. Работе со временем уделён целый раздел статьи, а мьютексы на каждом шагу - не то, что хочется видеть при работе с GUI (с точки зрения как удобства разработки, так и отзывчивости приложения). Не факт, что нужно писать именно как в примерах и руководствах - но я не мог не обратить на это внимание.
Что касается ассетов - то и там, и там хотя бы упоминаются только статические, а никаких специальных механизмов я найти не смог.
В итоге и Fyne, и Gio - весьма интересные проекты, но не слишком удобные для игр. Приложения же на них делать довольно удобно - этих приложений и сделано немало. В них есть и готовые виджеты, и темы, и старт в пару строк - Ebitengine не про это, а в Youngine это всё только предстоит сделать, пока он проявляет себя в более сложных проектах.
Если вы хотите сравнить разные подходы - я специально выложил проект dragon, демонстрирующий использование Youngine в связке с Ebitengine.
Я спрашивал про язык именно применительно к гуи. Почему вы выбрали его, а не что-то более удобное (может, потому, что сами изобрели это удобное)? Вот о чём был вопрос )
В итоге и Fyne, и Gio - весьма интересные проекты, но не слишком удобные для игр. Приложения же на них делать довольно удобно - этих приложений и сделано немало.
Если бы было удобно, была бы лавина новых юзеров. А так, увы... Здесь пока что всё плохо
Спасибо за развёрнутый ответ
Я спрашивал про язык именно применительно к гуи. Почему вы выбрали его, а не что-то более удобное (может, потому, что сами изобрели это удобное)? Вот о чём был вопрос )
Простота, близость к системе и самодостаточность - это то сочетание качеств Go, из-за которого я в принципе стал присматриваться к нему применительно к новой нише. При этом я работал с Go и раньше - просто в обычной для него среде, а для других задач использовал другие инструменты.
Распространённость на сервере - это то, в чём я увидел одну из выгод от использования Go: единая кодовая база обеспечила бы продолжающуюся экономию (во всяком случае, для моих разработок), которая окупила бы разовые инвестиции (речь не о финансовом вопросе, хотя он тоже имеет место быть).
Отдельно упомяну кросс-платформенность - поскольку я уже имел дело с GLFW в Go, я понимал, что скорее всего из-за Cgo рассчитывать можно только на неё, а кросс-компиляция - дело разве что будущего. Ebitengine здесь меня приятно удивил и продемонстрировал, что это будущее ближе, чем мне казалось. При этом даже кросс-платформенность в Go врождённая и простая, и уже только она обеспечила бы экономию - а кросс-компиляция вообще была бы чуть ли не киллер-фичей, которой далеко не каждый даже развитый инструмент может похвастаться (посмотрите например на macOS в Qt). В любом случае, я решил исходить в начальных поисках из того, что чем меньше зависимостей от Cgo, тем лучше, хоть совсем без них обойтись и не удастся (и такое решение не является при работе с Go необычным). Кстати, кросс-фичи Go кажутся мне востребованным в прикладной разработке даже больше, чем в сервисной.
Ebitengine - это та основа разработки, которая позволила не начинать путь совсем с нуля. Если говорить о низком уровне, то эта библиотека в начале разработки практически закрывает вопрос с ним. Кроме того, мне кажется, что сообщество в контексте игр на Go более или менее сошлось именно на ней - не окончательно, но упоминается она часто.
С высоким же уровнем не сложилось. У меня даже была в какой-то момент идея сделать Ebitengine драйвером Fyne, но я практически сразу от неё отказался - такая доработка (даже в возможности которой я не до конца уверен) была бы сравнима по объёму с собственной разработкой, к которой я и пришёл (это как раз те самые разовые инвестиции). Причём я изначально просто писал свой проект на Ebitengine и держал в голове, что наработки общего характера буду повторно использовать в будущих проектах - к тому, чтобы строить библиотеку, я пришёл постепенно.
Ядро библиотеки - это связка clock-input-scene. Не знаю, насколько нов мой подход к обработке ввода - как минимум, я прям его не встречал. Но в любом случае он устраняет те (значимые для меня) неудобства, с которыми я сталкивался в других средах. Способ же построения интерфейса, с которым в первую очередь имеет дело пользователь библиотеки, вполне типичен - можно даже визуальный дизайнер или какую-то разметку приделать впоследствии.
Как итог всего этого, я могу сделать играбельный прототип сразу для десктопа и телефона примерно за неделю, 95% которой уходит на реализацию игрового отображения и механик. Тут конечно стоит поставить акцент на "я" - мне все инструменты хорошо знакомы и привычны. Но взгляните на демонстрационный проект - мне кажется, он достаточно прост и для других тоже. А путь от прототипа до продукта непрост везде - не думаю, что именно Go тут будет камнем преткновения. Его экосистема в этом контексте пока довольно слабая - но так она не столь давно и для сервера была не сильнее, а что сейчас?
Надеюсь, я сумел ответить. Нет чего-то одного удобного - всё работает вместе.
Если бы было удобно, была бы лавина новых юзеров. А так, увы... Здесь пока что всё плохо
Ну не знаю... 25к звёзд на GitHub у Fyne, 11к - у Ebitengine. Недостаточно для лавины?)
Не проще перейти на rust, там есть tauri
Go в GUI, я создал