Дмитрий Александров

Если в кратце:
Динамическая библиотека - все зависимости(библиотеки - dll\so\dylib) не входят в состав библиотеки\исполняемого файла. Т.е. для работы будет необходимо чтобы они были в системе или лежали рядом. Плюс в том что библиотеки можно обновлять(как правило, часто это невозможно), скомпилированная библиотека\исполняемый файл имеет малый размер.
Статическая библиотека - все зависимости (библиотеки - lib\a), во время компиляции "вклеиваются" в твою библиотеку\исполняемый файл. Плюс в том что все зависимости(библиотеки) внедрены внутрь и какбы конечному пользователю нужно меньше телодвижений что бы все заработало. Размер библиотеки\исполняемого файла становится огромным.
Исполняемый файл - это уже бинарная (двоичная) программа которую сможет выполнить твой CPU.
Транслятор - сильно грубо говоря это переводчик. Переводит 1 язык в другой. К примеру он переводит человекочитаемый исходный код на "С++" в "С" или асемблер или машинный код.
Линковщик(он же компановщик) - опять же сильно грубо это утилита которая смотрит весь исходный код и связи с библиотеками после составляет так называемую таблицу символов в которой обозначает где находится и как называется функция из другой библиотеки. Так же он обозначает и экспортируемые функции которые смогут увидеть другие библиотеки.
Компилятор - в кратце это савокупность утилит запускаемых в определенном порядке чтобы из исходного кода получить машинный код который сможет выполниться на CPU. Этапов в нем много в т.ч. в него входит линковка и трансляция.

Если хочется разобраться в этом нормально и понимать все абсолютно верно а не так как описал я то смотри рекомендации которые выше уже дали по "книге дракона". Я тебе описал все это сильно грубо чтобы просто представлять что это.
PS внес поправочку копипасты =) Даниил Демидко

Универсального способа нет. Гуглить по фразам UPnP, stun, turn.
Для универсальности надо делать реализации всех способов разом, со стороны клиента перебирать каждый способ до достижения результата, если не один способ не помог то подключаться через промежуточный сервер.

Совсем отказаться от серверов или чего то что будет говорить где какой клиент крайне сложно. Мы живем в мире где куча НАТов и серых ip адресов с динамикой.
По факту Вам надо решить следующие проблемы:
1) Реализовать "пробивалку" NATов. Способов много и нужно учитывать максимальное их количество. Это и UPnP, и возможность пробития порта через соседа который это может сделать и соединение с другим клиентом и уже через него выходить в общую сеть обмена.
2) Нужен некий механизм доверия между клиентами т.к. никакого центрального сервера авторизации не будет. Тут способов тоже много и чаще всего применяется шифрование по некоторому ключу который генерируется у каждого клиента к каждому клиенту, после чего хранится локально. Даже если некий клиент прикинется другим клиентом с его ключем то ничего не выйдет. Сообщения дойдут но прочитать их он уже не сможет без индивидуальных ключей к каждому клиенту которые злоумышленник узнать уже не сможет никак.
3) Понадобится некая реализация системы для сообщения IP адреса и порта клиентов друг другу. Тут уже варианты абсолютно разные со своими плюсами и минусами. Самый простой это некоторый сервер который только знает ip:port:идентификатор_клиента, с ним все и работают(естественно ничего более этот сервер не делает и сообщения и данные ходят между клиентами напрямую).
Другой вариант это все тот же сервер который дает и знает ip:port:идентификатор_клиента но отличительно то что он динамический и создается у лучшего клиента(лучший выбирается по неким критериям типа хороший инет, выделенный ip, отсутсвие ната и т.д.). Т.е. сервер все также остался но переехал к самим клиентам и мало того их стало много. Этот способ и есть DHT и из него вырастает следующая проблема.
4) Т.к. теперь у тебя полностью децентрализованная сеть на основе DHT или своего велосипеда который тоже повторяет DHT выросла проблема в том что клиенты могут оказаться в разных сетях с этими DHT и вообще не знать друг о друге. Тут понадобится реализация некоего механизма что бы DHT сервера искали и знали друг о друге. Как это будет реализованно тоже огромный геморойный вопрос, можно сделать еще один слой в виде DHT над DHT, можно сделать некоторые центральные сервера, можно пойти путем жесткого бродкаста между DHT узлами и т.д.

Полноценно настоящая децентрализованная сеть возможно только в мире где у каждой железки в сети свой уникальный статичный IP и полностью отсутсвуют фаирволы а сама сеть построена без шлюзов и без деления на подсети. Но как понятно такого никогда не было и не будет но возможно внутри маленькой локальной сети.
Чуть не забыл, такой p2p чат уже существует в виде Tox. Отдельно существуют подобные чаты в виде плагинов в битторрент клиенте Vuze-.

