Z kącika majsterkowicza cz. 3

autor: Mr Knife

Podzielony ekran

   No to zaczynamy kolejny kurs z serii kącika majsterkowicza. Jak obiecałem, znów przyjrzymy się trybowi multiplayer, tylko tym razem podzielonym ekranem. Nie marnując cennych kilobajtów przejdźmy od razu do rzeczy.

Jak zrobić bardzo prosty podzielony ekran

   Wykonanie najprostszego trybu multiplayer zajmie nam tylko parę minut. Jak w takich przypadkach bywa nic wielkiego to nie będzie, ale komuś może się przydać. Na początek musimy przyjąć trochę założeń: ekran przewija się skokowo, przypuśćmy, że robimy strzelankę od góry.

Dzielimy ekran na dwie równe części, tak jak na rysunku obok. W moim przypadku 200x100 czyli ekran gracza ma 100x100. Robimy do tego odpowiednią grafikę itp. Tworzymy obiekt gracza pierwszego, nadajemy mu odpowiedni ruch. Do jego ekraniku dodajemy jeszcze odpowiednik gracza drugiego. Operacje analogicznie powtarzamy z drugim graczem. Teraz czas na komunikacje, otóż pobieramy położenie gracza pierwszego, dodajemy do niego "100"* i ustawiamy dla jego odpowiednika. W taki sposób mamy już prosty ruch gracza 1

* rozmiar ekranu gracza

Aby łatwiej wyobrazić sobie działanie silnika spójrzcie na drugi obrazek.  Dzięki przesunięciu o odpowiednią wartość sprawiamy wrażenie prawdziwego podzielonego ekranu.

Czas rozbudować komunikację między graczami

   Bardzo ważny element, bez którego oprócz chodzenia nic nie zrobimy. Najbardziej przejrzyste dla nas jest użycie do tego celu liczników, choć i wartości obiektu (o ile są wolne) będą w sam raz pasowały. Tworzymy jeden licznik odpowiedzialny za kierunek gracza 2, otwieramy edytor zdarzeń i ustawiamy, aby zawsze przyjmował on wartość kierunku gracza drugiego, a następnie zmieniał ją u odpowiednika gracza 2. Oczywiście na wartość tego licznika, jakby ktoś jeszcze się nie domyślił . Podobnie robimy z graczem drugim i analogicznie z resztą rzeczy tzn. strzelaniem, akcją. Aby nie zaśmiecać kodu masą liczników, można je czymś zastąpić. Jak? Na przykład przy strzale nie jest on potrzebny, zdarzenie odpowiednika może zareagować przecież na klawisz gracza drugiego.

Pełny, ale skomplikowany podzielony ekran

   Od razu uprzedzam, że nie jest to, aż takie trudne, ale ja wam sytuacji nie ułatwię . Po prostu będzie musieli trochę nad zdarzeniami posiedzieć, ale to tylko dla waszego zdrowia. Sam byłem na to skazany tworząc silnik ISIS, swoją drogą nawet mi się udał, a wydajność przekroczyła moje oczekiwania. Tym razem silnik oparty na zwykłym dodawaniu pozycji nie wystarczy. Musimy zrobić 3 ważne elementy:

   1. Mapa – serce silnika, tworzymy dość duży rozmiar obszaru gry. W jednym z rogów rozmieszczamy elementy mapy, czyli ściany, przeszkody. Wszystkie elementy niech będą małe, po co marnować miejsce . Nie musimy robić dwóch map, wystarczy jedna dla obu graczy. Gdy już to zrobisz patrz -> 2.

2. Odświeżanie – trudny element, ale należy poświęcić mu trochę więcej czasu. Co kryje się pod tym hasłem? Część obiektów aktywnych, z których zbudowana jest mapa, to ten sam obiekt. Trzeba je jakoś odróżnić. Tu odsyłam do tekstu Broo - Selekcja dobrych obiektów umieszczonego w poprzednim numerze Ślimaczka. Bogatsi w wiedzę z wskazanego Arta, możemy poszukać więcej informacji o tym zagadnieniu. Warto przejrzeć przykłady RomanX’a w szczególności o AI. Tam też występuje odświeżanie. Dlaczego jest to takie ważne? Po prostu jak inaczej mamy tworzyć na podstawie mapy obiekty na ekranie?? Ustawianie każdego z osobna odpada, a bez odświeżania silnik nie poradzi sobie wyświetlaniem kilku takich samych obiektów. Aby uzyskać dobrą wydajność, odświeżanie nie powinno obejmować wszystkich obiektów. Lepiej robić to na bieżąco, dodając obiekt odpowiedzialny za zasięg wzroku. Jeśli dany obiekt z nim koliduje to wtedy przeliczaj liczbę obiektów i nadaj im wartości. Odczytuje się to za pomocą licznika, a nawet kilku liczników. Trochę wtedy jest zabawy, ale za to jaki efekt końcowy

3. Przeliczanie pozycji – niestety najtrudniejsza rzecz jaką musimy zrobić. Na bieżąco musimy tworzyć nowe obiekty, ustawiać je na odpowiednie pozycje i w razie czego usuwać. Robimy to w taki sposób: obiekt w zasięgu gracza, twórz obiekt na ekranie, sprawdzaj jego pozycje od gracza, ustaw taką (po odpowiednim przeliczeniu) temu na ekranie, obiekt poza zasięgiem, zniszcz go. Na tym w wielkim skrócie to polega. Niby proste, ale dochodzi do tego jeszcze odświeżanie, walka o jak najlepszą wydajność. Co do odświeżania, a przeliczania pozycji -> co 0.01s dodaj do licznika odpowiedzialnego za dany typ obiektów "1", gdy jest on równy aktualnej liczbie obiektów w zasięgu gracza, zeruj licznik. Teraz kolizje: obiekt koliduje z zasięgiem gracza, przypisana mu wartość jest równa odpowiedniemu licznikowi, twórz obiekt na ekranie itp. Tak wygląda odświeżanie. Resztę robimy analogicznie .  

Gdy powyższy silnik okaże się zbyt trudny

   Istnieje jeszcze inny sposób na stworzenie takiego silnika, będzie on miał cechy tych dwóch przedstawionych przeze mnie. Otóż zamiast chodzić graczami, możemy przesuwać całą mapę! Ma wtedy ona rzeczywisty wymiar i oczywiście muszą być one dwie (dla każdego gracza). Zasady na jakich będzie działał ten silnik można się łatwo domyśleć, mapa odpowiednio reaguje na wciskane przez użytkowników klawisze. Przykład chyba jest zbędny, ale dobra. Po wciśnięciu strzałki w prawo dodaj do pozycji obiektów składających się na mapę gracza pierwszego 1 piksel. Problemy techniczne nie zaleją nas, jedyną rzeczą nad którą musimy się zastanowić to kilka zdarzeń, odpowiedzialnych za to, by mapy nie nakładały się na siebie. Ale jaki to duży problem, odpowiednie zastosowanie ukryj/pokaż i gotowe . Właściwości obydwu silników są bardzo zbliżone, pierwszy można użyć do produkcji typu ISIS, naprawdę świetnie się do tego nadaje, a drugi do zwykłych naparzanek od góry.

Kończymy

   To już wszystko, co przygotowałem dla was w tej części kącika, zapraszam do lektury następnego, którego oczywiście nie zabraknie w 6 numerze Ślimaczka.

PS. Dodam tylko, że zapuszczamy się coraz głębiej w trudniejsze zagadnienia tworzenia silników w TGF. Następny tekst będzie tak rozbudowany, że będę musiał go rozbić na dwie części.

by pepe9donkey