Oak, ну тут разница в целом в идеологии, libGDX это именно библиотека, точнее даже сборник библиотек, на основе которых можно написать свой движок. А в моем случае делается уже непосредственно движок, готовый для непосредственного употребления. Сохраняется возможность кодинга, но многие моменты уже есть в виде готового решения, зашитого в движок.
Плюсы и минусы пока рано обсуждать, мой движок пока еще в достаточно сыром состоянии.

DominaN, какие моменты, например? Мне действительно интересно, это не троллинг, если что.

Oak, ну, в движке уже есть готовый игровой мир, в котором просчитываются взаимодействия объектов. Уже есть встроенная физика, освещение, механизм игрового времени, AI. Есть некие базовые классы игровых объектов. Есть удобный рендер, в отличие от libGDX, где в основном приходится все писать самому через OpenGL враппер. Сейчас активно работаю над UI, так как буду делать SDK. Наличие SDK также важный фактор, отличающий просто библиотеку от движка. У меня движок будет идти оптимизированной библиотекой + SDK + игровая библиотека в качестве примера.

DominaN, до LibGDX был Slick, где отрисовка выполнялась аналогично Java2D, минус этого подхода был в куче вызовов glEnd(), каждый из которых заставлял отрисовывать кадр, что довольно медленная операция. Мне интересно, как тебе удалось избежать этой проблемы.
В LibGDX есть Box2D, Box2DLights, Ashley — физика, освещение, искусственный интеллект.

Вот удобное UI API — это действительно нужно. В самом ГДХ, с этим плохо.

И да, твоя философия, возможно, будет ограничивать разработчика. К примеру, хочу я сделать систему с объектами-контейнерами для компонентов, где компоненты бы подписывались на определённые сообщения (например, создание объектов или изменение позиции игроков). Достаточно ли прозрачен низкий уровень в твоей библиотеке, чтобы я смог реализовать свою собственную логику функционирования приложения.

ОТРЕДАКТИРОВАНО: И да, есть ли код на гитхабе? Нужна ли помощь с чем-то, хоть с доками? Действительно интересный проект, каких мало на форуме.

Oak, для ui есть scene 2d, но там придется рисовать свою графику для элементов интерфейса, можно создавать свои элементы интерфейса, вполне удобно

Naik, я некоторое время мучался с scene2d, но в конце концов забил на ту тягомотину :/ и на основе Actor и Stage полностью реализовал свой стек графических элементов.

Oak, 1. пока никак не удалось избежать просто перевел большую часть отрисовки на шейдеры. Но в ближайшее время планирую все перенести на glDrawArrays/Elements.
2. Вот, это о чем я и говорил - libGDX это по сути комплект библиотек, связанных на весьма абстрактном уровне.
3. Не совсем понял твой пример. Но, я думаю, с этим не возникнет проблем, так как все события, которые обрабатываются движком легко переопределяются в игровой библиотеке. Движок оперирует абстрактными методами, каждый фрейм для объектов проделываются следующие операции: проверка столкновений, проверка на выход за границы мира, непосредственно update() метод, причем он переопределяется для каждого наследника Entity, и сортировка по z-layer. При этом для каждой энтити есть гибкие настройки, как именно она должна обновляться, которые устанавливаются в init() энтити. Основных их четыре: solid - нужно ли проверять столкновения (но если энтите присвоен флаг trigger, то проверка будет произведена, однако игрок, естественно, не будет в нее утыкаться), solid - позволяет сократить проверки коллизий, за счет того, что просчитываются лишь динамические объекты, visible - определяет будет ли рисоваться объект, или нет, при этом в "физическом" плане он все равно никуда не девается, и layer - порядок отрисовки.
4. Код пока не совсем в приглядном состоянии, свежие исходники тут, если сможешь разобраться

DominaN,1. ну, glEnd()-ов хорошо бы избегать, тормозить будет знатно при большом количестве объектов :с

2. Ну да, это правда, но как раз это помогает сделать то, чего, как я понял, нельзя и/или трудно будет сделать в твоём движке, подробнее об этом в следующем разделе.

3. Удобная система, но немного противоречит принципам MVC. Как я понял (пока не читал особо код), твой фреймворк предоставляет высокоуровневые средства для разработки — классы Entity, проверку столкновений итд. Но, возможно, я бы захотел реализовать свою систему игровых объектов, построенную на других принципах. LibGDX позволяет это сделать, можно ли это будет сделать в твоём фреймворке?

4. В идеале хорошо бы добавить Gradle/Maven в репозитории, чтобы вручную не надо было загружать зависимости, ну или хотя бы добавить README.md со списком необходимых для сборки библиотек с указанием версии.
Я, конечно, догадался, что нужен lwjgl 3, но в файле Renderer было три ошибки (одинаковых) — `can't resolve name 'glLoadMatrix'` — дело в том, что в текущей версии lwjgl появилось две нотации метода — glLoadMatrixf и glLoadMatrixd для работы с разной точностью.
Код пока читаю

ДОБАВЛЕНО: не забудь такое сделать в командной строке:Это нужно, чтобы коммиты не отображались от "Кирилл"а, а от твоего пользователя на гитхабе, что гораздо удобнее).

Oak, я с гитом не особо дружу, вот нетбинс кое-как настроил напиши подробнее чо там и как добавить.

Ну тебе никто не мешает использовать отдельные пакеты движка, если ты можешь обеспечить их корректное взаимодействие в рамках твоей системы. Но зачем? Движок изначально берется потому-что там уже все готово, есть заточенный инструментарий и возможность расширить имеющийся функционал в игровой библиотеке.

glLoadMatrix(FloatBuffer buff) тебе нужен

Oak, а смысл сравнивать движок и библиотеку?
Это не конструктор же, где обычно не изменить кода