Decydując się na wydzielenie silnika poza grę(i stworzenie go quasi uniwersalnym) musiałem zdecydować jak on będzie wyglądać i co będzie oferował. Nauczony poprzednimi próbami pisania silnika w C++, które nie przetrwały nawet jednej mojej gry, postanowiłem, że będzie oferował on minimum możliwości, jakie powinien oferować silnik i będzie w maksymalnym stopniu korzystał z tego, co oferują mi zewnętrzne biblioteki. Postawiłem sobie też za cel, by wszystkie podsystemy mojego endżajnu były stosunkowo niezależne od pozostałych.

Jak na razie jestem zadowolony z tego, co napisałem – projekty(wszystkie 4) na dzień dzisiejszy mają 3940 linii, z czego tylko 2354 to kod a poszczególne podsystemy są niezależne od siebie w stu procentach(przynajmniej w interfejsach, w implementacji, dla ułatwienia dalszego pisania, musiałem je „połączyć”).

Stanąłem też przed ważnymi wyborami – jak rozwiązać rendering, jak zorganizować „ekrany” i przechodzenie pomiędzy nimi, zasoby, „obiekty gry”. To nie był mój „pierwszy raz”, więc miałem, marne, bo marne, pojęcie jak to może wyglądać i jak sprawuje się w działaniu. Przedstawię teraz te sposoby, na które wpadłem w czeluściach Internetu lub to, co sam wymyśliłem i tym samym rozpoczynam „cykl” o architekturze

Renderowanie

Napisanie dobrego i „łatwego w użyciu” renderera jest nie lada wyzwaniem. Przed przystąpieniem do (projektowania i) pisania musimy zdecydować przynajmniej w części jak on ma wyglądać – czy całość renderingu „zwalimy” na innych i to oni będą się męczyć „ze wszystkim” a my tylko udostępnimy podstawy, to my napiszemy większość a inni będą składać obiekty prawie jak z klocków czy stworzymy coś po środku, dzięki czemu za bardzo się nie napracujemy a i inni bardzo narzekać nie będą

Pomysły, które teraz opiszę mogą nie być identyczne z tym, co kiedyś gdzieś przeczytałem – pamięć ludzka nie jest idealna, a do tego wtedy, gdy o tym czytałem nie byłem na tyle „zaawansowany”(jakbym teraz był… ) by się temu bliżej przyglądać, lecz postaram się opisać to najlepiej jak potrafię.

Róbta, co chceta!

Chyba najłatwiejszym do zaimplementowania typ „renderera”(jeśli można to „coś” tak nazwać) jest… brak renderera! Prawie, że cała implementacja spada na użytkownika końcowego a my udostępniamy, co najwyżej najprostsze z możliwych rzeczy: leader modeli, tekstur, shakerów, kamery itp. To od programisty gry zależeć będzie, co, jak, gdzie i kiedy wyświetli i jak będzie przechowywał. Zaletą jest stosunkowo szybki czas pisania tego rozwiązania, lecz dla dużych gier, z tego, co wiem, bo nie miałem okazji pisać „dużych gier”, jest nieefektywny i stwarza dużo kłopotów. Dla prostych gier(szczególnie 2D, ale 3D pewnie też „da radę”) wystarcza.

Renderer, który sam potrafi wyświetlać

Z tego, co wiem, najtrudniejszy w implementacji renderer(wymaga najwięcej kodu), lecz koszt pisania zwraca się później – bez większych problemów można wykorzystać wszystko, co oferuje, a nowe obiekty składa się jakby z „klocków”. Nie mam kompletnie doświadczenia „jak to się robi”, lecz wymyśliłem(lub gdzieś wyczytałem/widziałem skrawki kodu), że do globalnego renderera dodaje się obiekty, które opisują same siebie a renderer odpowiada za resztę. W obiektach nie ma nawet skrawka kodu odpowiedzialnego za wyświetlanie. To rozwiązanie nie jest idealne, bo trzeba też zdecydować GDZIE „renderować”. Czy klasy odpowiedzialne za opisywanie obiektu będą potrafiły same siebie renderować czy też to klasa renderera będzie za to odpowiedzialna? Nie pisałem/używałem żadnego z tego rozwiązania toteż nie potrafię na to pytanie odpowiedzieć, które mi bardziej odpowiada.