Ну смотри.
Во первых зачем тебе TBO, захотелось секаса с мипмапами?) Да и они более тяжелые.
Во вторых, атлас имеет смысл если текстуры очень мелкие и их очень много, т.е. скорость увеличиться чисто за счет меньшего числа IO операций. Проще загрузить 1 раз файл побольше чем загрузить 100 мелких файлов. В наше время честно говоря не вижу особого смысла заморачиваться с атласами, кроме ситуаций когда каждая текстура размером меньше 64 пикселей.
Подгляди реализацию текстур\атласов и "текстурных регионов" в libgdx. Весьма просто и удобно сделано. Хочешь просто текстуру, хочешь из этой текстуры возьми регион(в общем и целом те самые атласы), есть и реальная реализации атласов.

Для ваших целей не годится, если хочется чегото эдакого и не хочется ноутбук\гибрид то есть другой вариант.
Разживаетесь смартфоном или планшетом с нормальным железом(больше ядер и минимум 2гб оперативки). На нем разворачиваете linux deploy с любимым дистром линуксов. По желанию докупаеются активные узб хабы и всякие разные ништяки(я к примеру подцеплял displayLink карточку и выводил картинку на обычный монитор)
Дальше есть несколько вариантов развития событий:
Первый вариант: собираете 2 стенда. узб хаб+мышь+клавиатура+displayLink. Первый ставите дома, другой на работе. Немного трахаетесь чтобы оно заработало. На выходе полноценное рабочее место в кармане и вау эффект(0______о) знакомых. Минус в том что придется много потрахаться чтобы все заработало, когда USB в режиме OTG девайс подзарядить не получится.
Второй вариант: Все тот же линь деплой, дома и на работе обычный VNC клиент. Эффект ВАУ все еще сохраняется. Из минусов только то что это всетаки VNC со всеми вытекающими.
Третий: Дома и на работе как основные системы линуксовые(хотя это не обязательно). Работаете с софтом через x-forward. Из минусов только то что пропадает эффект ВАУ и рядом сидячий бородатый линуксоид крутит пальцем у виска глядя на это. Работать будет довольно шустро, если заморочиться и не стратовать dm на девайсе то будет куча свободных ресурсов.

OpenJDK есть для armv7, работает неплохо. NetBeans тоже есть под арму.
В свое время игрался с перечисленными выше примерами, было очень интересно, было полезно для развития. Было ли это правильно и удобно, тут надо исходить из задачи. Гонял все это на honor 6(проц hisilicon 8 ядер, 3гб оперативки). Расберри пай тоже есть но в итоге валяется в ящике, для использования в виде повседневного пк не годится, как медиацентр не годится, годится как тонкий клиент или эксперементы железячников.
В конечном счете купил бу трансформер от асуса, 2гб оперативки конечно маловато для 10ки но для повседневных полевых задач годится на ура.

love2d, код на lua, очень прост, бесплатен и есть возможность пускать в браузере.

1) Купить бокс с USB3.0 и использовать как добротную флешку.
2) Использовать как %TEMP%

Поддержка ZIP архивов в яве есть из коробки. Не обновляется не значит плохо, вероятно просто не осталось багов.
Шифрация в яве делается через, внезапно,штатный класс Cipher.

Java и шарп действительно сильно похожи синтаксисом но внутренние отличия довольно большие. В общем перескочить можно с малой кровью.
Сравнивать libgdx и юнити очень некорректно.
Юнити это готовый и законченный движек с готовыми утилитами под него.
LibGDX это только фреймворк над базовыми вещами. Т.е. рендер\систему ресурсов\сеть\базовые классы игры, все придется писать самому. Утилиты,равно как и форматы хранения контента придется тоже писать самому. Редактор карт тоже придется писать самому. Другой вариант что многие описанные вещи можно найти уже написанные кем то и слепить все воедино.

Юнити хоть и мощный двиг но придется мириться с тем что он предоставляет и ни шагу в сторону как бы неудобно и нелогично это выглядело.
LibGDX дает тебе возможность написать именно нужные тебе для конкретной игры двиг с необходимым и удобным тебе тулсетом.

К примеру если игра изначально задумывается в виде платформера то намного удобнее написать все свое конкретно для данной игры на LibGDX, скорее всего это будет даже быстрее чем на юнити.
Если игра будет чем то вроде КС то такую игру намного проще и быстрее делать на Юнити но позже будет сложнее дорабатывать ради уникальных фишек и количество костылей будет расти пропорционально числу уникальных фич.