Алексей Сидоров

Когда не осталось никого, кто бы мог или хотел что-то сделать с кодом.

И еще хочу пару копеек о мире вставить. Совершенно надоели «космосимы» с упрощенной гидродинамической физикой. От искусственных ограничений на максимальную скорость теряется очень важное ощущение безграничности космоса, он превращается в некие декорации на фоне, этим очень сильно грешит серия X. Более того, почти во всех космических симуляторах космос статичен! Максимум планеты вращаются вокруг своей оси, но вокруг звезды они не вращаются, пояса астероидов просто висят, а астероиды в них просто напросто покачиваются. В то время, как в Элите всё вращалось, всё двигалось, если приходилось по каким-то причинам без автопилота путешествовать между планетами, то нужно было точно расчитывать ускорение и торможение, а также тот путь, который планета успевает пройти. Это всё создает ощущение присутствия ничуть не хуже красивых спецэффектов. Главное, что всё это работало на 486 процессоре. Сейчас же можно космос сделать куда более живым. А в случае с оффлайн симулятором можно даже некоторые релятивистские эффекты спокойно реализовать! (в онлайн симуляторе будет невозможно сымитировать никакие временные эффекты).
Увы, после Elite III я больше ни одной игры не встречал с живой вселенной и хоть какой-то вменяемой физикой. Потом стали делать одни аркады или с упором в экономику или с упором в бои.

А вообще дабы велосипед не изобретать, не проще ли взять движок от ooelite? Там уже вроде даже нормальные шейдеры чуть-ли на не на 3ем openGL'е прикрутили

Для меня всю жизнь идеалом была Elite III, по многим аспектам её за 15 лет никто не смог переплюнуть. Вот если бы кто-нибудь смог сделать её аналог, но с современной графикой и с продолжением её идей…

Ruby и Python хоть и имеют красивую, правильную объектную модель, но очень далеки от того, как работает реальное железо. В итоге это выливается в чудовищный оверхед, причем Ruby умудряется тормозить сильнее Python'а, php в этих же тестах где-то рядом, но все они плетутся в хвосте.
Я бы порекомендовал поизучать языки программирования со статической типизацией: они принципиально быстрее и ближе к железу.

Создаем либу, которая предоставляет общее sdk, обычно это набор абстрактных классов. Создаем класс Plugin, который содержит в себе необходимые точки входа, обычно это init для того, чтобы плагин сказал о том, что он умеет, load для того, чтобы плагин начал выполнять возложенные на него фичи и unload, для выгрузки. Далее делаем менеджер этих самых плагинов, который имеет в себе указатели на все доступные плагины, он уже разруливает что загружать, а что нет, а также разруливает всякие штуки наподобии зависимостей между плагинами.
Работать такая связка будет столь же быстро, как и монолитное приложение, зато каждый плагин будет являться лишь кирпичиком и можно будет гораздо проще отлаживать. Такого рода незначительно влияет на скорость загрузки приложения (необходимо таки делать некоторые лишние телодвижения в рантайме) и незначительно на объем потребляемой памяти. Можно организовать обмен эвентами между плагинами, но гораздо проще и быстрее сделать плагины реализациями некоторых интерфейсов, а обмен событиями использовать лишь в небольшой части плагинов, где это реально нужно.