Ostatnimi czasy pracuję nad projektem, który ułatwi mi pisanie gier w dwóch wymiarach. Zawiera engine oraz wiele przydatnych funkcji. Standardowo jest automatyczne rysowanie grafiki, callbacki przy zdarzeniach, miksowany dźwięk, kolizje obiektów wywołujące callbacki.

Główne założenie to modułowość – możliwość wyboru lib-u do danej funkcji, np. rysowania. Opracowana lista modułów poniżej (x-em oznaczone te, które oczekują wyboru lib-a, a obok nazwa domyślnego):

• Graphs (x – SDL)
• Sprites
• Logger (x – własny)
• Input (x – SDL)
• Text (x – własny)
• Thread (x – pthread)
• Timer
• Collision
• Audio (x – SDL_audio)
• Net (x – własny)

Wszystko kodzę w obiektowym C++. Aby napisać obsługę modułu pod inną bibliotekę, należy zaimplementować odpowiednią klasę, dziedziczącą niektóre metody po klasie bazowej danego modułu. Nie wykluczam, że frameworko-engine zostanie użyty nawet na telefonie komórkowym (Windows Mobile). To też w sumie mam w planach, aby całość miała charakter Platform-independent, kiedy już kodzimy grę. Grafika jest 32-bitowa. Nawet jeżeli obrazek jest ładowany jako 24-bitowy, to engine zapisuje go do 32-bitowego formatu w pamięci, aby potem można użyć „transparent key” na danej teksturze. Wymiary każdej tekstury w pamięci to kwadrat o boku równym dłuższej przekątnej oryginalnej tekstury z pliku. To daje możliwość obrotu obiektu w jego własnym zakresie.

Kilka ciekawych możliwości:

• ustalenie poziomów „wysokości” obiektów. Jeżeli jednym obiektem jest tło i ustawimy mu level 1, a inne dwa obiekty, wyglądające jak czołgi, ustawimy na wysokości 2, to w tym momencie mogą kolidować tylko czołgi. Levele są tutaj po to, aby kolizja mogła sprawdzać się pikselowo, a nie np. bounding boxami;
• tryby wyświetlania (np. z menu do gry) wywołują eventy, które mogą np. opóźnić przełączenie animacją przejścia;
• automatyczna pauza gry (po wywołaniu odpowiedniej funkcji);
• alarmy i pętle czasowe w module Timer;
• struktura drzewkowa Loggera w pamięci, dużo ciekawiej i sprawniej czyta się taki log w drzewku. Dany lib jednak nie musi jej w ten sposób zapisywać;
• na obiektach (np. owe czołgi na mapie) dokonuje się: translacji, obrotu, „pixel shaderingu” oraz używa animacji, opierającej się na serii tekstur;

Jako że frameworka planuje wrzucić na swój przyszły telefon, kodzone od zera są takie klasy jak:

• template List (a’la std::vector)
• Stack – czasem dość wygodny przykład listy, zwany stosem
• template Tree – wieloliniowe drzewo danych
• String (a’la std::string)
• matematyczne – Vector2, Matrix2 (może się kiedyś przyda)
• inteligentne wskaźniki

Ostatnią, dosyć ważną cechą framework’a jest pisanie apletów. Aplety te mają pełnić różne funkcje i mogą korzystać z możliwości frameworka. Przykłady:

• konsola a’la quake’owa – w związku z tym może powstanie jeszcze moduł do parametrów;
• efekty graficzne związane z czasem – parallax, efekty przejścia, latające literki lub wszystko naraz itp.;
• automatyczne odgrywanie kolejnych utworów w tle;
• tworzenie obiektów 3D za pomocą izometrii;
• interfejs do szybkiego pisania menu.

Wiele rzeczy jest do zoptymalizowania, jakże i napisania wpierw. Większość zamysłów jednak niemalże działa :) Nie wiem jak z publikacją – może kiedyś.

Ten post został opublikowany on wtorek, Lipiec 3rd, 2007 at 19:16 and is filed under Coding. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.