Dlatego ogólnie DDS musi być, to jest domyślne dla DirectX i najszybsze. Zrobiłbym wyjątek WYŁĄCZNIE dla tekstur nieba, bo to są największe tekstury w symulatorze, a przez to, że największe, także najbardziej narażone na widoczność artefaktów kompresji. Pewnym kompromisem jest też użycie DDS bez kompresji (testowałem, nie działa w bieżącej wersji).
Co to znaczy: "nie załatwiałoby żadnego problemu"? Popraw mnie jeśli się mylę, ale symulator musi gdzieś przetworzyć każdy jeden wierzchołek z tekstu na liczbę zmiennoprzecinkową, a przy ilości wierzchołków występujących w scenerii czas tego przetwarzania chyba MA znaczenie? Dalej przy każdym jednym zdarzeniu wszystkie jego parametry muszą być najpierw rozpoznane, następnie przetworzone na liczby stało lub zmiennoprzecinkowe (lub przekazane dalej jako tekst). Nie wiem czy identyfikatory są w programie wyszukiwane w tekście, czy może gdzieś po drodze tworzony jest ich indeks i wyszukiwane są po nim? Tak czy inaczej - indeks tworzony byłby podczas kompilacji - ten etap gdyby był w exe mógłby zostać pominięty. Jeśli wyszukiwanie jest bezpośrednie - tym lepiej - dostajesz gratis indeks i natychmiastowe wskazanie na obiekt.
Co do skutków ubocznych - jeśli implementacja formatu jest zupełna (czyli każda konstrukcja składniowa ma odpowiednik binarny) - nie może to wywołać żadnych skutków ubocznych poza przyśpieszeniem uruchamiania. Oczywiście zakładając, że kompilator i część konsumująca plik binarny nie ma błędów :)
Co do nowych elementów formatu - znów, co za problem? Format binarny może być otwarty, z możliwością dodawania dowolnej ilości nowych struktur. Struktury nieznane mogłyby być ignorowane przez loader, nowa wersja mogłaby je czytać i używać. I jeszcze jeden "gratis" - sprawdzenie poprawności. Podobnie jak z kompilowaniem kodu - część błędów wskaże kompilator zanim nawet spróbujesz coś uruchomić. Dodatkowo tu miałbyś możliwość dowolnej zmiany języka skryptowego. Nawet użycia kilku. Kwestia napisania kompilatora, którego "wiedza" ogranicza się do formatu binarnego, o bebechach softu nie musi wiedzieć nic. Może Ci 10 dev-ów pisać na raz 10 kompilatorów ;) Główny exe dostaje tę samą binarkę na wejściu, więc go nie obchodzi w jakim języku ktoś oskryptował scenerię.
Co do debugowania tego - tu byłoby troszkę trudniej - exe nie może już wskazać linii źródła, która robi konkretną rzecz. Co najwyżej rodzaj operacji i symbole (podobnie jest w .NET - na podstawie indeksu symboli można odtworzyć mniej więcej kod źródłowy z kodu binarnego). Nic niemożliwego jednym słowem. Oczywiście nie zrobisz wszystkiego sam, bo to jest jedyna niemożliwa rzecz :)
Odnoszę wrażenie, że chciałbyś zrobić wszystko na raz, a to jest, z całym szacunkiem - ponad siły jakiegokolwiek człowieka piszącego kod "po godzinach". Bez rozbicia kodu na moduły rozwijane przez różnych dev-ów szybkiego postępu nie będzie. Samo rozbicie na takie moduły to spore wyzwanie - zadanie dla głównego architekta, ale z pewnością jest prostsze i szybsze, niż zaimplementowanie tony nowych ficzerów. W obecnej bazie kodowej pewnie wszystko jest zależne od wszystkiego, i nic nie możesz zmienić bez ruszania całości. Po rozprzęgnięciu integralność wymuszają interfejsy, każdą rzecz możesz sobie spokojnie zmieniać, a jak trzeba, to nawet i interfejs możesz zmienić - ale konsekwencje tego będą już bardziej jawne i oczywiste.
Ostatnia uwaga - wszystko co jest powinno być przetwarzane na zasadzie kompatybilności wstecz. Nie szkodzi, że zrobisz nowy format obiektów. Dołożysz do tego import starych i po krzyku. W ten sposób nic nie będzie z niczym konfliktować. Nowe scenerie nie muszą banglać ze starym programem więc tu sprawa jest prosta. Jak masz nowy format danych dla exe, możesz główny program znacznie bardziej zmodyfikować bez ryzyka, że z istniejącymi danymi się wysypie. Istniejące dane będą przechodzić przez konwersję - więc jeśli coś nie bangla to nie ruszasz głównego kodu, tylko konwerter. Wg mnie nie da się rozwiązać problemu kompleksowo, jak to nazywasz, bo to wiązałoby się z napisaniem aplikacji od zera, a tak się nie robi. Przemysłowy algorytm jest taki, że odsprzęgasz części kodu do modułów, zmieniasz moduły. I to nie tak, że rozbijasz wszystko na moduły. Nie. Wydzielasz drobne fragmenty do modułów. Po małym kawałeczku.