Architektura Gry

Trudną częścią odpowiedzi na twoje pytanie jest to, że pytasz zarówno: "co powinienem zrobić teraz, dla ponga" i "co powinienem zrobić później, w jakiejś ogólnej grze".

Aby zrobić Ponga, nie potrzebujesz nawet klasy piłki i wiosła, ponieważ są one w zasadzie tylko pozycjami. Po prostu wsadź coś takiego do swojej klasy Gry:

Vector2 ballPosition, ballVelocity;
float leftPaddlePosition, rightPaddlePosition;

Następnie po prostu zaktualizuj i narysuj je w dowolnej kolejności w funkcjach Update i Draw W grze. Spokojnie!

But, say you chcesz utworzyć wiele kulek, a kulki mają wiele właściwości (położenie, prędkość, obrót, kolor itp.): możesz chcieć utworzyć klasę lub strukturę Ball, którą możesz instancjonować (to samo dotyczy łopatek). Można nawet przenieść niektóre funkcje do tej klasy, gdzie są one samodzielne (Funkcja Draw jest dobrym przykładem).

Zachowaj jednak koncepcję projektu - cała obsługa interakcji obiekt-obiekt (czyli rozgrywka) odbywa się w twojej klasie Game.

To wszystko dobrze, jeśli masz dwa lub trzy różne elementy rozgrywki (lub klasy).

Postulujmy jednak bardziej skomplikowaną grę. Weźmy podstawową grę pong, dodać kilka elementów pinball jak mutli-ball I gracz sterowane płetwy. Dodajmy kilka elementów z węża, powiedzmy, że mamy kontrolowanego przez AI "węża", a także niektóre przedmioty pickupa, które kulki lub wąż może trafić. I na dobrą miarę powiedzmy, że łopatki mogą również strzelać laserami jak w Space Invaders i śruby laserowe robią różne rzeczy w zależności od tego, w co uderzają.

rany, to jest ogromny bałagan w interakcji! Jak sobie z tym poradzimy? Nie możemy umieścić tego wszystkiego w grze!

Proste! Tworzymy interfejs (lub abstrakcyjną klasę lub wirtualną klasę), z którego wywodzić się będzie każda "rzecz" (lub "aktor") w naszym świecie gry. Oto przykład:

interface IActor
{
    void LoadContent(ContentManager content);
    void UnloadContent();

    void Think(float seconds);
    void UpdatePhysics(float seconds);

    void Draw(SpriteBatch spriteBatch);

    void Touched(IActor by);

    Vector2 Position { get; }
    Rectangle BoundingBox { get; }
}

(to tylko przykład. Nie ma " jednego prawdziwego interfejsu aktora", który będzie działał w każdej grze, będziesz trzeba zaprojektować własne. Dlatego nie lubię DrawableGameComponent.)

Posiadanie wspólnego interfejsu pozwala graczowi po prostu rozmawiać o aktorach - zamiast wiedzieć o każdym typie gry. Pozostaje tylko robić rzeczy wspólne dla każdego typu-wykrywanie kolizji , rysowanie, aktualizowanie, ładowanie, rozładowywanie itp.

Gdy już będziesz w aktorem, możesz zacząć martwić się o konkretne typy aktorów. Na przykład, może to być metoda w Paddle:

void Touched(IActor by)
{
    if(by is Ball)
         ((Ball)by).BounceOff(this.BoundingBox);
    if(by is Snake)
         ((Snake)by).Kill();
}

Teraz, Lubię, aby piłka odbiła się od wiosła, ale to naprawdę kwestia gustu. Możesz to zrobić na odwrót.

W końcu powinieneś być w stanie trzymać wszystkich aktorów na dużej liście, którą możesz po prostu powtórzyć w grze.

W praktyce możesz mieć wiele list aktorów różnych typów ze względu na wydajność lub prostotę kodu. To jest ok - ale ogólnie staraj się trzymać zasady gry tylko wiedząc o generic aktorzy.

Aktorzy mogą również chcieć zapytać, co inni aktorzy istnieją z różnych powodów. Daj więc każdemu aktorowi odniesienie do gry i upublicznij listę aktorów w grze (nie musisz być bardzo surowy w kwestii publicznego/prywatnego, gdy piszesz kod rozgrywki i jest to twój własny kod wewnętrzny.)

Teraz możesz nawet pójść o krok dalej i mieć wiele interfejsów. Na przykład: jeden do renderowania, jeden do tworzenia skryptów i sztucznej inteligencji, jeden do fizyki itp. Następnie mają wiele implementacje, które mogą być złożone w obiekty.

Jest to opisane szczegółowo w w tym artykule . A ja mam prosty przykład w tej odpowiedzi. Jest to odpowiedni kolejny krok, jeśli zaczniesz odkrywać, że twój interfejs pojedynczego aktora zaczyna przekształcać się w bardziej "drzewo" abstrakcyjnych klas.