MonoGame – Jak zbudowany jest kod gry?

Dzisiaj zajmiemy się podstawami tego jak zbudowany jest kod gry pisanej przy użyciu MonoGame. Jeżeli chcesz dowiedzieć się czym w ogóle jest MonoGame, zapraszam do przeczytania poprzedniego wpisu.

Tworzymy pusty projekt

Zakładam, że czytając dalej masz już zainstalowane MonoGame i możesz przystąpić do stworzenia nowego pustego projektu. Jeżeli tak to zaczynamy! Na początku stwórzmy sobie pusty projekt „MonoGame Cross Platform Desktop Project”. Generalnie rzecz biorąc można równie dobrze stworzyć projekt dedykowany na Windowsa. Jedyną różnicą jest to, że w pierwszym przypadku obraz będzie generowany przy pomocy OpenGL’a, a w drugim DirectX’a. Po stworzeniu pustego projektu przejdźmy dalej.

Do czego służą poszczególne metody?

Konstruktor co prawda nie jest metodą, ale od niego zaczniemy 😉 W naszym wygenerowanym kodzie powinien wyglądać tak:

W pierwszej linijce tworzymy nowy obiekt typu GraphicsDeviceManager, dzięki niemu będziemy mogli w ogóle wyświetlić nasze okno z grą. W skrócie: klasa ta odpowiada za zarządzanie urządzeniem graficznym – czyli m.in za renderowanie naszego obrazu. Dalej ustawiamy sobie w jakim folderze będą znajdowały się nasze zasoby. Takie jak obrazki, dźwięki itd.

W tym miejscu możemy ustawić sobie wszystko co chcemy zmienić przed startem naszej gry. Na przykład rozmiar okna, czy ma być widoczny kursor itd…

W tym miejscu jest tworzony obiekt typu SpriteBatch, który będzie używany do rysowania naszych tekstur. Również w tym miejscu powinniśmy umieścić kod, który będzie ładował nasze zasoby(tekstury itp).

Ta metoda jest wywoływana, podczas zamykania gry. Szczerze powiedziawszy nie wiem po co ona jest, skoro chwilę po jej wywołaniu proces gry i tak zniknie z pamięci RAM. Jeżeli mój słaby angielski, nie jest aż taki zły to piszą tutaj, że mamy wyładowywać w tejże metodzie wszystko co nie jest zasobem ConentManager’a. Wszystkie tekstury, dźwięki itp, które załadujemy będą, więc raczej ta metoda nie będzie nas interesować.

No i w końcu najważniejsze. Czyli metoda Update(). Służy ona do aktualizowania poczynań w naszej grze. To znaczy: poruszania wszystkim, zatrzymywaniu lub odtwarzaniu dźwięku, przechwytywaniu zachowań użytkownika i tak dalej… Właściwie cała logika gry będzie się tutaj znajdować. Oczywiście, nie oznacza to, że mamy ją pakować w całości do tej metody 😉

Z kolei ta metoda służy do wyświetlania wszystkiego na ekranie. Wszystko co jest związanie z rysowaniem będzie zawarte w tej metodzie. Wszystko co z nim nie związane – ma znajdować się w metodzie Update(). Dlaczego właśnie tak? Głównym powodem jest to, że metoda Update() będzie wywoływana tylko 60x na sekundę – oczywiście jeżeli nasz komputer da radę. Z kolei metoda Draw() jest wywoływana tyle razy na sekundę ile się da – w celu nadania animacji jak największej płynności.

Tyle jeżeli chodzi o budowę kodu w pustym projekcie. Jeżeli gdzieś się pomyliłem to czekam na komentarze 😉 W następnym wpisie coś sobie porysujemy po tym pustym polu, które powita nas po wciśnięciu F5 😛

1,056 total views, 1 views today

4 przemyślenia nt. „MonoGame – Jak zbudowany jest kod gry?

  1. Całkiem fajny wpis, krótki i na temat idealny do przeczytania w wolnej chwili :). Mam tylko pytanie jak planujesz rozwijać te serie o MonoGame? Czy będą to wpisy na różne tematy czy może chcesz zrobić jakiś drobny projekt od początku do końca ? 🙂 I mam też kolejne pytanie dlaczego akurat MonoGame, a nie np. Unity tam też możesz programować w C#.

    • Na pewno opiszę wszystko czego nauczyłem się do tej pory 😉 Opiszę też jeden projekt tak od początku do końca. Będzie to Snake + jak przenieść go na różne platformy. Jednak to muszę jakoś rozplanować i podzielić. Na jeden wpis trochę za dużo materiału :P.
      Co do Unity, kiedy chciałem z nim zaczynać miał jeszcze masę ograniczeń, do tego poradzono mi, że jeżeli chcę w pełni zrozumieć jak pisze się gry, lepiej zabrać się za coś w stylu MonoGame w C#, czy SFML/Allegro w C++. W Unity wiele rzeczy dzieje się pod maską i nawet się o tym nie wie 😉 To pewnie rodzi jakieś ograniczenia… Jednak ilość gier w Unity pokazuje, że chyba przeważa prostota jego używania nad tymi ograniczeniami 😛

      PS: Jak się kiedyś wezmę za Unity, na pewno go opiszę. Teraz brakuje mi wiedzy na ten temat 😉

Możliwość komentowania jest wyłączona.