Piszemy grΩ - podstawy

Jest wiele metod pisania gier. Pisz▒c prost▒ grΩ nie trzeba siΩ bawiµ w obiekty i enginy ale je┐eli naszym celem jest bardziej z│o┐ony projekt musimy przybraµ inny styl. W│a╢nie engin jest czym╢ co u│atwia prace i zapobiega r≤┐nym wpadkom. Engine jest to w│a╢ciwie system, na kt≤rym opiera siΩ dzia│anie gry. Dzielimy go na mechanizm sprit≤w(lub logiczny jak to wolni), mechanizm mapy i inne mniej istotne rzeczy. W tym artykule znajdziecie informacje jak siΩ zabraµ do pisania enginu. W tek╢cie wystΩpuj▒ fragmenty kodu w jΩzyku Pascal(Delphi). Je┐eli w trakcie czytania stwierdzisz, ┐e nie czaisz o co chodzi to radzΩ przerwaµ i zaczerpn▒µ trochΩ informacji na temat Object Pascala.

Projekt

Pierwsz▒ rzecz▒ jak▒ trzeba zrobiµ jest uzmys│owienie sobie co chcemy tak naprawdΩ napisaµ. Trzeba przybraµ za│o┐enia odno╢nie mapy i postaci w grze. Co i jakie ma mieµ mo┐liwo╢ci. Za│≤┐my, ┐e chcemy napisaµ jak▒╢ prost▒ platform≤wkΩ. Pierwsza sprawa to mapa. Mape mo┐na opisaµ przy pomocy dwuwymiarowej tablicy(np. array of array of byte;). Na razie nie posuwamy siΩ dalej poniewa┐ trzeba ustaliµ kwestie postaci. Trzeba zaplanowaµ odpowiednie klasy np.:
 
TSprite=class
x,y:integer; // po│o┐enie na ekranie
alive:boolean; // czy ┐yje
// Kod procedur na razie sobie darujemy
end;
 
Przyda│ by siΩ jeszcze jaki╢ system zarz▒dzania tymi spritami(wykrywanie kolizji, sprawdzanie czy ┐yj▒, rysowanie itp.). Ta kwestia bΩdzie opisana w dalszej czΩ╢ci artyku│u, poniewa┐ ciΩ┐ko j▒ pokr≤tce wyt│umaczyµ.
Ka┐dy mechanizm powinien a nawet musi znajdowaµ siΩ w osobnym unicie(module) np. mapa.pas, sprites.pas itp. Warto wspomnieµ, ┐e jest co╢ takiego jak komunikacja pomiΩdzy mechanizmami. Najm▒drzejszym rozwi▒zaniem jest ustalenie jakiej╢ hierarchii... sprajty > mapa. Oznacza to, ┐e mechanizm sprajt≤w mo┐e pobieraµ i zapisywaµ dane z mechanizmu mapy. Mapa ma jedynie kontrolΩ nad sob▒.

Mapa

Implementacje proponujΩ zacz▒µ od mapy. Mapa powinna byµ klas▒(k│ania siΩ Object Pascal). Najprostsza deklaracja mo┐e wygl▒daµ tak:

TMapa=Class
Pola:array [1..5,1..50] of byte; // 0- pustka 1- sciana
procedure draw(canvas:TCanvas);
end;

Pomin▒│em wiele rzeczy(np. odczyt z pliku), poniewa┐ nie s▒ one na razie istotne. DziΩki tablicy pola ka┐dy sprajt bΩdzie wiedzia│ czy mo┐e wej╢µ na dane pole. Jako urozmaicenie(w│a╢ciwe niezbΩdnik) mo┐na dodaµ trzeci wymiar tej tablicy.
W jednej przestrzeni bΩd▒ zapisane informacje o polach a w drugiej informacje np. o reprezentuj▒cych je rysunkach( np. nr bitmapki).

Sprajty

Bazuj▒c na tym co ju┐ jest napisane mo┐na wzi▒µ siΩ za mechanizm sprajt≤w. Implementacje zaczynamy od deklaracji klas reprezentuj▒cych dany rodzaj postaci. Wygl▒da to tak, ┐e najpierw deklarujemy jak▒╢ klasΩ podstawow▒(np. TSprite) a p≤╝niej jej pochodne(np. TPlayer(TSprite) i TEnemy(TSprite)). Ka┐da z tych klas ma mieµ jedn▒ istotn▒ metodΩ. Jej dzia│anie polega na wywo│aniu procedur takich jak np. rysowanie, AI itd.(wszystkie procki tzw. cyklowe). Ja j▒ nazywam finalizuj▒ca dan▒ klasΩ. Mo┐e wyja╢niΩ to w inny spos≤b. Za│≤┐my, ┐e podczas ka┐dego cyklu(jakiej╢ pΩtli lub timera) napiszemy:
 
Sprajt.sprawdz_klawisze(klawisze);
Sprajt.move;
Sprajt.rysuj(canvas);

Procedure finalizuj▒ca wywo│a te wszystkie procedury. Teraz mo┐na siΩ zabraµ za mechanizm sprit≤w. Zazwyczaj jest on po prostu klas▒. Uproszczona deklaracja bΩdzie wygl▒da│a tak:
 
TPostac=record
name:string;
case rodzaj: (rEnemy,rPlayer) of
rEnemy:enemy:TEnemy;
rPlayer:player:TPlayer;
end;

TSpriteEngine=class
sprajty:array of TPostac;
procedure sprites; // finalizuje wszystkie postacie z tablicy
procedure add;
procedure delete;
procedure search;
end;

Tak to mniej wiΩcej wygl▒da. Nie przytaczam kodu procedure, gdy┐ zajΩ│o by to zbyt wiele miejsca

Komunikacja

Jak to jest z t▒ wspomnian▒ komunikacj▒? Przede wszystkim chodzi tu oto aby sprajty widzia│y siΩ na mapie. Np. Je┐eli dana postaµ jest kontrolowana przez gracza to wpisuje to tablicy z mapa np. -1 i wszyscy przeciwnicy wiedz▒ kogo maj▒ atakowaµ oraz gdzie on siΩ znajduje. Jest to bardzo proste rozwi▒zanie i bardzo polecam jego u┐ywanie.

Podsumowanie

R≤┐nie bywa z lud╝mi, kt≤rzy pisz▒ gry. Niekt≤rzy porzucaj▒ projekty, gdy┐ brak im wytrwa│o╢ci(np. trafili na jaki╢ problem). WiΩkszo╢µ problemu bierze siΩ z braku koncepcji. Na pocz▒tku zawsze pisze siΩ │atwo, dopiero p≤╝niej zaczynaj▒ siΩ schody. Mam nadzieje, ┐e to nad czym siΩ mΩczy│em przez 1,5h pomo┐e w rozwi▒zaniu problem≤w. Je┐eli macie jakie╢ uwagi lub pytania to walcie ╢mia│o na moj▒ skrzynkΩ.

GREG
warsztat@poczta.fm
http://www.warsztat.px.pl