Рекомендую, на бумаге очень удобно думать. Т.е. это писанина навыброс, сам процесс шикарен тем, что если тебя отвлекут, у тебя будет лог мыслей.
Ход мыслей можно восстановить даже через неделю и через месяц.
pro-dev, многие делают как удобно, рекомендаций много, но все утыкается в четкое формулирование и придерживание собственных конвенций явно.
User могут назвать там, где в модели пока ничего нет, кроме регистрации и токенов, к user'у ставят в соответствие какие сущности чтобы он мог crudить, и до этого никому нет дела. От сущности трубуется всего лишь быть каким-то уникальным значением.
Но там где с пользователями взаимодействует уже разные модули, разные компоненты разрабатываемой системы, там уже приходится продумывать интерфейс взаимодействия с сущностью user, и уже оказывается, что для модуля Administration это не просто какой-то uuid, но и ещё политики прав и группы доступа, которые должны авторизоваться и аутентифицироваться разными методами, плюс восстановление доступа, плюс обработка данных, + что угодно. Вообще, основную суть называют AAA-задачей, и обычно модули администрирования, аутентификации и авторизации связаны сильнее всего прочего.
Также user'ом могут назвать, если для auth и авторизации используется сторонний модуль, библиотека, какое-то готовое решение, и весь этот функционал инкапсулирован, просто сделали биндинги, как-то обозвали, оно работает, код не модифицируется во время разработки системы, его никто не читает и не может увидеть, что там как-то возможно некорректно и нехорошо названия сущностям даны - ну, никому нет дела, даже вселенной. Если в код не вносятся изменения, то пускай там в тихом омуте черти водятся.
Называйте от функционала модуля / пакета. Делайте это однообразно, согласно избранной конвенции именования.
Так не делают, потому что клиенту доверять нельзя, клиент ничего не решает. Во-вторых, как вы себе представляете обнаружение сервера в такой схеме?
Для матмейкинга нужно придерживаться какой-то стратегии, а для этого нужно откуда-то считывать данные по игрокам, которые предварительно и собираются и хранятся где-то, и держать соединения, чтобы потом подсоединить их к одному матчу.
Игровой движок и разработка ПО вещи по сути ортогональные, и если вы заметили корреляцию, то это не значит что причина одна. На ваш вопрос однозначного ответа дать нельзя.
Как код, написанный с такой архитектурой, можно подружить с готовым бекендом - вопрос сугубо интимный, но если бы libgdx был движком - он бы не поднимался :)
bakdurak, в общем-то, в libgdx все понятно, разобраться не сложно, реализовано классически, примеры есть хорошие open source, но работы много, потому что движок, по сути, делать надо будет самому.