Microsoft XNA, część 1

10.05.2010 - Marcin Oczeretko
TrudnośćTrudność

    Teraz, gdy mamy już wszystkie potrzebne narzędzia, jesteśmy o krok od rozpoczęcia tworzenia pierwszej gry. Zanim jednak nadejdzie ten moment, zobaczmy najpierw, jakie elementy możemy wyróżnić w większości typowych gier.

   Na pewno działanie każdej gry zaczyna się od jakiegoś przygotowania i inicjalizacji urządzeń obsługujących grafikę, dźwięk czy wejścia (klawiatura, mysz).

   Później zwykle ładowane są szeroko pojęte zasoby - obrazki, dźwięki, itp.

   Następnie trafiamy do tak zwanej "pętli gry". Ta część kodu będzie wykonywana wielokrotnie, aż do zakończenia działania programu. Najpierw następuje w niej aktualizacja stanu gry, czyli np. pobieranie informacji z wejścia, albo wyliczanie nowych pozycji obiektów. Drugi krok to wyrysowanie kolejnej klatki na ekranie. Obie czynności powtarzane są tak długo, aż użytkownik postanowi zakończyć rozgrywkę.

   Wtedy zwalniane są wszystkie zasoby i następuja deinicjalizacja urządzeń, z których korzystano.

schemat typowej gry

     Aby zobaczyć, jak taki schemat zrealizować w XNA, stwórzmy nowy projekt w Visual Studio. Wybieramy kolejno: File $ \to $ New $ \to $ Project.

Tworzymy nowy projekt

Teraz w okienku, które powinno się pokazać, ustawiamy:

     Project type: XNA Game Studio 3.1 (kolor fioletowy na powyższym obrazku)

     Templates: Windows Game (3.1) (kolor niebieski)

     Name: wpisujemy nazwę projektu (kolor zielony)

     Klikamy "OK" i po chwili możemy uruchomić nowopowstałą grę (klawisz F5) i cieszyć swe oczy widokiem okienka z niebieskim tłem.

Pusty projekt w XNA

     Nic szczególnie ciekawego się tutaj nie wydarzy, ale zauważmy, że nie musieliśmy się w ogóle męczyć przy tworzeniu okna, czy też z ustawianiem różnych straszliwie nazywających się parametrów, aby zacząć cokolwiek wyświetlać. Co składa się w chwili obecnej na nasz projekt? Poza nieistotnym na razie obiektem Content, domyślną ikonką i miniaturką w naszym projekcie znajdziemy jeszcze dwa pliki z kodem: Program.cs i Game1.cs. Przeanalizujmy je.

    Program.cs:

    Po tym akapicie możemy całkowicie zapomnieć o jego istnieniu. Tworzona jest w nim instancja klasy Game1 i następnie, poprzez wywołanie metody Run(), uruchamiana jest nasza gra. Nie będziemy w ogóle modyfikować tego pliku.

    Game1.cs:

     Znajdziemy tu klasę Game1, która jest najważniejszą rzeczą w tym projekcie i reprezentuje naszą grę. Plik jest obficie przyzdobiony komentarzami, które można z czystym sumieniem usunąć. Czas na analizę poszczególnych fragmentów programu.

    Konstruktor:

1
2
3
4
5
public Game1()
{
    graphics = new GraphicsDeviceManager(this);
    Content.RootDirectory = "Content";
}

     W trzeciej linijce odbywa się inicjalizacja urządzeń graficznych. To bardzo niewiele kodu, dodatkowo został on przecież automatycznie wyprodukowany przez Visual Studio. Druga linijka odpowiada za ustawienie domyślnego folderu do przechowywania zasobów.

    Przy omawianiu reszty wygenerowanego kodu, szybko zauważymy, że jego struktura odpowiada schematowi gry przedstawionemu kilka akapitów wcześniej. Spójrzmy:

    Metoda Initialize():


1
2
3
4
5
protected override void Initialize()
{
    base.Initialize();
}
        

     Nie będziemy potrzebowali niczego tutaj dopisywać, wystarcza nam funkcjonalność zapewniana przez klasę, z której dziedziczymy. Możemy zatem usunąć ten fragment kodu. Miejmy jednak świadomość, że ta metoda istnieje, przeprowadza potrzebne inicjalizacje i jest wywoływana po konstruktorze.

    Metoda LoadContent():


1
2
3
4
5
protected override void LoadContent()
{
    spriteBatch = new SpriteBatch(GraphicsDevice);
}
        

     Metoda LoadContent() odpowiada za załadowanie potrzebnych naszej grze zasobów. Już za chwilę skorzystamy z niej, by wczytać kilka obrazków. Tworzona jest tu również instancja tajemniczego obiektu SpriteBatch, o którym również napiszę wkrótce kilka słów.

4
Twoja ocena: Brak Ocena: 4 (4 ocen)

Copyright © 2008-2010 Wrocławski Portal Informatyczny

design: rafalpolito.com