@"A warstwa wizualna powinna powstać na "przyczepkę" pokazując to co silnik gry przygotuje. "
No więc ja mam odmienne zdanie. W pierwszej kolejności powinno się zadbać o oprawę wizualną - z uwzględnieniem ograniczeń sprzętowych. Ponieważ w trakcie rysowania i obmyślania scenariusza może okazać się, że pewne rzeczy w silniku gry mogą okazać się zbędne. Poza tym podejście, że "kolory dobierze się później" uważam za błędne. Niestety, nie dobierze się.
(Takim przykładem kompletnego fiaska jest program GIMP. Wspaniałe możliwości, ale nie da się go używać, bo programiści byli zbyt zajęci "silnikiem" a nie interfejsem, który powstał właśnie "na przyczepkę".)
Interfejs w Gimpie nie powstał na przyczepkę - sposób jego konstrukcji to wyklucza i możliwość jego całkowitej wymiany. On został po prostu tak zaprojektowany i nie będzie odpowiadał każdemu. I to nie programiści projektują interfejsy użytkownika. A jeśli to robią, to nie są w trakcie tego programistami. Gimpshop widziałeś?
Przykładem zajęcia się oprawą wizualną gry zamiast jej rdzeniem są dziesiątki i setki gier, które nigdy nie zostały ukończone i pozostały kolorowym demem wizualnym. To co proponujesz to metoda prób i błędów - dość dokładnie da się określić co się da zrobić, o ile zna się sprzęt. Przykładem poprawnie konstruowanej gry jest np. Laura, która po wielu miesiącach pracy nad silnikiem będzie miała całkowicie nową oprawę wizualną. I dobiera się - po prostu robi to ktoś inny. W silniku nie ma rzeczy "zbędnych" - silnik gry realizuje to co ma realizować, inaczej jest robiony źle. Może też być zintegrowany z warstwą wizualizacji, ale od niego trzeba zacząć, bo robienie wizualizacji to metoda czołgowa - dostaniesz generowaną animację, której nie da się przekształcić w grę. Właśnie wtedy dojdziesz szybko do punktu w którym się czegoś nie da.
