Podstawowe komponenty w Unity

Piotr Wandycz

Dzisiaj trochę teorii. Komponenty są prostym sposobem realizacji systemu modułowego. Posiadając przykładowy obiekt przeciwnika w grze, możemy go określić kilkoma cechami charakterystycznymi, np.: jest widoczny na ekranie komputera (renderowany – potrzebuje renderera), możemy z nim wchodzić w kolizję i zareagować na ten fakt (collider), może na niego oddziaływać siła grawitacji (rigidbody), może posiadać własne źródło odtwarzania dźwięków (audio source) itd. Każdy obiekt w grze będzie zatem zlepkiem odpowiednich komponentów oraz naszych skryptów doprecyzowujących jego zachowanie.

Wystarczy nauczyć się, jak działa te kilkanaście podstawowych komponentów i jedynym ograniczeniem dla nas będzie nasza wyobraźnia. Zaczniemy od pięciu podstawowych, bez których nie obędzie się żadna gra. Jeśli utworzylibyśmy nowy „Empty object” w hierarchii to do  takiego pozornie pustego tworu zostaną od razu przypisane dwa podstawowe komponenty – Game Object i Transform.

Game Object to każdy element znajdujący się na scenie. Ma własną nazwę, może mieć także tag oraz warstwę, dzięki której wskażemy, z czym może wchodzić w kolizje. Są to jedynie teksty pozwalające poustawiać nam dokładne opisy, żeby później łatwo było znaleźć te obiekty, używając metod GameObject.Find(„nazwa”) czy GameObject.FindWithTag(„tag”). Jako że nazwę widać w hierarchii  – korzystam z niej żeby łatwo się tam odnaleźć, a szukając konkretnego obiektu i nie mając do niego referencji używam taga lub metody GameObject.FindObjectOfType<Typ>(), gdzie typ jest najczęściej moim skryptem. Przykładowo: FindObjectOfType<BackgroundMusic>().GetComponent<AudioSource>().time

Transform odpowiada za położenie obiektu w trójwymiarowym świecie. Pisząc grę 2D będziemy korzystać po prostu właściwości Position.X i Position.Y. Możemy także obracać i skalować obiekt w każdej z osi. Od strony kodu uzyskamy natomiast dostęp do rodzica / dziecka obiektu, gdyż w hierarchii możemy je w sobie zagnieżdżać. Tu przydatnymi metodami będą: transform.Find(“child_name”) oraz transform.parent

Do symulowania fizyki (masy, grawitacji, przyspieszenia, siły) został wprowadzony podział na komponent Rigidbody oraz Rigidbody 2D – prawdopodobnie, żeby nie wykonywać niepotrzebnych obliczeń. Mamy trzy rodzaje Rigidbody 2D – dynamiczne, kinematyczne i statyczne. Jeśli chcemy, żeby na postać działała grawitacja – jak w Super Mario Bros – to potrzebujemy Rigidbody dynamiczne. Jeśli sami ruszamy obiektem – kinematyczne. A jak coś ma się nie ruszać to statyczne. Trzeba pamiętać o jednej rzeczy: chcąc kolidować z obiektem, musi on posiadać co najmniej kinematyczne Rigidbody. Na statycznym możemy zrobić tylko trigger. Dość dużo osób w kodzie posługuje się nazwą rb, oznaczającą rigidbody.

Collidery 2D mogą wchodzić w kolizje wyłącznie z innymi colliderami 2D. Nie ma znaczenia czy jest to Box, Circle, Polygon czy coś bardziej zmyślnego. Do prostej gry te trzy w zupełności wystarczą. Musimy tylko uważać, żeby na jednym obiekcie nie dać Box Collider 2D, a na innym Box Collider – bo kolizja nie zadziała. Na collidery poświęcę osobny wpis. Na dzisiaj warto zapamiętać, że są dwa rodzaje kolizji – faktyczna i trigger. Lubię to tłumaczyć na przykładzie z drzwiami. Jak człowiek wejdzie w drzwi, to następuje kolizja fizyczna. A jak chcemy wykryć, że ktoś przekroczył próg drzwi i zareagować na to np. zmianą muzyki – jest to trigger.

Przy Sprite Renderer nie ma dużo filozofii. Wskazujemy na obrazek (sprite), który ma się wyświetlić. Mamy do dyspozycji właściwość odbicia (flip) w osi X i Y oraz kolejność rysowania. Im wyższy numer, tym później zostanie narysowany obiekt, czyli ten z najwyższym nie będzie niczym zasłonięty. Coś jak Z-index w HTMLu. Dobrą praktyką jest tworzenie obiektu-dziecka, odpowiedzialnego tylko za wyświetlanie obrazka, bo łatwiej się to później animuje 🙂

Z początku komponentów może wydawać się dużo, ale niektóre z nich się wykluczają lub są odpowiednikami do gier 2D i 3D. Najłatwiej zacząć pisać gry ograniczając się do tych pięciu i później pomału rozszerzać mechanikę o nowe rzeczy, w zależności od tego co będzie nam potrzebne.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *