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

А собственно в чем проблема?
- Умеете в синьке так покупайте и спите спокойно
- Не можете себе позволить покупку? Ну так значит может и не стоит тогда сидеть на синеме, значит и игра не принесет такой прибыли чтобы позволять пользоваться таким инструментом , а значит следует просто смириться и привыкнуть к бесплатным или более дешевым решениям?
- Если не уверены что прибыль будет но синема очень дорога то может пойти на аутсорс и купить\заказать нужные модели там?

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

Не используй визуальный редактор.
Почитай какие методы существуют у нужного компонента и реализуй то что тебе необходимо.

Штатными средствами libgdx?
А вообще у libgdx есть специальные рекомендации и реализации базовых штук для работ с памятью в т.ч. специальных пулов.

Собирал такое, сказать честно работает но с тонной нюансов.
1) Есть специализированные так называемые load-balancing router в железном исполнении, ручками щупал решение от peplink, круто, удобно и работает. Тут как бы самый простой вариант из всех, купил железку и не паришься. Сам тыкал но совсем чуть чуть, из жирных плюсов то что можно определенному трафику задавать приоритет нужного канала и такой фичи не добиться в других вариантах. Плохо что как правило дорого.
2) Такое собирал раза 3. Нужно 2 Router OS, в твоем случае со стороны компа микротик а на серваке можно в виртулке поднять ROS(только надо глянуть что там по лицензиям и ограничениям). Дальше Натягивается между ними vpn(можно с шифрованием), прокидываются EoIP, EoIP порты объединяются в bounding . Дальше хоть на балансировку хоть на резервирование. Из плюсов что дешево и доступно, из минусов то что по нормальному не получится задать приоритет определенному трафику в нужный канал.
3) Как уже предлагали это програмные решения как платные так и бесплатные. Платные никогда не щупал но видел что существуют. Бесплатные и приимущественно линуксовые трогал и хочу сказать что впечатления остались крайне негативные по сравнения с вариантами 1 и 2.

Все зависит от конечной задачи и нюансов в ней, вариантов в общем масса:

1) Использовать готовые протоколы типа ftp\scp\ssh\etc и их реализации клиент-сервер. В такой ситуации придется мириться с их проблемами\ограничениями\сложностями.
2) Пойти тупым путем, установить соединение, открыть стрим файла и пихать его в сокет, на другой стороне также открыть стрим и пихать все пришедшее на сокет в него. Тут уже сами себе буратино и можете извращаться и решать проблемы сами.
3) Пойти правильным путем и написать сначало тз для себя в котором точно определитесь что и как необходимо, необходимые меры надежности передачи и все возможные проблемы и методы их решений.
Т.е. образно говоря можно взять принципы передачи пакетов tcp\ip за основу:
1) Перед началом передачи файла передать crc файла клиенту, клиент посмотрел что такого нет и отвечает что ждет приема. Можно расширить и к примеру ответить что файл есть но изменился а значит надо передать только изменные блоки.
2) Сервер получив согласие клиента разбивает файл на чанки(некоторый заданный размер блоков)
3) Сервер отправляет crc клиенту и блок, клиент получает crc и получает блок затем сверяет его с crc и отвечает что все ок, сервер делает также со всеми оставшимеся блоками, если сервер не получил ок от клиента то отправить блок снова. Если расширять то можно сделать новый ответ серверу что такой crc для такого блока есть и давай следующий.
N) дорабатываешь все это до желаемого результата, к примеру добавляешь сжатие блоков, нумеруешь их чтобы не слать последовательно а была возможность асинхронной передачи, добавляешь шифрование и т.д.

Сохранить содержимое\состояние нужных компонентов в json\txt\prop\xml\etc при закрытии программы и востанавливать его при окртытии(отрисовалась форма, читаешь состояние и заполняешь нужное).