Gra sterowana kamerą - bieg po farbę

02.07.2017 - Filip Mróz
TrudnośćTrudność

Pomysł na nowy etap gry

Rozszerzenie gry o nowy etap jest dość dużą modyfikacją, dlatego warto przed rzuceniem się w wir programowania ustalić, jak będzie on wyglądał i jakie zmiany w konstrukcji gry wymusza. Na początek zastanówmy się, jak chcielibyśmy widzieć rozgrywkę od strony gracza, a następnie co my, jako programiści, musimy w tym celu zrobić.

Okiem gracza

Naszym zadaniem jest pomalowanie płotu i chcemy to zrobić właśnie teraz. Zaczynamy malowanie, ale dość szybko kończy nam się farba. Ponieważ Castorama, gdzie farby jest ocean, znajduje się na końcu ulicy, musimy się tam przebiec. Wracając z zakupem musimy z kolei uważać, by nie wylać farby z otwartego wiadra (pokrywek brak!), gdyż tracąc ją w ten sposób będziemy zmuszeni wrócić się po nowe wiadro. Po powrocie do płotu malujemy go do momentu, gdy przyniesiona farba się skończy. Wtedy powtarzamy procedurę. Tę mechanikę gry można podsumować schematem:

Okiem programisty

Od strony programistycznej będziemy mieli kilka poważnych zmian:

  1. Po pierwsze, musimy rozwinąć strukturę StanuGracza o StanBiegu, który będzie sterował rozgrywką w czasie biegu gracza. Zauważmy, że nasz nowy stan będzie musiał mieć dostęp do klasy podobnej do PrzetwarzanieObrazow, ponieważ tak jak StanMalowania będzie musiał analizować obraz z kamery. Klasa ta będzie musiała zostać poszerzona o nowe elementy pozwalające m.in. na wykrycie biegu gracza.
  2. Chcemy, aby oba stany malowania mogły mieć inne ustawienia (np. żeby kolor pędzla i wiadra mógł się różnić), więc StanGracza i StanBiegu będą miały osobne obiekty przetwarzające obrazy. Jeśli chodzi o związek między PrzetwarzanieObrazowBiegu i PrzetwarzanieObrazow, to pierwszy będzie dziedziczył po drugim. Dzięki temu ładnie wydzielimy nowe metody, zachowując możliwość korzystania z wcześniejszych funkcji:

  3. W StanMalowania wprowadzimy zużywanie się farby w miarę malowania. Będziemy musieli odpowiednio wizualizować pozostałą ilość farby.
  4. Musimy zmodyfikować StanGracza tak, by zarządzał rozgrywką oraz podległymi mu stanami. Chodzi między innymi o:
    • ustalanie który ze stanów powinien być aktywny
    • przesyłać informacje między stanami (np. w stanie malowania dodawać doniesioną farbę)
  5. Musimy od podstaw opracować StanBiegu, który będzie musiał:
    • zawierać informacje o aktualnym położeniu gracza i ilości niesionej farbie
    • wyznaczać prędkość „biegu” gracza i na jej podstawie uaktualniać położenie gracza
    • monitorować przechył wiadra i jeśli jest znaczny to usuwać farbę z wiadra
    • informować gracza o aktualnej sytuacji (położenie gracza, ilość niesionej farby, przechył wiadra)
  6. Należy rozszerzyć PrzetwarzanieObrazow do PrzetwarzaniaObrazowBiegu, dodając takie metody, aby StanBiegu mógł się na nich oprzeć, czyli:
    • wyznaczenie przechyłu wiadra jako orientacji przedmiotu wiadro na obrazie z kamery,
    • wyznaczenie pikseli obrazu, które się zmieniły.

Lista wydaje się dość długa, jednak zajmując się jedną rzeczą na raz bez problemu sobie ze wszystkim poradzimy.

Całą implementację podzielimy na trzy „skoki”:
  1. Zmiany w StanMalowania, mechanika zmieniania się etapów oraz stworzenie szkieletu StanBiegu na jej potrzeby.
  2. Uzależnienie prędkości gracza od jego ruchów w StanBiegu.
  3. Wprowadzenie przedmiotu reprezentującego wiadro, wykrywanie przechyłu i wynikające z niego straty farby.

Mając plan tego, co należy zrobić, weźmy się do roboty.

0
Twoja ocena: Brak

Copyright © 2008-2010 Wrocławski Portal Informatyczny

design: rafalpolito.com