Po trzech miesiącach zabawy z Unity postanowiłem podzielić się moimi przemyśleniami na ten temat.

Przygodę rozpocząłem od tutoriali, które pozwoliły mi  nakreślić ogólny obraz środowiska jakim jest Unity.  Po zapoznaniu się z kilkoma tutorialami  przyszedł czas na krótką refleksję nad dotychczasowymi postępami.

Projekt

Doświadczenie podpowiada mi, że najlepiej uczyć się na projekcie, stawiając sobie kolejne cele. Taki projekcik stworzyłem sobie. W miarę postępów ubogacałem go o kolejne pomysły. Lista do zrobienia jest już dużych rozmiarów, a lista zrobionych wcale się nie wydłuża w tak szybkim tempie.

Tematem przewodnim mojego projektu stała się machina wojenna, znana ludzkości od wieków, ulubiona machina wojsk oblegających zamki, czyli katapulta.

W początkowej fazie zadanie wydawało się nie zbyt trudne. Z biegiem czasu jednak żałowałem wyboru który padł na tę machinę. Postanowiłem jednak nie zmieniać jej i zmierzyć się z tą „bestią”.

Powstały dotychczas trzy wpisy na temat tego projektu:

  1. Część pierwsza
  2. Cześć druga
  3. Część trzecia

kolejność odwzorowuje zwiększanie się poziomu trudności .

Rozwiązując problem fizyki stworzyłem kolejny projekt, który służy za implementacje fizyki a dokładnie krzywych balistycznych.

Klasa implementująca krzywe balistyczne

Za podstawę pod moją implementacje krzywych balistycznych posłużył tutorial na YouTube Rendering a Launch Arc in Unity.

Dlaczego Unity

Celem nadrzędnym stało się poznanie Unity pod kątem wirtualnej rzeczywistości. Aby cel osiągnąć należało zapoznać się ze środowiskiem (przynajmniej pobieżnie), zrobić jakiś projekt.  Projekt powstał, nie jest jeszcze dokończony. Czy będzie? nie wiem.

Po tych kilku miesiącach mogę stwierdzić, że Unity pochłonęło mnie bez reszty, paliwem do pracy był cel, który z czasem zaczął się oddalać, a w ostatnich dniach zniknął gdzieś za horyzontem.

Od początku.

Początki bywają trudne, a później jest jeszcze gorzej.

Tak też było w przypadku Unity. Rozpocząłem od Unity3D, co miało swoje konsekwencje (podobno prościej w 2D).  Nigdy wcześniej nie miałem nic wspólnego z grafiką 3D, fizyka i matematyka nie jest moją mocną stroną.

Istnieje pewne przeświadczenie  wśród programistów, że nie musisz znać matematyki   na wysokim poziomie żeby tworzyć aplikacje i jest ono jak najbardziej słuszne. Do tej pory matematyka i fizyka  nie była mi specjalnie potrzebna.

Na pierwszy rzut oka Unity też tego nie wymaga wiele rzeczy jest gotowe wystarczy wy klikać. Ale zawsze jest jakieś ale, wychodząc po za schemat trzeba liczyć się z konsekwencjami.

Przykładem tego jest, wspomniana wcześniej, implemantacja krzywych balistycznych, która zabrała mi dwa tygodnie życia. Wyzwanie okazało się na tyle trudne, że musiałem się posłużyć wsparciem tutoriali. Gdyż sama implementacja wzorów nie wystarczy. Trzeba to umiejętnie wpleść w kod.

Powyżej moja implementacja, już po refaktoryzacji. W komentarzach pozostały pytania bez odpowiedzi. Poniżej funkcje liczące czas i dystans.

Oraz właściwa funkcja licząca wysokość lotu obiektu

Wywołanie funkcji w kodzie Unity, metoda FixedUpdate

Problemy

Dużym problemem dla mnie było  zrozumienie jak działa Unity. Czym tak naprawdę jest metoda FixedUpdate i metoda Time.deltaTime(), która zwraca czas wykonania zawartości metody FixedUpdate, a nie czas (jak myślałem). Według dokumentacji to w tym miejscu powinienem trzymać obliczenia związane z fizyką, logika a w Update.

  • FixedUpdate – fizyka
  • Update – logika

Obrazek zaczerpnięty z posta „Cykl życia skryptu” autorstwa Marek Winiarski Cykl życia skryptu w Unity3d: Kolejność wykonywania funkcji   , obrazek znajduje się na końcu artykułu.

Na marginesie ten cykl to powinienem sobie nad monitorem powiesić dwa miesiące temu, zaoszczędziło by to wiele czasu poświęconego na odkrywanie odkrytego.

Odnośnie metody Update i FixUpdate artykuł  Fix your (Unity) Timestep!.

Do unity podszedłem jako  programista C# przekonany o tym, że interfejsy są lekarstwem na wszystkie bóle. Taki antybiotyk, który zwalcza nawet wirusy.

Interfejsami chciałem rozdzielić zależności tak jak to ma miejsce w standardowym kodzie C#. Oddzielić interfejs od logiki.Udało się to zrobić ale poziom niżej niż  skrypty podczepione pod obiekty w Unity. W klasach nie dziedziczący po MonoBehavior. Przykładem tego jest wspomniany wyżej kod dotyczący implementacji krzywych balistycznych.

Unity przypomina mi WinFormsy, pod względem konstrukcyjnym, gdzie forma była ściśle powiązana z kodem, który opisywał zdarzenia zachodzące na formularzu. Być może nie jest to właściwe spostrzeżenie ale na pierwszy rzut oka tak mi się to kojarzyło.

To skojarzenie stało u podstaw nie do końca właściwego zrozumienia działania konstruktorów w Unity. W tym środowisku ważniejsze od konstruktora są metody Start i Awake. Działanie tych metod również jest różne, a właściwie czas ich wywołania.

  • Awake – jest pierwszy w kolejności, można traktować jako konstruktor
  • Start – następuje po Awake,

W tym artykule bardzo dobrze opisane są kolejne etapy  życia skryptu Cykl życia skryptu w Unity3d: Kolejność wykonywania funkcji

Wnioski

Środowisko wydaje się dosyć skomplikowane i takie jest. Zapomniałem już lekcji jakie udziela mi życie w związku z nauką programowania. Z nauką, która trwała latami i trwa do dziś. Jest to nieustający proces. Błędem było przeświadczenie, że mogę Unity nauczyć się w kilka tygodni, na to trzeba trochę więcej czasu, znacznie więcej czasu ;-).

Środowisko te przyniosło mi frajdę z programowania, to czego dawno nie było (od czasu zakończenia zabawy z torfowiskiem). Poczułem się jak na studiach w momencie implementacji wzorów z fizyki i myślenia innymi kategoriami.

Unity,  to dobra odskocznia od codziennego zmagania się z kodem. Czas który spędziłem nad tym projektem nie został stracony. Czy wrócę i czy będę go kontynuował? nie wiem. Ten projekt wywołał we mnie tęsknotę za Torfowiskiem i taplaniu się w błocie. Z drugiej jednak strony powinienem przynajmniej zaimplementować tę fizykę do projektu z katapultą. Trzeba coś po sobie pozostawić, godnego uwagi.

Linki:

 

 

 

Kategorie: Unity