Comments 18
*воспринял первые два слова названия, как приказ.
Конечно, несколько странно рендерить шрифты без знания хотя бы о baseline. Обычно проблемы всплывают либо с разноцветными/разностилевыми шрифтами либо с автоскейлом да ещё и под разные DPI.
P.S. Drawers это все же предмет одежды или ящики, а не тот кто делает Draw :D Рисовальщики обычно зовутся Renderers или Painters.
Конечно, несколько странно рендерить шрифты без знания хотя бы о baseline
Не знаю, честно. По-моему, не странно не знать чего-то, когда ты только начинаешь что-то делать.
P.S. Drawers это все же предмет одежды или ящики, а не тот кто делает Draw :D Рисовальщики обычно зовутся Renderers или Painters.
Интерфейс назван по конвенциям Go. Глагол + er. Иногда получаются не совсем корректные с точки зрения английского слова.
Редактировать прошлое сообщение уже поздно, поэтому накину ссылку с цитатой другим сообщением.
https://go.dev/doc/effective_go#interface-names
By convention, one-method interfaces are named by the method name plus an -er suffix or similar modification to construct an agent noun: Reader, Writer, Formatter, CloseNotifier etc.
Иногда этой конвенции можно избежать, но для интерфейсов из 1-го метода её чаще всего придерживаются. Для интерфейсов из более чем одного метода можно не делать комбинацию типа Read+Write = ReadWriter, а придумать концептуальное название. В нашем случае, всё равно будет полезно иметь методы типа IsDisposed(), так что можно было назвать интерфейс GraphicsObject или как-то так. Но именование - сложная штука и хорошее название должно быть консистентно с остальными именами в движке или библиотеки. Чтобы не делать слишком много предположений, я просто взял общепринятую концепцию и не добавлял методы, которые не пригодились конкретно в этой статье.
Я конечно все понимаю, но имхо GO создан достаточно заточенным на определенные задачи: обслуживания бекэнда, многопоточности, оптимизации памяти итд.
И мероприятие описанное в статье больше напоминает "натягивание совы на глобус"...
Кмк, специализированные среды такие как unity, unreal engine, renpy подходят для создания игр куда как лучше...
Если оно в итоге скомпилится в нативный бинарь, так ли принципиально на чем писать? У питона тоже есть VM, но тем не менее RenPy оказался в списке, так чем го хуже? У го есть свои проблемы и ограничения, но большая часть геймдева, если не всего программирования состоит из костылей, синей изоленты и такой-то матери. Читать игровой код местами будет больно, но вас вроде и не принуждают заниматься этим.
Как хобби даже очень хорошо, для общего развития...
А для создания продукта, а тем более игрового... ну такое себе
"Я хочу создать свой процессор, песок и медная проволока у меня уже есть"
Опять же сравнивая с питоном и всякими RenPy/PyGame/Kivy - чем они лучше, чем тот же ebiten, делая скидку на то что последний появился относительно недавно? Была б игра интересной, остальное вроде пользователей волновать не должно.
Могу добавить, что если человек неплохо владеет Go, то писать на нём игры относительно приятно. Да, ощущается недостаток библиотек и фреймворков, но что-то для себя делать не так сложно. Если я как-то смогу, то постараюсь двигать геймдев на Go хотя бы на локальном уровне.
Кроме привычного языка для гофера, полезны в геймдеве эти особенности тулчейна (не утверждаю, что этого нет в других тулчейнах, но всё же):
Очень удобный
go:embed. Легко все ресурсы записать в бинарник одной директивой.Профилирование и бенчмарки на высоте. И это встроенно в стандартную поставку.
Тестирование тоже из коробки. TDD для геймдева ещё никогда не было настолько просто.
В целом язык приятен: есть контроль над памятью, но не настолько, чтобы это было утомительно. Мы относительно надёжно можем выделять на стеке, а то, что на куче, удалит GC
Производительность достаточная, чтобы написать движок на самом Go, и игровую логику тоже писать на Go. Есть ещё интерпретаторы Go, если нужно динамическое скриптование прикрутить. AAA игры может и не получится написать таким образом, но в инде жить можно.
Так как язык не имеет традиционного ООП с наследованием, меньше соблазна делать иерархии типа
Label < Control < CanvasItem < Node < Object; Я не говорю, что это прямо ужасно, но мне кажется, что глубина в 6-7 - это не так красиво.С генериками стало проще писать нужные абстракции типобезопасно. Сделать систему сигналов и слотов - это не особо сложно.
Хороший stdlib. Он композируем и в нём есть всякие JSON и http сервера. В
C#относительно недавно завезли json в stdlib, а раньше нужно было ставить отдельный пакет. И этот пакет у меня время старта приложения замедлял на секунды 3-4, потому что, видимо, там какая-то нетривиальная инициализация (?)
Я уверен, есть и другие пункты. Go как минимум не так ужасен для геймдева, как может показаться. :)
Простите, что ворвусь в диалог спустя столь продолжительное время, но я несколько сломался в моменте «ощущается недостаток библиотек и фреймворков».
Я просто удивляюсь этому тезису, так как статья показывает, что есть «целый» движок написанный на go для создание игр. На go очень много кода уже написано, не смотря на то, что язык относительно молодой, у языка сейчас как раз период «пост-пубертата», когда он уже повзрослел и может полноценно применяться для повседневной разработки, но всё ещё есть куда расти, и есть что исправлять. Если заглянуть в списки awesome-go, то можно увидеть, что для разработки игр есть инструменты. Поэтому я не понял где ощущается недостаток.
Лучше тогда awesome-ebitengine приводить в качестве примера.
Речь идёт сугубо о разработке игр на Go. Не бекендов, не чего-то консольного, а именно графических игр с клиентом (!) на Go. У нас нет графического редактора шейдеров, нет графической IDE для разработки игр (в отличие от других языков, где обычно таки есть хотя бы один движок с IDE, типа Godot, Unity, Game Maker, etc). А с библиотеками есть трудности при поиске эффективной либы: есть около 4-5 библиотек для поиска пути (A*, greedy BFS), но все они слишком неэффетивные и для игруше не годятся, где есть квант времени на фрейм и в него надо уложиться. Если хотите, я могу продолжить список, чего ещё не хватает, но думаю и без этого моё уточнение понятно.
Пожалуйста, не упускайте контекст из виду. Если вам интересно погрузиться в разработку игр на Go и пообщаться на эту тему, приглашаю в чатик: https://t.me/go_gamedev
Спасибо за ответ. И за ссылку на чат.
По поводу второго абзаца я снова как-то недоумеваю. Графический редактор шейдеров вроде есть (https://www.shadertoy.com/, https://www.mattkeeter.com/projects/futureproof/), не на go написан, да, но нужен же именно редактор щейдеров? Godot имеет вроде биндинги api на go (https://github.com/ShadowApex/godot-go, https://github.com/godot-go/godot-go), но они неполноценные, так как неофициальные. И для меня лично странно писать о эффективности для языка с неотключаемым GC. Я лично не имею ничего против языка go. Я на нем с использованием библиотеки fyne писал gui для ряда проектов. И тогда очень полюбил язык, так как мне понравилась простота работы с языком. Я от python такой радости не испытывал, как от работы с go
Что именно недоумение вызывает? Мы сравниваем альтернативы: Unity и какой-нибудь Ebitengine. А не мёртвые биндинги для Godot.
В Ebitengine (единственный самый живой движок на Go) для шейдеров используется язык Kage. Для него нет редакторов.
Я лично не имею ничего против языка go.
А с чего вы взяли, что я имею? Я на Go уже больше 5 игрушек написал, если считать те, что дошли до релиза. Если бы мне совсем не нравилось, я бы этим не занимался. Просто надо понимать, что экосистема не такая зрелая, как в других альтернативах.
Предлагаю прекратить этот диалог. Как-то в нём мало пользы. Мне очень не нравится заход "я неудомеваю, как вы можете считать, что ...".
Всегда приятно видеть статьи про геймдев на Go
Update: https://github.com/hajimehoshi/ebiten/issues/2143
Возможно, в ebiten появится какое-то API для более дружелюбного позиционирование текста.
Будем следить за обновлениями.
Go ebiten: разбираемся с рендерингом и позиционированием текста