Silnik gier 2D — fundament (Faza 0)
Gry staną się nowym rodzajem twórczości na Moonlight — obok komiksów, książek, muzyki i animacji. Dziś kładziemy pod nie fundament techniczny: Faza 0 silnika gier 2D jest ukończona w kodzie. To jeszcze nie są funkcje dla twórcy — to szkielet, na którym wszystkie one staną.
Po co własny silnik?
Nie budujemy konkurencji dla wielkich silników gier — budujemy narzędzie dla twórców wizualnych, którzy już są na Moonlight. Cel jest prosty: rysujesz postać w Moonlight Animate, a potem grasz nią w tym samym programie — bez eksportowania plików między aplikacjami, bez uczenia się nowego środowiska. A gotową grę publikujesz na Moonlight tak samo, jak dziś publikuje się komiks czy album.
Najważniejsza decyzja: przenośny rdzeń
Priorytetem numer jeden jest eksport na wiele platform — komputer, przeglądarka, urządzenia
mobilne. Dlatego serce silnika (engine-core) powstało jako osobna, przenośna biblioteka,
całkowicie niezależna od warstwy okienkowej edytora. Pilnuje tego automatyczna bramka
czystości: specjalny skaner sprawdza każdy build i celowe naruszenie granicy natychmiast
zatrzymuje kompilację. Dzięki temu dokładnie ten sam kod, który napędza podgląd gry w edytorze,
trafi kiedyś do wyeksportowanej gry w przeglądarce.
Co dokładnie stanęło w Fazie 0
- Zegar gry o stałym kroku — fizyka i logika liczą się zawsze tym samym krokiem czasu, niezależnie od płynności ekranu. Sterowanie (play/pauza/tempo) zachowuje się jak oś czasu animacji, którą już znacie.
- Drzewo sceny — gra to hierarchia węzłów z transformacją 2D i cyklem życia (gotowość, klatka, krok fizyki, wejście, wyjście). Węzły można bezpiecznie dodawać i usuwać w trakcie działania gry.
- Sygnały i tablica zmiennych — jeden system zdarzeń i wspólny magazyn właściwości na każdym węźle. To fundament komunikacji między elementami gry.
- Jedno API, dwa sposoby programowania — cała logika przechodzi przez jedną powierzchnię API. Korzystają z niej równolegle skrypty Lua (z przeładowaniem na gorąco) i graf zdarzeń (programowanie wizualne, bez pisania kodu). Ponieważ oba front-endy wołają dokładnie te same funkcje, nigdy nie rozjadą się w możliwościach — udowodniliśmy to testem, w którym skrypt i graf wykonują tę samą operację na jednej scenie.
- Renderer 2D — sprite'y rysowane nowoczesnym, przenośnym potokiem graficznym do bufora pozaekranowego. Edytor tylko wyświetla gotowy obraz.
- Play w edytorze — eksperymentalne okno podglądu: obracający się sprite, skrypt Lua i krok grafu zdarzeń działające naraz na jednej scenie.
- Testy jednostkowe — zegar, hierarchia, tick sceny, sygnały, API, Lua i graf mają automatyczne testy, łącznie z „kamieniem milowym 0": scena z jednym sprite'em tyka 120 klatek bez zarzutu.
Co dalej?
Faza 0 była o architekturze. Kolejne fazy planu to już budowanie w górę: pełny viewport 2D z kamerą, mapa wejścia (klawiatura/pad/dotyk), fizyka, kompletny graf zdarzeń i skrypty, dźwięk, interfejs gry — aż po eksport gotowych gier. O każdym większym kroku przeczytacie tutaj.