Думаю культуры програмирования от группы энтузиастов и некоммерческого проекта ожидать сложно. Особенно с учетом того что и в коммерческих продуктах с культурой сложновато... Наверное тут проблема в самом определении "культуры кода". Но вот исходники от M$ (начиная еще с MS-DOS) меня также поражают отсутсвием оной. И например покопавшись в исходниках HomeWorld (первого) я тоже понял что некоторые вещи мне гораздо проще написать самому чем разбирать что они нарешали по данному поводу. Хотя все-таки код RElic'а читается лучше чем M$...
НАсчет же GLS - может я не "избалован" "правильно" организованным кодом, но в принципе сложностей с пониманием архитектуры и алгоритмов не встречал при переделках. Все модули организованы сходным образом, все объекты имеют внятную наследуемость, одинаковую типологию, единообразную архитектуру обработки.
Это конечно чисто мое мнение.

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

Получается что у меня - третий двиг под Дельфи на VCL... Как-то я не могу "отлипнуть" от объектной архитектуры и визуальных компонент, ну и назовем это "наследием" прародителя - GLScene.
Что же касаемо размеров экзешника... У меня в нем часть ресурсов хранится. :) Которые общие для любого уровня и т.д. Так что не стоит забывать и такие варианты.

О последней могу сказать что занимался ею года 4-5 назад. Собственно до сих пор уверен что большинство "недостатков" о которых говорят - не более чем незнание движка. Хотя может с тех пор появились какие-то новые, о которых я не в курсе.

Предположения возникают по причине того, что движков под Delphi с заточкой под VCL (что видно по размеру ехе-шника невооруженным глазом) не так уж и много. GLScene, 3D Cyber - из тех, которые могут дать такую картинку. Учитывая, что последний юзается практически только своим разработчиком и рендерит освещение исключительно через CG-шейдеры (насколько я помню), то можно предположить, что скорее всего GLScene. Ну и плюс, где-то у тебя в резюме упоминается сцена. И плюс этот двиг сейчас становится очень популярным, пиарится так, что заметить его недостатки на первый взгляд очень сложно.

Насчет

"добротно собранная аркада, глаза не режет, а наоборот приятно."

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

Движок можно сказать что частично самописный... Когда-то начинал с GLScene, но с тех пор накопилось столько переделок в исходниках оной, что там от "родного" рендера-то осталось не так уж и много... А все компоненты давно уж переделаны - свои спрайты, загрузчики моделей, системы частиц (кстати лиственные деревья системой частиц сделаны), загрузка ресурсов, шейдеры... А то меня производительность GLScene еще полтора года назад перестала устраивать...
Да LOT-файлы собираются обычным TForm. Как обошел создание стандартных компонент - раскрывать секрета не буду ,но это возможно... Если порыться в исходниках CreateForm и т.д. Фактически я окошко для ГУИ игры делаю обычной формой. И все, собственно - оно уже в игре.

Редактор ресурсов, а также редактор карт - все на одной основе - свой двиг когда-то "основанный" на GLScene. Видимо что-то характерное таки осталось (наверное остатки рендера дают о себе знать), раз возникают такие предположения.

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

Кстати, а на каком движке собирается? Самописный или что-то другое? (Я сначала подумал было на GLScene, но похоже, что ошибаюсь).

Еще я покопался в ресурсах (эх, любопытство...) и обнаружил, что .lot-файлы идентичны по структуре .dfm, и GUI видимо собирается на базе TForm... достаточно оригинально. Ума не приложу, как удалось обойти стандартные компоненты (точнее заставить вместо них работать самописные), но подход интересен. Открытым остался для меня вопрос, в чем писалась карта и сами ресурсы. (Ресурсы, подозреваю - через стандартные дельфийские редакторы ресурсов).

Впрочем, раскрывать секреты я не требую и не прошу, просто стало интересно.

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

Конечно поменяем и иконку и экзешник зажмем, но только релизные, сейчас как-то недосуг.

Спасибо за высокую оценку, а то я себе никак выше 7-ми баллов поставить не могу....

События формы действительно работают медленно, а вот GetAsyncKeyState работает с той же скоростью что и Direct Input ловушки (имхо). Но это не суть важно, не корову проигрываем

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

Кстати, а иконку следует к релизу изменить и можно ужать упаковщиком ехе-шник. Впрочем, это просто советы, ты наверняка и без меня все это знаешь :).

А так, твердые 9 баллов от коллеги по цеху.

Если я правильно понял вопрос....
Обработка идет вообще через Direct Input. Как мыши так и клавиатуры. А режим "одна кнопка зажата реакции на остальные нет" сделан специально, дабы исключить неадекватные перемещения "лесенкой". Так как в игре с таким режимом управления (аркадно-казуальным) обрабатывать перемещения сразу по двум координатам нельзя. Ведь условия игры подразумевают движение исключительно параллельно границам карты.
Т.е. фактически реакция на две кнопки движения не нужна совершенно, по условиям игры.
И справка...
Любые обработчики построенные на событиях типа OnKeyPress или через GetAsyncKey отличаются немалой "тормознутостью"... По крайне мере в сравнении с Direct Input.

Достаточно хорошо, однако утомляет одна небольшая погрешность в ловле нажатых клавиш. надо брать GetAsyncKey (если ничего не путаю). А то такое ощущение, что обработка идет в OnKeyPress формы... ибо когда одна кнопка зажата реакции на остальные нет.