Comments 19
libGDX - тру разработка игрушек, имхо)
бонусом ко всей трушности еще и суперспособность портировать игрушку на все платформы разом
Интересно, давай еще пиши про libgdx, желательно с примерами. А скелетную анимацию туда можно подключить?
Все таки, не понятно почему был задействован GWT вместо TeaVM? В gdx-liftoff это одна галочка, вместо другой, по сути. Скелет автоматически генерируется для обоих случаев, а поддержка HTML5 у TeaVM выше. Например, поддержка рефлексии, работа с jar-напрямую, то есть меньше проблем с библиотеками, как минимум. Мало того, проект жив и развивается, автор проекта на Хабре есть.
Да, здесь согласен, если начинать новый проект с нуля и ориентироваться именно на HTML5, то сегодня я бы скорее смотрел в сторону TeaVM. Поддержка Java-библиотек и рефлексии там действительно удобнее, и сам проект активно развивается.
В моём случае выбор GWT был скорее обусловлен тем, что я уже работал с ним раньше и хотел использовать проверенный для себя стек. Плюс статья в первую очередь про мой практический опыт с LibGDX, а не про сравнение GWT и TeaVM.
Но замечание справедливое - думаю, стоит отдельно попробовать TeaVM и написать о впечатлениях и отличиях на практике. Спасибо за дополнение.
Это можно было одной фразой написать - Привык к Java, поэтому и тут решил её использовать. Собственно никаких других плюсов и нет. Если есть желание заняться играми, то лучше использовать тот же C# и Unity (даже если графики не очень много). Ну и в такой статье я ожидал увидеть ссылку на какие-то свои наработки и идеи. Почему бы не рассказать, какую игру ты делаешь (какой жанр, какие фичи там будут), привести какие-то какой-то специфичный код, а не тот, который в каждой обучающей статье, может быть вставить какие-то картинки (ну не может же быть игра совсем без графики)? Я вот тоже год назад решил написать игру на LibGDX и почти сразу забросил, так как LibGDX практически не упрощает жизнь разработчику.
Спасибо за развёрнутый комментарий. Тут, наверное, стоит немного пояснить, зачем вообще я написал эту статью.
Во-первых, мне было интересно проверить, есть ли у аудитории Хабра вообще интерес к LibGDX. Поэтому я сознательно начал с довольно общего материала, а не сразу с разбора конкретной игры.
Во-вторых, я уже сделал на LibGDX несколько игр. Некоторые получились не очень, другие получше, но пока я не сделал игру, которой действительно могу похвастаться перед аудиторией Хабра 🙂
Поэтому я не стал превращать статью в пиар своих игр. Тем более что показывать пока особо нечего - игры есть, но той самой, которую не стыдно поставить на первое место и сказать «вот, смотрите, что я сделал», пока нет.
А вот технический опыт у меня уже накопился. И именно им я хотел поделиться: что в LibGDX работает хорошо, что работает не очень, что можно сделать, с чем возникают проблемы, какие решения оказались удачными, а какие пришлось переделывать.
То есть приведённый в статье код действительно простой и учебный. Но остальные вещи, о которых я рассказываю, это не примеры из книжки по программированию, а то, с чем я столкнулся в реальной разработке.
Возможно, кому-то этот опыт пригодится хотя бы для того, чтобы не повторять мои ошибки.
Если бы пять лет назад ко мне пришёл человек и сказал: «Вот так на LibGDX лучше делать, а вот так лучше не делай - я уже попробовал», я был бы ему очень благодарен. Такие советы иногда экономят гораздо больше времени, чем очередной tutorial.
Так что я воспринимаю ваш комментарий скорее как подсказку, куда двигаться дальше. Если интерес к теме действительно есть, следующие статьи уже можно делать более практическими: конкретные проблемы, архитектура, код, решения, которые я попробовал, и то, что из этого получилось.
Unity - это не только движок, а еще и среда, причем не факт что подходящая будущей игре. Другими словами, всё зависит от требований. LibGDX поддерживает тот же Box2D, скелетную анимацию, партиклы и прочее. Посмотрите выбор плагинов хотя бы в liftoff или сборник libgdx-awesome.
Да, вам придется писать больше кода в итоге, придется написать свой туллинг или адаптировать тот же Tiled под нужды. Но, результат будет не хуже :) Посмотрите те же Mindustry или Delver. Или вон, чувак упоролся и сделал клон Diablo 2: https://github.com/collinsmith/riiablo. LibGDX - вполне нормальный такой фреймворк.
Я тоже выбрал несколько лет назад для себя Libgdx - совершенно понятный любому java программисту и круто спроектированный фреймворк.
Удалось завершить проект! https://store.steampowered.com/app/2964690/DayOff_Moonriver_incident/
(если кому интересно напишите - вышлю стим ключи)
и не пожалел в целом.
Использовал box2d, box2d lights, Tiled (в качестве редактора сцен), lua4j (для скриптинга), и много мелких своих утилит.
И если позволите выскажу свое мнение.
Для 2д я наверное вряд ли возьму когда-либо unity, ue, godot. Возьму какой-нибудь легковесный фреймворк. Да, есть оверхед в написании некоторой начальной инфраструктуры, но зато потом - свобода и ощущение всесилия.
А вот для любого 3D - как раз Uniuty/Godot - слишком много этой самой инфраструктуры требуется - инструменты построения и редактирования сцены, редактор анимаций, работа с материалами, работа с мешами, с инверсной кинематикой и тому подобное.
Еще если думать про мультиплеер, стоит отметить что у готовых движков есть доступная инфраструктура под подбор матчей и флот игровых серверов. Я вот писал выше что в целом не пожалел выбором Libgdx, однако когда попытался в мультиплеер, осознал что нормальный матчмейкинг я не потяну.
А так, где-то в середине пути становится совершенно без разницы на чем игра, главное - контент.
Я вот писал выше что в целом не пожалел выбором Libgdx, однако когда попытался в мультиплеер, осознал что нормальный матчмейкинг я не потяну.
А что-то из github-топика смотрели? Речь о https://github.com/topics/matchmaking?l=java
Смотрел много разных решений. Все упирается в необходимость содержания серверов и их обслуживания своими руками, либо в существенные затраты на приобртение серверов у специалиизрованных сервисов. У того же юнити этот функционал если я не ошибаюсь чуть ли не бесплатен.
А, то есть вам для матчмейкинга надо что-то вроде PlayFab? За сервера придется платить на всех платформах, включая Unty, емнип.
О, чувак, ты крут, очень приличная игра у тебя получилась. Ты её один делал? Сколько по времени?
Про 3D согласен, что скорее всего для 3D Unity будет лучше, хотя бы потому что там очень много ассетов и 3д-персонажей и карт. Поэтому, я когда писал про libGDX, я конечно же имел ввиду исключительно 2D игры.
А про мультиплеер, я пришел к выводу что придется писать свой сервер и содержать всю серверную инфраструктуру, но с этим как раз у меня проблем нет, потому что много лет я занимался именно высоконагруженным бэкендом, там и стэк понятный и решения обкатанные. Но тоже надо понимать, что одно дело PvE - фармить шмотки в локации с другими игроками или бить босса впятером, где пропуск сетевого пакета или лаги не так критичны и почти не влияют на результат, и совершенно другое дело PvP, например арена 1 на 1 или 5 на 5, где пропуск любого пакета или лаги - очень критичны и могут сильно влиять на результат боя. Поэтому в PvP я даже не суюсь пока, а вот PvE очень даже неплохо получается.
Поднимайте цену! Хотя бы в US рынке. 2 доллара, мне кажется, сильно недооценивает игру.
Например, какой-то https://store.steampowered.com/app/1673940/BITGUN/ хочет сразу 10.
А изначально цена была выше - вообще не было конверсий после первого раунда видимости. Да и у игры по ссылке - тоже судя по количеству отзывов не все хорошо.
Да, я вообще не знаю, как работает продвижение инди игр.
Про bitgun я узнал пару лет назад из какой-то принесённой интернетом статьи от создателя игры про программирование. Купил для поддержки автора и чтобы попробовать в надежде, что будет работать на SteamDeck (хотя поддержка не заявлена). Top down shooter как раз подходящая тема для SteamDeck. Но нет, управление оказалось очень неудобным на контроллере, поэтому забросил. На компе было лениво пробовать, на компе есть Doom и много других игр 😀
Почему я выбрал LibGDX для разработки игр на Java в 2026 году