Alexej Simakov

Oн поддерживает и десктоп. Mышь и клавиатура поддерживаются. Обработка событий более общая. Например для кнопки мыши определяется только вжата ли она, значит определять щелчек придется самому как комбинацию этих событий. https://forums.coronalabs.com/topic/58255-mouse-an...

Может Lazarus? Логичное продолжение для паскаля. Вот тут написано какие библиотеки есть для разработки игр.

Можно для непритязятельной игрушки взять и love2d фреймворк (под ним lua, довольно простой скриптовый язык)

В блочном редакторе нет функций. Функция (или процедура) это и был бы модуль. А функции, конечно, можно выполнять в произвольном порядке (ну, без гарантии того, что получится что-то осмысленное). Тогда была бы возможность переиспользования кода. Собственно в этом заклпючается цель любой модуляризации. А чтобы модули можно было заменять они должны иметь одинаковый интерфейс.

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

Т.е. для крупных программных проектов такие языки не подойдут, а для мелких можно обойтись и без модульности.

Например все типы артефактов и задач получают свою компоненту. Модели, текстуры(это и скины тоже), анимация, полиграфия, медиа, звук. Или сделайте общую компоненту маркетинг для печатной продукции и веб сайта.
Например на маленьком сайте у нас было так "графика, текст, верстка, скрипты, база данных".
Обычно я рапределяю по тому в каком месте нужно над этим работать: работы отверточные, работы молоточные, покрасочные. Тогда задачи по компонентам будет легче группировать и обрабатывать в один заход.
Сборка это этап разработки перед выкатом продукта, другое дело если у вас есть сервер который нужно настраивать, тогда это "конфигурация" или "devops" или deployment или предрелизная подготовка, например. Надо продумать компоненты так, чтобы под каждую задачу или баг нашелся свой горшочек, чтобы не было такого что "ну оно как бы и туда и туда относится". Все.

Вот инструмент для разработки игр и десктопных программ на PHP develnext.org/ru
Начните с написания диздока. В нем кроме всего прочего описана механика игры в мельчайших подробностях. Без него вы закопаетесь в коде по уши и никогда не закончите свой проект.
Насчет клона игры Жизнь для разминки, тоже согласен. Чтобы понять как работает подобная симуляция.
Сложность на мой взгляд в императивном описании поведения каждого агента и мира.
Хотите поэкспериментировать с агентным моделированием, попробуйте NetLogo.

Мне кажется это наименее существенный вопрос. Важно иметь проработанную концепцию игры. А ее графическое представление не так важно для успеха, как может показаться (см. Thomas Was Alone)

usingpython.com/pygame-tilemaps

Если ты не собираешься модифицировать сам BGE, то GPL тебя никак не ограничивает. Пpодукты созданные с помощью GPL-программ* могут быть закрытыми сколько угодно.

-- * и не включающие в себя GPL программ.

https://love2d.org/wiki/Tutorial:Fire_Toward_Mouse

Есть опасения, что пользователи подумают что расы за деньги сильнее чем бесплатные, и перестанут играть из-за подозрения в дисбалансе. Оченъ сильный риск.

Надежнее было бы дать всем возможность выбирать свой стиль игры (расу) а монетизировать уже особые юниты.

У бесплатников должна быть уверенность в том, что они не в пригрышном положении. Значит если платник снаряжает свою армию элитным (купленым войном) это дает ему более широкий тактический выбор, но он должен будет пожертвовать какими-то другими юнитами, например двумя пехотинцами, чтобы сумма силы отряда игрока оставалась неизменной. Тогда у бесплатников будет шанс опять же тактически переиграть противника с элитными юнитами. Т.е. каждый игрок независимо платник или нет имеет одинаковое кол-во слотов в отряде и чем он их заполнит решать ему, но чем круче юниты тем больше "места" они занимают. И это будет основой равенства сил. Тратить деньги будут те, кому надоест катать одну и ту же тактику, и они захотят попробовать новых юнитов.

Для игры первым делом надо написатъ диздок. Попробуйте на HTML5/JS игру написать. Там хоть все более менее очевидно, не надо никаких инструментов сборки изучать и прочего околопрограммистского "счастья". Можно просто сосредоточится на алгоритме.
Ну и всякие штуки типа https://www.codingame.com тоже хороший тест на умение логически мыслить. Можно сразу понять стоит ли двигаться дальше.