02/2010 (182)
SPIS TREŚCI
17 Opis DVD
BIBLIOTEKA MIESIĄCA
6 Biblioteka cocos2d-iphone – Łatwe programo-
wanie gier 2D pod iPhone
Jakub Węgrzyn
Biblioteka cocos2d-iphone zapewnia wygodny i łatwy w uży-
ciu zestaw klas, które pozwalają na szybkie tworzenie dwu-
wymiarowych gier pod iPhone. Jeśli marzysz o tym, aby napi-
sać własną grę na ten właśnie telefon, to koniecznie przeczy-
taj ten artykuł.
KLUB TECHNICZNY
18 Co nowego we Flex 4
Rafał Nagrodzki
Flex jest jedną z najbardziej zaawansowanych technologii do
budowania aplikacji typu RIA w bezpośrednim tłumaczeniu bo-
gatych aplikacji internetowych. Silnikiem wyświetlającym apli-
kacje Flex’owe jest technologia Adobe Flash, która pozwala na
osiągnięcie jednolitego wyglądu uruchamianej aplikacji, nieza-
leżnie od wykorzystywanej przeglądarki czy systemu operacyj-
nego.
22 Technologie Progress OpenEdge – Część 6.
Obiekty ProDataSet
Piotr Tucholski
Progressowe obiekty typu Dataset (ProDataSet) rozszerzają moż-
liwości definiowania złożonych obiektów biznesowych oraz rela-
cji między nimi. Są bardzo ważnym elementem w procesie budo-
wania nowoczesnych aplikacji rozproszonych i wymiany danych z
innymi aplikacjami lub ich modułami poprzez XML.
CLOUD COMPUTING
26 Enterprise Private Clouds
Michał Kuratczyk
Cloud computing robi od pewnego czasu zawrotną karierę me-
dialną. Tematem zajmują się nie tylko tytuły poświęcone bran-
ży IT, ale także biznesowe i popularno-naukowe. Nawet Dilbert
wspomina już o cloud computing. Warto zatem zastanowić się
czym jest, a czym nie jest cloud computing i jak wpłynie na two-
rzenie i zarządzanie oprogramowaniem.
4 02/2010
PROGRAMOWANIE C++
30 Fabryki obiektów
Robert Nowak
Techniki opisane w tym artykule pozwalają tworzyć obiekty na
podstawie identyfikatorów dostarczanych w czasie działania pro-
gramu, co jest wygodniejsze niż podawanie typów w formie zro-
zumiałej dla kompilatora.
PROGRAMOWANIE GIER
34 Jak napisać swoją pierwszą grę komputerową
Konstanty Kalicki
Prawdopodobnie każdy gracz ma w głowie co najmniej jeden po-
mysł na rewelacyjną grę. Niektórzy idą dalej i zakładają zeszyty w
kratkę, których strony zapełniają pomysłami i szkicami. Niestety
w tym szczególnym przypadku sam pomysł to zbyt mało i – bez
konkretnych kroków – jest niewiele wart.
38 Techniki renderingu 2,5D w grach
City-Interactive team
Pierwsze gry wykorzystujce technik 2,5 D nazywan równie pseudo
3D powstay w latach 70 XXw. na 8 bitowe komputery Atari oraz
C64. Pionierami tej techniki byy gry „Night Driver”, „Outrun”, „Pole
Position”. To technika uywana w rónych kategoriach gier, ma za za-
danie stworzenie w grze dwuwymiarowej wraenia przestrzennoci.
42 Mapy kafelków w grach 2D – Wstęp i rysowanie
Jacek Zagrodzki
Marzysz o stworzeniu swojej wymarzonej dwuwymiarowej plat-
formówki albo klasycznego RTSa? Od czego zacząć? Oczywiście
od map kafelków (ang. tiled maps). Dzięki temu artykułowi po-
znasz podstawy tej techniki – dowiesz się, jak mapy kafelków za-
programować i jak je rysować.
54 Efektywny blitter – metody optymalizacji
Bartosz Taudul
Jak to jest, że jedne gry posiadają świetnie wyglądającą i płynną gra-
fikę, podczas gdy inne, mimo znacznie uboższego wyglądu, ledwo
sobie radzą z przerysowywaniem pola gry? Dlaczego u konkuren-
cji na ekranie może poruszać się całe mrowie przeciwników, podczas
gdy u nas już przy pięciu jest problem? Różnica tkwi w kunszcie pro-
gramisty odpowiedzialnego za niskopoziomową obsługę grafiki.
60 Xcode – Xcode – oto czytelnik. Czytelniku –oto
Xcode. Poznajcie się. Czyli wprowadzenie do pro-
gramowania najpopularniejszego urządzenia
mobilnego na świecie.
Patryk Bukowiecki, Jarosław Wojczakowski
iPhone i App Store to światowy fenomen. Firma Apple dokonała
niemożliwego i uwolniła wielką siłę niezależnych developerów
mogących od teraz spełniać swoje wizje i tworzyć gry jak daw-
niej, w pojedynkę lub w małych zespołach, siedząc nad nimi po
pracy, w garażach.
64 Cyfrowa kreacja – Artystyczne projektowania
gier
Arkadiusz Wychadaczuk
Niezalenie od tego, czy tworzymy film, spot reklamowy, efekty
specjalne, wizualizacj czy gr, potrzebujemy narzdzi, które pozwol
nam w produktywny i elastyczny sposób stworzy to, co widzimy
oczami wyobrani. Wtedy pojawia si konieczno wybrania oprogra-
mowania do tzw. cyfrowej kreacji.
68 Programowanie wizualne – co to takiego?
Arkadiusz Brzegowy
Niniejszy tekst to informacje, przykłady i tutorial przybliżające
technologię Quest3D. Artykułem tym chcę pokazać, że można
tworzyć aplikacje 3D i gry szybko oraz bez znajomości języka pro-
gramowania, bibliotek DirectX czy OpenGL. Jeszcze raz – można.
Jest do tego gotowe narzędzie. Resztę znajdziecie poniżej.
72 Producent – A kto to jest?
Łukasz Szczepański
Rola producenta w procesie budowania gry komputerowej bywa,
szczególnie dla osób postronnych, dość niejasna. Czytając poniż-
szy artykuł, przekonasz się, kim jest producent i jaka jest jego rola
we wspomnianym procesie.
EFEKTYWNOŚĆ PRACY
74 Wspinaczka do profesjonalizmu – Modelowa
ścieżka rozwoju kompetencji – podejście pragma-
tyczne
Sławomir Sobótka
Autor przedstawi jeden z modeli rozwoju kompetencji – Model
Braci Dreyfus, który odnosi się nie tylko do umiejętności technicz-
nych, ale również do ogólnej aktywności każdego z nas. Model
pozwoli Ci uświadomić sobie swój aktualny poziom kompetencji
w dowolnej dziedzinie oraz zaplanować dalszą drogę ich rozwo-
ju. Spojrzenie przez pryzmat modelu na kolegów z zespołu oraz
ew. podwładnych zwiększy efektywność Twej komunikacji i może
znacząco wpłynąć na redukcję frustracji.
FELIETON
82 GeeCon 2010
www.sdjournal.org
Miesięcznik Software Developer’s Journal (12 numerów w roku)
jest wydawany przez Software Press Sp. z o.o. SK
Redaktor naczelny:
Łukasz Łopuszański lukasz.lopuszanski@software.com.pl
Projekt okładki: Agnieszka Marchocka
Skład i łamanie:
Monika Grotkowska monika.grotkowska@software.com.pl
Kierownik produkcji:
Andrzej Kuca andrzej.kuca@software.com.pl
Dział produkcji i kolportażu:
Alina Stebakow alina.stebakow@software.com.pl
Nakład: 6 000 egz.
Adres korespondencyjny:
Software Press Sp. z o.o. SK,
ul. Bokserska 1, 02-682 Warszawa, Polska
tel. +48 22 427 36 91, fax +48 22 224 24 59
www.sdjournal.org cooperation@software.com.pl
Dział reklamy: adv@software.com.pl
Obsługa prenumeraty:
pren@software.com.pl
Dołączoną do magazynu płytę CD przetestowano programem
AntiVirenKit firmy G DATA Software Sp. z o.o.
Redakcja dokłada wszelkich starań, by publikowane w piśmie
i na towarzyszących mu nośnikach informacje i programy były
poprawne, jednakże nie bierze odpowiedzialności za efekty
wykorzystania ich; nie gwarantuje także poprawnego działania
programów shareware, freeware i public domain.
Uszkodzone podczas wysyłki płyty wymienia redakcja.
Wszystkie znaki firmowe zawarte w piśmie są własności
odpowiednich firm.
Zostały użyte wyłącznie w celach informacyjnych.
Redakcja używa systemu automatycznego składu
Osoby zainteresowane współpracą prosimy o kontakt:
cooperation@software.com.pl
Druk: Artdruk www.artdruk.com
Wysokość nakładu obejmuje również dodruki. Redakcja nie
udziela pomocy technicznej w instalowaniu i użytkowaniu
programów zamieszczonych na płycie CD-ROM dostarczonej
razem z pismem.
Sprzedaż aktualnych lub archiwalnych numerów pisma po
innej cenie niż wydrukowana na okładce – bez zgody wydawcy
– jest działaniem na jego szkodę i skutkuje odpowiedzialnością
sądową.
5
 Biblioteka Miesiąca

Biblioteka
cocos2d-iphone
Łatwe programowanie gier 2D pod iPhone

Biblioteka cocos2d-iphone zapewnia wygodny i łatwy w użyciu zestaw

klas, które pozwalają na szybkie tworzenie dwuwymiarowych gier pod
iPhone. Jeśli marzysz o tym, aby napisać własną grę na ten właśnie
telefon, to koniecznie przeczytaj poniższy artykuł.
giem jest posiadanie komputera Mac z pro-
Dowiesz się: Powinieneś wiedzieć: cesorem Intela, co wyklucza większość star-
• Jakie są podstawowe konstrukcje języka Ob- • Jak programować w języku C. szych urządzeń. Ponadto konieczne jest po-
jective-C; siadanie zainstalowanego systemu Mac OS
• Jak przygotować środowisko pozwalające X w wersji 10.5 lub wyższej. Niestety łącz-
na tworzenie gier; ny koszt zakupu telefonu i komputera mo-
• Jak korzystać z biblioteki cocos2d-iphone. że swobodnie dotrzeć do pułapu 10 tysięcy
złotych , co dla wielu osób stanowi barierę
nie do przebicia.
gość tytułów opracowanych za jej pomocą, Jeżeli jednak jesteśmy szczęśliwymi po-
które skutecznie walczą o swoje miejsce w siadaczami odpowiedniego sprzętu, musi-
Poziom AppStorze. my zaopatrzyć się w iPhone SDK zawierają-
trudności ce niezbędne biblioteki oraz edytor XCode.
Wymagane narzędzia W tym celu należy założyć darmowe konto
Rozpoczęcie prac nad tworzeniem apli- na portalu iPhone Dev Center. I na tym eta-
kacji dla iPhone’a wymaga sporych nakła- pie moglibyśmy już zakończyć kompleto-

C
hyba każdy pamięta, jaka rewo- dów finansowych. Podstawowym wymo- wanie narzędzi pod warunkiem, że wystar-
lucja została dokonana przez la-
ta królowania odtwarzacza iPod,
którego główną siłą był internetowy sklep
z muzyką iTunes. Dziś można już powie-
dzieć, że Apple ponownie wyprzedził
konkurencję, wprowadzając do sprzedaży
telefon iPhone, jednocześnie uruchamia-
jąc sklep z aplikacjami AppStore. Telefon
mimo wielokrotnie wytykanych wad, bra-
ków funkcjonalności czy też wysokiej ceny
sprzedaje się doskonale. Ogromną część
sprzedawanych aplikacji stanowią gry.
Wystarczy wspomnieć, że kilka tytułów
sprawiło, iż ich autorzy zarobili miliony
dolarów i w tej chwili mają swoje firmy
tworzące kolejne gry. Nic nie stoi na prze-
szkodzie, aby samemu spróbować swoich
sił w tej dziedzinie.
Wielką pomocą w pierwszych próbach
tworzenia własnej gry jest biblioteka coco-
s2d-iphone. Zapewnia ona wygodny i ła-
twy w użyciu zestaw klas, które pozwala-
ją na szybkie tworzenie gier 2D dla telefo-
nu iPhone. O jej sile świadczyć może mno- Rysunek 1. Tworzenie przykładowego projektu Objective-C

6 02/2010
 Programowanie gier pod iPhone

czy nam możliwość testowania tworzonych

aplikacji za pomocą emulatora, przewrotnie Listing 1. Instalacja szablonu projektu cocos2d-iphone
noszący nazwę iPhone Simulator. Niestety, $ cd cocos2d-iphone/
nawet jeżeli jesteśmy posiadaczami telefo- $ ./install_template.sh
nu wyprodukowanego przez firmię Apple,
nie dostąpimy możliwości uruchamiania na Listing 2. Witaj świecie!
nim naszej aplikacji. Po raz kolejny będzie- #import <Foundation/Foundation.h>
my musieli sięgnąć do naszej kieszeni i po-
święcając sto dolarów amerykańskich, sta- int main (int argc, const char *argv[])
niemy się posiadaczami konta na iPhone {
Developer Program Portal. Dla pocieszenia NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
dodam tylko, że od tej chwili nie musimy NSLog (@"Hello World");
ponosić żadnych dodatkowych kosztów, na- [pool drain];
wet jeżeli zdecydujemy się umieścić naszą return 0;
aplikację w AppStore i zacząć zarabiać na }
niej pieniądze.
Ostatni element procesu przygotowania Listing 3. Przykładowa deklaracja klasy
do tworzenia gier to zainstalowanie bibliote- #import <Cocoa/Cocoa.h>
ki cocos2d-iphone, która na dzień powstania
niniejszego artykułu dostępna jest w wersji @interface Student : NSObject
0.8.1. Po jej pobraniu i rozpakowaniu otrzy- {
manego archiwum warto zainstalować sza- NSString* name;
blon projektu, który pozwoli na szybkie two- }
rzenie gier z poziomu edytora XCode. W tym
celu z poziomu terminala systemu Mac OS X - (void) displayName;
należy wykonać operacje przedstawione na @end
Listingu 1.
Od tej chwili moglibyśmy rozpocząć przy- Listing 4. Implementacja przykładowej klasy
godę z tworzeniem gier dla iPhone’a. Tutaj #import "Student.h"
pojawia się jednak kolejny problem – język
Objective-C. Co prawda możliwe jest wyko- @implementation Student
rzystanie w tym celu języka C++, jednak i tak
pewne fragmenty będą musiały powstać za - (void) displayName
pomocą Obj-C. Ponadto wiązać się to będzie {
z utratą wszelkiego wsparcia ze strony biblio- NSLog( name );
teki cocos2d-iphone. }
@end
Podstawy języka Objective-C
Poniższy artykuł absolutnie nie pretendu-
je do miana kompletnej specyfikacji tego ję-
zyka. Zajęłoby to zdecydowanie zbyt dużo
miejsca i czasu, jednak aby rozpocząć swoją
przygodę z tworzeniem gier, nie potrzebuje-
my rozległej wiedzy. Wystarczy kilka wska-
zówek i jestem przekonany, że każdy, kto
zdążył do tej pory zapoznać się z dobrym,
klasycznym językiem C, poradzi sobie z tym
zadaniem.
Nie byłby to artykuł wprowadzający
w podstawy programowania w dowolnym
języku, bez przykładu Hello World. Leni-
wych czytelników uprzedzam, że urucho-
mienie go nie wymaga przepisania nawet
linijki kodu. Otóż twórcy edytora XCode
okazali się odpowiednio przewidujący. Aby
nie przedłużać oczekiwania, rozpocznijmy
od utworzenia nowego projektu – w tym
wybieramy z menu aplikacji File>New pro-
ject… i w nowo otwartym oknie wybieramy
z listy opcję Command Line Utility, a w polu
znajdującym się po prawej stronie zaznacza-
my ikonę Foundation Tool (Rysunek 1). Po
kliknięciu przycisku Choose… pozostaje tyl- Rysunek 2. Tworzenie projektu z wykorzystaniem biblioteki cocos2d

www.sdjournal.org 7
 Biblioteka Miesiąca
ko wprowadzić odpowiednią nazwę projek-
tu i wybrać katalog na dysku, w którym ma
zostać utworzony. W tym momencie dyspo-
nujemy podstawowym projektem wraz z ko-
dem przedstawionym na Listingu 2.
Na pierwszy rzut oka kod nie różni się
zbytnio od tysięcy podobnych programów
pisanych w czystym C. Jednak odrobi-
nę dłuższa chwila pozwoli na wychwyce-
nie pierwszych różnic. Na początek dyrek-
tywa #import – jest ona odpowiednikiem
#include, jednak zapewnia ona, iż plik zo-
stanie dołączony tylko raz. Kolejna linia ko-
du ujawnia korzenie Objective-C sięgają-
ce wspomnianego języka C. Mamy więc do
czynienia z funkcją main zwracającą wartość
typu int i przyjmującą dwa parametry po-
zwalające na dostęp do argumentów przeka-
zanych z linii poleceń. Kolejna linia jest od-
powiedzialna za rezerwację pamięci tworzo-
nych od tej pory obiektów. W tym momen-
cie dochodzimy do sedna prezentowanej
aplikacji, czyli wyświetlenia na wyjściu stan-
dardowym komunikatu Hello World. W tym
celu użyta została funkcja NSLog. Przyda
nam się ona podczas prac nad praktycznie
każdą kolejną aplikacją. Kolejne linie są od-
powiedzialne za zwolnienie pamięci i zwró-
cenie odpowiedniej wartości.
Po tym lekko przydługim wstępie pozo-
staje tylko uruchomienie opisanego pro-
gramu. Możemy tego dokonać za pomocą
przycisku znajdującego się na pasku narzę-
dziowym lub wybierając menu Build>Bu-
ild and Go (Run). Aby zobaczyć wiado-
mość, jaką nasza aplikacja wysłała w świat,
należy otworzyć okno konsoli (menu Ru-
n>Console).
Wiemy już, że deklarowanie i wywoły-
wanie funkcji jest dokładnie takie samo jak
mechanizm znany nam z języka C. Jednak
pora przesunąć się bliżej w stronę obiekto-
wości, która przecież znalazła swoje miej-
sce w nazwie omawianego języka progra-
mowania. Dodatkowo, warto wyjaśnić, iż
podobnie jak w języku C++ nagłówek kla-
Rysunek 3. Uruchomiona aplikacja cocos2d
8 02/2010
sy umieszcza się w pliku z rozszerzeniem
.h, jednak pliki zawierające jej implemen-
tację mają rozszerzenie .m. Listing 3 przed-
stawiający deklarację prostej klasy wyraźnie
ujawnia, jak daleko Objective-C odsunął się
od stylu języka C++.
Przedstawia on minimalistyczną klasę
o nazwie Student, która zawiera jedno po-
le typu NSString o nazwie name. Łatwo za-
uważyć, iż deklaracja klasy w języku Objec-
tive-C rozpoczyna się słowem kluczowym
@interface, po którym wpisana została na-
zwa klasy. Po dwukropku powinna znaleźć
się nazwa klasy bazowej – w tym wypadku
NSObject. Nawiasy klamrowe określają ob-
szar, który pozwala na deklarację pól kla-
sy, które domyślnie są polami chronionymi
(atrybut @protected).
Poza nawiasami klamrowymi przewi-
dziano miejsce na deklarację metod klasy.
Znak - określa iż metoda jest metodą in-
stancyjną. Wykorzystanie znaku + pozwo-
liłoby oznaczyć metodę jako statyczną.
Następnie w nawiasach podany został typ
zwracanej wartości. Po tym pozostaje już
tylko podać nazwę metody. Warto tutaj do-
dać, iż w języku Objective-C wszystkie me-
tody są publiczne.
Na zakończenie deklaracji klasy wystar-
czy wpisać słowo kluczowe @end. Niestety
taka deklaracja klasy mało przypomina to,
z czym można się spotkać w innych języ-
kach programowania. Jednak zapewniam,
że po krótkim czasie stanie się to natural-
ne i zrozumienie takiego kodu stanie się
proste.
Pora teraz przejść do implementacji kla-
sy – Listing 4. Zadeklarowana wcześniej
klasa zawiera tylko jedną metodę, więc
przedstawiony kod powinien być w mia-
rę zrozumiały. W pierwszej kolejności na-
leży za pomocą dyrektywy #import dołą-
czyć odpowiedni nagłówek. Słowo kluczo-
we @implementation jest tutaj naturalnym
odzwierciedleniem słowa @implementation
z nagłówka klasy. Implementacja kolejnych
metod sprowadza się do podania jej nagłów-
ka i wprowadzenia odpowiedniego kodu po-
między nawiasami klamrowymi. Zakończe-
nie implementacji klasy oznacza się słowem
kluczowym @end.
Warto w tym miejscu zaprezentować, w
jaki sposób Objective-C pozwala na dekla-
rację metod przyjmujących argumenty. Na
początek przykład metody jednoargumen-
towej:
- (void) displayText: (NSString*)text;
Na powyższym przykładzie widać, iż de-
klaracja argumentu składa się z jego typu
(zawartego w nawiasach – w przykładzie
wskaźnik na typ NSString) oraz jego na-
zwy. Sam argument jest oddzielony od na-
zwy funkcji dwukropkiem. Pozostaje tyl-
ko przedstawić deklarację funkcji wieloar-
gumentowej, która powstaje w analogicz-
ny sposób:
- (int) sum: (int)a with: (int)b;
Powyższej zadeklarowana metoda zwraca
sumę dwóch liczb całkowitych. Warto tu-
taj zauważyć, iż język Objective-C stosuje
nazwane argumenty. Pozwala to na czytel-
niejsze przedstawienie działania metody
za pomocą samego nagłówka, jednak spra-
wia, iż zagnieżdżone wywołania metod
mogą stać się prawdziwym utrapieniem
dla programisty chcącego utrzymać swój
kod w ryzach.
Wywołanie prostej metody odbywa się w
prosty sposób, który niestety ponownie jest
unikalny dla języka Objective-C:
[stud displayName];
Pomiędzy nawiasami kwadratowymi na-
leży w pierwszej kolejności podać nazwę
utworzonego wcześniej obiektu, a następ-
nie nazwę wywoływanej metody. Gdy-
by displayName była metodą statycz-
ną (dla przypomnienia – oznaczona zna-
kiem +), jej wywołanie miałoby następu-
jącą formę:
[Student displayName];
Jak widać, nazwa obiektu została zastąpiona
odpowiednią nazwą klasy. Wywołanie me-
tod przyjmujących parametry odbywa się w
analogiczny sposób:
[stud displayText:@”Hello World”];
Korzystanie z metod zwracających wartość
już nie powinno być zaskoczeniem:
int c = [stud sum:3 with:5];

Powyższy wstęp stanowi tylko niewielki uła-
mek wiedzy niezbędnej do świadomego ko-
rzystania z właściwości języka Objective-C.
Pominięte zostały tutaj tak ważne elemen-
ty jak chociażby zarządzanie pamięcią. Oso-
by chcące zgłębić tę wiedzę zapraszam do
skorzystania z materiałów wymienionych
w ramce.
Witaj świecie po raz drugi
Tym razem pora na pierwszy przykład wy-
korzystania biblioteki cocos2d-iphone. Jeże-
li instalacja szablonu projektu powiodła się,
wystarczy z menu File > New Project… wybrać
odpowiednią pozycję (Rysunek 2) i nadać na-
zwę CocosGame. W wyniku tych działań po-
wstanie kompletny projekt zawierający źró-
dła biblioteki oraz prostą aplikację wyświe-
tlającą komunikat tekstowy na ekranie tele-
fonu (Rysunek 3).
Warto przeanalizować plik CocosGame-
AppDelegate.m przedstawiony na Listin-
gu 5. Zawiera on automatycznie wyge-
nerowany kod odpowiedzialny za inicja-
lizację gry. Na początek dokonamy zmia-
ny orientacji ekranu z poziomej na piono-
wą. W tym celu należy zlokalizować nastę-
pującą linię:
[[Director sharedDirector]
setDeviceOrientation:CCDeviceOrientation
LandscapeLeft];
I dokonać jej zamiany na:
[[Director sharedDirector]
setDeviceOrientation:CCDeviceOrientat
ionPortrait];
Kolejna linia, na którą warto zwrócić uwagę,
to ta odpowiedzialna za wyświetlanie liczni-
ka klatek na sekundę. Jego wyłączenia moż-
na dokonać, komentując linię:
[[Director sharedDirector] setDisplayFPS:
YES];
Cocos2d tak jak każda biblioteka tego typu
narzuca pewną filozofię podziału aplikacji.
W tym przypadku najważniejsze elemen-
ty to sceny (klasa Scene) i warstwy (kla-
sa Layer), przy czym użytkownik ma peł-
ną dowolność w interpretacji zakresu tych
bytów. Proponuję scenę rozważać jako poje-
dynczy ekran, taki jak menu główne, ekran
gry itp. Każda scena może zawierać dowol-
ną liczbę warstw. Tworzenie własnych scen
i warstw odbywa się poprzez dziedziczenie
z odpowiednich klas.
Tworzenie prostego menu
Jednym z zadań, które można realizować bar-
dzo szybko za pomocą biblioteki cocos2d-
www.sdjournal.org
Programowanie gier pod iPhone
iphone, jest tworzenie menu gry. W poniż- składające się z kilku prostych ekranów. Na
szym przykładzie zostanie stworzone menu początek zajmiemy się menu głównym, któ-
Listing 5. Plik CocosGameAppDelegate.m
#import "CocosGameAppDelegate.h"
#import "cocos2d.h"
#import "HelloWorldScene.h"
@implementation CocosGameAppDelegate
@synthesize window;
- (void) applicationDidFinishLaunching:(UIApplication*)application
{
// Init the window
window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
// cocos2d will inherit these values
[window setUserInteractionEnabled:YES];
[window setMultipleTouchEnabled:YES];
// must be called before any othe call to the director
// WARNING: FastDirector doesn't interact well with UIKit controls
// [Director useFastDirector];
// before creating any layer, set the landscape mode
[[Director sharedDirector] setDeviceOrientation: CCDeviceOrientationLandscapeLeft];
[[Director sharedDirector] setAnimationInterval:1.0/60];
[[Director sharedDirector] setDisplayFPS:YES];
// Default texture format for PNG/BMP/TIFF/JPEG/GIF images
// It can be RGBA8888, RGBA4444, RGB5_A1, RGB565
// You can change anytime.
[Texture2D setDefaultAlphaPixelFormat:kTexture2DPixelFormat_RGBA8888];
// create an openGL view inside a window
[[Director sharedDirector] attachInView:window];
[window makeKeyAndVisible];
[[Director sharedDirector] runWithScene: [HelloWorld scene]];
}
- (void)applicationWillResignActive:(UIApplication *)application {
[[Director sharedDirector] pause];
}
- (void)applicationDidBecomeActive:(UIApplication *)application {
[[Director sharedDirector] resume];
}
- (void)applicationDidReceiveMemoryWarning:(UIApplication *)application {
[[TextureMgr sharedTextureMgr] removeAllTextures];
}
- (void)applicationWillTerminate:(UIApplication *)application {
[[Director sharedDirector] end];
}
- (void)applicationSignificantTimeChange:(UIApplication *)application {
[[Director sharedDirector] setNextDeltaTimeZero:YES];
}
- (void)dealloc {
[[Director sharedDirector] release];
[window release];
[super dealloc];
}
@end
9
 Biblioteka Miesiąca

re zawiera trzy przyciski. W tym celu należy ra dziedziczy z klasy Scene (Listing 6). Składa • init– jest odpowiedzialna za inicjaliza-
utworzyć nową klasę o nazwie MainMenu, któ- się ona z czterech metod: cję sceny, w tym przypadku utworzenie
trzech przycisków i ich wyświetlenie na
Listing 6. MainMenu.h ekranie;
• onPlayItem, onHelpItem, onAboutItem
#import "cocos2d.h" – metody zostaną automatycznie wy-
@interface MainMenu : Scene wołane w przypadku wciśnięcia odpo-
{ wiedniego przycisku przez użytkow-
} nika.
- (id) init;
- (void) onPlayItem: (id)sender; Podczas tworzenia menu wykorzystywa-
- (void) onHelpItem: (id)sender; na jest przede wszystkim klasa Menu odpo-
- (void) onAboutItem: (id)sender; wiedzialna za zarządzanie przyciskami, wy-
@end świetlanie ich w odpowiedniej kolejności
oraz automatyczne pozycjonowanie. Na po-
Listing 7. Plik MainMenu.m czątek jednak należy utworzyć przyciski.
#import "MainMenu.h" W tym celu wykorzystana zostanie klasa
#import "Game.h" MenuItemFont reprezentująca proste przyci-
#import "HelpMenu.h" ski tekstowe:
#import "AboutMenu.h"
MenuItem* planitem = [MenuItemFont
@implementation MainMenu itemFromString:@”Play” target:
self selector:@selector
- (id) init (onPlayItem:)];
{
self = [super init]; Pierwszy z argumentów określa etykie-
if ( self != nil ) tę przycisku, natomiast drugi określa
{ obiekt, do którego zostanie wysłana in-
MenuItem* playItem = [MenuItemFont itemFromString:@"Play" target:self formacja o jego wciśnięciu. Ostatni argu-
selector:@selector(onPlayItem:)]; ment definiuje metodę obsługi tego zda-
MenuItem* helpItem = [MenuItemFont itemFromString:@"Help" target:self rzenia.
selector:@selector(onHelpItem:)]; Po zdefiniowaniu kilku przycisków, można
MenuItem* aboutItem = [MenuItemFont itemFromString:@"About" target:self przystąpić do utworzenia kompletnego me-
selector:@selector(onAboutItem:)]; nu. W tym celu należy wykorzystać metodę
menuWithItems:
Menu* menu = [Menu menuWithItems:playItem, helpItem, aboutItem, nil];
[menu alignItemsVertically]; Menu* menu = [Menu menuWithItems:
[self addChild:menu]; playItem, helpItem,
} aboutItem, nil];

return self; Klasa Menu pozwala również na auto-

} matyczne rozmieszczenie przycisków na
ekranie. W tym przypadku przyciski zo-
- (void) onPlayItem: (id) sender staną ułożone w jednej pionowej kolum-
{ nie:
[[Director sharedDirector] replaceScene:[RotoZoomTransition
transitionWithDuration:1.0 scene:[Game node]]]; [menu alignItemsVertically];
}
Kompletna implementacja klasy MainMenu
- (void) onHelpItem: (id) sender została przedstawiona na Listingu 7. Imple-
{ mentacja metod odpowiedzialnych za obsłu-
[[Director sharedDirector] replaceScene:[RotoZoomTransition gę zdarzeń związanych z przyciskami menu
transitionWithDuration:1.0 scene:[HelpMenu node]]]; zostanie omówiona w dalszej cześci artyku-
} łu. Aby przetestować nową scenę, należy w
pliku CocosGameAppDelegate.m dodać na-
- (void) onAboutItem: (id) sender główek:
{
[[Director sharedDirector] replaceScene:[RotoZoomTransition #import "MainMenu.h"
transitionWithDuration:1.0 scene:[AboutMenu node]]];
} Następnie po zlokalizowaniu linii:

@end [[Director sharedDirector] runWithScene:

[MainMenu scene]];

10 02/2010
 Programowanie gier pod iPhone

Należy dokonać jej zmiany na następującą:
[[Director sharedDirector] runWithScene:
[MainMenu node]];
W ten sposób poinformowaliśmy bibliote-
kę cocos2d, że pierwszą sceną aplikacji jest
menu główne reprezentowane przez klasę
MainMenu. Uruchomiona aplikacja zosta-
ła przedstawiona na Rysunku 4.
Implementacja kolejnych ekranów została
przedstawiona na Listingach 8-11. Ze wzglę-
du na ich podobieństwo do menu głównego
nie będą one dokładniej omawiane.
Mając trzy ekrany menu, możemy doko-
nać ich połączenia. W tym celu należy w me-
todach obsługi zdarzeń dla przycisków doko-
nać zamiany aktualnie wyświetlanej sceny na
tą wybraną przez użytkownika:
[[Director sharedDirector] replaceScene:
[AboutMenu node]];
Powyższa linia wyświetli na ekranie telefo-
nu scenę reprezentującą ekran informacji o
aplikacji. W tym miejscu warto skorzystać
z kolejnej ciekawej możliwości oferowanej
przez omawianą bibliotekę. Chodzi o możli-
wość użycia efektów przejścia pomiędzy sce-
nami. Wszystkie klasy z tym związane moż-
na znaleźć w pliku Transitions.h. Poniższy
przykład wykorzystuje efekt szybkiego ob-
racania ekranu wraz ze skalowaniem, która
trwa przez jedną sekundę:
[[Director sharedDirector] replaceScene:
[RotoZoomTransition transitionWithDuration:
1.0 scene:[AboutMenu node]]];
W taki sposób zakończyliśmy proces two- Kółko i Krzyżyk
rzenia menu, które mimo swojej prostoty Jak wskazuje tytuł paragrafu, naszym ce-
jest w pełni funkcjonalne. Nie pozostaje nic lem będzie stworzenie mobilnej wersji kla-
innego jak przejść do sedna artykułu – two- sycznej gry Kółko i Krzyżyk (Rysunek 5).
rzenia prostej gry. Skupimy się jednak na aspektach związa-
Listing 8. Plik AboutMenu.h
#import "cocos2d.h"
@interface AboutMenu : Scene
{
}
- (id) init;
- (void) onBackItem: (id)sender;
@end
Listing 9. Plik AboutMenu.m
#import "AboutMenu.h"
#import "MainMenu.h"
@implementation AboutMenu
- (id) init
{
self = [super init];
if ( self != nil )
{
MenuItem* backItem = [MenuItemFont itemFromString:@"Back" target:self
selector:@selector(onBackItem:)];
Menu* menu = [Menu menuWithItems:backItem, nil];
[menu alignItemsVertically];
[self addChild:menu];
}

return self;
}

- (void) onBackItem: (id) sender

{
[[Director sharedDirector] replaceScene:[RotoZoomTransition
transitionWithDuration:1.0 scene:[MainMenu node]]];
}

@end

Listing 10. Plik HelpMenu.h

#import "cocos2d.h"

@interface HelpMenu : Scene

{
}

- (id) init;
- (void) onBackItem: (id)sender;

@end
Rysunek 4. Widok prostego menu

www.sdjournal.org 11
 Biblioteka Miesiąca

nych z wykorzystaniem biblioteki cocos2d aplikacji, należy je umeścić w katalogu Reso- go MarkType pozwalającego na określenie każ-
i w pełni świadomie zostaną pominięte ta- urces widocznego w panelu znajdującego się dego z tych stanów.
kie elementy jak opracowanie algorytmów po lewej stronie okna edytora XCode. Podstawowym obiektem wykorzysty-
sztucznej inteligencji, które mogłyby za- W grze kółko i krzyżyk mamy do czynie- wanym w grze będzie pole gry reprezento-
ciemnić główną treść. nia z polem gry w rozmiarze 3x3, przy czym wanie przez klasę BoardField. Jej interfejs
Na początek potrzebne są trzy pliki graficz- każde z nich może być w jednym z trzech sta- wraz z definicją opisanego wcześniej wyli-
ne w formacie PNG przedstawiające odpo- nów: puste, oznaczone krzyżykiem lub ozna- czenia został przedstawiony na Listingu 12.
wiednio pojedyncze pole gry, kółko oraz krzy- czone kółkiem. Dlatego też pierwszym kro- Warto zwrócić uwagę na deklarację interfej-
żyk. Aby możliwe było ich wykorzystanie w kiem będzie utworzenie typu wyliczeniowe- su TargetedTouchDelegate. Jest on dostar-
czany przez bibliotekę cocos2d i ułatwia ob-
Listing 11. Plik HelpMenu.m sługiwanie zdarzeń związanych z interfej-
sem dotykowym na poziomie pojedyncze-
#import "HelpMenu.h" go obiektu graficznego (w naszym przypad-
#import "MainMenu.h" ku pola gry). Klasa BoardField będzie im-
plementować dwie z czterech udostępnia-
@implementation HelpMenu nych metod.
Pierwsza metoda ccTouchBegan jest wy-
- (id) init woływana za każdym razem, gdy aplikacja
{ otrzyma informacje o nowym dotknięciu
self = [super init]; ekranu urządzenia przez użytkownika. Ko-
if ( self != nil ) rzystając z otrzymanych danych na temat
{ pozycji, należy dokonać decyzji, czy zda-
MenuItem* backItem = [MenuItemFont itemFromString:@"Back" target:self rzenie to powinno zostać przechwycone i
selector:@selector(onBackItem:)]; zwrócić wartość logiczną YES lub NO. Po-
zwala to na uniknięcie konieczności imple-
Menu* menu = [Menu menuWithItems:backItem, nil]; mentacji często skomplikowanych i podat-
[menu alignItemsVertically]; nych na błędy, algorytmów śledzących po-
[self addChild:menu]; szczególne ruchy. Interfejs multitouch do-
} stępny w urządzeniu jest bardzo wygodny
dla użytkownika, ale przeciętnego progra-
return self; mistę może przyprawić o ból głowy. Dlate-
} go też warto korzystać z ułatwień , jakie w
tej dziedzinie zostały udostępnione przez
- (void) onBackItem: (id) sender bibliotekę cocos2d.
{ Drugą metodą implementowaną przez
[[Director sharedDirector] replaceScene:[RotoZoomTransition opisywaną klasę jest ccTouchEnded, której
transitionWithDuration:1.0 scene:[MainMenu node]]]; nazwa jednoznacznie wskazuje, iż jest wy-
} woływana w momencie zakończenia poje-
dynczego ruchu na ekranie. Jednak w tym
@end

Listing 12. Plik BoardField.h

#import "cocos2d.h"

typedef enum
{
MarkTypeNone,
MarkTypeCross,
MarkTypeCircle
} MarkType;

@interface BoardField : TextureNode <TargetedTouchDelegate>

{
MarkType mark;
}

@property (assign) MarkType mark;

+ (id)itemWithTexture:(Texture2D *)texture;
- (id)initWithTexture:(Texture2D *)texture;

@end
Rysunek 5. Widok gry

12 02/2010
 Programowanie gier pod iPhone

wypadku nie jest konieczne sprawdzanie,

czy otrzymaliśmy zdarzenie związane z do- Listing 13. Plik BoardField.m
tykiem, który jest powiązany z obiektem. #import "BoardField.h"
Otrzymamy informację o takim zdarzeniu
tylko wtedy, gdy metoda ccTouchBegan @implementation BoardField
zwróci wartość YES. Na początku może
się to wydawać nieco zagmatwane, jednak @synthesize mark;
kompletny kod źródłowy opisywanej klasy
przedstawiony na Listingach 12 i 13 powi- + (id)itemWithTexture:(Texture2D *)texture
nien wszystko wyjaśnić. {
Warto przy tym zwrócić uwagę na meto- return [[[self alloc] initWithTexture:texture] autorelease];
dy onEnter i onExit. Są one wywoływane w }
momencie, gdy obiekt klasy dziedziczącej
po klasie CocosNode (lub jej pochodnej) zo- - (id)initWithTexture:(Texture2D *)texture
stanie dodany lub usunięty ze sceny. W na- {
szym przypadku zostały one wykorzystane self = [super init];
w celu uruchomienia mechanizmu śledze- if ( self )
nia zdarzeń związanych z interfejsem doty- {
kowym. self.texture = texture;
Krótkiego wyjaśnienia może wymagać mark = MarkTypeNone;
implementacja opisanej wcześniej meto- }
dy ccTouchBegan. W pierwszej kolejności
sprawdza ona, czy pole nie zostało już wcze- return self;
śniej zaznaczone. Jeżeli jest ono puste, na- }
leży na podstawie współrzędnych określić,
czy właśnie to pole zostało dotknięte przez - (void)onEnter
użytkownika. Jeżeli oba powyższe warun- {
ki są spełnione, wystarczy zwrócić wartość [[TouchDispatcher sharedDispatcher] addTargetedDelegate:self priority:0
YES, aby poinformować, iż zdarzenie zwią- swallowsTouches:YES];
zane z tym konkretnym dotknięciem zo- [super onEnter];
stało na stałe powiązane z rozpatrywanym }
obiektem.
Dziedziczenie z klasy TextureNode zwal- - (void)onExit
nia programistę z konieczności ręcznego {
renderowania obiektu na ekranie. Należy je- [[TouchDispatcher sharedDispatcher] removeDelegate:self];
dynie dostarczyć teksturę, która ma poja- [super onExit];
wić się na ekranie urządzenia. Zajmuje się }
tym metoda iniWithTexture, która jest od-
powiedzialna za inicjalizację obiektu kla- - (BOOL)ccTouchBegan:(UITouch *)touch withEvent:(UIEvent *)event
sy BoardField. Bliźniacza metoda statyczna {
itemWithTexture upraszcza proces tworze- if ( mark != MarkTypeNone )
nia obiektu. {
Klasa BoardField wykorzystuje prosty, return NO;
ale ogromnie przydatny mechanizm powia- }
domień, który jest udostępniany przez bi-
bliotekę Cocoa. Jego sercem, a jednocześnie CGSize size = [self.texture contentSize];
samowystarczalnym elementem jest klasa CGRect rect = CGRectMake( -size.width/2, -size.height/2, size.width, size.height );
NSNotificationCenter udostępniana w for- if ( !CGRectContainsPoint( rect, [self convertTouchToNodeSpaceAR:touch] ) )
mie singletonu. W celu wysłania do wszyst- {
kich nasłuchujących obiektów, informacji o return NO;
zaistnieniu jakiegoś zdarzenia (identyfikowa- }
nego za pomocą nazwy) wystarczy wywołać
metodę postNotificationName z odpowied- return YES;
nimi parametrami. Przykład jej użycia przed- }
stawia metoda ccTouchEnded, która infor-
muje o zaznaczeniu danego pola przez użyt- - (void)ccTouchEnded:(UITouch *)touch withEvent:(UIEvent *)event
kownika. {
[[NSNotificationCenter defaultCenter] postNotificationName:@"BoardFieldTouch"
Silnik gry object:self];
Możliwe, że w przypadku gry w kółko i }
krzyżyk określenie silnik gry jest lekką
przesadą, jednak posłużymy się nim z bra- @end
ku lepszej alternatywy. Zostanie on zawar-

www.sdjournal.org 13
 Biblioteka Miesiąca

Listing 14. Plik Game.h

#import "cocos2d.h" -(void) fieldTouched:(NSNotification*)notification;

#import "BoardField.h" -(void) opponentTurn;
@interface Game : Scene <UIAlertViewDelegate> -(BOOL) checkBoard:(MarkType)mark;
{ -(void) markField:(BoardField*)field mark:(MarkType)mark;
NSMutableArray* fields; -(void) markRandomField:(MarkType)mark;
int fieldsCounter; -(void) displayMessage:(NSString*)message;
} @end

Listing 15. Plik Game.m

#import "Game.h" {
#import "MainMenu.h" [fields release];
#include <stdlib.h> [super dealloc];
@implementation Game }
-(id) init -(void) fieldTouched:(NSNotification*)notification
{ {
self = [super init]; fieldsCounter++;
if( self ) // Mark touched board field
{ BoardField* field = [notification object];
// Reset marked fields counter [self markField:field mark:MarkTypeCross];
fieldsCounter = 0; // Check if player has won
// Load board field texture if ( [self checkBoard:MarkTypeCross] )
Texture2D* fieldTexture = [[TextureMgr {
sharedTextureMgr] addImage:@"ttt- [self displayMessage:@"You won the game!"];
field.png"]; }
// Calculate position of top-left board field else if ( fieldsCounter == 3*3 )
CGSize displaySize = [[Director sharedDirector] {
winSize]; [self displayMessage:@"Tie!"];
float x = ( displaySize.width - 2*fieldTexture.contentS }
ize.width )/2.0f; else
float y = displaySize.height - ( displaySize.height {
- 2*fieldTexture.contentSize.height id delay = [DelayTime actionWithDuration:0.5];
)/2.0f; id call = [CallFunc actionWithTarget:self selector:
// Create game board @selector(opponentTurn)];
fields = [[NSMutableArray alloc] initWithCapacity:3]; id sequence = [Sequence actions:delay, call, nil];
for ( int i = 0; i < 3; ++i ) [self runAction:sequence];
{ }
NSMutableArray* column = [NSMutableArray }
arrayWithCapacity:3]; -(void) opponentTurn
[fields addObject:column]; {
for ( int j = 0; j < 3; ++j ) fieldsCounter++;
{ // Mark random field
BoardField* field = [BoardField itemWithTexture: [self markRandomField:MarkTypeCircle];
fieldTexture]; // Check if player has lost the game
field.position = CGPointMake( if ( [self checkBoard:MarkTypeCircle] )
x + i*fieldTexture.contentSize.width, {
y - j*fieldTexture.contentSize.height [self displayMessage:@"You have lost!"];
); }
[self addChild: field]; }
[column addObject: field]; - (BOOL) checkBoard:(MarkType)mark
} {
} int i, j;
// Listen for board fields touch notifications // Check columns
[[NSNotificationCenter defaultCenter] addObserver: for ( i = 0; i < 3; ++i )
self selector:@selector(fieldTouched:) {
name:@"BoardFieldTouch" object:nil]; for ( j = 0; j < 3; j++ )
} {
return self; BoardField* field = [[fields objectAtIndex:i]
} objectAtIndex:j];
- (void) dealloc if ( field.mark != mark )

14 02/2010
 Programowanie gier pod iPhone

Listing 15. Plik Game.m

{ Texture2D* texture = NULL;

break; if ( mark == MarkTypeCircle )
} {
} texture = [[TextureMgr sharedTextureMgr] addImage:
if ( j == 3 ) @"ttt-circle.png"];
{ }
return YES; else if ( mark == MarkTypeCross )
} {
} texture = [[TextureMgr sharedTextureMgr] addImage:
// Check rows @"ttt-cross.png"];
for ( i = 0; i < 3; ++i ) }
{ else
for ( j = 0; j < 3; j++ ) {
{ return;
BoardField* field = [[fields objectAtIndex:j] }
objectAtIndex:i]; TextureNode* node = [TextureNode node];
if ( field.mark != mark ) node.texture = texture;
{ CGSize size = [field contentSize];
break; node.position = CGPointMake( size.width/2, size.height/2 );
} [field addChild:node];
} id fadeIn = [FadeIn actionWithDuration:0.75];
if ( j == 3 ) [node runAction:fadeIn];
{ }
return YES; -(void) markRandomField:(MarkType)mark
} {
} BoardField* field = NULL;
// Check diagonally from top-left to bottom-right corner while ( !field || field.mark != MarkTypeNone )
for ( i = 0; i < 3; i++ ) {
{ int index = arc4random()%(3*3);
BoardField* field = [[fields objectAtIndex:i] int column = index/3;
objectAtIndex:i]; int row = index%3;
if ( field.mark != mark ) field = [[fields objectAtIndex:column] objectAtIndex:row];
{ }
break; [self markField:field mark:mark];
} }
} -(void) displayMessage:(NSString*)message
{
if ( i == 3 ) [[Director sharedDirector] pause];
{ UIAlertView* dialog = [[UIAlertView alloc] init];
return YES; [dialog setDelegate:self];
} [dialog setTitle:@"Game Over"];
// Check diagonally from bottom-left to top-right corner [dialog setMessage:message];
for ( i = 0; i < 3; i++ ) [dialog addButtonWithTitle:@"OK"];
{ [dialog show];
BoardField* field = [[fields objectAtIndex:2-i] [dialog release];
objectAtIndex:i]; }
if ( field.mark != mark ) -(void) alertView:(UIAlertView *)alert clickedButtonAtIndex:
{ (NSInteger)buttonIndex
break; {
} [[Director sharedDirector] resume];
} // Return to main menu
if ( i == 3 ) [[Director sharedDirector] replaceScene:
{ [RotoZoomTransition
return YES; transitionWithDuration:1.0 scene:
} [MainMenu node]]];
return NO; }
} @end
-(void) markField:(BoardField*)field mark:(MarkType)mark
{
field.mark = mark;

www.sdjournal.org 15
 Biblioteka Miesiąca

ty w klasie GameScene reprezentującej po-
jedynczą rozgrywkę przedstawionej na Li-
stingach 14 i 15. W związku z prostotą opi-
sywanej gry nie jest ona zbyt złożona, jed-
nak warto opisać kilka kluczowych ele-
mentów. .
Klasa GameScene zawiera tylko dwa po-
la. Pierwsze z nich opatrzone nazwą fields
przechowuje w tablicy wszystkie obiek-
ty reprezentujące pojedyncze pola gry.
NSMutableArray jest kontenerem udostęp-
nianym przez bibliotekę Cocoa i pozwala na
przechowywanie obiektów dowolnego typu.
Drugie pole będzie wykorzystywane w celu
śledzenia liczby zaznaczonych pól. Informa-
cja ta pozwoli na wykrycie zakończenia gry w
przypadku remisu.
Przegląd silnika gry rozpoczniemy od
jego inicjalizacji, która odbywa się w meto-
dzie init. Pierwszą czynnością, jaką należy
wykonać, jest załadowanie tekstury pustego
pola gry. W dalszej części metody wykorzy-
stana ona jest podczas tworzenia obiektów
klasy BoardField i ich rozmieszczania na
Rysunek 6. Widok gry
ekranie. W metodzie tej kolejny raz pojawia
się klasa NSNotificationCenter. Do tej po-
ry wykorzystaliśmy ją tylko w celu wysyła-
nia informacji o zdarzeniach. W tym miej-
scu rejestrujemy metodę fieldTouched,
która posłuży do ich obsługi. Jej działanie
jest dosyć oczywiste - dokonuje ona za-
znaczenia dotkniętego pola, a następnie
sprawdza, czy użytkownik zapewnił sobie
tym ruchem zwycięstwo lub remis. Jeżeli
nie, wykonywany jest ruch przeciwnika.
Jak wspomniałem we wstępie, nie będzie-
my zajmować się opracowaniem algorytmu
sztucznej inteligencji. Dlatego też przeciw-
nik gracza zachowuje się dosyć nieprzewi-
dywanie, a wynika to z prostego faktu za-
znaczania losowego pola gry.
Przy okazji metody markField odpowie-
dzialnej za załadowanie odpowiedniej tek-
stury i zaznaczenie pola kółkiem lub krzy-
żykiem, warto zwrócić uwagę na wykorzy-
stanie mechanizmu akcji. Jest on udostęp-
niany przez bibliotekę cocos2d i pozwa-
la na odtwarzanie prostych animacji. Aby
zapewnić płynne pojawienie się zaznacze-
nia na dotkniętym polu, użyta została ak-
cja FadeIn. Jednak możliwości udostępnia-
ne przez ten mechanizm są znacznie więk-
sze. Warto spojrzeć do dokumentacji, aby
zapoznać się ze wszystkimi dostępnymi ak-
cjami. Zapewniam, że samo eksperymento-
wanie z nimi może przynieść dużo satys-
fakcji, a otrzymane efekty często przerasta-
ją oczekiwania.
Na koniec każdej gry należy poinformować
gracza o jego rezultatach. W przypadku na-
szej gry może to być zwycięstwo, przegrana
lub remis. W tym celu wykorzystany zosta-
nie natywny interfejs użytkownika systemu,
a dokładniej okienko UIAlertView (Rysunek
6). Metoda displayMessage prezentuje spo-
sób jego inicjalizacji w kilku linijkach kodu,
które można streścić jako utwórz, nazwij, do-
daj przyciski i pokaż.
Na tym kończy się proces tworzenia gry.
Zainteresowane osoby odsyłam do płyty
dołączonej do numeru, na której znajdu-
ją się kompletne źródła gry wraz z plikiem
projektu. Wystarczy otworzyć go za pomo-
cą edytora XCode i uruchomić w symula-
torze. Warto bliżej przyjrzeć się samej bi-
bliotece cocos2d-iphone i poeksperymen-
tować z utworzoną aplikacją. A jeżeli uda
się stworzyć coś ciekawego, nie pozosta-
je nic innego jak pochwalenie się naszymi
umiejętnościami poprzez umieszczenie gry
w AppStore.
Podsumowanie
Niestety zarówno sam temat tworzenia
gier, jak i zakres możliwości oferowanych
przez bibliotekę cocos2d stanowczo wy-
kracza poza zakres jednego artykułu. Mam
jednak nadzieję, że udało mi się przybli-
żyć podstawowe zagadnienia związane z
tym jakże emocjonującym zajęciem. Osoby
chcące rozwinąć swoją wiedzę odsyłam do
ramki zawierającej adresy najważniejszych
stron internetowych.
Na sam koniec warto wspomnieć, że bi-
blioteka cocos2d-iphone rozpowszechniana
jest na stosunkowo liberalnej licencji GNU
Lesser General Public License, co pozwala na
bezpieczne wykorzystywanie jej w komercyj-
nych projektach.
JAKUB WĘGRZYN
Pracuje na stanowisku Starszego Programi-
sty Gier Natywnych w firmie Gamelion, wcho-
dzącej w skład Grupy BLStream. Jakub specja-
lizuje się w technologiach związanych z pro-
dukcją oprogramowania na platformy mobil-
ne, ze szczególnym naciskiem na tworzenie
gier. Grupa BLStream powstała, by efektyw-
niej wykorzystywać potencjał dwóch szybko
rozwijających się producentów oprogramowa-
nia – BLStream i Gamelion. Firmy wchodzące
w skład grupy specjalizują się w wytwarzaniu
oprogramowania dla klientów korporacyjnych,
w rozwiązaniach mobilnych oraz produkcji i te-
stowaniu gier.
Kontakt z autorem: jakub.wegrzyn@game-lion.com

W Sieci
• http://www.cocos2d-iphone.org/ – cocos2d for iPhone;
• http://lethain.com/entry/2008/oct/03/notes-on-cocos2d-iphone-development/ – Notes on Cocos2d iPhone Development;
• http://www.cocoadevcentral.com/d/learn_objectivec/ – Cocoa Dev Central: Learn Objective-C;
• http://developer.apple.com/iphone/ – iPhone Dev Center.

Literatura
• Programming in Objective-C 2.0, Stephen G. Kochan, Addison Wesley;
• iPhone Games Projects, PJ Cabrera, Apress;
• Beginning iPhone Development: Exploring the iPhone SDK, Dave Mark, Jeff LaMarche, Apress.

16 02/2010

Kurs Video Programowanie w języku Java
Od Witaj świecie do aplikacji korporacyjnych. Cz.V
Aplikacje internetowe - Serwlety
Piąty odcinek serii to krok w kierunku tworzenia aplikacji kor-
poracyjnych. Tym razem zajmować się będziemy podstawowym
mechanizmem, stojącym u podstaw współczesnych narzędzie
do tworzenia aplikacji internetowych na platformie Java – serw-
letami.
Na początku dowiemy się jak wygląda typowa komunikacja z
użyciem protokołu HTTP oraz w jaki sposób serwery serwletów
czyli kontenery serwletów wpasowują się w ten model.
W kolejnych krokach dowiemy się jak przygotować środowisko,
które umożliwi stworzenie pierwszego serwletu. Pobierzemy i
przygotujemy jeden z najpopularniejszych kontenerów – Apache
Tomcat oraz zainstalujemy odpowiednią wersję środowiska Eclip-
se, przeznaczonego do tworzenia aplikacji korporacyjnych.
Następnie stworzymy pierwszy serwlet, który dynamicznie
stworzy zawartość strony internetowej, po to by w kolejnej od-
Jeśli nie możesz
odczytać zawartości
płyty DVD, a nie jest ona
uszkodzona mechanicznie,
sprawdź ją na co najmniej dwóch
napędach DVD.
W razie problemów z płytą, prosimy pisać
pod adres: cd@software.com.pl
Opis DVD
słonie zademonstrować przekazywanie parametrów i generowanie
odpowiedzi z ich użyciem.
Jednym z podstawowych mechanizmów, który umożliwia prze-
chowywanie stanu w aplikacjach internetowych jest sesja, która
jest dostępna w serwletach. Dowiemy się, jak z użyciem Java EE
zarządzać sesją w środowisku serwletów i jak generować odpowie-
dzi posługując się nią.
Ostatni element, który poznamy w tym odcinku to będzie przetwa-
rzanie stron JSP. Dowiemy się, czemu służą strony JSP i w jakiej są
relacji do serwletów oraz poznamy podstawy używania stron JSP.
Kurs Video Flex – Papervision3D
Odc. 7 - Przez dwa odcinki zajmiemy się grafiką 3D oraz biblioteką
Papervision3D. Na początku stworzymy pierwszą scenę wraz z jej
elementami oraz poznamy podstawy pv3D.
Odc. 8 - Kontynuując eksperymenty z Papervision3D, zacznie-
my ładować bardziej skomplikowane modele oraz dodamy interak-
tywność do naszej aplikacji.
Video Kurs Quest3D - Prosta gra FPP
Redakcja
nie udziela pomocy
technicznej w instalowaniu
i użytkowaniuprogramów
zamieszczonych na płytach DVD-ROM
dostarczonych razem z pismem.
17
 Klub techniczny Progress Software

Technologie
Progress OpenEdge
Część 6. Obiekty ProDataSet
Progressowe obiekty typu Dataset (ProDataSet) rozszerzają możliwości
definiowania złożonych obiektów biznesowych oraz relacji między nimi.
Są bardzo ważnym elementem w procesie budowania nowoczesnych
aplikacji rozproszonych i wymiany danych z innymi aplikacjami lub ich
modułami poprzez XML.
• Obiekt ten może być automatycznie za-
Dowiesz się: Powinieneś wiedzieć: pełniany danymi, przy zachowaniu relacji
• Jakie są zastosowania obiektów ProDataSet; • Ogólne zasady manipulacji danymi. Znajo- między nimi.
• Jak się je tworzy i nimi zarządza; mość obiektów DataSet jest dodatkowym • Wszelkie modyfikacje danych w PDS, do-
• O obsłudze zdarzeń dedykowanych dla Pro- atutem. dawanie i usuwanie rekordów są automa-
DataSetu. tycznie wychwytywane.
• PDS może być przekazany jako pojedynczy
parametr między procedurami wewnątrz
Korzyści: sesji lub pomiędzy sesjami.
PDS pozwalają na zdefiniowanie struktury da- • Obsługa zdarzeń przez trygery (Callback
Poziom nych, reprezentującą wybrane tablice, niezależnie Procedures). Można dopasować obsługę
trudności od struktury zewnętrznych danych w bazie. Pod- standardowych zdarzeń lub napisać wła-
stawową korzyścią jest tutaj możliwość tworzenia sną w języku OpenEdge ABL.
logiki biznesowej i logiki interfejsu odnoszących • Obsługa mapowania danych PDS do/z pli-
się do formatu danych zawartych w strukturze ków XML.
PDS, dopasowanych do specyfiki aplikacji.

W
niniejszym odcinku zapoznamy Spośród wielu sposobów zastosowania PDS w
się z zagadnieniami definiowa- Inne korzyści to: aplikacjach, najczęściej stosowane to:
nia, zapełniania danymi, prze-
prowadzania operacji na danych dla obiek- • Dane pochodzące z różnych źródeł mogą • Zastosowanie PDS do reprezentacji złożo-
tów ProDataSet oraz ich wymianą z innymi być traktowane jako jeden obiekt. nych danych.
aplikacjami.
ProDataSet (PDS) jest obiektem utwo-
rzonym w pamięci, złożonym z tablic tym- ����������������������������������������������������������

czasowych. Dla tablic tych można opcjonal-

nie zdefiniować relacje. Ponadto PDS mo-
że być podłączony do zdefiniowanych źró-
����������������
deł danych, które odpowiadają za zapełnie-
nie obiektów informacjami. Zmiany danych �������
w ProDataSetach mogą być przesyłane z po- ��������
wrotem celem zapisania w źródłach danych.
Inaczej mówiąc, ProDataSet realizuje mapo- ����������������
wanie pomiędzy zbiorem tablic w bazie da- �����������
nych (lub innym typie źródeł danych) i ich re-
prezentacją w pamięci.
������������
Obiekty ProDataSet są definiowane nieza-
leżnie od struktury danych, którymi są zapeł-
nione. Z tego powodu przy ich pomocy moż-
na w łatwy i pewny sposób odseparować da-
ne aplikacji od specyfikacji oryginalnego źró-
dła danych. Rysunek 1. Dołączenie źródła danych do PDS

18 02/2010

• Tam i z powrotem, czyli przetwarzanie da-
nych pomiędzy sesją klienta i serwera.
• Wstawienie tablic tymczasowych do PDS
w celu wykorzystania jego zaimplemento-
wanych cech (np. obsługi zdarzeń).
Tworzenie ProDataSetów
Definicja ProDataSetu (DATASET) musi być
poprzedzona zdefiniowaniem jednej lub kil-
ku tablic tymczasowych (TEMP-TABLE). Na-
stępnym krokiem jest zdefiniowanie i podłą-
czenie obiektów źródeł danych (DATA-SOURCE
– patrz Rysunek 1). Listing 1 pokazuje całą
aplikację, służącą do zapełnienia PDS (dsOr-
derOrderline) złożonego z dwóch tablic tym-
czasowych (ttOrder, ttOrderLine) i relacji
między nimi (drOrderOrderLine), do którego
przyłączone są dwa źródła danych (srcOrder,
srcOrderLine). Każdy bufor tablicy tymcza-
sowej może być podłączony do innego źródła
danych. Podczas ładowania danych brane są
pod uwagę pola o identycznych nazwach (ta-
blica tymczasowa –> źródło danych) , a pozo-
stałe ignorowane. Można określić jednak wła-
sny sposób mapowania , jeśli pola mają różne
nazwy, lecz odpowiadający typ i charakter da-
nych (np.: BUFFER ttOrder:ATTACH-DATA-
SOURCE(DATA-SOURCE srcOrder:HANDLE,”Cu
stomer.Name,CustName”)).
Do zapełniania PDS służy metoda FILL, przy
czym istnieje pięć trybów zapełniania. Domyśl-
nym MERGE polega na dodaniu rekordów do ist-
niejącego zestawu z pominięciem duplikatów.
Co ciekawe, można zapełnić nie cały PDS, lecz
wybrane tablice tymczasowe. Dopuszczalne jest
również zapełnianie z pominięciem relacji mię-
dzy tablicami.
W języku Progress ABL można utworzyć Pro-
DataSety także jako obiekty dynamiczne. Jest to
użyteczna technika, gdy struktura obiektu nie
jest znana podczas kompilacji. Obiekty takie wy-
korzystuje się np. przy obsłudze WebSerwisów
lub przy realizacji zapisu zmian do bazy. Przy-
kład ilustrujący utworzenie dynamicznego PDS
załączony jest na płycie CD.
Edycja
Proces edytowania danych w PDS (patrz Rysu-
nek 2) rozpoczyna się od dodania w definicji
tablicy tymczasowej elementu BEFORE-TABLE
(patrz Listing 1), który służy do przechowy-
wania wartości przed edycją (oryginalna tabli-
ca określana jest jako AFTER-TABLE). Każda ta-
blica tymczasowa posiada logiczny atrybut
TRACKING-CHANGES, którym włącza się proces
śledzenia zmian w tablicy BEFORE i AFTER.
W większości przypadków edytowane są tyl-
ko wybrane rekordy. Aby nie obciążać niepo-
trzebnie sieci, powinno się przesyłać z powro-
tem do serwera bazy tylko te zmodyfikowane
dane. W tym celu tworzy się dynamiczny PDS
o strukturze identycznej jak oryginalny obiekt
(metoda CREATE -LIKE) i zapełnia się go zmo-
www.sdjournal.org
Technologie Progress OpenEdge
dyfikowanymi danymi (metoda GET-CHANGES). PDS umożliwia obsługę konfliktów, które mogą
Zapis do bazy realizowany jest za pomocą me- wystąpić podczas zapisu realizowanego według
tody SAVE-ROW-CHANGES. Technologia zapisu strategii Optimistic Locking.
Listing 1. Kompletny przykład aplikacji. Pliki z definicjami
/* Plik ttDefs.i, zawierający definicję tablic tymczasowych */
DEFINE TEMP-TABLE ttOrder NO-UNDO
FIELD OrderNum AS INTEGER FORMAT "zzzzzzzzz9"
FIELD OrderDate AS DATE FORMAT "99/99/99"
FIELD ShipDate AS DATE FORMAT "99/99/99"
FIELD PromiseDate AS DATE FORMAT "99/99/99"
FIELD OrderTotal AS DECIMAL FORMAT "->,>>>,>>9.99"
INDEX OrderNum IS UNIQUE PRIMARY OrderNum.
DEFINE TEMP-TABLE ttOrderLine NO-UNDO BEFORE-TABLE ttOrderLineBefore
FIELD OrderNum AS INTEGER FORMAT "zzzzzzzzz9"
FIELD LineNum AS INTEGER FORMAT ">>9"
FIELD ItemNum AS INTEGER FORMAT "zzzzzzzzz9"
FIELD Price AS DECIMAL FORMAT "->,>>>,>>9.99"
FIELD Qty AS INTEGER FORMAT "->>>>9"
FIELD Discount AS INTEGER FORMAT ">>9%"
FIELD ExtendedPrice AS DECIMAL FORMAT "->>>,>>9.99"
INDEX OrderNum_LineNum IS UNIQUE PRIMARY OrderNum LineNum.
/* Plik dsDefs.i, zawierający definicję PDS */
DEFINE DATASET dsOrderOrderLine FOR ttOrder, ttOrderLine
DATA-RELATION drOrderOrderLine FOR ttOrder, ttOrderLine
RELATION-FIELDS (OrderNum, OrderNum).
/* Plik srcDefs.i, zawierający definicje źródeł danych*/
DEFINE QUERY qOrder FOR Order.
DEFINE DATA-SOURCE srcOrder FOR Order.
DEFINE DATA-SOURCE srcOrderLine FOR OrderLine.
�
�
�����������������������
�������������������������
�������������
����������������������������������
�������������
�� � � ��
�����������������������������
��������������
�����������������������
� �� � � ��
� �� � � ��
� �� � � ��
� �� � � ��
� �� � � ��
�����������
Rysunek 2. Proces edycji danych
W Sieci
• http://communities.progress.com/pcom/community/psdn/openedge – Progress Software Deve-
lopers Network, część ukierunkowana na zagadnienia techniczne związane z OpenEdge®;
• http://web.progress.com – strona Progress Software Corporation;
• http://www.progress.com/pl – strona Progress Software sp z o.o.
19
 Klub techniczny Progress Software

Obsługa zdarzeń • zapytanie: QUERY-OFF-END znaleźć pod podanymi poniżej odnośnikami.

Do obsługi zdarzeń służą procedury typu Cal-
lback Procedure, uruchamiane automatycznie,
gdy zachodzi zdarzenie na wybranym obiekcie.
Niektóre zdarzenia mają zdefiniowaną domyśl-
ną obsługę, jednakże deweloper aplikacji ma
możliwość zdefiniowania własnej obsługi. Po-
niżej przedstawiam typy obiektów i zdarzenia,
które można dla nich zdefiniować:
• PDS, tablica tymczasowa, bufor: BEFORE-
FILL , AFTER-FILL
• tablica tymczasowa: ROW-CREATE, ROW-
DELETE, ROW-UPDATE
Aby zdefiniować obsługę, należy (patrz Li-
sting 2):
• napisać kod procedury dla obsługi zdarzenia
• skojarzyć procedurę przy pomocy metody
SET-CALLBACK-PROCEDURE.
Dla osób, które chciałyby pogłębić wiedzę z te-
go tematu o np. obsługę błędów i transakcji,
mapowanie do/z plików XML (ten temat był
poruszany w poprzednim odcinku), polecam
skorzystać chociażby z informacji, które można
Niniejszym odcinkiem kończę serię sześciu ar-
tykułów poświęconych technologiom Progress
OpenEdge. Ciekawych tematów z tego zakresu
nie brakuje, toteż mam nadzieję, że w niedale-
kiej przyszłości cykl ten będzie kontynuowany.
Dziękuję i do zobaczenia.
PIOTR TUCHOLSKI
Autor jest od 12 lat związany z technologiami Pro-
gress Software. Wieloletni konsultant i Kierownik
Działu Szkoleń Progress Software sp. z o.o., specja-
lizujący się w technologii OpenEdge.
Kontakt z autorem: piotr.tt@gmail.com

Listing 1. Kompletny przykład aplikacji c.d. Procedura AllInOne.p

/* Definicje zmiennych */ ttOrder.OrderTotal WITH FRAME ttOrderFrame

DEFINE VARIABLE iCustNum AS INTEGER FORMAT ">>>>9" 1 COL TITLE "Order".
LABEL "Customer Number". FOR EACH ttOrderLine OF ttOrder:
DEFINE VARIABLE cCustName AS CHARACTER FORMAT DISPLAY ttOrderLine.OrderNum
"x(30)" LABEL "Name". ttOrderLine.LineNum
DEFINE VARIABLE hChangeDataSet AS HANDLE NO-UNDO. ttOrderLine.ItemNum
DEFINE VARIABLE hdsOrderOrderLine AS HANDLE NO-UNDO. ttOrderLine.Price
/* Pliki include z definicjami */ ttOrderLine.Qty
{ttDefs.i} ttOrderLine.Discount
{dsDefs.i} ttOrderLine.ExtendedPrice WITH FRAME
UPDATE iCustNum WITH FRAME CustFrame TITLE "Customer Lookup". ttOrderLineFrame
{srcDefs.i} 1 COL
/* Przyłączenie źródeł danych */ TITLE "Order Lines".
BUFFER ttOrder:ATTACH-DATA-SOURCE(DATA-SOURCE srcOrder: UPDATE
HANDLE,?,?). ttOrderLine.Qty
BUFFER ttOrderLine:ATTACH-DATA-SOURCE(DATA-SOURCE ttOrderLine.Discount
srcOrderLine:HANDLE,?,?). WITH FRAME ttOrderLineFrame 1 COL.
/* Przygotowanie zapytania */ END.
QUERY qOrder:QUERY-PREPARE("FOR EACH Order WHERE END.
Order.CustNum = " + STRING(iCustNum)). /* Utworzenie dynamicznego PDS: hChangeDataSet o takiej
/* Zapełnienie ProDataSetu danymi */ samej strukturze jak
DATASET dsOrderOrderLine:FILL(). dsOrderOrderLine */
/* Wyszukanie rekordu i wyświetlenie danych */ hdsOrderOrderLine = DATASET dsOrderOrderLine:HANDLE.
FIND Customer WHERE Customer.Custnum = iCustNum NO-LOCK. CREATE DATASET hChangeDataSet.
ASSIGN cCustName = Customer.NAME. hChangeDataSet:CREATE-LIKE( hdsOrderOrderLine , "cds" ).
DISPLAY cCustName WITH FRAME CustFrame. /* Process Get-Changes to extract Changes at DataSet Level */
/* Włączenie śledzenia zmian dla ttOrderLine */ hChangeDataSet:GET-CHANGES(hdsOrderOrderLine).
TEMP-TABLE ttOrderLine:TRACKING-CHANGES = TRUE. /* Wyłączenie śledzenia zmian */
/* Użytkownik może zmienić wartości Qty i Discount */ TEMP-TABLE ttOrderLine:TRACKING-CHANGES = FALSE.
FOR EACH ttOrder: /* Zapis zmian do bazy */
DISPLAY ttOrder.OrderNum FOR EACH ttOrderLineBefore TRANSACTION:
ttOrder.OrderDate BUFFER ttOrderLineBEfore:SAVE-ROW-CHANGES().
ttOrder.ShipDate END.
ttOrder.PromiseDate

Listing 2. Obsługa zdarzenia

/* Przypisanie procedury Callback do zdarzenia After-Fill DEFINE VARIABLE dOrderTotal AS DECIMAL INITIAL 0 NO-UNDO.
obiektu OrderLine */ FOR EACH ttOrderLine WHERE ttOrderline.OrderNum =
BUFFER ttOrderLine:SET-CALLBACK-PROCEDURE ttOrder.OrderNum:
("AFTER-FILL", "postOrderLineFill", THIS-PROCEDURE). dOrderTotal = dOrderTotal + ttOrderLine.ExtendedPrice.
/* Kod procedury */ END.
PROCEDURE postOrderLineFill: ttOrder.OrderTotal = dOrderTotal.
DEFINE INPUT PARAMETER DATASET FOR dsOrderOrderLine. END.

20 02/2010
 Klub techniczny Adobe

Co nowego w Flex 4
Flex jest jedną z najbardziej zaawansowanych technologii do
budowania aplikacji typu RIA w bezpośrednim tłumaczeniu bogatych
aplikacji internetowych. Silnikiem wyświetlającym aplikacje Flex’owe
jest technologia Adobe Flash, która pozwala na osiągnięcie jednolitego
wyglądu uruchamianej aplikacji, niezależnie od wykorzystywanej
przeglądarki czy systemu operacyjnego.

Spark
Dowiesz się: Powinieneś wiedzieć: Flex 4 został zaprojektowany w oparciu o ideę
• Jakie są różnice pomiędzy Flex 3 a Flex 4; • Co to Flex; „Design in Mind”, której celem jest zapewnienie
• Co to FXG; • Co to architektura Halo. szybkiej i bezproblemowej współpracy progra-
• Co to Spark. misty i grafika. Aby umożliwić realizację tego
pomysłu , wprowadzono całkiem nową archi-
tekturę komponentów Spark, bazującą na do-
brze nam znanej z Flex'a 3 architekturze Halo.
Oddzielono w przejrzysty sposób wygląd kom-
tymi w pakiecie mx.*. Aby uniknąć konflik- ponentów od ich logiki, gdzie w starej architek-
tów pomiędzy tymi klasami, rozszerzono turze granica ta była często mało czytelna. Za-
Poziom przestrzenie nazw do: MXML 2006, MXML dbano również o lekkość komponentów, któ-
trudności 2009, Spark, Halo. re aktualnie nie zawierają już wszystkich zbęd-
nych elementów jak suwaki czy wirtualizację.
• MXML 2006: Przestrzeń nazw używa- Przyśpieszyło to w dużym stopniu inicjalizację
na w poprzedniej wersji. aplikacji, jak i zmniejszyło jej rozmiar.

W
niniejszym artykule postaram się
wyjaśnić najważniejsze zmiany, ja-
kie zaszły w najnowszej wersji Fle-
x'a. Przesiadając się z Flex'a 3 na Flex'a 4 , mu-
simy pamiętać przede wszystkim, że nowa bi-
blioteka wymaga wsparcia FlashPlayer'a 10, tu-
dzież wszystkie aplikacje powinny być kompi-
lowane pod najnowszą wersję FlashPlayer'a.
Osobom , które znają poprzednią wersję Flex'a,
nie powinna sprawić trudności migracja na 4-
tą wersję biblioteki. Doświadczymy co prawda
mnogości zmian architektonicznych, pojawiają
się nowe przestrzenie nazw i odmłodzono dużą
część komponentów, jednak w większości przy-
padków ich interfejs udostępniony programi-
ście nie odbiega znacznie od interfejsu znane-
go z architektury Halo.
Przestrzenie nazw i pakiety
Flex 3 wszystkie klasy biblioteki trzymał w
jednym pakiecie mx.*, natomiast we Flex 4
wprowadzono nowy pakiet spark.* zawiera-
jący komponenty, klasy bazowe, efekty, filtry,
układy widoku, podstawowe kształty geome-
tryczne, skórki i narzędzia.
Wiele klas zawartych w pakiecie spark.*
współdzieli swoje nazwy z klasami zawar-
• URI: http://www.adobe.com/2006/mxml
• Domyślny prefix: mx Layout
• MXML 2009: Nowa przestrzeń nazw Dużym usprawnieniem w stosunku do Ha-
MXML-a. Nie zawiera tagów kompo- lo jest nowy sposób definiowania układu roz-
nentów. mieszczenia komponentów. Dla programi-
• URI: http://ns.adobe.com/mxml/2009 stów piszących w MXML-u niewiele uległo
• Domyślny prefix: fx zmianie. Podstawowe właściwości takie jak
• Spark: width, height, minWidth, explicitWidth,
• URI: library://ns.adobe.com/flex/spark percentWidth dalej mają to samo znacze-
• Domyślny prefix: s nie. Działanie LayoutManagera, jak i pod-
• Halo: stawowy cykl życia komponentu także nie
• URI: library://ns.adobe.com/flex/halo uległ zmianie. Metody commitProperties(),
• Domyślny prefix: mx measure() i updateDisplayList() są wy-
woływane przez LayoutManagera w tej sa-
Dodano również wsparcie przestrzeni nazw mej kolejności i reguły unieważniania pozo-
dla selektorów CSS (przykład na Listingu 2). stały te same.
Tabela 1. Kombinacje komponentów Spark i odpowiadające im klasy z Halo
Kontenery Halo Kombinacje układów z kontenerami Spark
Canvas Group + BasicLayout
HBox Group + HorizontalLayout
VBox Group + VerticalLayout
Tile Group + TileLayout
List List + VerticalLayout
TileList List + TileLayout

22 02/2010

Zasadniczymi zmianami w stosunku do
Flex 3 są:
• Odseparowanie układu od kontenera po-
zwoliło na zmianę rozmieszczenia kompo-
nentów w trakcie działania aplikacji. Zmi-
nimalizowano tym samym liczbę kontene-
rów wymaganych do stworzenia zaawanso-
wanego układu rozmieszczenia i pozwoliło
na wielokrotne użycie tego samego kodu.
• Znacznie przyśpieszono i uproszczono
tworzenie własnych układów rozmiesz-
czenia, odseparowując je od logiki kon-
tenerów.
• Definiowania arbitralnych transformacji
2D.
• Przewijanie zawartości kontenera w do-
wolnym kierunku piksel po pikselu.
• Transformacje 3D udostępnione przez
Flash Playera.
• Definiowanie głębokości każdego potomka
kontenera, do którego przypisano układ.
• Przypisywanie transformacji bez wpływu
na układ komponentów. Możemy dzięki
temu animować dowolny obiekt, nie wy-
wołując zmiany układu komponentów.
• Wszystkie właściwości określające wy-
miary nie zmieniają się w trakcie cy-
klu życia komponentu. Wyeliminowa-
no tym samym wprawiające w zakłopo-
tanie reprezentowanie wymiarów nie-
przeskalowanych w trakcie measure(),
natomiast już przeskalowanych w trak-
cie etapu updateDisplayList();
Ponieważ układ rozmieszczenia odseparowano
od kontenera, został zmieniony sposób pracy z
tym elementem. Przykładowo możemy użyć
HorizontalLayout w połączeniu z komponen-
tem List. Ustawimy również odstępy pomię-
dzy elementami na 0px i wyjustujemy. Przykła-
dowy kod przedstawiono na Listingu 3.
Tworząc kombinację grup i układów, w
łatwy sposób możemy uzyskać zachowa-
nia kontenerów znanych z architektury Ha-
lo. Przykładowe kombinacje umieszczono w
Tabeli 1.
Scrollbars
Jak już wspomniałem, architektura Spark zo-
stała mocno odchudzona. Oznacza to, że su-
waki nie są domyślnie dołączone do kontene-
rów, jak to miało miejsce w Halo. Programista
musi sam zadecydować, czy będą one wyma-
gane dla danej grupy obiektów, czy też kon-
tenera. Aby zapewnić wyświetlenie suwaków
dla kontenera, gdy będą potrzebne, należy
opakować daną grupę komponentów tagiem
Scroller, co przedstawiono na Listingu 4.
States
Flex 4 oferuje całkiem nowe zarządzanie stana-
mi aplikacji. Dzięki nowej składni zapisu wszyst-
www.sdjournal.org
Co nowego w Flex 4
kie stany w odróżnieniu od poprzedniej wersji są Component skinning
umieszczone w tablicy. Każdy komponent defi- We Flex 4 zostało mocno uproszczone tworze-
niuje własne zachowanie na zmianę stanu przy nie własnych skórek komponentów. Na Listin-
pomocy metod includeIn oraz excludeFrom. gu 7 przedstawiono sposób tworzenia przykła-
Dla przypomnienia sposób deklaracji stanu we dowej skórki dla przycisku. Przede wszystkim
Flex 3 został przestawiony na Listingu 5, nato- musimy zwrócić uwagę na deklarację czterech
miast nowy zapis przedstawiony na Listingu 6. stanów przycisku: up, over, down, disabled.
Listing 1. Przykład użycia przestrzeni nazw w aplikacji
<s:Application
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/halo">
<mx:DateChooser id="main_calendar" x="20" y="20"/>
<s:Button label="wyślij" x="220" y="20"/>
</s:Application>
Listing 2. Przykład użycia przestrzeni nazw z selektorami CSS
<fx:Style>
@namespace s "library://ns.adobe.com/flex/spark";
@namespace mx "library://ns.adobe.com/flex/halo";
s|Button {
color: #FF0000;
}
mx|DateChooser {
color: #FF0000;
}
</fx:Style>
Listing 3. Przykład użycia HorizontalLayout
<s:List id="list">
<s:layout>
<s:HorizontalLayout gap="0" verticalAlign="justify" />
</s:layout>
...
</s:List>
Listing 4. Dodanie suwaków do grupy komponentów
<s:Scroller width="200">
<s:Group>
<s:layout>
<s:HorizontalLayout gap="0" verticalAlign="justify" />
</s:layout>
<s:Button label="jeden" />
<s:Button label="dwa" />
<s:Button label="trzy" />
<s:Button label="cztery" />
</s:Group>
</s:Scroller>
Listing 5. Stany we Flex 3
<mx:states>
<mx:State name="submitState" basedOn="">
<mx:AddChild relativeTo="{loginForm}" >
<mx:Button label="Wyślij" bottom="10" right="10"/>
</mx:AddChild>
<mx:RemoveChild target="{firstTextInput}"/>
</mx:State>
</mx:states>
<mx:TextInput id="firstTextInput" />
<mx:Canvas id="loginForm" />
23
 Klub techniczny Adobe

Przykładowo zapis alpha.disabled=".5" przejściu w stan over. Zapis jest intuicyjny. używając atrybut skinClass, co zaprezento-
oznacza, że gdy przycisk będzie w stanie disa- Analogicznie możemy zdefiniować odrębne wano na Listningu 8.
bled, jego przezroczystość zostanie ustawiona właściwości dla każdego z atrybutów w zależ-
na 50%. Natomiast color.over=”0x33CC22” ności od wybranego stanu. Tak przygotowaną Flash XML Graphics (FXG)
definiuje zmianę koloru wypełnienia tła po skórkę podpinamy pod komponent Button, Ponieważ było duże zapotrzebowanie na przy-
jazny i wydajny system zapisu obiektów graficz-
Listing 6. Stany we Flex 4 nych, postanowiono wykorzystać format SVG.
Istnieją jednak pewne różnice pomiędzy możli-
<s:states> wościami graficznymi Flash Playera a formatem
<s:State name="submitState" /> SVG, co nie pozwoliło na bezpośrednią imple-
</s:states> mentację we Flash Playerze. Starano się utrzy-
<s:TextInput id="firstTextInput" excludeFrom="submitState" /> mać jak najwięcej zgodności ze specyfikacją
<s:Group id="loginForm" > SVG, czego wynikiem jest jego niestandardowa
<s:Button label="Wyślij" bottom="10" right="10" includeIn="submitState"/> implementacja w postaci formatu FXG.
</s:Group> FXG jest mocno zoptymalizowany pod
kątem Flash Playera. Umożliwia z poziomu
Listing 7. Skórka przycisku zadeklarowana w pliku MySkin.mxml xml-a za pomocą następujących tagów two-
<?xml version="1.0" encoding="utf-8"?> rzyć złożone obiekty graficzne:
<s:Skin xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/
flex/spark" alpha.disabled=".5"> • BitmapFill;
<!-- stany --> • BitmapGraphic;
<s:states> • Ellipse;
<s:State name="up" /> • GradientEntry;
<s:State name="over" /> • Graphic;
<s:State name="down" /> • Group;
<s:State name="disabled" /> • Library;
</s:states> • Line;
<!-- obramowanie i wypełnienie --> • LinearGradient;
<s:Rect id="rect" radiusX="4" radiusY="4" top="0" right="0" bottom="0" left="0"> • LinearGradientStroke;
<s:fill> • Matrix;
<s:SolidColor color="0x77CC22" color.over="0x33CC22" color.down="0xBB9911" /> • Path;
</s:fill> • RadialGradient;
<s:stroke> • RadialGradientStroke;
<s:SolidColorStroke color="0x131313" weight="2"/> • Rect;
</s:stroke> • SolidColor;
</s:Rect> • SolidColorStroke;
<!-- tekst --> • TextGraphic;
<s:Label text="Button!" color="0x131313" • Transform.
textAlign="center" verticalAlign="middle"
horizontalCenter="0" verticalCenter="1" Wiązanie obustronne
left="12" right="12" top="6" bottom="6" Wiązanie obustronne (ang. Two Way Binding)
/> pozwala na stworzenie wiązania znanego z Flex
</s:Skin> 3, jednak działającego w obie strony. Na Listin-
gu 9 przedstawiono implementację wiązania
Listing 8. Wiązanie obustronne w Flex 3 obustronnego we Flex 3, natomiast na Listingu
<?xml version="1.0" encoding="utf-8"?> 10 jego nową, skróconą wersję udostępnioną we
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library:// Flex 4. W obu wersjach aplikacji wprowadzając
ns.adobe.com/flex/spark"> zmiany do jednego z pól tekstowych, zmiany bę-
<s:Button verticalCenter="0" horizontalCenter="0" skinClass="MySkin" /> dą widoczne również w 2 z pól tekstowych.
</s:Application>
RAFAŁ NAGRODZKI
Listing 9. Wiązanie obustronne we Flex 3 Freelancer i student Katolickiego Uniwersytetu
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"> Lubelskiego. Z technologią Flash/Flex zaprzyjaź-
<mx:TextInput id="t1" text="{t2.text}"/> niony od 2004r.
<mx:TextInput id="t2" text="{t1.text}"/> Kontakt z autorem: kontakt@burzaone.net
</mx:Application>

Listing 10. Wiązanie obustronne we Flex 4 W Sieci

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
• http://www.adobe.com/devnet/flex/
<mx:TextInput id="t1" text="@{t2.text}"/>
articles/flex3and4_differences.html;
<mx:TextInput id="t2"/> • http://www.adobe.com/devnet/flex/
</mx:Application> videotraining/flex4beta/.

24 02/2010
 Cloud computing

Enterprise
Private Clouds
Cloud computing robi od pewnego czasu zawrotną karierę medialną.
Tematem zajmują się nie tylko tytuły poświęcone branży IT, ale także
biznesowe i popularno-naukowe. Nawet Dilbert wspomina już o cloud
computing. Warto zatem zastanowić się czym jest, a czym nie jest cloud
computing i jak wpłynie na tworzenie i zarządzanie oprogramowaniem.
rynku technologii. O Software as a Service,
Dowiesz się: Powinieneś wiedzieć: ostatnim wariancie cloud computing, mó-
• Idea i zastosowanie cloud computing • Podstawowa znajomość procesu produkcji wi się dużo już od dłuższego czasu. Jest to
• Czym jest Platform as a Service oprogramowania po prostu udostępnianie aplikacji bizneso-
• Wirtualizacja zasobów IT wych w formie usługi, a nie licencji. Dzię-
ki temu klient nie ponosi kosztów począt-
kowych, nie musi utrzymywać swojego śro-
dowiska, ani zatrudniać specjalistów do za-
rządzania nim. W tym wypadku podsta-
Różne rodzaje wą rozliczenia jest zazwyczaj ogólna ilość
cloud computingu użytkowników lub ilość równolegle otwar-
Poziom Ze względu na olbrzymią pojemność poję- tych sesji.
trudności cia cloud computingu, należy wyróżnić kil- Przykładem oprogramowania dostarcza-
ka jego rodzajów. Po pierwsze, usługodaw- nego wyłącznie w modelu SaaS jest Google
cą może być firma zewnętrzna lub dział IT Apps, zaś dostępnego zarówno w modelu tra-
klienta. Mówimy wówczas o chmurze pu- dycyjnym (licencyjnym), jak i w modelu Sa-

D
efinicja dopiero się krystalizuje, ale
najważniejszym jej wyróżnikiem
jest udostępnianie zasobów IT za
pośrednictwem sieci i pobieranie opłat za
stopień ich wykorzystania. Klient nie pono-
si nakładów inwestycyjnych z góry i nie musi
obawiać się niedoszacowania ani przeszaco-
wania swoich potrzeb. Jednocześnie specja-
lizacja usługodawcy oraz efekt skali powodu-
je, że usługi takie powinny być wyższej jako-
ści, a koszty dla klienta niższe, niż gdyby sam
utrzymywał środowisko IT. Czy cloud com-
puting jest zatem czymś nowym? I tak i nie.
Tak, ponieważ do niedawna nie było takich
platform jak Google App Engine czy Ama-
zon EC2. Są to bez wątpienia rozwiązania
innowacyjne, dające nowe możliwości. Czy
jednak stary, poczciwy, hosting stron WWW
nie pasuje do podanej definicji? Pasuje. Po-
dobnie jak odpłatne konta pocztowe w ser-
wisach internetowych, czy aplikacje bizne-
sowe dostępne przez internet. Cloud com-
puting nie jest zatem koncepcją rewolucyjną,
a jedynie kolejnym krokiem w ewolucji bran-
ży IT. Usługi IT stają się dobrem powszech-
nym, co pociąga za sobą zmiany w sposobie
ich świadczenia.
blicznej (public cloud) lub prywatnej (pri-
vate cloud).
Po drugie, usługi świadczone w tym mo-
delu mogą dotyczyć jednej z trzech warstw
– infrastruktury, platformy programi-
stycznej lub aplikacji biznesowych. Nazy-
wamy je odpowiednio Infrastructure as a
Service (IaaS), Platform as a Service (Pa-
aS) lub Software as a Service (SaaS). Przy-
kładem IaaS jest Amazon EC2 – możemy
tu wykupić potrzebny nam czas proceso-
rów, miejsce na dyskach i przepustowość
sieci. Usługodawca nie wnika w jaki spo-
sób korzystamy z tej infrastruktury, ale od-
powiada za jej gotowość do pracy. Google
App Engine jest już przykładem usługi Pa-
aS, gdyż usługodawca daje nam konkretne
narzędzia, z których możemy korzystać do
stworzenia potrzebnej nam aplikacji. Co
prawda w dalszym ciągu płacimy za zaso-
by fizyczne (procesor/pamięć/sieć/dysk),
ale jednak dostajemy już nie tylko infra-
strukturę, ale kompletne, ustandaryzowa-
ne, środowisko do rozwoju i działania apli-
kacji – możemy co prawda wybrać jeden z
dwóch języków (Java, Python), ale nie mo-
żemy zastosować dowolnej dostępnej na
aS jest Oracle CRM i jego wersja SaaS – CRM
On Demand.
Enterprise private clouds
Enterprise private cloud, to nic innego jak
prywatny cloud danego przedsiębiorstwa,
udostępniający usługi IT działom bizneso-
wym i partnerom (spółkom zależnym, itp).
Z punktu widzenia programistów, najciekaw-
szym wariantem takiej chmury, jest Platform
as a Service.
Korzystanie z prywatnego PaaS oznacza
dla programistów kilka zmian, w porówna-
niu do tradycyjnego modelu. Wspomnia-
łem już, że w modelu PaaS programista jest
ograniczony do narzędzi i technologii do-
stępnych na platformie. Może to budzić
niechęć ze względu na osobiste preferen-
cje, ale daje wymierne korzyści biznesowe
firmie, dla której przecież pracujemy. Stan-
daryzacja i konsolidacja środowisk pozwala
wyraźnie obniżyć koszty sprzętu, licencji,
pomocy technicznej oraz personelu. Oczy-
wiście powinna istnieć możliwość dodania
określonej technologii do zestawu narzę-
dzi dostępnych na platformie, ale nie ma
co liczyć na pełną dowolność, jak w przy-

26 02/2010

padku zupełnie niezależnych projektów i
środowisk. W zamian programista otrzy-
muje jednak wiele korzyści. Po pierwsze
dostaje możliwość prostego tworzenia do-
datkowych środowisk na żądanie. Z zało-
żenia chmura powinna być łatwa w rozbu-
dowie i powinna pomieścić dodatkowe in-
stancje, jeśli ich potrzebujemy. Co więcej,
tworzenie środowisk powinno być zauto-
matyzowane, a zarządzanie nimi oddane w
ręce użytkowników. Programista może za-
tem zażądać utworzenia nowego środowi-
ska, czy to z jakiegoś wzorca (np. czyste śro-
dowisko z aplikacją w wersji X), czy też po-
przez skopiowanie innego środowiska (po-
trzebuję identycznego środowiska jak Y, żeby
zdiagnozować problem, który występuje tyl-
ko tam). Środowisko takie powinno zostać
utworzone w czasie minut lub godzin, a
nie dni czy tygodni, jak to często bywa, gdy
utworzenie środowiska wymaga akceptacji
przełożonych, zamówienia sprzętu i ręcz-
nej pracy. Idąc tym tropem, możemy tak-
że przenieść środowiska testowe ze stacji
roboczych na platformę PaaS, dzięki cze-
mu nie musimy sami nimi zarządzać, mo-
żemy przywracać je do poprawnego stanu,
gdy coś pójdzie nie tak, a wszystkie zmiany
konfiguracyjne (np. podłączenia do baz da-
nych, adresy serwerów aplikacji czy web se-
rvices) są centralnie zarządzane i nie musi-
my się tym zajmować. Warto także zazna-
czyć, że prywatny PaaS nie ogranicza moż-
liwości debugowania systemu – o ile pu-
bliczny dostawca niekoniecznie udostępni
nam wszelkie możliwości diagnostyczne, o
tyle prywatny PaaS daje możliwość włącze-
nia odpowiednich opcji i podłączenia się z
narzędziami diagnostycznymi.
Zmiany organizacyjne
Cloud computing, zwłaszcza prywatny,
wymaga przede wszystkim zmiany sposo-
bu myślenia o zasobach IT. Tak jak SOA nie
jest technologią opartą na web services, tyl-
ko architekturą wymagającą zmiany sposo-
bu i szerszego spojrzenia na tworzenie i po-
nowne wykorzystanie aplikacji, tak cloud
computing nie wymaga żadnej szczególnej
technologii, ale przede wszystkim zmiany
w procesie zarządzania zasobami. Techno-
logia jest rzeczą wtórną, która usprawnia
ten proces i umożliwia zapewnienie do-
stępności, wydajności i bezpieczeństwa w
tych nowych warunkach. O ile korzystanie
z usług publicznych dostawców cloud com-
puting może być (i często jest) decyzją od-
dolną, o tyle projekt budowy wewnętrznej
platformy PaaS w firmie, wymaga konkret-
nych nakładów początkowych, zmiany pro-
cesu zakupów sprzętu i licencji oraz roz-
liczania innych działów za korzystanie z
nich. Należy zwrócić uwagę, że wiele apli-
www.sdjournal.org
kacji, ze względu na poufność przetwa-
rzanych danych lub inne uwarunkowania,
nie może być uruchomiona na publicz-
nych środowiskach, dlatego korzystanie z
nich decyzją oddolną powinno być zgod-
ne z polityką bezpieczeństwa firmy, a bu-
dowa prywatnej platformy może być nie-
zbędna. Na czas budowy takiego środowi-
ska można z kolei skorzystać z publiczne-
go IaaS, w którym od ręki będziemy mo-
gli wynająć sprzęt potrzebny do rozpoczę-
cia projektu.
Techniczna realizacja PaaS
Udostępnianie platformy aplikacyjnej ja-
ko usługi oznacza przede wszystkim zmia-
nę modelu sprzedaży/współpracy między
działem utrzymania systemów, a działami
rozwoju i utrzymania aplikacji. Niemniej
jednak, aby zapewnić sprawne działanie ta-
kiej platformy, co jest warunkiem koniecz-
nym osiągnięcia sukcesu, przydatne są od-
powiednie rozwiązania techniczne. Jeśli
tworzenie środowisk potrzebnych do roz-
woju aplikacji będzie trwało zbyt długo
lub utworzone środowiska będą wymagały
ręcznych poprawek, programiści powrócą
do rozwijania kodu na własnych kompute-
rach. Jeśli wzrost obciążenia w jednej apli-
kacji będzie powodował spadek wydajno-
ści całej platformy, menedżerowie poszcze-
gólnych aplikacji będą żądać separacji śro-
����������� �����������
����������������������������
���������������
���
�������
��������������
���������
������������������
��������������
����������������������������������
�����������������
�������������
�������
�������
Rysunek 1. Schemat koncepcyjny architektury IaaS/PaaS
Enterprise Private Clouds
dowisk, co zniweczy korzyści wynikające z
konsolidacji.
Wirtualizacja
Można stworzyć środowisko bez problemu
spełniające definicję PaaS nie korzystając
z żadnego rozwiązania wirtualizacyjnego,
ale zastosowanie takiej technologii pozwala
osiągnąć znacznie większe korzyści z wdro-
żenia platformy PaaS. Wirtualizacja pozwala
zwiększyć utylizację zasobów sprzętowych,
zachować ciągłość pracy w czasie prac kon-
serwacyjnych (np. wymiana sprzętu) oraz
pomaga zarządzać środowiskami. Pozwala
tworzyć wzorcowe instalacje dostępnych
na platformie komponentów, np. kompo-
nent baza danych zawierający odpowiednio
skonfigurowany system operacyjny z podłą-
czeniem do przestrzeni dyskowych, bazę da-
nych w odpowiedniej wersji i ze wszystkimi
poprawkami, narzędzia diagnostyczne i tak
dalej. Po przygotowaniu odpowiednich kom-
ponentów, gdy będziemy zaczynać nowy
projekt, programista będzie mógł zażądać
nowego środowiska ze wszystkimi potrzeb-
nymi komponentami, a po wprowadzeniu
niezbędnych zmian wymaganych dla danej
aplikacji (np. schematy bazy danych, połą-
czenie z odpowiednim modułem repozy-
torium kodu), zachować obraz jako wzor-
cowy dla innych osób pracujących nad tym
projektem.
�����������
�����������
������
���������������
������������
��������� �����������
��������
����������
����������
����������
�����������
�����������
�������������
��������
27
 Cloud computing
Sprawnie działająca platforma PaaS po-
winna pozwolić na stworzenie środowisk
dla wszystkich zainteresowanych w ciągu
kilku godzin.
Warstwa middleware
W warstwie oprogramowania middlewa-
re, przydatnych może być kilka funkcji. Po
pierwsze klastrowanie z synchronizacją se-
sji użytkowników, jako podstawowy me-
chanizm skalowania i zapewniania ciągło-
ści pracy tej warstwy. Po drugie, możliwość
jednoczesnego korzystania z różnych wer-
sji tych samych bibliotek, bowiem nasza
aplikacja niekoniecznie będzie działać na
zupełnie niezależnym środowisku. Insta-
lacja nowej aplikacji wraz z zależnościami
nie może powodować zmiany wersji biblio-
teki używanej przez już działającą aplika-
cję. Kolejna sprawa, to możliwość testowe-
go uruchomienia aplikacji na platformie.
Dopóki całe środowisko nowej aplikacji
jest niezależne – możemy testować aplika-
cję do woli bez udostępniania jej użytkow-
nikom. Jeśli jednak chcemy przeprowadzić
ostateczne testy przed upublicznieniem
aplikacji na platformie PaaS, musimy mieć
możliwość uruchomienia nowej aplikacji
tylko dla wybranych użytkowników (te-
sterów). Kolejna kwestia bardzo ułatwia-
jąca zarządzanie tak dynamiczną platfor-
mą, z wieloma środowiskami i aplikacja-
mi, to mechanizm skryptowy pozwalający
zautomatyzować czynności administracyj-
ne. Nawet jeśli korzystamy z wirtualizacji i
możemy tworzyć obrazy wzorcowe, to po
każdym skorzystaniu z takiego wzorca, po-
trzebujemy zmienić kilka parametrów (ad-
resy, porty i tym podobne). Do tego należy
doliczyć późniejsze zmiany, które trzeba w
powtarzalny sposób wykonywać na wszyst-
kich środowiskach (np. dodanie nowego
data source). Ręczne wykonywanie zmian
mogłoby spowodować niespójność środo-
wisk i tym samym zniwelować korzyści
wdrożenia PaaS.
Bardzo ciekawym rozwiązaniem, dopie-
ro wchodzącym na rynek, są serwery apli-
kacji działające bezpośrednio na hyperviso-
rze – bez klasycznego systemu operacyjne-
go. Takie podejście pozwala nie tylko pod-
nieść wydajność, dzięki lepszemu zarzą-
dzania pamięcią (normalnie system opera-
cyjny i JVM częściowo pokrywają się funk-
cjonalnością w tym zakresie), ale również
pozwala wyraźnie uprościć całe środowisko
(skoro nie ma systemu operacyjnego, to nie
trzeba go konfigurować, optymalizować,
ani aktualizować). Dodatkowo uzyskuje-
my mniejsze obrazy maszyn wirtualnych,
gdyż nie zawierają one binariów systemu
operacyjnego. Pozwala to obniżyć koszty
przestrzeni dyskowych, zaoszczędzić miej-
28
sce na urządzeniach backupowych i skró-
cić czas migracji maszyny wirtualnej mię-
dzy fizycznymi serwerami.
Poza samym kontenerem, warto rów-
nież zastosować technologię in-memory da-
ta grid. Pozwala ona przechowywać duże ilo-
ści danych obiektowych (w tym obiekty se-
sji HTTP) w pamięci operacyjnej, dzięki cze-
mu odciąża kontener JEE. Rozwiązania wy-
raźnie przyspieszają działanie aplikacji i po-
zwalają skalować aplikacje praktycznie w nie-
skończoność.
Warstwa bazy danych
Podobnie jak w przypadku serwerów apli-
kacji, w warstwie baz danych zastosowanie
klastrów również pozwala zachować cią-
głość pracy i umożliwia skalowanie syste-
mów w razie takiej potrzeby. Kluczowe sta-
je się także zarządzanie przestrzenią dys-
kową. Zastosowana technologia powinna
nie tylko umożliwiać łatwą rozbudowę, ale
również równomiernie rozkładać obciąże-
nie między dostępne dyski. W przeciw-
nym wypadku, w krótkim czasie mieliby-
śmy analogiczną sytuację jak z serwerami
bez wirtualizacji – gdy do aplikacji przy-
pisane są na stałe określone zasoby sprzę-
towe, to prawie zawsze część z nich jest
przeciążona, a część niedociążona. Podob-
nie jak w przypadku serwerów, aby w pełni
czerpać korzyści z konsolidacji, potrzebu-
jemy zatem warstwy wirtualizacji dla zaso-
bów dyskowych.
Zarządzanie zasobami
W praktycznie każdym systemie, także nie
korzystającym z platformy PaaS, warto ko-
rzystać z mechanizmów ograniczania do-
stępu do zasobów pojedynczym użytkow-
nikom, czy aplikacjom. Użytkownicy nie
powinni odczuwać wyraźnego spadku wy-
dajności w sytuacji, gdy jeden z nich ge-
neruje skomplikowany raport. W tym wy-
padku baza danych powinna odpowied-
nio ograniczyć zasoby dostępne dla sesji
tego użytkownika, umożliwiając normal-
ną pracę pozostałym. Zarządzanie zasoba-
mi staje się jeszcze ważniejsze, gdy na jed-
nym fizycznym komputerze mogą działać
na przykład dwie maszyny wirtualne, każ-
da ze swoim systemem operacyjnym i ba-
zą danych, a każda z baz danych obsługuje
kilka różnych aplikacji. Jeśli nie zdefiniuje-
my odpowiedniej polityki przydziału zaso-
bów, nie będziemy w stanie zapewnić wy-
maganego poziomu świadczenia usług dla
poszczególnych aplikacji.
Cykl życia “chmury”
Jednym z głównych założeń cloud compu-
ting jest samoobsługa użytkowników. To
oni tworzą kolejne środowiska, gdy ich po-
trzebują, są odpowiedzialni za odpowied-
nie ich kategoryzowanie (test/produkcja),
żądają dodatkowych zasobów, jeśli wiedzą,
że będą potrzebne (w sytuacjach nieprze-
widzianych za taką rozbudowę odpowiada
już dostawca platformy) i wyłączają instan-
cje, których dłużej nie potrzebują. Dostawca
chmury PaaS, także prywatnej, musi zatem
zapewnić interfejs do zarządzania środowi-
skami klienta.
Rozliczanie
wykorzystania zasobów
Zgodnie z definicją, rozliczanie klientów
jest oparte o zużycie określonych zasobów.
Czynnikami wpływającymi na koszt korzy-
stania z clouda mogą być zarówno warto-
ści techniczne (czas procesora, zużycie sie-
ci, etc), jak i biznesowe – na przykład ilość
kampanii marketingowych przeprowadzo-
nych przy użyciu danej aplikacji. Moż-
na sobie łatwo wyobrazić sytuację, w któ-
rej dostępne są również różne taryfy, po-
dobnie jak to jest u operatorów telefonicz-
nych. Opłata składa się zwykle z części sta-
łej (abonamentu) oraz zmiennej – zależnej
od wykorzystanych zasobów. W celu mi-
nimalizacji kosztów zmiennych, koniecz-
na może się okazać optymalizacja aplikacji
– czynność, o której niestety wiele osób za-
pomniało w dobie wydajnych i często prze-
szacowanych serwerów (analizy pokazu-
ją, że średnie obciążenie serwerów rzadko
przekracza 20%).
Podsumowanie
Budowa prywatnej chmury Platform as a
Service pozwala osiągnąć cele, do których
dąży praktycznie każde przedsiębiorstwo
– skrócenie czasu od pomysłu do realizacji
(time to market), a co za tym idzie wzrost
przychodów. Konsolidacja sprzętu i licen-
cji oraz łatwa dynamiczna rozbudowa za-
pewnia jednocześnie niższe koszty utrzy-
mania, oraz brak konieczności ponoszenia
dużych kosztów na początku każdego pro-
jektu. Z punktu widzenia programisty, to
przede wszystkim likwidacja barier orga-
nizacyjnych i większa swoboda w korzysta-
niu z zasobów firmy, a jednocześnie mniej
czasu straconego na zarządzaniu środowi-
skami i mniej problemów wynikających z
różnic między nimi. Dobrze zrealizowana
platforma powinna zatem przynieść korzy-
ści wszystkim zainteresowanym.
MICHAŁ KURATCZYK
Principal solution architect, Oracle Polska
02/2010
 Programowanie C++

Fabryki obiektów
Techniki opisane w tym artykule pozwalają tworzyć obiekty na
podstawie identyfikatorów dostarczanych w czasie działania programu,
co jest wygodniejsze niż podawanie typów w formie zrozumiałej dla
kompilatora.

tworzyć obiekty na podstawie identyfikato-

Dowiesz się: Powinieneś wiedzieć:
• Jak tworzyć obiekty w C++; • Jak pisać proste programy w C++;
• Co to jest wzorzec fabryki. • Co to jest dziedziczenie i funkcje wirtualne.
Funkcje fabryczne
Przykład wykorzystania fabryki obiektów
Poziom został pokazany na Listingu 2, gdzie poka-
trudności zano funkcję create tworzącą obiekty klas
na podstawie danych zapisanych w strumie-
niu wejściowym, na przykład w pliku. Funk-
cja ta dostarcza obiekt odpowiedniego typu
ra, rolę tę pełni funkcja createObj. Po utwo-
rzeniu obiektu możemy wczytać składowe,
wykorzystując mechanizm funkcji wirtual-
nych, wołając metodę read dla utworzone-
go obiektu.
Przy zapisie obiektu do strumienia wyj-
ściowego (na przykład do pliku) nie potrze-
bujemy dodatkowych mechanizmów, któ-
re dostarczą identyfikator dla danego typu,
ponieważ możemy wykorzystać mechanizm
funkcji wirtualnych. Posiadając wskaźnik lub
referencję na klasę bazową, wołamy meto-
dę write, która zapisuje identyfikator klasy
konkretnej oraz jej składowe. Odczyt obiek-
tu jest o wiele bardziej złożony niż zapis ze

F
abryka obiektów jest klasą, której
obiekty pośredniczą przy tworze-
niu innych obiektów. Dostarcza-
na informacja jednoznacznie identyfiku-
je konkretny typ, znany w momencie kom-
pilacji, ale nie jest to literał, więc informa-
cja o typie jest nieodpowiednia dla kom-
pilatora, na przykład jest to napis lub inny
identyfikator. Fabryka ukrywa przed użyt-
kownikiem mechanizm zamiany identyfi-
katora na literał dostarczany do operato-
ra new, upraszczając tworzenie obiektów
(patrz Rysunek 1).
W języku C++ podczas tworzenia obiektu
należy podać konkretny typ w formie zrozu-
miałej dla kompilatora (patrz Listing 1). Nie
możemy posłużyć się mechanizmem funkcji
wirtualnych, nie możemy także przekazać
identyfikatora typu w czasie działania, argu-
mentem operatora new może być tylko literał
oznaczający typ znany w momencie kompila-
cji. Po utworzeniu obiektu można się do nie-
go odwoływać poprzez wskaźnik lub referen-
cję na klasę bazową, ale przy tworzeniu nale-
ży podać rzeczywisty typ obiektu, nie można
użyć mechanizmu późnego wiązania (funk-
cji wirtualnych).
konkretnego dla hierarchii Figure. Metody względu na to, że zapis posługuje się istnie-
zapisu (write) oraz odczytu (read) są do- jącymi obiektami, natomiast odczyt musi je
starczane przez każdą z klas konkretnych. tworzyć.
Jeżeli chcemy obiekt utworzyć (odczytać),
to typ obiektu jest dostarczany w czasie dzia- Fabryka skalowalna
łania, jest on wyznaczany przez identyfika- Funkcja createObj jest prostą fabryką obiek-
tor dostarczany przez strumień. Ponieważ tów, pozwala ona tworzyć obiekty na podsta-
tak dostarczany identyfikator nie jest ak- wie informacji, która jest dostarczana w cza-
ceptowany jako argument dla operacji new, sie działania, ale ma wiele wad: mapowanie
należy wykorzystać fabrykę, która pozwoli identyfikatora na typ za pomocą instrukcji
Listing 1. Podczas tworzenia obiektu należy podać typ w odpowiedniej formie
class Bazowa { /* ... */ }; //przykładowa definicja typu
class KonkretnaA : public Bazowa { /* ... */ };
Bazowa* p = new KonkretnaA; //przy tworzeniu trzeba podać konkretny typ
//nazwa typu musi być zrozumiała dla kompilatora
Szybki start
Aby uruchomić przedstawione przykłady, należy mieć dostęp do kompilatora C++ oraz
edytora tekstu. Niektóre przykłady korzystają z udogodnień dostarczanych przez bi-
bliotekę boost::mpl, warunkiem ich uruchomienia jest instalacja bibliotek boost (w wer-
sji 1.36 lub nowszej) Na wydrukach pominięto dołączanie odpowiednich nagłówków
oraz udostępnianie przestrzeni nazw, pełne źródła dołączono jako materiały pomoc-
nicze.

30 02/2010

switch sprawia, że funkcja ta jest zależna od
wszystkich klas w hierarchii, jeżeli będzie
dodawana lub usuwana jakaś klasa, to mody-
fikacji będzie musiał podlegać także kod fa-
bryki; brak kontroli przy wiązaniu identyfi-
katora z typem sprawia, że musimy zapew-
nić, aby przy odczycie obiektu korzystać z
tego samego identyfikatora co przy zapisie.
Poza tym, zestaw identyfikatorów jest zaso-
bem globalnym, przy modyfikowaniu zbio-
ru klas w danej hierarchii musi on podlegać
modyfikacjom.
Fabryka skalowalna, przedstawiona na
Listingu 3, umożliwia tworzenie obiektów
na podstawie identyfikatorów, wprowadza
mniejszą liczbę zależności w porównaniu
z poprzednio omówionym rozwiązaniem,
ponieważ jest ona zależna tylko od klasy
bazowej, a nie od wszystkich klas konkret-
nych. Mniejsza liczba zależności wynika z
zastosowania wskaźnika na funkcję two-
rzącą obiekty danej klasy konkretnej oraz
przez użycie dynamicznej struktury prze-
chowującej mapowanie pomiędzy identy-
fikatorem a typem.
Klasa konkretna woła metodę registerFig,
przekazując swój identyfikator oraz funkcję
tworzącą obiekty danej klasy. Metoda ta doda-
je element do kolekcji, można więc elastycznie
modyfikować zestaw klas, których obiekty bę-
dą tworzone przez fabrykę. Jeżeli chcemy usu-
wać wpisy, to należy zaimplementować meto-
dę unregister, która będzie usuwała elemen-
ty z kolekcji.
Tworzenie obiektów odbywa się w meto-
dzie create, która wyszukuje funkcję two-
rzącą dla danego identyfikatora. Jeżeli taka
funkcja zostanie znaleziona, to jest ona woła-
na (patrz Listing 3), a obiekt utworzonej kla-
sy jest zwracany.
Klasa konkretna musi dostarczyć funkcję
tworzącą obiekty, funkcja ta (patrz Listing 4)
może być umieszczona w module zawierają-
cym implementację klasy konkretnej, podob-
������ �������
���������������������
������
Rysunek 1. Tworzenie obiektów przez fabrykę
www.sdjournal.org
Fabryki obiektów
nie moduł ten może zawierać kod rejestrują- zanie bezpośrednie (wybór typu w zależno-
cy dany typ w fabryce, tak jak pokazano na ści od identyfikatora za pomocą switch lub
Listingu 4. łańcucha if ... else), ponieważ wymaga prze-
Fabryka skalowalna jest bardziej elastycz- chowywania kolekcji wiążącej identyfikator z
na, ale też bardziej kosztowna niż rozwią- funkcją tworzącą. Obiekt jest tworzony za po-
Listing 2. Przykład, w którym uzasadnione jest wykorzystanie fabryki
class Figure { //klasa bazowa
public:
enum Type { SQUARE, CIRCLE, /* ... */ };//identyfikatory klas konkretnych
virtual bool write(ostream& os) const = 0;//zapisuje obiekt
virtual bool read(istream& is) = 0;//odczytuje obiekt
};
class Square : public Figure {//jedna z klas konkretnych
public:
bool zapisz(ostream& os) {//zapisuje kwadraty
os << KWADRAT;//zapisuje identyfikator typu
//zapisuje poszczególne składowe
}
bool read(istream& is) {//odczytuje obiekt, zakładając, że jest to kwadrat
//odczytuje poszczególne składowe
}
};
//pozostałe klasy konkretne także dostarczają metody odczytu i zapisu
//...
Figure* createObj(istream& is) {//funkcja pełni rolę fabryki
Figure::Type type;
is >> type; //odczytuje identyfikator typu
Figure* obj;
switch(type) { //zapewnia mapowanie pomiędzy identyfikatorem a typem
case SQUARE://w formie zrozumiałej dla kompilatora
return new Square(); //tworzy odpowiedni obiekt
case CIRCLE: /* ... */
}
}
//tworzy obiekt na podstawie identyfikatora i odczytuje jego składowe
Figure* create(istream& is) {
Figure* obj = createObj(is); //tworzy obiekt odpowiedniego typu
obj->read(is);//obiekt istnieje, może wykorzystać funkcje wirtualne
}
Listing 3. Fabryka skalowalna
class FigFactory {
public:
typedef Figure* (*CreateFig)(); //wskaźnik na funkcję tworzącą obiekt
//rejestruje nowy typ
void registerFig(int id, CreateFig fun) {
creators_.insert( value_type(id, fun) ); //dodaje do kolekcji
}
//tworzy obiekt na podstawie identyfikatora
Figure* create(int id) { //tworzy obiekt danego typu
Creators::const_iterator i = creators_.find(id);
if(i ! = creators_.end() ) //jeżeli znalazł odpowiedni wpis
return (i->second)(); //woła metodę fabryczną
return 0L; //zwraca pusty wskaźnik, gdy nieznany identyfikator
}
private:
typedef std::map<int, CreateFig> Creators;
Creators creators_;//przechowuje powiązania pomiędzy identyfikatorem a funkcją
tworzącą
};
31
 Programowanie C++

średnictwem tej funkcji, więc tworzenie trwa Aby zaimplementować w pełni funkcjo- sze, problem dostarczania odpowiedniego
dłużej (jeden skok więcej w porównaniu z nalną fabrykę obiektów, należy uwzględ- obiektu fabryki wymaganego przy rejestra-
metodą bezpośrednią). nić dodatkowe zagadnienia. Po pierw- cji klas (na wydruku 4 została użyta funk-
cja getFactory). Często stosowanym roz-
Listing 4. Przykład funkcji tworzącej i rejestracji typu w fabryce wiązaniem jest singleton. Po drugie, należy
zarządzać czasem życia powołanych obiek-
Figure* CreateSquare() { //funkcja tworząca dla typu konkretnego tów, fabryka tworzy obiekty na stercie, ale
return new Square(); kto ma je zwalniać? W tym celu warto po-
}; służyć się sprytnymi wskaźnikami (patrz
FigFactory& factory = getFactory();//pobiera obiekt fabryki SDJ 11/2009). Kolejnym zadaniem jest
factory.registerFig(SQUARE, CreateSquare); //rejestruje się w fabryce wiązanie identyfikatora z typem, aby wy-
kluczyć możliwości pomyłek. Można od-
Listing 5. Fabryka skalowalna zarządzająca identyfikatorami powiedzialność dostarczania identyfika-
typedef shared_ptr<Figure> PFigure; //sprytny wskaźnik torów przenieść na fabrykę, obiekt ten ma
class FigFactory { może tworzyć unikalne identyfikatory, zaś
public: klasy, które są rejestrowane w fabryce, mo-
gą ten identyfikator przechowywać w skła-
typedef PFigure (*CreateFig)(); //wskaźnik na funkcję tworzącą obiekt dowej statycznej (patrz Listing 5). Obiekty
int registerFig(CreateFig fun) {//zwraca id zarejestrowanego typu klas będą wykorzystywały ten identyfika-
creators_.insert( value_type( currentId_, fun) ); tor podczas zapisu, natomiast fabryka wy-
return currentId_++; //zwraca identyfikator korzystuje go podczas odczytu.
} Inną możliwością jest generowanie identy-
PFigure create(int id); //tworzy obiekt danego typu (patrz Listing 3) fikatora przez mechanizmy kompilatora, na
przykład używając struktury type_id, wtedy
private: nie trzeba zarządzać nim w fabryce.
int currentId_; //kolejny wolny identyfikator Inicjacja fabryki skalowalnej (rejestracja
//składowe związane z funkcjami tworzącymi typów) może być uproszczona, jeżeli będzie
}; wykorzystywana kolekcja typów z biblioteki
FigFactory& factory = FigFactory::getInstance();//singleton boost::mpl (patrz SDJ 12/2009) oraz algoryt-
Square::id_ = factory.registerFig(CreateSquare); //ustawia identyfikator my, które na kolekcji operują( patrz Listing
6). Funkcja tworząca może być metodą sta-
Listing 6. Rejestracja klas w fabryce skalowalnej przez algorytm biblioteki boost::mpl tyczną klasy konkretnej, wtedy nie musi za-
class Square : public Figure { wierać nazwy tworzonej klasy. Takie rozwią-
public: zanie prezentuje Listing 6.

//każda klasa konkretna dostarcza metodę statyczną create Podsumowanie

static Figure* create() { return new Square; } Opisany sposób tworzenia obiektów na pod-
}; stawie identyfikatora dostarczanego pod-
czas działania programu jest jednym z wzor-
struct RegisterFigure { //szablon użyty do rejestracji ców kreacyjnych, termin został zapropono-
template<typename T> void operator()(T) { wany przez bandę czworga (Gamma, Helm,
T::id_ = Factory::getInstance().registerFig( T::create ); Johnson, Vlissides) w książce Wzorce projek-
} towe. Inne udogodnienia dotyczące tworze-
}; nia obiektów, takie jak fabryki prototypów
typedef mpl::vector<Square, Circle> Types; //kolekcja typów dla klas konkretnych i fabryki abstrakcyjne, są tematem jednego z
mpl::for_each< Types > ( RegisterFigure() ); //woła w czasie wykonania operację dla kolejnych artykułów.
każdego typu

W Sieci
• http://www.boost.org – dokumentacja bibliotek boost;
• http://www.open-std.org – dokumenty opisujące nowy standard C++.

ROBERT NOWAK
Więcej w książce Adiunkt w Zakładzie Sztucznej Inteligencji Insty-
Zagadnienia dotyczące współcześnie stosowanych technik w języku C++, wzorce projekto- tutu Systemów Elektronicznych Politechniki War-
we, programowanie generyczne, prawidłowe zarządzanie zasobami przy stosowaniu wy-
szawskiej, zainteresowany tworzeniem aplika-
jątków, programowanie wielowątkowe, ilustrowane przykładami stosowanymi w bibliotece
standardowej i bibliotekach boost, zostały opisane w książce Średnio zaawansowane progra- cji dla biologii i medycyny, programuje w C++ od
mowanie w C++, która ukaże się niebawem. ponad 10 lat.
Kontakt z autorem:rno@o2.pl

32 02/2010
 Programowanie gier
Jak napisać pierwszą
grę komputerową
Czyli najtrudniejszy pierwszy krok
Prawdopodobnie każdy gracz ma w głowie co najmniej jeden pomysł na
rewelacyjną grę. Niektórzy idą dalej i zakładają zeszyty w kratkę, których
strony zapełniają pomysłami i szkicami. Niestety w tym szczególnym
przypadku sam pomysł to zbyt mało i – bez konkretnych kroków – jest
niewiele wart.
Dowiesz się:
• Z jakich technologii możesz korzystać two-
rząc pierwszą grę;
• Czym jest prototyp;
• Jak zorganizować sobie pracę.
Poziom
trudności
T
rudno jest zainteresować poważną
firmę inwestycją w grę , przysyła-
jąc im zeszyt z pomysłem. Na pa-
pierze każda gra – choćby była oryginalna
i rewolucyjna – wygląda podobnie i, nie-
stety, zazwyczaj nieciekawie. Dzisiaj pro-
dukcja gry komputerowej to duży budżet
i wiele zaangażowanych osób. Mówimy tu
o co najmniej dziesiątkach tysięcy złotych
w przypadku małych gier, a milionach do-
larów w przypadku produkcji większych,
nie ma więc co się dziwić, że mało kto wy-
łoży pieniądze na realizację pomysłu jakie-
goś gościa z zeszytem. Zwłaszcza pamięta-
jąc, że gry to kapryśne produkty i czasem
nawet bardzo dobra produkcja może prze-
paść na rynku w wyniku niesprzyjających
okoliczności lub pecha (przykładowo Vam-
pire: The Masquerade – Bloodlines czy choć-
by Psychonauts).
Skoro widoki na to, że dyrektor znanej fir-
my podsłucha nasz pomysł w autobusie i od
ręki nas zatrudni, są marne, trzeba przejść
do planu B.
34
Powinieneś wiedzieć:
• co to gra komputerowa;
• … i jaką grę chcesz zrobić.
Na potrzeby niniejszego artykułu założy-
my, że nasz pomysł na grę to gra platformo-
wa, której bohaterem jest wściekła małpa.
Małpa zbiegła z miejskiego ZOO i teraz ści-
ga po mieście biznesmanów w garniturach,
aby zatłuc ich wielkim bananem. Grę robo-
czo nazywamy Monkey Business
Plan B, czyli „Wystarczy chcieć”
Plan B sprowadza się do tego, że musimy grę
wykonać sami. Pierwszym krokiem powin-
na być ocena naszych umiejętności i moż-
liwości. Jeśli jesteśmy akurat John’em Car-
mack’iem lub mamy szafę pełną pieniędzy,
to sprawa jest dosyć prosta. W innym przy-
padku musimy usiąść i zastanowić się, co
właściwie potrafimy.
Spisujemy wszystkie nasze umiejętno-
ści takie jak rysowanie, modelowanie gra-
fiki trójwymiarowej, projektowanie baz da-
nych, interfejsów baz danych, projektowanie
stron WWW, programowanie (w czymkol-
wiek) lub dowolną inną umiejętność powią-
zaną z szeroko pojętą informatyką. Nawet je-
śli lista jest bardzo krótka, nadal jest nadzie-
ja, nie poddajemy się. Kolejny krok to próba
dopasowania naszych umiejętności do kon-
kretnego projektu.
Jeśli planujemy grę handlową lub nawet
MMORPG (Massive Multiplayer Online Ro-
le Playing Game), a potrafimy tylko tworzyć
bazy danych, to możemy przyciąć nasz pro-
jekt tak, by dało się go zrealizować na bazie
danych lub tylko formularzu. Przykładem
bardzo wciągającej gry wykonanej napraw-
dę prostą metodą jest Drug Wars lub jej pol-
ski odpowiednik MaXDila 2000. Kilka pól
tekstowych i zabawa murowana na wiele go-
dzin.
Co możemy zrobić, gdy nie mamy żadne-
go doświadczenia w tworzeniu graficznych
interfejsów użytkownika i jedyne, co potra-
fimy, to wyświetlanie znaków ASCII? Może-
my zrobić grę oczywiście. Jest cały gatunek
gier Roguelike, czyli tak zwanych rogalików.
Są to gry naśladujące kultową grę Rogue (stąd
ich nazwa). Cała grafika reprezentowana jest
tu za pomocą znaków ASCII. Prostota repre-
zentacji wizualnej może być myląca – gry te
są często przerażająco złożone. Przykładem
może być ADOM lub Dwarf Fortress. Stwo-
rzenie gry w tak ubogiej oprawie graficznej
może przy okazji ujawnić słabe punkty sce-
nariusza lub mechaniki. Gdy nie ma nic, co
by nas rozpraszało, to właśnie fabuła i game-
play trzymają nas przy klawiaturze (lub kon-
trolerze).
W takim razie co robić, jeśli umiemy tyl-
ko rysować lub tworzyć modele trójwymia-
rowe? Paradoksalnie możemy się odprę-
żyć, jesteśmy w dosyć komfortowej sytu-
acji. Sieć jest pełna zdesperowanych progra-
mistów szukających grafików, którzy po-
mogliby skończyć ich projekt. Pozostaje tyl-
ko przekonać ich, że to właśnie nasz projekt
jest ciekawszy.
Oczywiście może się też zdarzyć, że kart-
ka pozostaje pusta, ponieważ nie posiada-
my żadnych umiejętności, które pomogły-
by nam w stworzeniu gry. W takiej sytu-
acji nadal nie wszystko jest stracone – wy-
02/2010

starczy bliżej zainteresować się narzędzia-
mi do tworzenia gier. Nie zawsze oferują
swobodę, jakiej oczekujemy. Nie zawsze są
wydajne. Mają jednak jedną ogromną zale-
tę, a mianowicie są proste w obsłudze i czę-
sto darmowe lub bardzo tanie. Dzięki temu
skupiają wokół siebie spore społeczności. To
z kolei oznacza, że dostępne jest bardzo du-
żo gotowych przykładów i poradników, jak
stworzyć własne gry, bazując na danym na-
rzędziu. Przykładem takiego narzędzia mo-
że być Game Maker.
Gdy umiemy trochę programować, po-
winniśmy rozważyć wykorzystanie istnie-
jącego silnika lub framework’a. Zawsze pa-
miętajcie, że gra to olbrzymie przedsięwzię-
cie i trzeba ułatwiać sobie życie jak się tyl-
ko da. Częstym błędem jest zabieranie się do
pisania własnego silnika, żeby potem na nim
stworzyć grę. Przypomina to trochę wywa-
żanie drzwi otwartych na oścież – jest wie-
le darmowych rozwiązań, które zaoszczędzą
nam miesięcy żmudnej dłubaniny. No chy-
ba że właśnie ta dłubanina wciąga was naj-
bardziej – wtedy twórzcie silniki i dzielcie
się nimi z innymi. Kto wie, może zostanie-
cie zauważeni.
W naszym przypadku lista jest krótka
– trochę doświadczenia z C++ i PHP. Po-
trafimy coś narysować w Gimp’ie, ale na
tym nasze zdolności artystyczne się, nieste-
ty, kończą.
Na tym etapie trzeba zdecydować, czy pi-
szemy grę dwuwymiarową, czy trójwymia-
rową. Większość z nas w pierwszym odru-
chu powie, że oczywiście trójwymiarową.
W tym przypadku jednak więcej nie za-
wsze znaczy lepiej. Jak powiedział Anto-
ine de Saint-Exupéry „wiesz, że osiągnąłeś
perfekcję w projekcie, nie, gdy nie masz już
nic do dodania, lecz gdy nie możesz już nic
uprościć”. Zastanówmy się , czy ten trzeci
wymiar jest rzeczywiście konieczny. Czy
bez niego gra nie będzie ciekawa? Czy me-
chanika nie może działać w dwóch wymia-
rach? Jeśli zdecydujemy się na realizowa-
nie gry w trzech wymiarach, musimy li-
czyć się ze znaczącym wzrostem nakładu
pracy i złożoności zadania. W przypadku
gry dwuwymiarowej do stworzenia grafi-
ki wystarczy usiąść do przysłowiowego „pa-
inta” na kilka minut i naszkicować sprite’a.
Może być nawet paskudnie brzydki – pro-
grammers art’y też mają swój urok i przede
wszystkim pozwalają zaprezentować pro-
jekt innym osobom. Oczywiście może-
my także skorzystać z ogromnej ilości gra-
fik dostępnych za darmo w sieci. Przykła-
dem może być Reiner`s Tilesets – zbiór do-
stępnych za darmo obiektów i tile’i do gier
w rzucie izometrycznym. Pewnym proble-
mem jest tworzenie przyzwoicie wyglądają-
cych animacji dwuwymiarowych. Koniecz-
www.sdjournal.org
Jak napisać swoją pierwszą grę komputerową
ne jest ręczne rysowanie kolejnych klatek,
co jest dosyć uciążliwe.
Pewnym ułatwieniem może być tworze-
nie grafiki wektorowej – rozwiązuje to pro-
blem niewprawnej drżącej ręki, pozwala wy-
pełniać kształty gradientami i ułatwia ani-
mowanie. Co prawda powstaje grafika fla-
szowa, ale lepszy rydz niż nic.
Taka grafika nie musi być grafiką docelo-
wą – może służyć tylko do przygotowania
prototypu gry, który będziemy chcieli – ce-
lem zachęcenia do współpracy – pokazać
wydawcy lub kolegom potrafiącym rysować.
Jednak w przypadku trzech wymiarów
sprawa się komplikuje. Żeby nasza gra za-
częła dobrze wyglądać, musimy stworzyć
model w jakimś programie do modelowa-
nia, takim jak darmowy Blender. Jednak
sam model to nie wszystko – raczej dopie-
ro początek. Jeśli będzie to obiekt animo-
wany, musimy przygotować animację. Ten
krok jest łatwiejszy niż animowanie ra-
strowych obiektów dwuwymiarowych ze
względu na wektorowy charakter modeli
trójwymiarowych (zakładając, że nie po-
rywamy się na nic niestandardowego jak
voxele).
Kolejna sprawa to pokrycie naszego
obiektu barwą, czyli stworzenie tekstu-
ry. Musimy namalować obraz dwuwymia-
rowy, który zostanie zmapowany na po-
wierzchnię obiektu trójwymiarowego.
Można więc powiedzieć, że i tak musi-
my wykonać pracę, której wymagałaby na-
sza gra, gdybyśmy zdecydowali się na gra-
fikę dwuwymiarową. W zależności od te-
go, na jak złożone efekty specjalne i oświe-
tlenie się decydujemy na tym etapie, może-
my skończyć prace nad modelem lub jesz-
cze wygenerować mapy normalnych, ma-
py nierówności, mapy odbić i co tylko nam
przyjdzie do głowy.
Oczywiście możemy znaleźć darmowe
modele trójwymiarowe w sieci. Jednak
doświadczenie uczy, że dużo trudniej jest
znaleźć odpowiadający nam model trójwy-
miarowy niż bitmapę dwuwymiarową. Na-
wet gdy znajdziemy odpowiedni obiekt,
może okazać się, że nie posiada on wszyst-
kich map, których potrzebujemy lub jest
wykonany w sposób uniemożliwiający wy-
korzystanie z naszymi metodami wyświe-
tlania.
W naszym konkretnym przykładzie naj-
rozsądniejszym rozwiązaniem wydaje się
być grafika dwuwymiarowa. Gry platfor-
mowe jako gatunek kojarzone są z dwuwy-
miarowymi planszami. Dzięki uproszcze-
niu świata gry będziemy mogli szybciej za-
implementować zasady rozgrywki i skupić
się na dodawaniu ekstra funkcjonalności
takiej, jak rzucanie bananem w odległych
przeciwników.
Podstawowymi elementami, znajdujący-
mi się w większości gier, są:
• silnik graficzny odpowiedzialny za wy-
świetlanie gry;
• biblioteki odpowiedzialne za odgry-
wanie efektów dźwiękowych oraz mu-
zyki;
• silnik symulacji fizycznej;
• skrypty;
Jeśli planujemy stworzenie gry dwuwy-
miarowej , warto zainteresować się PopCap
Games Framework. Framework ten jest
bardzo kiepsko udokumentowany (garść
dokumentów opisujących ogólne zasady
działania), jednak jego prostota rekompen-
suje wszelkie wady. Nawet niewprawny
programista po przejrzeniu przykładów
dostarczonych wraz z kodem źródłowym
może napisać prototyp gry platformowej
(lub dowolnej innej) w dosłownie kilka go-
dzin. Framework zapewnia wszystko, cze-
go potrzeba do stworzenia gry dwuwymia-
rowej. Znajdziemy tu parser XML’a, obsłu-
gę rejestru, dźwięku oraz animacji. Two-
rzenie interfejsu użytkownika jest stosun-
kowo proste i już na starcie dysponujemy
praktycznie wszystkimi potrzebnymi kon-
trolkami. Nic, tylko siadać i pisać. Oczy-
wiście im głębiej w las, tym więcej drzew
– framework nie jest pozbawiony wad. Nie
powinny one jednak przeszkadzać w two-
rzeniu pierwszej gry. Nie musimy ograni-
czać się do PopCap’a – jest wiele innych
bardzo dobrych bibliotek i framework’ów
wspomagających tworzenie gier dwuwy-
miarowych – chociażby SDL, Allegro czy
Blitz2D.
W przypadku gdy decydujemy się reali-
zować nasz projekt w trzech wymiarach,
wybór jest jeszcze większy. Możemy zdecy-
dować się na silniki graficzne takie jak Irr-
licht lub Ogre. Jako że są to silniki graficz-
ne same w sobie nie oferują żadnej funkcjo-
nalności poza wyświetlaniem sceny. Tu z po-
mocą przychodzą społeczności powstałe wo-
kół tych projektów. Z łatwością znajdziemy
dodatkowe narzędzia ułatwiające budowa-
nie silnika gry.
Ponieważ zdecydowaliśmy się na reali-
zację naszej gry w dwóch wymiarach, wy-
bieramy framework PopCap. Pozwoli to
nam bardzo szybko stworzyć pierwszą wer-
sję gry.
Do obsługi dźwięku możemy wykorzy-
stać gotowe biblioteki, takie jak FMOD lub
OpenAL (Open Audio Library). Pierwsza
z nich jest biblioteką komercyjną. Jeśli bę-
dziemy chcieli sprzedawać naszą grę, musi-
my liczyć się z kupnem kosztownej licen-
cji – nawet do kilku tysięcy dolarów. Jeśli
jednak nasza gra ma być produktem dar-
35
 Programowanie gier
mowym, możemy korzystać z FMOD bez-
płatnie.
Tym, którzy od komercyjnych bibliotek
dostają wysypki, na pewno przypadnie do
gustu OpenAL. Jest to biblioteka w peł-
ni open source, rozwijana przez społecz-
ność na wzór OpenGL (choć nie w tak sko-
ordynowany sposób). Dzięki temu nazew-
nictwo i konwencje nazw przypominają
OpenGL.
Wybrany przez nas framework PopCap
posiada moduły odgrywające dźwięk, jed-
nak decydujemy się na zaimplementowa-
nie własnego modułu wykorzystującego bi-
bliotekę OpenAL. Jest darmowa i oferu-
je dźwięk przestrzenny, co jest dla nas bar-
dzo ważne. Przecież chcemy, żeby odgłos
banana uderzającego w biznesmana dobie-
gał dokładnie z miejsca, w którym znajdu-
je się małpa i brzmiał inaczej w zależności
od otoczenia.
Kolejnym ważnym elementem naszej
gry mogą, lecz nie muszą, być skrypty.
Zaimplementowanie silnika skryptowego
może nam pozwolić na przeniesienie czę-
ści logiki poza kod. W szczególności po-
zwoli to na modyfikowanie parametrów i
zachowań obiektów w świecie gry bez ko-
nieczności rekompilacji silnika. Nie każda
gra wymaga implementowania skryptów
– na pewno nie będą potrzebne w prostej
platformówce czy grze logicznej. General-
nie wszędzie tam, gdzie mechanika gry jest
powtarzalna i nie występują nieprzewidzia-
ne zdarzenia, skrypty są zbędne. Będą za
to niezastąpione w grach role-playing lub
przygodówkach.
Dwa języki, które można polecić, to z
pewnością Lua oraz Python. Prawdopodob-
nie lepszym rozwiązaniem (przynajmniej na
początek) będzie wykorzystanie Lua. Jest to
język skryptowy projektowany z myślą o in-
tegracji z C lub C++. Jest bardzo lekka, szyb-
ka i prosta do opanowania. Te cechy spra-
wiają , że jest bardzo popularna wśród twór-
ców gier.
Nasz projekt nie wymaga silnika skrypto-
wego. Co prawda rozważaliśmy dodanie nie-
standardowych zachowań planszy takich jak
walące się budynki czy załamujące się pod
małpą kładki dla pieszych. Jednak po do-
kładnej analizie doszliśmy do wniosku, że
takich zdarzeń będzie niewiele i szybciej bę-
dzie zaprogramować je na twardo niż imple-
mentować skrypty. Nie ma sensu wytaczać
artylerii na muchę.
Ostatnim wartym rozważenia elemen-
tem jest wykorzystanie biblioteki symula-
cji fizycznej. Nie powinniśmy dać się po-
nieść modzie na symulowanie wszystkie-
go. Musimy się zastanowić , czy nasza gra
potrzebuje symulacji fizycznej. Jeśli to
przygodówka, to pewnie nie. Gry, w któ-
36
rych często dochodzi do interakcji z oto-
czeniem w trudny do przewidzenia spo-
sób, takie jak różnego rodzaju strzelanki
lub symulatory wyścigów, prawdopodob-
nie skorzystają na zaimplementowaniu
symulacji fizycznej. Do wyboru jest bar-
dzo dużo zarówno komercyjnych, jak i dar-
mowych rozwiązań. Popularniejsze biblio-
teki open source to Open Dynamics Engi-
ne (ODE), Bullet, Tokamak. Spośród po-
zostałych rozwiązań warto wymienić Ha-
vok, PhysX oraz Newton Game Dynamics.
Praktycznie wszystkie te silniki pozwolą
nam zaimplementować realistycznie za-
chowujące się bryły sztywne, efekty czą-
steczkowe oraz efekt rag-doll (wykorzysty-
wany do symulowania realistycznie padają-
cych bezwładnych ciał).
W naszej grze zdecydowaliśmy się wyko-
rzystać silnik ODE. Użyjemy go, by zasymu-
lować realistyczne upadki postaci trafionych
bananem oraz różne przedmioty, które mał-
pa może przewrócić. Takie smaczki nie bę-
dą miały wpływu na rozgrywkę, jednak bę-
dą dawały graczowi dużo satysfakcji z poko-
nania wroga i sprawią, że plansza będzie bar-
dziej interaktywna.
Możemy także zdecydować się na kom-
pleksowe rozwiązanie i wykorzystać gotowy
silnik gry. Tu wybór jest bardzo duży. Więk-
szość silników dostarczana jest wraz z narzę-
dziami i edytorami pozwalającymi w wy-
godny sposób projektować gry. Minusem za-
stosowania gotowego silnika będzie oczywi-
ście utrata elastyczności , jaką daje nam na-
pisanie własnego silnika dopasowanego do
naszych potrzeb. Może się jednak okazać,
że znajdziemy silnik doskonale pasujący do
wizji naszej gry. Warte uwagi pozycje to To-
rque Game Engine, Blitz3D, Unity i id Tech
od 1 do 3 (silniki , na których powstał Do-
om, Quake 2 oraz 3), Virtools czy Blender
Game Engine. Niektóre z wymienionych
silników pozwalają na tworzenie gier prak-
tycznie bez pisania kodu – w VirTools mo-
żemy dosłownie składać grę z klocków meto-
dą drag and drop.
Prototyp
Bez względu na to, jaki silnik zdecyduje-
my się wykorzystać, pierwszą rzeczą, któ-
rą stworzymy, powinien być prototyp na-
szej gry. Prototyp jest to bardzo prosta wer-
sja gry pozwalająca zapoznać się z mecha-
niką rozgrywki i ją przetestować. Najczę-
ściej opiera się na bardzo prostych elemen-
tach graficznych i powinien pozwalać gra-
czowi na zagranie w grę i jej wygranie (lub
przegranie). Jeśli piszemy grę przygodową,
prototyp powinien być jedynym zadaniem,
które postać musi wykonać – na przykład
wydostać się z celi, wykorzystując znale-
ziony pod pryczą widelec. Jeśli nasza gra
będzie strzelanką, w prototypie powinni-
śmy móc strzelać i niszczyć wrogów. Ce-
lem może być dotarcie żywym do określo-
nych drzwi.
Generalnie prototyp powinien powstać
w kilka dni, a w idealnej sytuacji godzin.
Jeśli w ciągu tygodnia nie jesteśmy w sta-
nie ukończyć prototypu ,może być to ważna
wskazówka, że nasz projekt jest zbyt obszer-
ny jak na nasze możliwości i trzeba zrewido-
wać plany. Może na początek warto stwo-
rzyć prostszą grę, którą będziemy potem
rozszerzać o nową funkcjonalność? Tak czy
inaczej bardzo ważne jest , abyśmy jak naj-
szybciej mogli zobaczyć efekty swojej pracy
w postaci działającej gry. Da nam to siłę i mo-
tywację do dalszej pracy!
Dzięki prototypowi stosunkowo wcze-
śnie możemy stwierdzić , czy nasza gra jest
interesująca i czy nasze pomysły faktycznie
sprawdzają się. Jeśli nie – oszczędziliśmy
właśnie sporo czasu. Jeśli tak – możemy od
razu sprawdzić, czy wymyślone sterowa-
nie sprawdza się, czy interfejs jest czytelny
i tak dalej. Możemy też pokazywać proto-
typ ewentualnemu inwestorowi lub współ-
pracownikom (na przykład grafikowi ,któ-
ry zachwycony wciągającą rozgrywką przy-
gotuje nam profesjonalną oprawę wizual-
ną). Taki prototyp możemy pokazać w sieci
i próbować ewentualnie zwerbować pomoc
do naszego projektu. Jeśli nie możemy po-
chwalić się działającą wersją gry, zostanie-
my potraktowani w najlepszym razie jak
marzyciele i zachęceni do dalszych prac.
Takimi miejscami w sieci ,gdzie możemy
podzielić się naszymi doświadczeniami
lub skorzystać z wiedzy i doświadczenia
innych przy pisaniu gier, jest na przykład
GameDev.net lub nasz rodzimy Warsztat
(www.gamedev.pl).
W naszym idealnym przypadku wokół
naszego projektu powstaje prężna społecz-
ność zdolnych ludzi nienawidzących biz-
nesmenów w garniturach, ale lubiących
rzucać bananami. Szybko powstaje fanta-
styczna komiksowa oprawa graficzna i gra
podbija serca graczy. A druga część także
portfele.
Pozostaje życzyć powodzenia w zmaga-
niach z pierwszą grą!
KONSTANTY KALICKI
Opiekun specjalizacji Programowanie Gier Kom-
puterowych na PJWSTK
epg@pjwstk.edu.pl
02/2010
 ������������������
��������������������
������������
�������������������������������������������������������������������
�������������������������������������������������������������������
����������������������������������������������������������������������������
��� ��������� �������� �� �������� ������������ ������ ��� ��� ��������
����������������������������������������������������������
������������
��� ���������������������������������
��� �����������������������������������������
�����
��� ��������������������������
�������
���������
�
��� ������� ����� ��� ������ �������
������������� �������� ������ ������
������ ������ ������������� �����
����������������������������������������������
������������������������������������������
��������������������������������������������
������������ ��� ��� ��� ���������� �������� ����
����� ������� �� ����� ����� ����������� ���� �����
�������������� ��������� �������� ��������
�����������������������������������������
�������������������������������������������
�������������������������������������������
��������� ��� �� ���� ������� ��� ���������
���������� ����� ������������ �����������
����� ������� ����� ������������ ��� ����������
�����������������������������������������������
����������������������������������������
��������������������������������
��������� ����������� ����������� �����
���� ���������� �� ������� ������������ �������
��� ���������� ������ ���������� ������ ������
������ ����������� ��� ������� ������� �������
����� ��� �������� ��� ������ ����� �����������
����� ����� ���������� �� ������� ���������
��� �������� ����������� �� ������� ��� �������
����������������������������������������
��� ��������� ��� �������� ��� ��������������
��
��������������������
��� ����������������������������������������
�����������������������
������������������������������������������
��������������������������������������������
����������������������������������������
��������������������
��� ������ �������� ������ ����� ��������� ��� ��
����������������������������������������
��� ������ �������� ������ ����� ������������ ��� �����
������� ���������� �������� ���� ������ ���
���������������� �������� �� ��������� ������
�����������������������������������������
��������������������������������������������
�������������������������������������
������������������������������������������
������������������������������������������
�����������������������������������������������
����������� �� ����������� ��������������� ����
����� ������� ��� �������� ������� ��������� ���
����� ���� ������������ �� ���������� ��������
���������������������������������������������
�� ������� ����������� ������ ��������� ���������
��������� ��� �� ��������� ��� ������� ������
�����������������������������������������
������� ����������� ����� �� ������� �������
�����������������
������������ ������ ��������� ��� ��������
�������������������������������������������
�������������������������������������������
���� ��������� ���������� �� ����������� �� ��
���� ��������������� ����������� ���� ���������
�����������������������������
��������� �������������� ��������� ��� ���
����������� ���� ����� ���������� ������ ������
�������� ���� ������������� �������� �� �����
�������������������������������������������
���������� ��������� ��� ��� ���������������
��������� ����� ������ ��������� �����������
��������������������������������������
��������������������������������������������
������ ������� ��� �� ��������� ����������
�������� ���������� ������������ ���� ������
�������������������������������������������
��� ���������� ���������� �� ���� ������� ���� �����
��������� ���� �������� ���������� �� ����������
�������������� �������� ������ ���������� ���
���� ������� ��� ����������� ��� ����������� ����
�����������������������������������
��������� ������������� ��������� ��� ������
�����������������������������������������������
�������������������������������������������
����� �������� �������� �� ��������� �����������
��������������������������������������������
���������� �� ������� ������� �� ����������������
������������������������������������������
��������������������������������������������
��� ������� �� �������������� ���� ���������
��������������������������������������������
���������������������������������������������
��������� ���������������������� �� ������������
�������������������������������������������
������������������������������������������
��������������������������������������������
���������������������������������������������
���������������������������������������������
�������������������������������������
�������
����������������������������������������������
���������������������������������������������
�����������������������������������������������
�������������������������������������������
��� ������ ��������� ��� ����������� �� ������ ��
���������������������������������������������
����������������������������������������������
������������������������������������������
������������ ���������� ��������� �������������
���������������������������������
���������������������������������������
�������������������������������������������
�������������������������������������������
������������������������������������������
�����������������������������������������������
��������������������������������������������
���������������������������������������
�����������������
������� ������ ��������� ����� ���������
������������
���������������
������
����������������������������������������
�������������
��������������������������������������
���
����������������������
����������������������������
����������������������������������������
���������������������������������������������
�������������������������������������������
�������������������������������������������
���������������������������������������������
�������������������������
��� ������ ��������� ������������ �������� �����
������� ���������� ����� ���������������
��������� ��� ������� ������� ��� ������ �����
���������������������������������������
��������������������������������������
����
��� ����������������������������������������������
�������������� ����������� �� �����������
�������������������������������������
��� ������� ����� �������������������
���������������������������������������
�����
�������������������������������������������
����������� ������� ��� ������� �������� ���
���������� ����� ���������� �������� �������
������ ������ ������� ����������� �� ������
����� �� ���������� ���� �������� ������������

���������������������

�������� ��������������������� �������������

��� ����� �� ������������������ ��
�����������������������������
�� ������������� �� ������ ����
�������������������������
����
���������������������������� �������������
���
���
���

���������������������

�������� ������������������������������������ �������������

��� ���� ������������� �� ���������� ��
�� ������������� �� ������� ����
����������������������������������
���
���
�������� �������� �� ������������ ��
��� ����� �� ������������������ ��
�����������������������������
�� ������������� �� ����������� ������������������������������
�������������� ����
����������������������������������������
�����
���
���
���
���

����������������� ��
 ������������������
���������������������������������������������
��������� ������ ��������� ������ �������� ����
�����������������������������������������
��� ��� ��������� ����������� ������������ �����
�����������������������������������������
��������������������������������������������
����� �� �������� ������� ����� �������� ������
�������������������������������������������
��������������������������������������������
������������������������������������������
�������������������������������������������
�����������������������������������������
�������������������������������������������
�����������������������������������
�� ����������� ����� ����� ��� ����������
���������������������������������������������
����������������������������������������������
����� ��������� ������ ��� ������� ������ ��������
��������������������������������������������
��� ������������ ��������� ���� ��������� �����
���������������������������������������������
�������������������������������������������
��������������������������������������������
���������������������������������������������
����������� ������������� ������� ���������
��������������������������������������������
���� ��������� �������� ����������� ��� ��������
������������ ���������� ���� ���������� ��������
���������������������������������������������
���������������������������������������������
������������������������
��� ������ ������������ ��� �������� ��� ������
������������ �������� ����� ����������� ����
�������� ������ ����������� �������� �����
�������� ����� ���������� �������������
�����������������������������������������
�������������������������������������
�����������������������������������������������
����������
��
��������� �� ���������� ���� ��������� ������
������������������������������������
��� �����������������������������������������
����������������������������������������
����������� ��������� ��� ���������� ����
�������������� ������������� �������������
���������� ��� ������������ ��������� ��
�����������������������������������������
���������� ���� ��������� ���� �������� �����
�������������������������������
������������� ���� ������ ����� ��������� ���
�������� ��������� ���� ����� ������� �����������
��������� ����� ������ ����������� ���������
����������������������������������������
��� ��������� �� ����� ������� ����� �� ����� ���
����������� ���������� ������������ �� ����
���� ����� ���� ������ ��������� �������� �� ���
�������������������������������������
��������������������������
��� ������ �� ������ ������� ��� �������� �����
���������������� ������ ����� �� ������� ���
����������������������������������������
�� ��������� �������� ��������� ��������
���������������������������������
�����������������������������������������
�������������������������������������������
��� ������ �������� ��������� ����� ����������
����� ������������ ��������� ���������������
�����������������������������������������
�����������������������������
�������������������������
�������������������������������������������
���������������������������������������������
�������� �� �������� ��������� ����� ����������
���� �� ������ ��������� ���� ������ �����������
��������������������
��������������
������������������������������
� �������������������������������������������
���������� ������ ��������� ��� �������� ������
��������������
����������������
���������
� ���������������������
���������������������������������������
��� ����������� ������� ������� �����������
��������������
��� ��������� �� ������� ������� �����������
���������������
��� �������� �� ��������� ������� ���������
��������������������������������������
��� �������� �������� ����� ���������� �����
����������������������������������������
����������������������������
��� ������� �� ������� ������� �����������
�������� �� ���� ����������� ��� ��������� ����
�������� ������� �������� ������ ����������
��������������
������������ ���� ���������� ���������� �����
�������������������������������������������
����� ����� ����� �������� ��� ��������� ����� ����������
����������������� �����������������������������
�����������������������������������������������
������������������������������������
�� ���������� ���������� �������� ��������
������� ���������� ����� ������� ������������ ���
��������������������������������������������
��������������������������������������������������
��� �������� ��� ������ ��������� ��� �����������
����������������������������������������������
����������������������������������������������
������������������ �������� ��������� �����
�������������������������������������������������
����������������������������������������
�������������������������������������
�������������������������������������������
����������������������������������������������
������������������������������������������������
������������������������������������������������
������������������������������������������������
��������������������������������������������
�������������������������������������������������
�����������������������������
��������������������������������������������
������������ �������� ��������� ��������� ���
������ ������ �������� �� ����������� �����������
������������������������������������������������
��������� ������� ���� ���������� ��������������
��� ���� ��� ��������� �������������� �������
����� ����� ������� �������� ���� ��� �������������
���� ������������� ������� ��� �� �������� ����������
��������� ������������� ����� �� ������������ ���
�������� ���� ���� �� ���������� ����������� ���
������������������������������������
����� �� ��������� ��������� ����������
���������� ���� ������� ��� ��������� ������ ���
��������������������������������������������
���� �������� ������� ����� ��������������� ����
���������� ������������ �� �������� ��������
��������������
����� ������������� ��������������� ��������
����� ����������� ������� ���������� ����� ��������
������� ��� ���������� ��������� �� ��������� �� ����
����������������������������������������������
��� ����������� ������������ �� ������ ��������
���������������������������������������������
������ ��������������� ���������� ���������� ���
��������������� ������� ������ ����� ������������
���������������������������������������������������
�������������������������������������������������
����� �������� �� ������� ������ ����������� �������� ����
���������������������������������������
�������
������������������������
 Programowanie gier
Mapy kafelków
w grach 2D
Wstęp i rysowanie
Marzysz o stworzeniu swojej wymarzonej dwuwymiarowej platformówki
albo klasycznego RTSa? Od czego zacząć? Oczywiście od map kafelków
(ang. tiled maps). Dzięki temu artykułowi poznasz podstawy tej techniki
– dowiesz się, jak mapy kafelków zaprogramować i jak je rysować.
Dowiesz się:
• W jaki sposób działają mapy kafelków (ang.
tiled maps);
• Jak rysować mapy kafelków;
• Jak zastosować kilka sztuczek optymaliza-
cyjnych.
Poziom
trudności
A
rtykuł ten poświęcony jest jednej
z podstawowych technik używa-
nych do tworzenia dwuwymia-
rowych gier – mapom kafelków (ang. tiled
maps). Metoda ta używana jest z powodze-
niem od bardzo dawna, a z jej użyciem po-
wstało dużo świetnych gier. Mimo iż w dzi-
siejszych czasach może wydawać się trochę
archaiczna, to stanowi świetny punkt wyjścia
w nauce programowania gier, a także ciągle
doskonałą i stosowaną technikę w programo-
waniu na urządzenia o ograniczonych zaso-
bach, np. telefony komórkowe.
Artykuł wprowadza w świat map kafel-
ków, a następnie przedstawia sposoby ich
implementacji. Kolejnym zagadnieniem bę-
dą układy współrzędnych używane w ma-
pach oraz prosta metoda ich rysowania.
Temat rysowania zostanie następnie roz-
szerzony o rysowanie z buforem. W artyku-
le znajdzie się też kilka sztuczek optymali-
zacyjnych.
Tekstowi będą towarzyszyć Rysunki i
Listingi. Listingi pełnią rolę koncepcyj-
ną – będą to fragmenty pseudokodu ma-
42
Powinieneś wiedzieć:
• Podstawowa znajomość C++ i biblioteki SDL
lub podstawowa znajomość Javy.
jące zobrazować pewne zagadnienia. Jako
że kompletny, przykładowy kod też jest do-
brym źródłem informacji, do artykułu do-
łączona jest prosta implementacja opisywa-
nego materiału. Jest ona stworzona w Javie
(Micro Edition, projekt w NetBeans) oraz
C++ (SDL, projekt w Visual C++ Express
2008). Wszystkie narzędzia potrzebne do
uruchomienia dołączonego kodu dostępne
są za darmo.
Wykafelkuj sobie świat
Wyobraźmy sobie, że chcemy stworzyć pro-
gram, powiedzmy grę, w którym będzie wy-
stępował pewien dwuwymiarowy świat.
Chcemy, by po tym świecie mogła poruszać
się postać sterowana przez gracza. Oczy-
wiście świat musi być widoczny, więc bę-
dziemy go rysować na ekranie. Świat powi-
nien być dość duży, na pewno większy niż
ekran. Oglądać go będziemy z boku (al'a Ma-
rio Bros) bądź z góry (al'a klasyczne RTSy).
Chcemy, żeby różne fragmenty świata mia-
ły różny wygląd i różne właściwości (np. że
coś jest z cegieł albo z trawy, że po czymś
gracz może się poruszać, a po czymś nie itp.)
A do tego chcemy takich światów mieć kil-
kanaście, np. jako różne plansze w grze. Jak
to zrobić?
Istnieje wiele różnych technik. Podzielo-
ny jest ogólnie na dwie grupy – rastrowe i
wektorowe (pikselowe i geometryczne).
W skrajnej formie wersji rastrowej może-
my narysować cały świat jako jeden ogrom-
ny obrazek. W wersji wektorowej cały świat
reprezentowany jest przez np. zbiór wielo-
kątów. Oba podejścia różnią się m.in. zuży-
ciem pamięci, mocą obliczeniową potrzeb-
ną do rysowania, złożonością algorytmów,
dokładnością, z jaką możemy tworzyć ele-
menty świata, czy łatwością ich tworzenia i
modyfikowania.
Podejście typu wielki obrazek pociąga za so-
bą ogromne zużycie pamięci, ale za to ryso-
wanie w tym przypadku jest szybkie i pro-
ste. Wystarczy narysować na ekranie widocz-
ny fragment obrazu-świata. W każdej chwili
możemy dodać (dorysować) nowy element
lub szczegół. Z drugiej strony, jeśli naraz chce-
my zmienić wygląd dużej części świata, trze-
ba go mozolnie przerysować. Trzeba także wy-
myślić sposób przypisania różnych cech róż-
nym obszarom świata.
Wersja geometryczna to najczęściej mniej-
sze zużycie pamięci, ale wymaga znacznie
większej mocy obliczeniowej przy rysowa-
niu, a samo rysowanie trudniej jest zaim-
plementować. Dodanie nowych elementów
świata wymaga dodania nowych wielokątów
lub edycji istniejących. Wraz ze wzrostem
złożoności i ilości geometrii coraz trudniej
połapać się w edycji świata. Plusem tego po-
dejścia jest łatwość nadawania cech obsza-
rom świata – możemy na przykład przypi-
sać cechy wielokątom lub stworzyć specjal-
ne kształty, które nie będą rysowane, a bę-
dą służyć jedynie do opisywania cech wybra-
nych obszarów.
Istnieje jednak technika, która wpasowu-
je się gdzieś pomiędzy te skrajne podejścia.
Z jednej strony opiera się na rysowaniu przy
użyciu obrazków, ale jednocześnie pozwala
na wyodrębnienie poszczególnych fragmen-
02/2010
 Mapy kafelków

tów świata, operowania na nich i nadawania pewnych obiektów. Mogą to być przeciwni- Tak naprawdę, przedstawiony powyżej po-
im cech. Do tego dochodzi małe zużycie pa- cy czy przedmioty, które gracz może zbie- dział jest dość umowny, niektóre informacje
mięci oraz łatwość i szybkość rysowania. Z rać. Mogą to też być obiekty niewidoczne, można zaliczyć do kilku grup. Najważniej-
drugiej jednak strony odbywa się to kosztem np. punkt startowy planszy czy punkt na- sze jest, aby pamiętać, że kafelek może prze-
dokładności i szczegółowości, z jaką może- wigacyjny dla algorytmów sztucznej inteli- chowywać dowolne informacje dotyczące je-
my tworzyć świat. Technika ta opiera się na gencji. go obszaru.
przedstawieniu świata za pomocą mapy kafel-
ków (ang. tiled maps).
Idea jest prosta – nakładamy na świat
siatkę (jak w zeszycie w kratkę) i dokonu-
jemy podziału na prostokątne lub kwadra-
towe fragmenty, zgodnie z liniami siatki.
Fragmenty będące wynikiem podziału bę-
dziemy nazywać kafelkami. Wszystkie ka-
felki mają te same rozmiary i sąsiadując ze
sobą, pokrywają całą powierzchnię świa-
ta. Każdy kafelek ma przypisany obrazek
(wszystkie kafelki używają obrazków o ta-
kich samych rozmiarach) oraz dowolne pa-
rametry opisujące obszar zajmowany przez
tafelkę. Nadając wygląd i cechy fragmen-
tom świata, możemy zmieniać tylko po-
szczególne kafelki.
Rysunek 1 pokazuje dwuwymiarowy bar-
dzo szczegółowy świat oraz jego wersję ska-
felkowaną.

Informacje
umieszczone w kafelku
Kafelek stanowi podstawowy element ma-
py. Jest on prostokątem (często kwadratem,
ale nie jest to reguła) zawierającym informa-
cje na temat fragmentu powierzchni świata,
który pokrywa. Są to całkowicie dowolne in-
formacje, sami musimy określić, co jest nam
potrzebne. Można wyróżnić kilka grup ta-
kich informacji: wizualne, fizyczne, rozgryw-
kowe, obiektowe.
Informacje wizualne opisują wygląd ka-
felka i są używane przez algorytmy rysujące.
Może to być obrazek do wyświetlenia w miej-
scu, gdzie znajduje się kafelek, może to być
informacja, że kafelek jest niewidoczny, mo-
że to być kolor (np. jeśli chcemy, aby kafelek
był jednolicie wypełniony kolorem).
Informacje fizyczne zawierają cechy uży- Rysunek 1. Dwuwymiarowy świat i jego reprezentacja z użyciem kafelków. Zaledwie dziesięć kafelków
wane w procesie symulacji świata gry. Na pozwoliło na dość wierne odwzorowanie
przykład, czy gracz może przejść przez kafel-
ka, czy może go zniszczyć, jego wytrzymałość
na uderzenia, śliskość jego powierzchni (może
wpływać na ruch gracza), wartość i kierunek
siły grawitacji itp.
Informacje rozgrywkowe to wszelkie in-
formacje specyficzne dla mechaniki i zasad
naszej gry. Na przykład, ilość życia, jaką tra-
ci gracz wchodząc na kafelka, dozwolony czas
przebywania na kafelku (powiedzmy, że po
tym czasie gracz ginie), czy kafelek został od-
wiedzony (np. jeśli chcemy, żeby gracz musiał
dotrzeć do pewnych wyznaczonych miejsc w
świecie).
Informacje obiektowe najczęściej dotyczą Rysunek 2. Mapa (z lewej) i ekran (z prawej). Na czerwono zaznaczony jest viewport; znajduje się on
występowania w miejscu położenia kafelka zarówno w mapie, jak i na ekranie

www.sdjournal.org 43
 Programowanie gier

Warto też zauważyć, że cechy kafelka nie

Listing 1. Reprezentacja przykładowego kafelka przez klasę; pseudokod muszą być liczbami. Na przykład zamiast
class Tile trzymać ogólną informację, czy przez kafel-
{ ka można przejść, można przechowywać ob-
short imageId; // id of an image used to draw a tile szar kolizyjny (np. w postaci wielokąta). W
boolean isSolid; // if true – tile collides with a player przykład kierunku i siły grawitacji w kafel-
byte lifeMod; // life modifier ku przechowywać będziemy odpowiedni
} wektor. Może to nawet być tekst, np. wiado-
mość wyświetlana na ekranie, gdy gracz wej-
void foo() dzie na kafelka.
{
Tile myTile = new Tile(); // create new tile Kafelek w pamięci
myTile.lifeMod = SOME_VALUE; // change tile's property W tym momencie mamy w głowie ideę map
short lifeMod = myTile.lifeMod; // read tile's property kafelków i tworzenia świata za ich pomocą.
} Kolejnym krokiem jest przeniesienie idei do
programu – do naszej gry.
Listing 2. Reprezentacja przykładowego kafelka przez pole bitowe wraz z funkcjami dostępu do Zaczniemy od stworzenia reprezentacji ka-
informacji; pseudokod
felka. Wiemy, że kafelki są kontenerami zawie-
int TILE_SHIFT_imageId = 0; rającymi różne informacje na temat pewnego
int TILE_MASK_imageId = 0xffff; miejsca w świecie. Potrzebujemy zatem struk-
tury danych, która będzie te różnorodne in-
int TILE_SHIFT_lifeMod = 16; formacje przechowywać. Mamy co najmniej
int TILE_MASK_lifeMod = 0xff; dwie opcje:

int TILE_SHIFT_solid = 24; • obiekty – informacje zapisane są jako po-

int TILE_MASK_solid = 0x1; la klasy;
• liczby całkowite traktowane jak pola bi-
void set_tile_lifeMod( int tile, short value ) towe – informacje zapisane są na kolej-
{ nych bitach liczby całkowitej.
value =<< TILE_SHIFT_lifeMod;
tile &= value; Jak to wygląda w praktyce? Powiedzmy, że
return tile; chcemy, aby nasze kafelki przechowywały
} następujące informacje:

short get_tile_lifeMod( int tile ) • identyfikator obrazka używanego do ry-

{ sowania kafelek;
short lifeMod = tile >> TILE_SHIFT_lifeMod; • flagę mówiącą o tym, czy kafelek jest pu-
lifeMod &= TILE_MASK_lifeMod; sty (gracz może po nim przejść), czy nie
return lifeMod; (gracz koliduje z kafelkiem);
} • ilość życia, którą gracz straci (wartości
ujemne) lub zyska (wartości dodatnie),
void foo() stykając się z kafelkiem.
{
int myTile = 0; // create new tile Listingi 1 i 2 zawierają przykładowe spo-
myTile = set_tile_lifeMod( myTile, SOME_VALUE ); // change tile's property soby implementacji takiego kafelka wraz z
short lifeMod = get_tile_lifeMod( myTile ); // read tile's property prostym przykładem użycia – stworzenie
nowego kafelka oraz odczyt i zmiana jed-
ASSERT( lifeMod == SOME_VALUE ); // we've set tile's life modifier nej z informacji przez niego przechowy-
// to SOME_VALE, so getting it back wanych. Listingi są napisane w pseudo ko-
// from tile must give the same value dzie, ale można je łatwo dostosować do C++
lub Javy.
Listing 3. Kafelek jako mapa cech: implementacja w języku C++ Listingi 1 i 2 zawierają przykładowe spo-
// empty tile soby implementacji takiego kafelka wraz
std::map< std::string, boost::any > m_tile; z prostym przykładem użycia – stworze-
nie nowego kafelka oraz odczyt i zmiana
// let's add gravity vector property to the tile jednej z informacji przez niego przecho-
m_tile["gravity"] = Vector2( 0, -3 ); wywanych. Listingi są napisane w pseudo
kodzie, ale można je łatwo dostosować do
// read the gravity vector property C++ lub Javy.
Vector2f& gravity = boost::any_cast<T&>( m_tile[„gravity"] ); Listing 1 to wersja, w której używamy kla-
sy. Zaletą tego rozwiązania jest łatwość i oczy-
wistość kodu – po prostu odnosimy się do po-
la klasy.

44 02/2010

Listing 2 to wersja, w której informacje o
kafelku są zapisane na bitach liczby całkowi-
tej. Ta wersja jest trochę bardziej zagmatwa-
na od wersji z klasą. Nie mamy bezpośred-
niego dostępu do składowych kafelka – mu-
simy stworzyć sobie pewien mechanizm do-
stępu do nich. W tym przykładzie są to funk-
cje set_tile_lifeMod i get_tile_lifeMod.
Zaletą tego podejścia jest łatwość kopiowania
kafelków oraz łatwość zapisu i odczytu mapy
do/z pliku.
Kafelek jako mapa cech
Istnieje jeszcze inna, ciekawa, aczkolwiek
rzadko stosowana metoda – możemy kafel-
ka zaimplementować jako prawdziwy kon-
tener na różnorodne informacje. Wyko-
rzystamy do tego asocjacyjne struktury da-
nych przechowujące elementy dowolnego
typu – czyli zadajemy pewien klucz i otrzy-
mujemy pewną wartość dowolnego typu. W
naszym przypadku klucz niech będzie tek-
stem (string). Takie rozwiązanie często na-
zywa się property map, czyli mapa cech lub
właściwości.
Przykładowa implementacja tej techni-
ki w języku C++ (zakładam, że mamy swo-
ją klasę Vector2) przedstawiona jest na Li-
stingu 3.
Podobną strukturę możemy zaimplemen-
tować w Javie ME (patrz Listing 4).
Jest to podejście bardzo elastyczne i szcze-
gólnie przydatne, gdy tworzymy grę stero-
waną danymi. Możemy określać i dodawać
dowolne cechy kafelków w locie – nie musi-
my określać na sztywno w kodzie, jakie po-
la będzie miała klasa, a możemy np. wczy-
tać definicję kafelka z pliku (czyli możemy
tworzyć różne kafelki bez ponownej kompi-
lacji programu). Ponadto, kafelki mogą się
różnić między sobą cechami, jakie posiada-
ją, np. niektóre kafelki mogą mieć wartość
dla gravity, a niektóre nie. W podejściu kla-
sycznym wszystkie kafelki mają ten sam ze-
staw cech.
W praktyce jednak, podejście to nie jest
często stosowane ze względu na duży narzut
pamięciowy (trzeba stworzyć obiekt konte-
nera, który będzie trzymał informacje o sta-
nie zawartości, do tego dużo pamięci zajmu-
ją klucze w postaci tekstu) i wydajnościowy
(odwołanie się do elementu za pomocą klu-
cza trwa dłużej niż zwykłe odwołanie się do
pola klasy).
Jeśli jednak narzuty nie stanowią dla nas
problemu, a chcemy stworzyć uniwersalny
i elastyczny system, jest to rozwiązanie god-
ne polecenia.
Mapa w pamięci
Teraz musimy zająć się przeniesieniem do
programu całej mapy. Mapa to dwuwymia-
rowy uporządkowany zbiór kafelków. Za-
www.sdjournal.org
Mapy kafelków
tem pierwszym rozwiązaniem, jakie nasu- tać, że tablice w C++ i Javie są indeksowa-
wa się na myśl, jest użycie dwuwymiarowej ne od zero, czyli pierwsza kolumna i pierw-
tablicy zawierającej kafelki, obojętnie, czy szy rząd to 0,0.
są one reprezentowane jako obiekty, czy
pola bitowe. Jest to rozwiązanie proste i in- Mapa w pamięci
tuicyjne, gdyż bardzo łatwo i bezpośrednio – tablica jednowymiarowa
możemy określić rozmiar mapy i odwołać Na niektórych platformach występują różne
się do interesującego nas kafelka. problemy z tablicami wielowymiarowymi.
Listingi 5 i 6 przedstawiają przykłady Czasami rozwiązanie takie może być niedo-
w Javie i C++. Jest tam reprezentacja ma- stępne, czasami może działać wolno.
py, jej tworzenie (o zadanym rozmiarze) i Z takich czy innych powodów zamiast
odwoływanie się do konkretnego kafelka tablic dwuwymiarowych można użyć ta-
(znajdującego się w czwartej kolumnie i blic jednowymiarowych. W tym przypad-
trzecim wierszu). Na listingach widać, jak ku mapa w pamięci stanowi długi pasek ka-
łatwo wykonuje się te czynności; po pro- felków, a kolejne rzędy są doklejane do sie-
stu podajemy ilość kafelków w poziomie bie z boku.
(szerokość mapy) i pionie (wysokość ma- Jednak pojawia się tutaj pytanie – jak okre-
py) oraz rząd i kolumnę kafelka, do którego ślić rozmiar mapy i jak odnieść się do kon-
chcemy się odwołać (3 i 2). Należy pamię- kretnego kafelka? Tablica musi przechowy-
Listing 4. Kafelek jako mapa cech: implementacja w języku Java
// empty tile
Hashtable m_tile = new Hashtable();
// let's add gravity vector property to the tile
m_tile.put( "gravity", new Vector2( 0, -3 ) );
// read the gravity vector property
Vector2 gravity = (Vector2)m_tile.get( "gravity" );
Listing 5. Mapa jako tablica dwuwymiarowa; Java
Tile[][] tiledMap;
public void CreateMap( int width, int height )
{
tiledMap = new Tile[width][height]; // create empty map
for( int u=0; u<width; ++u ) { // create tiles
for( int v=0; v<height; ++v ) {
tiledMap[u][v] = new Tile();
}
}
// make tile in 4th column and 3rd row solid
tiledMap[3][2].isSolid = true;
}
Listing 6. Mapa jako tablica dwuwymiarowa; C++
Tile** tiledMap;
void CreateMap( int width, int height )
{
tiledMap = new Tile*[width];
for( int i=0; i<width; ++i ) {
tiledMap[i] = new Tile[height];
}
// make tile in 4th column and 3rd row solid
tiledMap[3][2].isSolid = true;
}
45
 Programowanie gier

wać wszystkie kafelki, więc jej rozmiar jest mechanizmy łatwego tworzenia map o za- pewne problemy, używaj tablic jednowy-
iloczynem rozmiaru mapy (w kafelkach) w danym rozmiarze i łatwego dostępu do ka- miarowych.
pionie i w poziomie. Natomiast aby odnieść felka za pomocą jego położenia w siatce ma-
się do konkretnego kafelka, musimy prze- py (kolumna i wiersz). Jeśli nasz kod będzie Przyspieszenie – tablica
liczyć wiersz i kolumnę na indeks w tabli- używał tych mechanizmów, a nie odnosił się indeksów początków wierszy
cy: indeks = wiersz * szerokość mapy w bezpośrednio do tablicy z kafelkami, jeste- Jeśli zdecydujemy się na użycie tablicy jed-
kafelkach + kolumna. śmy zawsze w stanie zmienić reprezentację nowymiarowej do przechowywania mapy,
Listingi 7 i 8 przedstawiają przykłady ana- mapy na inną, bez konieczności zmiany ko- bardzo często będziemy obliczać indeks
logiczne do tych, które były pokazane na Li- du odwołującego się do niej. kafelka na podstawie jego wiersza i kolum-
stingach 5 i 6, ale z użyciem tablicy jednowy- Jeśli wygodnie jest Ci z tablicami dwu- ny w mapie. Dla przypomnienia: indeks =
miarowej. wymiarowymi, to używaj właśnie ich. Jeśli wiersz * szerokość mapy w kafelkach
wolisz mieć pełniejszą kontrolę nad spo- + kolumna. Zatem przy każdym odwoła-
Czego używać? sobem odwoływania się do konkretnego niu się do kafelka wykonywane jest mno-
Suma summarum, sposób reprezentacji ma- kafelka lub na platformie, na którą progra- żenie. Istnieje sposób na pozbycie się tego
py nie jest aż tak ważny, jak to, żeby mieć mujesz tablice wielowymiarowe sprawiają mnożenia.
Zauważmy, że działanie: wiersz * szerokość
mapy w kafelkach daje nam w wyniku indeks
Listing 7. Mapa jako tablica jednowymiarowa; Java pierwszego kafelka w zadanym wierszu. Może-
Tile[] tiledMap; my zatem raz obliczyć indeksy pierwszych ka-
felków dla wszystkich wierszy i przechowywać
public Tile GetTile( int u, int v) je w tablicy. Wtedy operacja obliczania indek-
{ su wygląda następująco: indeks = pierwsze_
return tiledMap[v * mapWidth + u]; kafelki[wiersz] + kolumna. Pozbyliśmy się
} mnożenia przy odwołaniu do kafelka.
Wartości tablicy pierwsze_kafelki łatwo
public void CreateMap( int width, int height ) obliczyć w pętli:
{
tiledMap = new Tile[width * height]; // create empty map for( int i=0; i < ilość_wierszy; ++i )
pierwsze_kafelki[i] = i * szerokość_
for( int i=0; i < width*height; ++i ) mapy;
{
tiledMap[i] = new Tile(); Zmniejszenie zużycia pamięci
} – mapa indeksów do kafelków
Jeśli nie potrzebujemy możliwości modyfika-
// make tile in 4th column and 3rd row solid cji właściwości pojedynczych kafelków w ma-
tiledMap[2*mapWidth + 3].isSolid = true; pie, to można zmodyfikować jej implementa-
cję tak, by zamiast trzymać kafelki trzymała
// the same as above but using convenience function: tylko typ kafelka, a same kafelki przechowy-
GetTile(3,2).isSolid = true; wać gdzieś z boku. W praktyce z boku może
} oznaczać tablicę (taka jakby biblioteka kafel-
ków), a mapa może zawierać indeksy do tej
Listing 8. Mapa jako tablica jednowymiarowa; C++ tablicy.
Tile* tiledMap; Jeśli kafelki zawierają dużo informa-
int mapWidth; cji, można w ten sposób zyskać na pamię-
ci. Ale nie można zmieniać właściwości po-
Tile& GetTile( int u, int v ) jedynczych kafelków. Można jedynie global-
{ nie zmieniać właściwości wszystkich kafel-
return tiledMap[v * mapWidth + u]; ków danego typu (przez zmianę kafelka w
} bibliotece).
Przykład: mapę indeksów to kafelków
void CreateMap( int width, int height ) możemy trzymać jako tablicę short'ów (2
{ bajty na kafelek), daje to nam możliwość
mapWidth = width; posiadania kilkudziesięciu tysięcy różnych
tiledMap = new Tile[width * height]; kafelków (prawie na pewno wystarczy),
a ilość zużytej pamięci = szerokość
// make tile in 3rd column and 2nd row solid mapy * wysokość mapy * 2 + n*ilość
tiledMap[2*mapWidth + 3].isSolid = true; typów kafelków (gdzie n to rozmiar ka-
felka w pamięci). W wersji klasycznej
// the same as above but using convenience function: zużycie = szerokość mapy * wysokość
GetTile(3,2).isSolid = true; mapy * n.
} Dla mapy, powiedzmy, 60x30 kafelków z
kafelkiem zajmującym 10 bajtów i 100 róż-
nymi kafelkami wygląda to następująco:

46 02/2010
 Mapy kafelków

• wersja klasyczna = 60*30*10 = 18000
• wersja indeksowa = 60*30*2 + 100*10 =
3600+1000 = 4600
Im większa mapa, tym większy zysk na pa-
mięci w wersji indeksowej. Technika ta mo-
że być bardzo przydatna na platformach z
ograniczoną ilością pamięci, np. na telefo-
nach komórkowych.
Okno na świat
Mamy przygotowane struktury danych
przechowujące kafelki i mapę. Powoli zbli-
żamy się w kierunku rysowania. Zanim jed-
nak tego dokonamy, musimy określić dwie
rzeczy:
• co chcemy rysować – jaki wycinek mapy;
• gdzie chcemy rysować – w którym miej-
scu ekranu.
Mapy są najczęściej większe od obszaru, w
którym będą wyświetlane. Z tego powodu
musimy określić, jaki wycinek mapy chcemy
narysować. Sam obszar wyświetlania też nie
jest rzeczą oczywistą – najczęściej będzie to
cały ekran, ale tak być nie musi – prostokąt-
ny wycinek świata możemy narysować w do-
wolnym miejscu ekranu i nadać mu dowol-
ny rozmiar.
To swoiste okno na świat nazywać będzie-
my dalej viewport – czyli prostokątna widocz-
na część mapy plus informacja, gdzie ma być
umieszczona na ekranie. Listing 9 zawiera
przykład klasy Viewport, a Rysunek 2 poka-
zuje wzajemne relacje między mapą, view-
portem a ekranem.
W niektórych systemach graficznych view-
port zawiera dodatkowo informacje na temat
skalowania, tzn. jeśli widoczny wycinek świa-
ta, mimo iż jest to tylko wycinek, jest więk-
szy od obszaru, na którym ma być narysowa-
ny, można go pomniejszyć, aby go dopasować.
Jednak w przypadku naszej prostej mapy ka-
felków skala równa się jeden – czyli wycinek
mapy ma ten sam rozmiar co obszar, na któ-
rym go rysujemy.
Układy współrzędnych
W tym miejscu, gdy mówimy o świecie, view-
porcie i ekranie, pojawia się zagadnienie ukła-
dów współrzędnych. W naszym zagadnie-
niu występują układy: świata, viewportu i
ekranu.
Układy te mają te same jednostki – pikse-
le – oraz kierunki i zwroty osi (przyjmijmy,
że oś X rośnie w prawo, Y w dół). Jedyna róż-
nica to inne początki – układy są przesunięte
względem siebie.
Układ świata ma swój początek w górnym
lewym rogu pierwszego kafelka mapy. Układ
viewportu zaczyna się w górnym lewym ro-
gu okna na świat. Układ ekranu to po prostu
układ ekranu, ma swój początek w górnym le- wiersza w mapie. Służy on do wskazywania
wym rogu ekranu. konkretnego kafelka, np. (1, 4) oznacza kafe-
Występuje jeszcze jeden układ współrzęd- lek w drugiej kolumnie i piątym wierszu ma-
nych, który ma inne jednostki. Nazwijmy go py (pamiętajmy o numerowaniu od zera).
kaflowy układ współrzędnych – jest to układ, Rysunek 3 pokazuje wzajemne zależności
w którym współrzędne to numer kolumny i między układami.
Listing 9. Klasa Viewport; pseudokod
public class Viewport
{
/* size of viewport in pixels */
int width;
int height;
/* position of top-left corner of viewport in the world */
int worldX;
int worldY;
/* position of top-left corner of viewport in the screen */
int screenX;
int screenY;
}
Listing 10. Prosty algorytm rysowania mapy; pseudokod
void DrawMap()
{
// determine visible tiles bounds:
int left = viewport.worldX / tileWidth;
int right = viewport.worldY / tileHeight;
int top = left + (viewport.width / tileWidth) + 1;
int bottom = top + (viewport.height / tileHeight) + 1;
// make sure we draw only within viewport, so set clipping:
setClip( viewport.screenX, viewport.screenY, viewport.width, viewport.height );
// draw tiles:
for( int v=top; v <= bottom; ++v )
{
for( int u=left; u <= right; ++u )
{
// calculate tile's position on screen:
int x = u * tileWidth - viewport.worldX + viewport.screenX;
int y = v * tileHeight - viewport.worldY + viewport.screenY;
// get tile and draw it:
Tile tile = map.getTile( u, v );
DrawTile( tile, x, y );
}
}
}
Listing 11. Fragment prostej klasy TileSet; Java
public class ImagesTileSet
{
private Image[] tileImages; // array of tile-images
public void DrawTile(Graphics g, int tileIdx, int x, int y)
{
g.drawImage( tileImages[tileIdx], x, y, Graphics.LEFT | Graphics.TOP );
}
}

www.sdjournal.org 47
 Programowanie gier

Żeby nie pogubić się we współrzędnych i duje się punkt (x,y). Działania wyglądają na- Przyspieszenie – rozmiar
układach, w dalszej części artykułu będę uży- stępująco: kafelka wielokrotnością liczby 2
wał następujących oznaczeń: Operacje przechodzenia między układami to
(world x,y) → (u,v) ciągłe mnożenie lub dzielenie przez rozmiar
• układ świata: (world x,y); u = world_x / tile_width kafelka. Na niektórych platformach operacje
• układ viewportu: (view x,y); v = world_y / tile_height te (zwłaszcza dzielenie) są powolne. Na po-
• układ ekranu: (screen x,y); moc przychodzą jednak operacje bitowe na
• układ kaflowy: (u,v). Znając położenie kafelka w świecie, musimy liczbach całkowitych.
przenieść je do współrzędnych viewportu, a Mnożenie i dzielenie przez liczbę, która
Przechodzenie między układami następnie do współrzędnych ekranu. jest potęgą liczby 2, można zastąpić przesu-
Wszystkie funkcje rysujące obrazy operują nięciami bitowymi. Przesuwamy o tyle bi-
w układzie ekranu. Natomiast kafelki ułożo- (world x,y) → (view x,y) → (screen x,y) tów, do której potęgi jest podniesiona liczba
ne są w mapie i znamy ich współrzędne ka- screen_x = world_x - viewport_world_x + 2. Jeśli chcemy pomnożyć, przesuwamy bity
flowe. Dlatego żeby narysować mapę, będzie- viewport_screen_x; w lewo, jeśli podzielić – w prawo.
my musieli przenosić współrzędne pomiędzy screen_y = world_y - viewport_world_y + Przykładowo, jeśli chcemy pomnożyć przez
układami. viewport_screen_y; 8 (2 do potęgi 3), możemy liczbę przesunąć o
Pierwszym krokiem jest obliczenie poło- 3 bity w lewo. Analogicznie, jeśli chcemy po-
żenie kafelka w świecie (tzn. współrzędnych Na koniec możemy złożyć w całość oblicza- dzielić przez 64 (2 do potęgi 5), możemy licz-
górnego lewego rogu kafelka). Aby to zrobić, nie położenia kafelka na ekranie. bę przesunąć o 5 bitów w prawo.
wykonujemy następujące działania: Zatem jeżeli znamy rozmiar kafelka w na-
(u,v) → (screen x,y) szym programie i wiemy, że nie będzie się
(u,v) → (world x,y) screen_x = u * tile_width - viewport_ zmieniał, możemy przyspieszyć operacje na
world_x = u * tile_width world_x + viewport_ kafelkach, używając przesunięć bitowych.
world_y = v * tile_width screen_x; Należy jednak uważać, gdyż w czasie trwania
screen_y = v * tile_height - viewport_ projektu założenia mogą się zmienić. Może
Czasami potrzebna jest operacja odwrot- world_y + viewport_ się okazać, że jednak musimy użyć rozmiaru
na, tzn. stwierdzenie, w jakim kafelku znaj- screen_y; kafelka innego niż potęga dwójki. Lub może
się okazać, że musimy obsługiwać kilka roz-
Listing 12. Fragment prostej klasy TileSet; C++/SDL miarów kafelków (w czasie działania aplika-
class TileSet cji, np. różne mapy o różnych rozmiarach
{ kafelka; bądź w czasie kompilacji, np. gdy
private: tworzymy różne wersje gry z różnymi roz-
SDL_Surface** m_tileImages; // array of pointers to tile-images miarami kafelków w zależności od rozmiaru
SDL_Rect m_tileRect; // (0, 0, tile width, tile height) ekranu urządzenia docelowego, często dzieje
się tak przy tworzeniu gier na telefony).
public: Dobrze jest posiadać mechanizm pozwa-
void DrawTile( SDL_Surface* target, int tileIdx, int x, int y ) lający na łatwe przełączanie implementacji
{ między wersjami obsługującymi mnożenie/
SDL_Rect dstRect; dzielenie i przesunięcia bitowe.
dstRect.x = x;
dstRect.y = y; Proste rysowanie
Wreszcie jesteśmy gotowi, aby narysować ma-
SDL_BlitSurface( m_tileImages[tileIdx], &m_tileRect, target, &dstRect ); pę. Najprostszy sposób rysowania mapy ka-
} felków, w dużym uproszczeniu, jest nastę-
}; pujący:

• określamy, które kafelki są widoczne w

viewporcie – musimy wyznaczyć ko-

Rysunek 3. Układy współrzędnych. Niebieski – układ ekranu. Czerwony – układ viewportu. Zielony Rysunek 4. Macierz kafelków. Zamiast trzymać
– układ świata i układ kafelkowy (mają te same osie i początek, ale różne jednostki; ich jednostki to obrazki kafelków w oddzielnych plikach można je
odpowiednio piksele i „kratki”). Czarne strzałki pokazują pozycję viewportu w świecie i na ekranie umieścić w jednym dużym obrazie

48 02/2010
 Mapy kafelków

lumny najbardziej z lewej i z prawej stro-
ny viewportu, oraz rzędy u góry i u dołu
viewportu.
• następnie rysujemy kafelki po kolei,
rzędami lub kolumnami – dla każde-
go kafelka obliczamy jego położenie we
współrzędnych ekranu; transformacja
(u,v) –> (screen x, screen y); a następnie
rysujemy obrazek odpowiadający kafel-
kowi
Spójrzmy na na Listing 10 i prześledźmy, co
się tam dzieje.
Najpierw obliczamy skrajne wiersze i ko-
lumny widoczne w viewporcie. Aby wyzna-
czyć lewą kolumnę i górny wiersz, używa-
my położenia viewportu w świecie i przeno-
simy go do współrzędnych kaflowych (dzie-
lenie przez rozmiar kafelka). Prawą kolum-
nę i dolny wiersz wyznaczamy przez dodat-
nie do lewej kolumny/górnego wiersza roz-
miaru viewportu w kafelkach (zaokrąglając
do góry).
Następnie należy ustawić przycinanie (clip-
ping), żeby rysowane kafelki nie wyszły poza
obszar viewportu. Jeśli rysujemy na całym
ekranie, operację tę można pominąć.
Kolejnym krokiem jest samo rysowanie
– w podwójnej pętli przechodzimy po kolej-
nych kafelkach (poruszamy się w układzie ka-
flowym, zmienne u,v). Dla każdego kafelka
obliczamy jego współrzędne na ekranie, po-
bieramy go z mapy i rysujemy go.
określa się mianem tile set. Stwórzmy więc
klasę TileSet.
Klasa TileSet musi być w stanie zwrócić
lub narysować żądany obrazek. Obrazki bę-
dziemy identyfikować przez ich numer w
zbiorze (przez indeks, numerujemy od ze-
ra). Przyjmijmy zatem, że obrazki kafelków
będą przechowywane w klasie TileSet w
tablicy. Listingi 11 i 12 przedstawiają frag-
menty przykładów takiej klasy wraz z kon-
kretnym kodem rysującym pojedynczego
kafelka.
Czasami tileset składa się z kilkudziesię-
ciu lub nawet kilkuset kafelków. Przechowy-
wanie tak dużej ilości obrazków w oddziel-
nych plikach może być niewygodne. Dlate-
go, wykorzystując fakt, że wszystkie kafelki
mają takie same rozmiary, można umieścić
obrazki w jednym dużym obrazie, obok sie-
bie, w rzędach, tworząc macierz kafelków.
Rysunek 4 przedstawia przykład takiej ma-
cierzy.
Następnie przy ładowaniu można kafel-
ki wyciąć z macierzy i umieścić w oddziel-
nych obrazkach, a te umieścić w tablicy (jak
na Listingach 11 i 12). Można też trzymać w
pamięci cały duży obrazek z macierzą kafel-
ków, a rysując pojedynczego kafelka, użyć od-
powiedniej funkcji rysującej tylko fragment
obrazu.
Przyspieszenie
– pozbycie się mnożeń
W tym miejscu chciałbym jeszcze wrócić do
algorytmu rysowania kafelków. Kod z Listin-
gu 10 rysuje kolejne wiersze mapy, zaczynając
od góry viewportu, schodząc w dół. W każ-
dym wierszu kafelki rysowane są od lewej do
prawej. Dla każdego kafelka obliczane są jego
położenie na ekranie i indeks w mapie.
Można zauważyć, że w obrębie wiersza po-
zycje kolejnych kafelków zwiększają się za-
wsze o szerokość kafelka. Można więc, za-
miast obliczać współrzędną x dla każde-
go kafelka, obliczyć ją dla pierwszego kafel-
ka w rzędzie, a następnie zwiększać o szero-
kość kafelka.
Analogicznie można postąpić z wiersza-
mi. Współrzędna y kolejnych wierszy zwięk-
sza się zawsze o wysokość kafelka. Można
więc obliczyć współrzędną y tylko pierwsze-
go wiersza, a dla kolejnych zwiększać ją o wy-
sokość kafelka.
Składając to razem, okazuje się, że wystar-
czy obliczyć położenie tylko jednego kafel-
ka – położonego najbardziej u góry z lewej
w viewporcie – a następnie odpowiednio
zwiększać współrzędne x i y rysowania.
Podobnie można postąpić z indeksem ka-
felka w mapie. W danym wierszu, indek-
sy kolejnych kafelków zwiększają się o 1, a z

Rysowanie
pojedynczego kafelka, „tilesety”
Wszystko niby już jasne, wiemy jak ryso-
wać mapę, ale w Listingu 10 zamiast ko-
du, który rysuje konkretne kafelki, jest ma-
giczna funkcja DrawTile. Specjalnie jej nie
opisywałem, gdyż można ją zrealizować na Rysunek 5. Rysowanie mapy z buforem – na ekran rysujemy fragment bufora zawarty wewnątrz
viewportu. Pierwszy rysunek od lewej przedstawia stan początkowy – mapa narysowana na buforze,
różne sposoby. Przyjrzyjmy się, jak można
viewport umieszczony pośrodku bufora. Jeśli viewport porusza się po mapie, ale mieści się w buforze
to zrobić. (rysunek drugi od lewej), nie trzeba przerysować bufora. Natomiast jeśli viewport wyjdzie poza bufor
Do tej pory zakładaliśmy, że kafelek za- (rysunek trzeci), należy wycentrować viewport w buforze i przerysować bufor kafelkami (rysunek
wiera w sobie jakąś informację na temat czwarty)
tego, jak ma wyglądać. W przykładach by-
ło to pole imageId określające, jaki obrazek
ma być użyty. Równie dobrze może to być
wskaźnik lub referencja do konkretnego
obrazka, a samo rysowanie w najprostszej
wersji może być odwołaniem do funkcji w
stylu drawImage/SDL_BlitSurface, której
przekazujemy obrazek i współrzędne. W
takim wypadku musimy wcześniej wczy-
tać interesujące nas obrazki i umieścić re-
ferencje do nich w kafelkach. Możemy rów-
nież wczytać obrazki, umieścić je w tablicy,
a w kafelkach trzymać indeksy, np. w polu
imageId. Rysunek 6. Dorysowywanie kafelków na cyklicznym buforze. Kratkowany prostokąt to bufor. Na
początku rysujemy kafelki, aby wypełnić obszar viewportu. W drugim kroku viewport przesunął się w
Bardzo często postępuje się właśnie w ta-
prawo i należało dorysować dwie kolumny kafelków (zaznaczone na żółto). W trzecim kroku viewport
ki sposób. Określamy pewien zbiór obraz- przesunął się jeszcze bardziej w prawo – należy dorysować kolumnę z prawej strony. Jednak bufor
ków, które będziemy używać jako reprezen- skończył się, więc przenosimy dorysowywaną kolumnę na drugą stronę (na żółto zaznaczono miejsce,
tacje graficzne kafelków. Taki zbiór obrazków gdzie ostatecznie dorysowano kolumnę), a viewport zostaje „zawinięty”

www.sdjournal.org 49
 Programowanie gier

każdym kolejnym wierszem indeks wraca do niektórych platformach (np. powolne telefo- dzie źródłowym (funkcja drawMapOpti-
skrajnie lewej kolumny widocznej w viewpor- ny komórkowe) może to owocować pewnym mized).
cie, a następnie zwiększa się o szerokość całej przyspieszeniem, zwłaszcza gdy rysujemy du-
mapy w kafelkach. żo kafelków. Rysowanie z buforem
Używając opisanych operacji, pozbywa- Implementację tej optymalizacji moż- W prostym rysowaniu mapy kafelków wy-
my się kilku mnożeń dla każdego kafelka. Na na znaleźć w załączonym do artykułu ko- wołujemy funkcję rysującą pojedynczy kafe-
lek (a co za tym idzie rysującą obrazek) tyle
Listing 13. Rysowanie zawiniętego viewportu razy, ile jest kafelków widocznych na ekranie.
Ilość ta zależy od wielkości kafelka i ekranu
// get viewport bounds (left, right, top, bottom) in pixels i czasem może być całkiem spora (mały kafe-
int left = viewport.bufferX; lek, duży ekran).
int right = viewport.bufferX + viewport.width; Różne platformy bardzo różnie realizują ry-
if( right > bufferWidth ) // wrap sowanie pojedynczych obrazków. Dla niektó-
{ rych obojętne jest, czy rysujemy dużo małych
right -= bufferWidth; obrazków, czy mało dużych, ale dla niektórych
} ma to istotne znaczenie. Przykładem mogą być
Javowe telefony komórkowe – w wielu z nich
int top = viewport.bufferY; narzut wywołania funkcji rysujących obrazek
int bottom = viewport.bufferY + viewport.height; jest znaczny i trzeba się z nim liczyć, i warto
if( bottom > bufferHeight ) { // wrap rysować mniej, ale większych obrazków. Z te-
{ go powodu powstała koncepcja rysowania ma-
bottom -= bufferHeight; py kafelków z buforem.
} Idea jest następująca. Zamiast na ekran ry-
sujemy mapę na buforze. Bufor jest większy
// determine case od rozmiaru ekranu. Na początku umieszcza
if( left < right && top < bottom ) { się viewport w środku bufora i rysuje kafel-
// case #1: whole viewport fits inside buffer ki na całej powierzchni bufora. Na ekran ry-
drawBufferRegionToScreen( ... ); sujemy tylko część bufora zawartą wewnątrz
} viewportu.
else if( left > right && top < bottom ) { Jeśli vieport nie przemieszcza się po mapie,
// case #2: y in bounds, split x to nie ma potrzeby przerysowywania kafel-
ków w buforze, wystarczy tylko rysować bu-
// rectangle 1 for na ekran. Dzięki temu w każdej klatce gry
drawBufferRegionToScreen( ... ); rysujemy tylko jeden duży obraz.
Jeśli viewport porusza się po mapie, to prze-
// rectangle 2 suwamy go także w buforze i sprawdzamy,
drawBufferRegionToScreen( ... ); czy ciągle się w nim mieści. Jeśli tak, to nie
} musimy przerysowywać kafelków i rysujemy
else if( left < right && top > bottom ) { bufor na ekran. Pamiętajmy, że rysujemy tyl-
// case #3: x in bounds, split y ko część bufora zawartą wewnątrz viewpor-
tu – dzięki przemieszczaniu viewportu we-
// rectangle 1 wnątrz bufora na ekranie mamy wrażenie po-
drawBufferRegionToScreen( ... ); ruszania się po mapie.
Przerysowanie kafelków odbywa się dopie-
// rectangle 2 ro w momencie, gdy viewport wyszedł poza
drawBufferRegionToScreen( ... ); obszar bufora. Należy wtedy ponownie na-
} rysować kafelki na całej powierzchni bufora
else { i wycentrować w nim viewport.
// case #4: x split, y split Rysunek 5 przedstawia sposób działania
rysowania z buforem.
// rectangle 1 Nie jest to rozwiązanie idealne – ciągle
drawBufferRegionToScreen( ... ); musimy co jakiś czas przerysować wszyst-
kie widoczne kafelki, przez co co pewien
// rectangle 2 czas mogą występować zwolnienia. Zda-
drawBufferRegionToScreen( ... ); rza się to, gdy viewport dochodzi do krawę-
dzi bufora. Jednak pomiędzy przerysowa-
// rectangle 3 niami rysowanie na ogół odbywa się szyb-
drawBufferRegionToScreen( ... ); ciej. Warto więc technikę tę przetestować
w swojej aplikacji.
// rectangle 4
drawBufferRegionToScreen( ... ); Rysowanie – cykliczny bufor
} Rysowanie do bufora cyklicznego to modyfi-
kacja i rozwinięcie techniki rysowania do bu-

50 02/2010
 Mapy kafelków

fora. Metoda ta rozwiązuje problem przery-

sowywania wszystkich widocznych kafelków
co pewien czas – dorysowujemy tylko kafel-
ki, które znalazły się w viewporcie, a nie było
ich tam wcześniej.
Na początku rysujemy kafelki tak, żeby
zapełnić obszar viewportu. Jeśli viewport
przesuwa się wewnątrz bufora, dorysowu-
jemy tylko brakujące kafelki (np. jeśli bufor
porusza się w prawo, będziemy dorysowy-
wać kolejne kolumny z prawej strony). Te-
raz bardzo ważna informacja – dokładnie
tak samo postępujemy (tzn. rysujemy bra-
kujące kafelki), gdy bufor przekroczy kra-
wędź ekranu (w tym momencie w meto-
dzie z buforem trzeba było przerysować ca-
ły bufor). Jednakże pojawia się pytanie
– gdzie narysować brakujące kafelki, jeśli
viewport wychodzi poza bufor? Odpowiedź
znajduje się na Rysunku 6 – dorysowujemy
z drugiej strony bufora, a viewport zawija-
my. Dzięki zawijaniu viewportu i rysowa-
niu kafelków cyklicznie na buforze nie mu-
simy dokonywać całkowitego przerysowa-
nia bufora (chyba że viewport w całości wyj-
dzie poza bufor).
Zawijany viewport
Co to w praktyce znaczy, że viewport jest za-
winięty? Jak narysować na ekranie obszar
bufora zawarty w viewporcie, jeśli nie jest
on prostokątem, tylko dwoma prostokąta-
mi przyległymi do prawej i lewej krawędzi
ekranu? A jeśli bufor zamiast prawo-lewo
będzie poruszał się góra-dół? Wtedy view-
port po zawinięciu stanie się dwoma prosto-
kątami przyległymi do górnej i dolnej krawę-
dzi bufora. A co, jeśli viewport będzie poru-
szał się jednocześnie w prawo-lewo i w gó-
rę-dół? Wtedy po zawinięciu stanie się czte-
rema prostokątami.
Jak to wszystko narysować na ekranie?
Każdy prostokąt składowy viewportu rysu-
jemy oddzielnie, ale wszystkie prostokąty
umieszczamy na ekranie sąsiadująco wzglę-
dem siebie, tak aby składały się w jednoli-
tą całość.
Rysunek 7 przedstawia ideę zawijania view-
portu i rysowania go na ekranie. Przeanalizuj-
my go dokładnie. Mamy cztery przypadki.
Przypadek (1) jest najprostszy – viewport w
całości mieści się w buforze; wystarczy nary-
sować prostokąt na ekranie. W przypadku (2)
musimy narysować dwa prostokąty – prosto-
kąt 1 rysujemy na ekranie we współrzędnych
viewportu, a prostokąt 2 sąsiadująco z prawej.
Analogicznie postępujemy w przypadku (3),
z tą różnicą, że prostokąt 2 umieszczamy są-
siadująco od dołu. W przypadku (4) musimy
narysować aż cztery prostokąty; prostokąt 1
umieszczamy we współrzędnych viewportu,
a pozostałe trzy sąsiadują z prawej, z dołu i z
prawej-dołu. Listing 13 pokazuje zarys przy-
Rysunek 7. Rysowanie zawiniętego viewportu na ekranie. U góry znajdują się cztery możliwe
przypadki ułożenia viewportu w buforze. Na dole przedstawiony jest, dla każdego przypadku, sposób
rysowania viewportu na ekranie. Niebieska kropka to współrzędne viewportu na ekranie
Listing 14. Sprowadzanie viewportu do obszaru bufora
void wrapToBuffer()
{
// bufferX/Y is current position of viewport within buffer
int newX = m_bufferX;
int newY = m_bufferY;
// keep X in bounds:
if( m_bufferX > m_bufferWidth ) {
newX = m_bufferX % m_bufferWidth;
}
else if( m_bufferX < 0 ) {
// keep in mind that modulo of negative value gives negative result
// so actually newX is calculated by substracting from bufferWidth
newX = m_bufferWidth + ( m_bufferX % m_bufferWidth );
}
// keep Y in bounds:
if( m_bufferY > m_bufferHeight ) {
newY = m_bufferY % m_bufferHeight;
}
else if( m_bufferY < 0 ) {
newY = m_bufferHeight + ( m_bufferY % m_bufferHeight );
}
// set new position within buffer:
if( newX != m_bufferX || newY != m_bufferY ) {
setPositionInBuffer( newX, newY );
}
}
Listing 15. Rozszerzenie klasy Vieport na potrzeby implementacji rysowania mapy kafelków z
buforem cyklicznym
class CyclicViewport extends Viewport
{
int previousWorldLeft;
int previousWorldRight;
int previousWorldTop;
int previousWorldBottom;
}

www.sdjournal.org 51
 Programowanie gier

kładowego kodu realizującego rysowanie za- fora. W praktyce osiąga się to przez umiesz- ny bufor), wystarczy opracować sposób do-
winiętego viewportu. Konkretną implemen- czenie viewportu w buforze we współrzęd- rysowywania kafelków, które pojawiły się w
tację można znaleźć w dołączonym do arty- nych równych reszcie z dzielenia (modulo) viewporcie.
kułu kodzie źródłowym. położenia viewportu w świecie przez jego Wydaje się to oczywiste – dorysowujemy
Istnieje jeszcze jeden szczególny przypa- rozmiar. Listing 14 pokazuje to działanie kolumny lub wiersze – z prawej, lewej, góry
dek: viewport może w całości znaleźć się w praktyce. lub dołu. Jednak jeśli viewport przesunął się
poza buforem. Musimy temu zapobiegać zarówno w poziomie, jak i w pionie, sytuacja
– jeśli tylko viewport w całości wyskoczy po- Dorysowywanie komplikuje się.
za bufor, musimy sprawić, że od razu poja- brakujących kafelków Rysunek 8 przedstawia możliwe scena-
wi się z jego drugiej strony – w ten sposób Jeśli wiemy już, jak narysować na ekranie riusze. Musimy wziąć pod uwagę wszystkie
zawsze będzie znajdował się wewnątrz bu- zawijany viewport (lub jak kto woli cyklicz- przypadki. Żeby to zrobić, sprawdzimy kolej-
no wszystkie kafelki widoczne w aktualnym
położeniu viewportu – jeśli kafelek jest obec-
nie widoczny, a nie był widoczny w poprzed-
nim położeniu viewportu, oznacza to, że jest
o nowy i należy go dorysować do bufora.
Zatem pierwszym krokiem jest określe-
nie, które kafelki pojawiły się, a które były
już widoczne. W tym celu rozszerzymy kla-
sę Viewport, dodając informacje o skrajnych
wierszach i kolumnach ostatnio widocznych
w viewporcie (tzn. podczas poprzedniego
Rysunek 8. Możliwe przypadki dorysowywania nowych kafelków. Kartkowany prostokąt to wycinek rysowania). Na Listingu 15 pokazane jest,
świata. Prostokąt zielony to kafelki widoczne w poprzednim położeniu viewportu. Prostokąt niebieski jak można to zrobić.
to kafelki obecnie widoczne w viewporcie. Na różowo zaznaczono kafelki, które zostaną dorysowane Następnie musimy przejść w pętli po
wszystkich kafelkach widocznych w nowym
Listing 16. Obliczanie współrzędnych kafelka na buforze cyklicznym viewporcie (iterujemy po współrzędnych u,v)
i dla każdego sprawdzić, czy znajdował się w
int bufferU = u % bufferWidthInTiles; obszarze poprzednio rysowanych kafelków
int bufferV = v % bufferHeightInTiles; – sprawdzamy, czy (u,v) kafelki znajdują się
int x = buffU * tileWidth; wewnątrz poprzednich granic viewportu. Je-
int y = buffV * tileHeight; śli nie, tzn. kafelek jest nowy, musimy go na-
rysować.
Listing 17. Dorysowywanie kafelków do bufora cyklicznego Powstaje jednak pytanie – w jakim miejscu
int bufferWidthInTiles = m_bufferWidth / tileWidth; go narysować? Rysując kafelka na buforze cy-
int bufferHeightInTiles = m_bufferHeight / tileHeight; klicznym, musimy jego położenie w świecie
(world u,v) sprowadzić do położenia w bu-
// paint new tiles, but only ones that appeared in new viewport: forze (buffer u,v) i dopiero wtedy obliczyć
for( int v = currTop; v <= currBottom; ++v ) współrzędne (buffer x,y) rysowania. Pomocą
{ służy tu operacja reszty z dzielenia (modulo).
for( int u = currLeft; u <= currRight; ++u ) Dla każdego rysowanego kafelka wykonu-
{ jemy obliczenia przedstawione na Listingu
int buffU = u % bufferWidthInTiles; 16, przy czym (u,v) to współrzędne kaflowe
int buffV = v % bufferHeightInTiles; w świecie, (bufferU, bufferV) to współrzęd-
ne kaflowe w buforze, a (x,y) to współrzędne
// calculate (buffer x,y) używane do rysowania na buforze.
int x = buffU * tileWidth; Listing 17 przedstawia sposób dorysowy-
int y = buffV * tileHeight; wania kafelków. Przedstawiony kod zawiera
operacje modulo dla każdego kafelka, moż-
if (u >= 0 && v >= 0 && u < mapWidth && v < mapHeight) na je jednak zoptymalizować, aby wykony-
{ wać to działanie tylko raz. Optymalizacja ta
// get tile and draw it: jest użyta w dołączonym do artykułu kodzie
int tileIdx = v * mapWidth + u; // (!!) using (world u,v) here źródłowym.
int imageId = map.m_tiles[tileIdx].m_imageIdx;
Rozmiar bufora
if (imageId >= 0) Warto zauważyć, że rozmiar bufora musi być
{ co najmniej o jeden kafelek większy niż rozmiar
tileSet.DrawTile(g, imageId, x, y); viewportu. Jeśli nie spełnimy tego warunku,
} viewport zawinie się na samego siebie. W efek-
} cie, po narysowaniu, część wspólna nałożonych
} na siebie części viewportu znajdzie się na ekra-
} nie dwa razy. Do tego dorysowywane kafelki
narysują się na kafelkach obecnie widocznych

52 02/2010

w viewporcie, zakrywając je. Ogólnie rzecz uj-
mując – mogą dziać się dziwne rzeczy.
Ponadto rozmiar bufora musi być wielo-
krotnością rozmiaru kafelka. Jest to bardzo
ważne – bez spełnienia tego warunku ka-
felki dorysowywane w ostatnim wierszu/
kolumnie będą przycięte.
Podsumowanie rysowania
„z buforem cyklicznym”
Dla czytelności przedstawię teraz wszystkie
kroki rysowania „z buforem” w formie listy:
• przy inicjalizacji umieszczamy viewport
w początku bufora (górny-lewy róg) i
wypełniamy obszar viewportu kafelka-
mi;
• jeśli viewport w całości znalazł się poza
buforem, sprowadzamy go do wnętrza
bufora przez zawinięcie pozycji (pozycja
viewportu w świecie modulo rozmiar
bufora);
• iterujemy po wszystkich kafelkach aktu-
alnie widocznych w viewporcie;
• jeśli kafelek nie był widoczny w po-
przednim viewporcie, rysujemy go na
buforze;
• aby narysować kafelka, obliczamy jego
współrzędne (u,v) w buforze (pozycja
kafelka w mapie modulo rozmiar bu-
fora w kafelkach), a następnie oblicza-
my współrzędne rysowania (x,y) i rysu-
jemy;
• gdy wszystkie nowe kafelki zostaną nary-
sowane, na buforze rysujemy obszar bu-
R E
www.sdjournal.org
fora widoczny w viewporcie na ekran
(jeden z czterech przypadków).
Już wiemy, jak rysować z buforem cyklicz-
nym. A jak ta metoda ma się do wcześniej
omówionych metod rysowania mapy?
W metodzie prostej rysujemy wszystkie
kafelki co klatkę (chcemy tego uniknąć,
wolimy rysować jeden duży obraz). W po-
dejściu z buforem nie przerysowujemy ka-
felków wcale (o to chodziło, rysujemy jeden
duży obraz co klatka), robimy to dopiero
w momencie, gdy trzeba przerysować cały
bufor. Jednak może wystąpić wtedy chwi-
lowy zauważalny spadek płynności (musi-
my przerysować cały bufor kafelkami + na-
rysować bufor na ekran).
W rysowaniu z buforem cyklicznym jeste-
śmy pomiędzy dwoma poprzednimi meto-
dami – w przeciętnym scenariuszu musi-
my dorysowywać pewną ilość kafelek co
klatkę (tylko nowe kafelki), ale za to nie
mamy sytuacji, gdy trzeba przerysować
wszystko w jednym momencie (znikają
spadki płynności).
Rozważmy jeszcze skrajne przypadki. Jeśli
viewport nie porusza się, nie musimy prze-
rysowywać kafelków wcale. Jeśli viewport
co klatka zmienia diametralnie swoje poło-
żenie, może zaistnieć potrzeba przerysowa-
nia całego viewportu. Jednak statystycznie,
w zwykłej grze, rzadko kiedy w viewporcie
pojawia się w kolejnej klatce więcej niż je-
den wiersz/kolumna nowych kafelków. W
tym właśnie tkwi zaleta tej metody, w prze-
K L A M
Mapy kafelków
ciętnym przypadku daje dobre wyniki, mi-
mo iż w skrajnych sytuacjach trzeba przery-
sować cały bufor i do tego narysować go na
ekranie.
Na dzisiaj koniec
Artykuł przedstawił podstawy zagadnienia
map kafelków. Droga do stworzenia swojej
wymarzonej gry na pewno się skróciła. Jed-
nakże był to zaledwie wstęp – w tej chwili
możemy stworzyć mapę i ją narysować. Żeby
stworzyć grę, trzeba zapoznać się z kolejnymi
zagadnieniami, takimi jak rysowanie obiek-
tów na mapie (np. postać gracza), wykrywa-
nie kolizji z kafelkami, tworzenie map w edy-
torach, ładowanie i zapisywanie ich z/do pli-
ków etc.
Mam nadzieję, że lektura artykułu była do-
brym punktem wyjścia do dalszego poszerza-
nia swojej wiedzy.
JACEK ZAGRODZKI
Pracuje na stanowisku Kierownika Działu Tech-
nologicznego w firmie Gamelion, wchodzącej
w skład Grupy BLStream. Jacek specjalizuje się
w programowaniu gier w oparciu o technolo-
gię JME. Grupa BLStream powstała, by efektyw-
niej wykorzystywać potencjał dwóch szybko roz-
wijających się producentów oprogramowania –
BLStream i Gamelion. Firmy wchodzące w skład
grupy specjalizują się w wytwarzaniu oprogra-
mowania dla klientów korporacyjnych, w roz-
wiązaniach mobilnych oraz produkcji i testowa-
niu gier.
Kontakt z autorem: jacek.zagrodzki@game-lion.com
A
53
 Programowanie gier

Efektywny blitter
Metody optymalizacji
Jak to jest, że jedne gry posiadają świetnie wyglądającą i płynną
grafikę, podczas gdy inne, mimo znacznie uboższego wyglądu, ledwo
sobie radzą z przerysowywaniem pola gry? Dlaczego u konkurencji na
ekranie może poruszać się całe mrowie przeciwników, podczas gdy u
nas już przy pięciu jest problem? Różnica tkwi w kunszcie programisty
odpowiedzialnego za niskopoziomową obsługę grafiki.
źródłowego i docelowego. Pierwszym zada-
Dowiesz się: Powinieneś wiedzieć: niem funkcji blitującej jest wyznaczenie prze-
• Jak znacznie przyspieszyć rysowanie grafiki; • Jak się robi gry. cięcia interesujących nas obszarów obu ob-
• Jak użytecznie posługiwać się kodem asem- razów, będzie to prostokąt, na którym prze-
blerowym; prowadzane będą zmiany. Czasami (przy-
• Że należy wierzyć pomiarom, a nie przeczu- padek numer 6) może się okazać, że część
ciom. wspólna nie występuje – wtedy nie pozostaje
nam nic innego jak wyjść z funkcji. W pozo-
stałych wypadkach musimy wyznaczyć sze-
funkcja prawie na pewno pozbawiona będzie reg zmiennych, które umożliwią nam potem
większości możliwych do zastosowania opty- szybkie przetwarzanie danych. Będą to na
Poziom malizacji. Optymalizacji, które wiążą się z po- przykład szerokość i wysokość obszaru prze-
trudności gorszeniem jakości wynikowej grafiki, a więc cięcia – używane jako liczniki wewnętrznej i
czegoś, co jest niedopuszczalne w uogólnio- zewnętrznej pętli rysowania, wskaźniki na le-
nym algorytmie blittera. Ale nie uprzedzaj- we górne (początkowe) piksele części wspól-
my faktów. nej obrazów, mapowane na ich współrzęd-

J
ak to? – ktoś może się oburzyć po prze-
czytaniu takiego wstępu, przecież od cza-
sów Windowsów 3.0 mamy akcelerację
operacji graficznych!. Już Amiga miała sprzęto-
wy blitter! – krzyknie ktoś inny. Jest to, oczy-
wiście, prawda, niemniej trzeba wziąć pod
uwagę fakt, że nie wszystkie dzisiejsze plat-
formy posiadają takie udogodnienia. Takie
na przykład telefony komórkowe. Widoczny
jest, co prawda, mniej lub bardziej raczkujący
trend wprowadzania pełnoprawnych akcele-
ratorów grafiki trójwymiarowej, które można
wykorzystać również do przyspieszania grafi-
ki 2D, ale po pierwsze, sprzęt ten jest dostęp-
ny tylko w modelach z najwyższej półki, a po
drugie, korzystanie z niego wiąże się z pew-
nymi ograniczeniami. Hardware'owych roz-
wiązań przyspieszających tylko i wyłącznie
grafikę dwuwymiarową na urządzeniach
przenośnych nie stwierdzono. No, może po-
za obecnymi na Nintendo DS wynalazkami
do obsługi duszków rodem z Atarynki.
Problem może być dla nas mało widocz-
ny, w sytuacji gdy używamy w naszej grze
zewnętrznych bilbliotek. Taki na przykład
SDL posiada implementację funkcji blitują-
cych jeden obraz na drugi. Sęk w tym, że taka
Blitter?
Blitter jest to specjalizowany sprzętowy
układ, mający za zadanie przenosić duże blo-
ki danych z jednego obszaru pamięci do dru-
giego. Jego nazwa bierze się od skrótu BLIT
– BLock Image Transfer, co można tłuma-
czyć jako blokowy transfer obrazu. Jak zo-
stało wcześniej wyjaśnione, nas interesować
będzie programowa implementacja algoryt-
mów wykonywanych przez tenże układ.
Funkcja realizująca zadanie blittera zawsze
musi przyjmować obraz źródłowy i docelowy.
W dobrym tonie byłoby również umożliwienie
wskazania miejsca, w którym na obrazie doce-
lowym ma się znaleźć obraz źródłowy, a zatem
dodatkowo należy przekazać parę współrzęd-
nych, które będą specyfikowały punkt zaczepie-
nia. Użyteczna jest również możliwość wyspe-
cyfikowania obszaru obrazu źródłowego, który
chcemy narysować. Dzięki temu będziemy mo-
gli przechowywać, przykładowo, 10 klatek ani-
macji na jednym obrazie, a podczas blitowania
podamy, która klatka (tj. obszar obrazu, który ją
zawiera) nas interesuje.
Rysunek 1 przedstawia niektóre możliwe
kombinacje wzajemnych położeń obrazów
ne. Potrzebować będziemy również informa-
cji o tym, ile bajtów należy przeskoczyć, aby
z ostatniego piksela w linii przenieść się do
pierwszego piksela w następnej linii, w obu
obrazach, ale ta wartość obliczona zostanie
później, zależy bowiem od szerokości piksela.
Wszystkie te zmienne zostały przedstawione
na Rysunku 2.
Moje piksele mają
szerokość równą jeden!
Na ekranie – prawdopodobnie tak, ale nas,
jako programistów, bardziej interesuje szero-
kość bitowa. Czy też może – w szerszym zna-
czeniu – format piksela. Czym się różni jed-
no od drugiego? Mówiąc o szerokości bitowej
, myślimy o kolorze ośmio-, szesnasto-, dwu-
dziestocztero- czy trzydziestodwu-bitowym.
Jednak powiedzenie, że jeden piksel zajmu-
je 32 bity, jest dla nas niewystarczające. Ja-
kie jest ułożenie kanałów w tych 32 bitach?
RGBA? ARGB? ABGR? Każda z kombina-
cji jest poprawna, co więcej, na każdą z nich
można się natknąć przy różnych okazjach.
Dlatego dopiero powiedzenie, że format pik-
sela to, od najmłodszych bitów, 8 bitów kana-
łu alfa, 8 bitów kanału niebieskiego, osiem bi-

54 02/2010
 Efektywny blitter

tów kanału zielonego i osiem bitów kanału
czerwonego, jest dla nas satysfakcjonujące.
Mogłoby się wydawać, że im więcej bitów
mamy na każdy kanał, tym lepiej będzie wy-
glądała finalna grafika, prawda? W teorii tak,
w praktyce nie bardzo. Przykładowo, Nokia
szczyci się, że niektóre jej telefony mają ekra-
ny zdolne wyświetlić 16 milionów kolorów
(kolor 24-bitowy). Dobry dowcip. Na 24 bi-
tach (a raczej na 32, żeby dane były wyrów-
nane do szerokości słowa) kolory, owszem, są
trzymane. Ale podczas wyświetlania z każdej
składowej obcinane są dwa najmłodsze bity,
przez co tak naprawdę otrzymujemy kolor 18-
bitowy (po 6 bitów na składową). Należy sobie
zadać pytanie – czy dla marnych dwóch bitów
opłaca się implementować wszystkie operacje
graficzne tak, by działały z kolorem 32-bito-
wym zamiast użyć po prostu koloru 16-bito-
wego? Jakby nie patrzeć, oznacza to dwukrot-
ne zwiększenie liczby danych przesyłanych
z/do pamięci, czego zignorować nie możemy.
Udało nam się zatem dokonać pierwszej opty-
malizacji blittera – zakładamy, że powierzch-
nia ekranowa (a więc ta, na której będziemy w
większości przypadków rysowali) zawsze bę-
dzie miała głębokość szesnastu bitów.
Bardzo ważną, a zarazem niezwykle ba-
nalną optymalizacją działania blittera jest
zapewnienie odpowiedniego formatu pikse-
la obrazów źródłowych. Przykładowo, jeżeli
chcemy rysować na obrazie, który ma format
565 (po 5 bitów na składowe czerwoną i nie-
bieską, 6 na składową zieloną), to należy spra-
wić, oczywiście w miarę możliwości, by ob-
raz źródłowy również miał format 565. Dzię-
�� ��
ki temu blitowanie można zaimplementować
za pomocą prostej pętli kopiującej. Natomiast
gdyby obraz źródłowy miał format 888, dla
każdego piksela należałoby przeprowadzać
konwersję do formatu obrazu docelowego. Po
wykonaniu testów okazało się, że blitowanie
565 –> 565 trwa 1,23 milisekund, a blito-
wanie 888 –> 565 trwa 5 ms. Różnica chyba
całkiem spora. Tutaj coś, na co warto zwrócić
uwagę: graficy, jak to artyści, zbyt dużej uwa-
gi do zagadnień technicznych nie przykłada-
ją. Lepiej im patrzeć na ręce, żeby się potem
nie okazało, że całoekranowa bitmapa tła po-
siada kanał alfa, przez co przelatuje niezmie-
niona przez nasz sprytny automatyczny kon-
werter zamieniający wszystkie ładowane ob-
razy mające format 888 (bez kanału alfa) na
format 565. W efekcie, zamiast prostego ko-
piowania pamięci musimy przeprowadzić
operację blendingu.
Optymalizacja kopiowania
Implementacją funkcji blitujących jako ta-
kich zajmować się tu nie będziemy. Dość po-
wiedzieć, że są to pętle podobne do tej z Li-
stingu 1. Na podstawie tej pętli, realizującej
kopiowanie 565 –> 565, można stworzyć
wszystkie inne, dodając tylko odpowiednie
konwersje formatów piksela.
Czy taką, optymalnie napisaną wydawało-
by się pętlę można jeszcze przyspieszyć? Oka-
zuje się, że zastąpienie wewnętrznej pętli sys-
temową funkcją memcpy przyspiesza wykona-
nie funkcji prawie trzykrotnie. Jest to rezultat
zdecydowanie nieintuicyjny, w końcu zastępu-
jemy banalne przepisywanie w pętli wielokrot-
��
��������������
��������������
nym wywoływaniem funkcji, co nie może być
szybkie, w końcu muszą zostać przekazane pa-
rametry (przez stos), funkcja zwraca też pew-
ną wartość, która nie jest nam potrzebna, ale
zwrócona zostać musi... A jednak. Tylko i wy-
łącznie zbadanie rzeczywistej szybkości wy-
konywania kodu na urządzeniu jest w stanie
stwierdzić, czy zastosowana przez nas opty-
malizacja nie jest tylko optymalizacją. Przykła-
dowo, podczas prac nad przyspieszaniem pew-
nego kawałka kodu udało się zastąpić opera-
cję mnożenia prostymi bitowymi operacjami
logicznymi. Mogłoby się wydawać, że prze-
sunięcia bitowe są szybsze od powolnego ob-
liczania iloczynu, że wyeliminowanie mno-
żenia z pewnością przyspieszy działania algo-
rytmu. Po przeprowadzeniu testów wydajno-
ściowych okazało się, że wersja z mnożeniem
jest szybsza. Morał jest prosty: nigdy nie należy
ufać swojemu przeczuciu, zawsze należy opie-
rać się na twardych pomiarach.
Załóżmy jednak, niech będzie to ekspery-
ment myślowy, że funkcja memcpy nie istnieje,
zmuszeni jesteśmy używać własnoręcznie na-
pisanej pętli kopiującej. Czy w takiej sytuacji
Listing 1. Pętla blitująca
void Blit565To565( … )
{
do
{
int w = width;
do
{
*dst++ = *src++;
}
while( --w );
dst += dstSkip;
src += srcSkip;
}
while( --height );
}

Listing 2. Wewnętrzna pętla programu z

�� �� �� Listingu 1

.L5:
ldrh r5, [r0], #2
subs ip, ip, #1
strh r5, [r1], #2 @ movhi
Rysunek 1. Niektóre z możliwych wzajemnych konfiguracji obrazów podczas blitowania
bne .L5

Listing 3. Odwinięcie pętli

��������� UInt32 w = width / 4;

do
��������

�������������������
������� ������������������� {
��������� ��������������������
����������������� *dst++ = *src++;
*dst++ = *src++;
���������������������������� ���������������������������� *dst++ = *src++;
����������������������������� �������������������������� *dst++ = *src++;
����������������������
}
while( --w );
Rysunek 2. Zmienne używane podczas blitowania

www.sdjournal.org 55
 Programowanie gier
można w jakiś sposób przyspieszyć program z
Listingu 1? Spójrzmy, jak wygląda wewnętrz-
na pętla po skompilowaniu (Listing 2). Mne-
moniki ldrh i strh odpowiednio ładują i
zapisują 16-bitową wartość z/do pamięci,
zwiększając jednocześnie wskaźnik o 2 bajty.
Instrukcja subs zmniejsza licznik pętli, a bne
wykonuje skok (następną iterację pętli), jeżeli
wynik odejmowania jest różny od zera. Widać
tu jasno, że tylko 50% wykonywanych przez
procesor instrukcji odnosi się do kopiowania
pamięci, a więc tego, co nas najbardziej inte-
resuje. Oczywiście, ocenić relatywnego czasu
wykonywania poszczególnych instrukcji nie
sposób, przynajmniej bez posiadania symu-
latora procesora na poziomie bramek logicz-
nych. Mamy tu wszak instrukcje zapisu i od-
czytu z pamięci (duże opóźnienie!), co praw-
da dostęp jest sekwencyjny, więc cache znacz-
nie przyspiesza działanie, ale konkretnie, o ile
procent? Modyfikacje licznika pętli są na po-
ziomie rejestrów procesora, ale operacja sko-
ku czeka, aż ALU obliczy wynik odejmowa-
nia... Na szczęście kompilator sprawia się nad-
zwyczaj dobrze, przeplatając obsługę licznika
pętli z działaniami operującymi na pamięci,
co minimalizuje czas oczekiwania na zakoń-
czenie operacji zależnej.
Dygresje na bok, chcemy zmaksymalizo-
wać liczbę operacji na pamięci, minimalizu-
jąc jednocześnie liczbę operacji potrzebnych
do obsługi pętli. Listing 3 przedstawia pętlę
odwiniętą 4 razy. Nie da się tu oczywiście nie
zauważyć poważnego problemu: pętla dzia-
ła tylko dla szerokości będących wielokrot-
nościami czwórki. Aby kod działał popraw-
nie, należy wpierw obsłużyć ułamkową część
szerokości. Można też zintegrować odwinię-
cie pętli z obsługą części ułamkowej w całość.
Jak? Za pomocą mechanizmu Duffa (Duff's
device). Przykład wykorzystania tej techniki
przedstawiony został na Listingu 4. To dzi-
Rysunek 3. Jedna z grafik wykorzystanych w
grze Boom Letters firmy Gamelion
56
waczne przeplecenie instrukcji switch z pę- wi nas tych wartości. Podobnie, podczas skła-
tlą do .. while jest jak najbardziej legalną kon- dania finalnej wartości piksela nie ma sensu
strukcją w języku C, co więcej, realizuje do- obcinanie najmłodszych trzech bitów ze skła-
kładnie taką funkcjonalność, jaką właśnie te- dowej niebieskiej, ponieważ i tak za chwi-
raz potrzebujemy. Spójrzmy na Listing 5, któ- lę wykonywane jest przesunięcie bitowe. Po
ry przedstawia zapis asemblerowy powyższej wprowadzeniu modyfikacji wynikowy kod
pętli. 80% instrukcji dotyczy odczytu/zapisu asemblerowy zmniejszył się o jedną instruk-
pamięci, a tylko 20% zajmuje się sprawdza- cję. Nie jest to może jakaś ogromna zmiana,
niem warunku końca pętli! Jednocześnie wi- ale na początek wystarczy.
dzimy, że w środku pętli obecne są punkty Czym by się można teraz zająć? Może spró-
wejścia dla różnych wartości części ułamko- bujmy popatrzeć na matematykę, w końcu
wej szerokości. sześć mnożeń musi nieźle spowalniać nasz
Nie należy się zbytnio przejmować tym, że kod. Spójrzmy na to, w jaki sposób wykony-
w przykładzie pętla została odwinięta cztery wana jest interpolacja koloru źródłowego z
razy. W rzeczywistości może zostać wykorzy- docelowym (tutaj wartość alfa będzie w za-
stana dowolna liczba, chociaż dobrze byłoby kresie 0 – 1, a nie 0 – 255):
się wpierw zastanowić, czy nie należałoby
użyć którejś z potęg dwójki. Wszak żeby ob- d = s * a + d * ia
liczyć wynik i resztę z dzielenia przez takie
liczby, wystarczy wykonać proste operacje bi- Rozwińmy ia :
towe. Koniecznie należy za to przeprowadzić
testy szybkości dla każdej sprawdzanej licz- d = s * a + d * ( 1 – a )
by odwinięć. Przykładowo, wykorzystanie
mechanizmu Duffa w kodzie zmieniającym O, jakoś to teraz wygląda. Rozwijajmy dalej:
format dźwięku, przy ośmiokrotnym odwi-
nięciu pętli, przyspieszyło wykonanie pętli z d = s * a + d – d * a
4,60 ms do 4,16 ms. Szesnastokrotne odwi-
nięcie pętli zmieniającej głośność dźwięku Listing 4. Mechanizm Duffa
spowodowało spadek czasu potrzebnego na
wykonanie pętli z 13,25 ms do 10,26 ms. UInt32 w = ( width + 3 ) / 4;
switch( width % 4 )
Blending {
Czyli innymi słowy mieszanie. Złożenie czę- case 0:
ści jednego koloru z proporcjonalnie odwrot- do
ną częścią innego koloru. Występuje wszę- {
dzie tam, gdzie wykorzystywana jest wartość *dst++ = *src++;
alfa. Należy tu zwrócić uwagę, że podczas bli- case 3:
towania wartość alfa piksela pochodzi tak na- *dst++ = *src++;
prawdę z dwóch źródeł. Pierwszym jest, o case 2:
ile występuje, kanał alfa obrazu źródłowego. *dst++ = *src++;
Drugim źródłem jest globalna wartość alfa, case 1:
opcjonalnie podawana do funkcji blitującej. *dst++ = *src++;
Dopiero połączenie globalnej wartości z war- }
tością z kanału alfa, inną dla każdego piksela, while( --w );
daje nam finalną wartość alfa, która powinna }
zostać użyta podczas rysowania.
Do rzeczy jednak. Listing 6 przedstawia Listing 5. Skompilowany program z
naiwną implementację blittera 8888 –> 565. Listingu 4
Kod, rzecz oczywista, działa zgodnie z ocze- .L7:
kiwaniami, jednak prędkość jest zdecydowa- ldrh r6, [r0], #2
nie niesatysfakcjonująca. Wystarczy spojrzeć strh r6, [lr], #2 @ movhi
na liczbę operacji wykonywanych dla każde- .L10:
go piksela, aby wiedzieć czemu (Listing 7). ldrh r6, [r0], #2
30 instrukcji asemblera, 6 mnożeń, na szczę- strh r6, [lr], #2 @ movhi
ście tylko 2 odczyty z pamięci i jeden zapis. .L11:
No, mogłoby być lepiej. Optymalizację mo- ldrh r6, [r0], #2
żemy zacząć od wyrzucenia z kodu niepo- strh r6, [lr], #2 @ movhi
trzebnych operacji, które co prawda mają ja- .L12:
kiś wpływ na czytelność, ale nas interesuje jak ldrh r6, [r0], #2
największa wydajność. Aby pobrać ze źródło- subs ip, ip, #1
wego piksela wartość alfa, nie ma sensu usu- strh r6, [lr], #2 @ movhi
wanie kanałów R, G i B, ponieważ przesunię- bne .L7
cie w prawo o 24 bity automatycznie pozba-
02/2010
 Efektywny blitter

A teraz wyciągnijmy wartość alfa przed na-
wias:
d = d + a * ( s – d )
Sukces! Udało nam się wyeliminować jedno
mnożenie! A ponieważ przetwarzamy trzy
kanały, rzeczywista liczba mnożeń spada z
sześciu do trzech. Liczba instrukcji asemble-
ra pozostała niezmieniona, ale czy to ozna-
cza, że kod będzie się wykonywał tyle sa-
mo czasu? Należy wykonać pomiary i wy-
ciągnąć wnioski, co niech zostanie zadaniem
dla czytelnika.
Trzy mnożenia na piksel to całkiem do-
bry wynik, liczby kanałów zmienić się nie
da, a mnożenia przez wartość alfa też raczej
nie wyeliminujemy. Czy spoczniemy zatem
na laurach? Nie, zmniejszymy liczbę mno-
żeń z trzech do jednego. Niemożliwe? Ha! W
chwili obecnej przetwarzamy 8-bitowe war-
tości na 32-bitowych rejestrach. Przy mnoże-
niu przez 8-bitową alfę wykorzystane jest tyl-
ko 16 bitów. Co by było, gdyby zostawić star-
sze 8 bitów w młodszym 16-bitowym słowie
na wynik mnożenia, a w górnym 16-bitowym
słowie wstawić drugi kanał? Popatrzmy:
0606 * 5 / 10 = 3030 / 10 = 0303
Działa! Na obsługę trzech kanałów zabrak-
nie nam jednak miejsca w rejestrze. Zauważ-
my jednak, że docelowy format piksela to i
tak 565. Rozpiszmy to sobie:
RRRRRGGGGGGBBBBB
Hmm... A gdyby tak...
00000GGGGGG00000RRRRR000000BBBBB
Udało nam się zmieścić trzy kanały w 32 bi-
tach, zostawiając miejsce na wynik mnoże-
nia, dzięki czemu możemy obliczyć wartości
wszystkich kanałów, wykonując tylko jedno
mnożenie. Oczywiście należy zauważyć kil-
ka rzeczy. Kolory z obrazu źródłowego muszą
zostać stratnie przekształcone z formatu pik-
sela 888 na 565. Musimy również użyć 5-bi-
tową alfę, żeby zmieścić się w buforach. Stra-
ta jakości, może się wydawać, dosyć znaczna,
jednak w rzeczywistości jest praktycznie nie-
zauważalna. Implementacja tej optymalizacji
przedstawiona jest na Listingu 8. To, co się
dzieje w środku pętli, jest czarną magią w po-
równaniu z poprzednią wersją, ale spójrzmy
na Listing 9. Liczbę mnożeń udało się zredu-
kować do jednego, a liczba wykonywanych in-
strukcji asemblera spadła do 21! Dobrze rów-
nież zauważyć, iż mimo wielu operacji odczy-
tu z pamięci (z tego samego adresu) w kodzie
wysokopoziomowym, kompilator był w sta-
nie wygenerować tylko jeden rzeczywisty do-
stęp do pamięci.
Może się wydawać, że tego to już się na pew-
no bardziej nie da zoptymalizować. Ale proszę
się zastanowić, czy 21 instrukcji asemblera to
nie jest troszkę za dużo, w przypadku gdy war-
tość alfa jest równa 0, a więc piksel powinien

Rysunek 4. Animacja postaci w grze Tiger Woods PGA Tour

Listing 6. Naiwny blitter 8888 –> 565 Listing 7. Skompilowany program z Listingu 6

UInt32* src; .L5:

UInt16* dst; ldrh r4, [r8, #0]
ldr ip, [sl], #4
do and r2, r4, #2016
{ mov lr, ip, lsr #24
int w = width; rsb r0, lr, #255
do mov r1, r2, asr #3
{ and r3, r4, #63488
UInt32 a, ia, sr, sg, sb, dr, dg, db; mov r6, r3, asr #8
a = ( *src & 0xFF000000 ) >> 24; and r5, r4, #31
ia = 255 – a; mul r4, r0, r1
mov r2, r5, asl #3
sr = ( *src & 0x00FF0000 ) >> 16; mul r5, r0, r6
sg = ( *src & 0x0000FF00 ) >> 8; and r1, ip, #65280
sb = ( *src & 0x000000FF ); mul r6, r0, r2
dr = ( *dst & 0xF800 ) >> 8; mov r3, r1, lsr #8
dg = ( *dst & 0x07E0 ) >> 3; and r0, ip, #16711680
db = ( *dst & 0x001F ) << 3; mla r1, lr, r3, r4
mov r2, r0, lsr #16
dr = ( sr * a + dr * ia ) >> 8; mla r3, lr, r2, r5
dg = ( sg * a + dg * ia ) >> 8; and ip, ip, #255
db = ( sb * a + db * ia ) >> 8; mla r2, lr, ip, r6
mov r0, r1, lsr #5
*dst = ( ( dr & 0xF8 ) << 8 ) | ( ( dg & 0xFC ) << 3 ) | ( ( db & 0xF8 ) >> and ip, r3, #63488
3 ); and r1, r0, #2016
orr r0, ip, r1
src++; mov r2, r2, asl #16
dst++; orr r3, r0, r2, lsr #27
} subs r7, r7, #1
while( --w ); strh r3, [r8], #2 @ movhi
} bne .L5
while( --height );

www.sdjournal.org 57
 Programowanie gier

być po prostu przeskoczony bez zmian? A je-
żeli alfa jest równa 255 – nie ma potrzeby wy-
konywania blendingu, można po prostu sko-
piować (po zmianie formatu piksela) wartość
z obrazu źródłowego do docelowego. Są to rze-
czy, wydaje się, oczywiste, ale kto o tym wcze-
śniej pomyślał? Koszt związany z obsługą róż-
nych zachowań w zależności od alfy nie jest
oczywiście zerowy, ale spójrzmy na pomiary
szybkości wykonywania. Blitowanie obrazu, w
którym wszystkie piksele mają wartość kanału
alfa równą 0, zajęło 4,34 ms. Dla wartości alfa
równych 255 było to 7,43 ms. Dla innych war-
tości, czyli wtedy gdy musiał być wykonywany
blending, rysowanie trwało 15,57 ms. Różni-
ca dosyć znaczna! Szczególnie gdy w progra-
mie wykorzystujemy grafiki takie jak przedsta-
wiona na Rysunku 3. Aby uzyskać zadowalają-
cą liczbę klatek na sekundę przed wprowadze-
niem optymalizacji polegającej na zmianie za-
chowania w zależności od wartości alfa, grafi-
ka musiała zostać pocięta na kilka mniejszych.
Zauważenie problemu umożliwiło użycie nie-
pociętej grafiki bez spadku wydajności, równo-
cześnie zmniejszając nakład pracy grafików.
O takich rzeczach, jak wczesne wyjście z
funkcji, w przypadku gdy użytkownik podał
globalną wartość alfa równą 0, chyba nie trze-
ba mówić.
Problemy z pamięcią
Podczas prac nad grą Tiger Woods PGA Tour
dla firmy Electronic Arts pojawił się dość nie-
oczekiwany problem. Blitter co prawda był
szybki, ale zostały zupełnie zaniedbane wy-
magania pamięciowe. Przedstawiona na Ry-
sunku 4 animacja ma rozmiar 2987x103
piksele i, przy 32-bitowym kolorze, zajmu-
je w pamięci 1,17 MB. Co gorsza, w pamię-
ci musiały się jednocześnie znajdować jesz-
cze 3 inne animacje o podobnych rozmia-
rach. Przy ograniczeniu możliwej do użycia
pamięci do 10 MB (wymaganie platformy)
stało się to znacznym problemem. Pewnym
rozwiązaniem byłoby użycie obrazu z paletą,
co zmniejszyłoby zużycie pamięci czterokrot-
nie, jednak oznaczałoby to znaczną degrada-
cję jakości obrazu, chociażby przez utratę an-
tyaliasingu czy przezroczystości cieni.
Problem został usunięty przez zastosowanie
kompresji RLE (Run Length Encoding). Polega
ona na ustaleniu kodów operacji, które potem
są odpowiednio interpretowane przez blitter.
Przykładowo, kod 0 niech odpowiada ciągowi
pikseli przezroczystych (w ciągu danych zapisa-
na jest długość ciągu obejmowanego przez kod),
kod 1 może odpowiadać pikselom nieprzezro-
czystym (zapisujemy dodatkowo długość cią-
gu i wartości pikseli, dla szybkości można użyć
formatu docelowego, e.g. 565), piksele półprze-
zroczyste mogą być opisane kodem 2 (plus dłu-
gość i wartości pikseli razem z kanałem alfa). To
oczywiście tylko przykład. Analizę obrazów
podczas kompresji można rozszerzyć o wykry-
wanie obszarów takiego samego koloru, obsza-
rów ze stałą wartością alfa, gradientów itp. Blit-
ter interpretujący kod 0 może w tym momen-
cie przeskoczyć o zapisaną liczbę pikseli, w ogó-
le ich nie przetwarzając. Interpretacja kodu 1
sprowadza się do wywołania funkcji memcpy
– odpada konieczność konwersji pikseli z for-
matu 888 na 565 przy każdym rysowaniu.
Po zastosowaniu powyższej metody obszar
pamięci zajmowany przez animację z Rysun-
ku 4 został zmniejszony do 122 KB. Dziesię-
ciokrotne zmniejszenie, chyba całkiem nie-
źle? Operacja kompresji może być na tyle
szybka, aby dało się ją wykonywać podczas ła-
dowania obrazów z dysku, ale dużo lepszym
rozwiązaniem jest wykonanie jej tylko raz
– podczas tworzenia assetów programu. Wy-
nikowy rozmiar na dysku może być co praw-
da większy – PNG z animacją zajmował 99,6
KB, a po kompresji RLE 121 KB, ale należy
pamiętać, że obraz w formacie RLE lepiej
się kompresuje. Po spakowaniu obrazu PNG
programem 7zip rozmiar wynikowego archi-
wum wyniósł 99,2 KB, a obraz RLE skompre-
sował się do 45 KB. Nie dość, że zmniejsza-
ją się wymagania pamięciowe, zmniejsza się
więc również zajętość dysku przez aplikację.
Co dalej?
Przedstawione techniki w żadnym razie nie
wyczerpują możliwych do zastosowania roz-
wiązań. Z całą pewnością da się wymyślić
jeszcze wiele innych sposobów na przyspie-
szenie programowego rysowania obrazów,
czego czytelnikom życzę. Pewną pomocą mo-
że być książka Graphics Programming Black
Book autorstwa Michaela Abrasha, traktu-
jąca co prawda o sprzęcie trochę przestarza-
łym, ale pełna wielu świetnych pomysłów i
wskazówek. Książkę można ściągnąć za dar-
mo pod adresem http://nondot.org/~sabre/
Mirrored/GraphicsProgrammingBlackBook/.
BARTOSZ TAUDUL
Bartosz Taudul zajmuje się, pośród wielu innych
rzeczy, rozwojem i optymalizacją niskopoziomo-
wych procedur graficznych w wieloplatformo-
wej bibliotece opracowywanej w firmie Gamelion
wchodzącej w skład Grupy BLStream.
Kontakt z autorem: wolf@pld-linux.org
Listing 9. Skompilowany program z
Listingu 8

Listing 8. Jednoczesne przetwarzanie wszystkich kanałów .L5:

ldr r0, [r5], #4
do ldrh r2, [r4, #0]
{ and r3, r0, #248
int w = width; and ip, r0, #16252928
do and r1, r2, #2016
{ mov r3, r3, lsr #3
UInt32 a, tmp; orr r2, r2, r1, asl #16
a = *src >> 24; orr r3, r3, ip, lsr #8
and r1, r0, #64512
tmp = ( ( *dst | ( ( *dst & 0x07E0 ) << 16 ) ) & 0xFFFFF81F ) + ( ( ( ( ( ( orr ip, r3, r1, asl #11
*src & 0xF80000 ) >> 8 ) | ( ( *src & 0x0000F8 ) >> 3 ) | ( bic r2, r2, #2016
( *src & 0x00FC00 ) << 11 ) ) - ( ( *dst | ( ( *dst & 0x07E0 rsb r3, r2, ip
) << 16 ) ) & 0xFFFFF81F ) ) * a ) >> 5 ); mov r0, r0, lsr #24
*dst = ( tmp & 0xF81F ) | ( ( tmp & 0x07E00000 ) >> 16 ); mul r1, r0, r3
add ip, r2, r1, lsr #5
src++; and r3, ip, #132120576
dst++; bic r0, ip, #2016
} orr r2, r0, r3, lsr #16
while( --w ); subs lr, lr, #1
} strh r2, [r4], #2 @ movhi
while( --height ); bne .L5

58 02/2010
 Programowanie gier

Xcode
Xcode – oto czytelnik. Czytelniku – oto Xcode. Poznajcie się.
Wprowadzenie do programowania najpopularniejszego
urządzenia mobilnego na świecie.
iPhone i App Store to światowy fenomen. Firma Apple dokonała
niemożliwego i uwolniła wielką siłę niezależnych developerów mogących
od teraz spełniać swoje wizje i tworzyć gry jak dawniej, w pojedynkę lub
w małych zespołach, siedząc nad nimi po pracy, w garażach.
Krok drugi
Dowiesz się: Powinieneś wiedzieć: – ściągnięcie i zainstalowanie
• Co potrzebne jest do programowania gier • Podstawy obsługi Xcode; odpowiednich materiałów
na iPhone’a; • Znać podstawy C++ i Objective-C; Po pomyślnej rejestracji na portalu pracę czas
• Jak zacząć pracę nad grą i jakie są etapy jej • Przeczytać artykuł dotyczący programowa- zacząć! W zależności od zainstalowanego OS-u
produkcji; nia na iPhone; na Macu należy ściągnąć i zainstalować SDK
• Jak warto zorganizować sobie strukturę pro- • Podstawowe informacje na temat develop- w wersji Leopard bądź Snow Leopard. SDK
jektu. mentu gier. zawiera:

• Xcode – środowisko pozwalające

ga płatna w wysokości $99 (lub 299 dla du-
żych firm) pozwala na uruchamianie aplikacji
Poziom na sprzęcie i późniejszą dystrybucję aplikacji
trudności na App Store. Prócz tego płatna rejestracja da-
je większy dostęp do bazy wiedzy i przykładów
przygotowanych przez Apple. Niezbędne będą
takie dane, jak numery konta, informacje o ban-
na programowanie/kompilowanie/
uruchamianie stworzonej aplikacji,
• iPhone simulator – symulator iPhone po-
zwalający na uruchomienie stworzonej
aplikacji, jej testowanie i debugowanie,
• Tools – zestaw dodatkowych narzędzi
pozwalających na łatwiejsze i sprawniej-

D
o napisania gry wymagany jest ku. Należy przy tym pamiętać, że wszelkie przy- sze programowanie i tworzenie aplika-
komputer Mac, co może wiązać chody z App Store należy rozliczyć z Urzędem cji. Jednym z ciekawszych narzędzi jest
się z wydatkiem zaczynającym się Skarbowym. Tak głosi prawo. Instruments pozwalający na dokładne i
w okolicach dwóch tysięcy złotych. Do testo-
wania dzieła na pewno też dobrze mieć do-
celowe urządzenie – iPhone’a lub iPoda To-
uch. Gdy już te absolutnie podstawowe wa-
runki zostają spełnione, nic (lub prawie nic)
nie stoi na przeszkodzie, by rozpocząć pracę
nad grą marzeń. Z tym, co stanąć może, po-
staramy się rozprawić w poniższym artykule.
Zapraszamy do lektury.

Krok pierwszy
– rejestracja na portalu
Czas zacząć. Zdecydowanie pierwszym kro-
kiem powinno być zarejestrowanie na oficjal-
nym portalu developerskim Apple dostęp-
nym pod adresem:
http://developer.apple.com/iphone/
Dzięki temu developer będzie mógł korzy-
stać ze wszystkich zasobów i informacji poma-
gających w programowaniu na iPhone OS. Sa-
ma rejestracja podzielona jest na dwie części.
Pierwsza darmowa umożliwia ściąganie SDK
i uruchamianie aplikacji na symulatorze. Dru- Rysunek 1. Ekran powitalny Xcode IDE

60 02/2010
 Xcode

Stwórzmy grę! nie lada doświadczenia i wiedzy. Profesjonalne

Rysunek 2. Ekran powitalny symulatora iPhone
szybkie namierzenie problemów związa-
nych z zarządzaniem pamięcią.
Krok trzeci
– odpalenie środowiska i stwo-
rzenie przykładowej aplikacji
Do tego celu służy środowisko Xcode. Jest to
główne narzędzie SDK pozwalające na tworze-
nie aplikacji, testowanie, uruchamianie i przy-
gotowywanie wersji na urządzenie. Sercem ze-
stawu narzędzi Xcode jest Xcode IDE – graficz-
ny kombajn zawierający profesjonalny text editor,
system tworzenia aplikacji, debugger oraz kom-
pilator. Więcej o Xcode można przeczytać pod
adresem: http://developer.apple.com/tools/Xcode/.
Wiele gier powstaje, bazując na już istnieją-
cych produktach. Warto jednak sięgnąć po
własny produkt, którym zawojujemy rynek.
Pomysł – skąd go wziąć?
• burza mózgów.
Twórcze głowy zasiadają do stołu (na łące,
w pubie itd.) i snują pomysły, dzieląc się swo-
imi przemyśleniami. Wyznaczona osoba no-
tuje. Zakaz krytykowania i wyśmiewania
pod groźbą stawiania kolejki.
• analiza rynku (co na rynku robi konku-
rencja, na co jest popyt, czego brakuje?);
• przypadkowe olśnienie. Czasami uderza
znienacka, czasami pod wpływem jakiejś
innej gry. App Store pełen jest takich gier,
wiele z nich odnosi sukces właśnie dzięki
nieprzewidywalności i oryginalności.
Strona organizacyjna produkcji gry
Czasy, w których każda gra powstawała w zaci-
szu domowym i była tworzona przez jedną lub
dwie osoby, dawno odeszły do lamusa. Aktual-
nie w tworzenie gry bardzo często zaangażowa-
nych jest wiele osób. W zależności od wielkości
projektu może to być 4 lub nawet 400 osób.
Aby poprawnie zarządzać taką ekipą, trzeba
i zdroworozsądkowe podejście do sprawy wy-
maga stworzenia planu produkcji gry. Dzieje się
to w pierwszym etapie zwanym zazwyczaj pre-
produkcją. Podczas tego etapu liderzy projektu
wraz z producentem, bazując na GDD i TDD,
gry przygotowują zadania dla poszczególnych
członków zespołu.
Niezbędne narzędzia
w procesie developmentu gry
Do sprawnej organizacji całego przedsięwzię-
cia przydadzą się różne narzędzia. Pozwolą
one na łatwiejszą, sprawniejszą i szybszą pra-
cę całego zespołu. W dzisiejszych dniach two-
rzenie gry wymaga takich narzędzi jak:
• Managing tools – pozwalają na stworze-
nie planu, przydzielenia zadań członkom
zespołu i koordynację całego procesu pro-
dukcji. Najbardziej znanym komercyjnym
rozwązaniem jest Microsoft Project. Ist-
nieją także alternatywne darmowe roz-
wiązania takie jak np. dotProject.;
• Bugtracking – dzięki niemu zarządzanie
błędami, które mogą wystąpić w trakcie
trwania projektu staje się dużo prostsze,
przejrzystsze i szybsze. Do najpopular-
niejszych bugtrackerów należą: Mantis,
Bugzilla czy Track Studio;

����
����������
�����������������
�����������
����������������
�����������������

��������������
������������������������������
����������������������������
�������������������������
��������������������������������������������������������������������
������������������������������
���������������������������
����������������������������������

Rysunek 3. Boozle – gra firmy Vivid Games

inspirowana pomysłami z firmowej imprezy Rysunek 4. Przykładowy szkielet głównej klasy w grze zaprojektowany za pomocą UML

Na Skróty
• SDK (ang. Software Development Kit) – Zestaw narzędzi dla programistów niezbędny do stworzenia aplikacji korzystającej z określonych
funkcji pod określonym systemem operacyjnym.
• App Store – Sklep online firmy Apple pozwalający na zakup cyfrowych produktów, między innymi gier na iPhone’a.
• GDD (ang. Game Design Document) – Dokument zawierający wszystkie wymagane informacje pozwalające na stworzenie gry. Tworzony jest
przez “Game Designera”
• TDD (ang. Technical Design Document) – Techniczna wersja GDD opisująca wszelkie zagadnienia dotyczące gry od strony technicznej.
• API (ang. Application Programming Interface) – Interfejs programowania aplikacji umożliwiający komunikację z systemem operacyjnym, bi-
blioteką bądź innym zewnętrznym systemem.
• Cocoa – Jedno z pięciu głównych API systemu operacyjnego Mac OS X firmy Apple,
• Xcode – Zintegrowane środowisko programistyczne firmy Apple. Służy do tworzenia aplikacji i innego oprogramowania przeznaczonego
m. in. na system Mac OS X.
• UML (ang. Unified Modeling Language) – Zunifikowany Język Modelowania służący do opisu świata obiektów w analizie obiektowej oraz
programowaniu obiektowym.

www.sdjournal.org 61
 Programowanie gier

• Time manager – zestaw narzędzi pozwa- dzo często zintegrowany jest on bezpo- Tworzenie gry krok po kroku
lający na organizację czasu pracowni- średnio z narzędziami służącymi do za- Etapy produkcji gry dzieli się na następujące
ków, ich czasu pracy przy projekcie. Bar- rządzania projektem. fazy produkcji:

• Preproduction – Etap planowania gry.

W trakcie jego trwania powstaje cały
plan produkcji i lista zadań do wyko-
nania przez poszczególnych członków
zespołu.
• First playable – wynikiem tego etapu
jest pierwsza wersja gry pozwalająca
na sprawdzenie, czy założenia dotyczą-
ce grywalności ustalone w czasie pre-
produkcji sprawdzają się w rzeczywi-
stości.
• Alpha – Na zakończenie tej części pro-
jektu powstaje pełna wersja gry, mo-
że jednak ona zawierać różnego rodzaju
błędy w funkcjonalności. Według najpo-
pularniejszych metod prowadzenia pro-
jektów, wersja Alpha powinna jednak
być już całkowicie wyposażona w tryby
gry, teksty, grafiki itd.
• Beta – Etap projektu, w którym głów-
ną uwagę spędza się na naprawianiu błę-
dów i szlifowaniu finalnego produktu.
• Release Candidate – Po zakończeniu te-
go etapu powstaje pierwsza wersja będąca
kandydatem do wydania gry. Jest to w peł-
ni stabilna, niezawierająca błędów gra.
Rysunek 5. Przykładowy szkielet głównej klasy w grze w języku Java • Gold Master – Powstający w tym czasie
produkt jest finalną wersją gry, która do-
stępna jest dla graczy.
Debugowanie i naprawianie błędów • Localization – Etap, w którym gra jest lo-
Pakiet Xcode zawiera w swoim zestawie bardzo ciekawą i pomocną aplikację o nazwie In-
struments. Dzięki niej jesteśmy w stanie podglądać wiele rzeczy podczas pracy aplikacji na kalizowana na różne języki. W tym cza-
symulatorze bądź na iPhonie. Program ten pozwala między innymi na: sie powstają alternatywne wersje języko-
we gry bądź jedna wersja z możliwością
• przeglądanie stanu pamięci wyboru języków.
Możesz śledzić zmiany alokacji pamięci dla wybranej aplikacji. Dzięki temu łatwo i przyjemnie
• Marketing – Po zakończonych etapach
można namierzyć największe „pochłaniacze” pamięci. Jest to dość istotne, gdyż należy pamię- ukończony produkt jest gotowy do wyda-
tać, że iPhone to tylko telefon i jego zasoby są ograniczone. Najbezpieczniejszą granicą, której nia, aby jednak osiągnął sukces, muszą po-
nie warto przekraczać, to zużycie 30MB realnej pamięci. wstać odpowiednie materiały marketin-
gowe służące do reklamowania i promocji
• znajdowanie wycieków pamięci
gry. Bardzo często zdarza się, że materia-
Opcja bardzo przydatna dla mniej wprawionych programistów. Bardzo często zapomina się o ły marketingowe powstają dużo wcześniej
tak ważnej rzeczy jak zwalnianie zaalokowanej pamięci. Szczególnie zarażeni są tym progra- lub równolegle z procesem produkcyjnym
miści Java przesiadający się na C++. W Javie menadżer pamięci czyści ją za nich, tutaj trzeba gry. Kontakt z mediami i fanami powinien
pamiętać o tym samemu. Skutkiem tego bardzo często zdarzają się wycieki pamięci, które w zostać zawiązany znacznie wcześniej, by
większych projektach jest bardzo ciężko namierzyć. Tutaj z pomocą przychodzi nam opcja Ac-
o grze było wiadomo cokolwiek, zanim po-
tivity Monitora. Dzięki niej dokładnie możemy zlokalizować wyciek cennych bajtów. Program
wskaże nam dokładną linijkę w kodzie, gdzie wyciek nastąpił. Co ciekawe, wycieki pamięci jawi się ona na rynku.
zdarzają się też w samym OS-ie.
Etapy tworzenia kodu gry
• analizę zużycia czasu procesora

Jest to narzędzie podobne do Task Managera znanego z Windowsa. Dzięki niemu może-
Podział prac pomiędzy programistami
my sprawdzić poziom zużycia pamięci realnej i wirtualnej, a także czas zużycia procesora dla Lider programistów wraz z project manage-
wszystkich aplikacji uruchomionych na iPhonie. rem w czasie planowania projektu rozdzie-
lają poszczególnym członkom zespołu za-
• obserwowanie file systemu i dostępu do plików dania. Dobry podział zadań to połowa suk-
Pozwala na przejrzenie wszystkich operacji dyskowych/plikowych, jakie występują od urucho-
cesu. Ważne jest to, aby każdy z programi-
mienia aplikacji na iPhonie. Jest to rzadziej używana opcja, jednakże pozwala ona programi- stów miał swoje pole działania, a współpra-
ście na obserwację zachodzących procesów związanych z plikami. ca pomiędzy kodem poszczególnych progra-
mistów odbywała się za pomocą określone-
go interfejsu.

62 02/2010

Tworzenie szkieletu klas w UML
bazując na TDD przez programistów
Najwygodniejszym i najszybszym sposo-
bem na sprawne zaplanowanie rozłożenia
klas pomiędzy programistami jest stwo-
rzenie szkieletu całego projektu. Czy wy-
obrażacie sobie tworzenie go bezpośrednio
w kodzie? Byłoby to bardzo czasochłonne i
trudne. W tym momencie z pomocą przy-
chodzi nam UML. Dzięki niemu tworzenie
zarysu kodu staje się dużo wygodniejsze, a
dowolną zmianę można zrobić dosłownie
w chwilę.
Recenzja, ewentualne zmiany
i finalizowanie klas w UML przez lidera
W tworzeniu kodu uczestniczą wszyscy pro-
gramiści. Po podzieleniu poszczególnych za-
dań przez lidera każdy z nich tworzy szkie-
Rysunek 6. Ekran powitalny aplikacji Instruments
Rysunek 7. Przykładowy wyciek pamięci w OS
www.sdjournal.org
let klas mu przydzielonych. Na końcu ca-
łość zostaje złożona i dopracowania pod ką-
tem interfejsów i komunikacji. Bazując na do-
kumentacji programiści są w stanie szybko
wprowadzić zmiany w kodzie, tak aby speł-
niał on wymagania projektu. Na tym pozio-
mie projektowania powstają także komen-
tarze do klas, metod i argumentów, które w
późniejszej produkcji znacznie usprawnią
pracę z kodem.
Generowanie kodu
wraz z komentarzami z UML
Dodatkową zaletą UML-a jest możliwość wyge-
nerowania kodu w prawie dowolnym języku pro-
gramowania. Dzięki temu po fazie projektowej
programiści mają gotowy kod, który muszą tylko
uzupełnić. Wszelkie hierarchie, interfejsy itp. są
już określone i praca jest dużo wygodniejsza.
Xcode
Programowanie
poszczególnych metod i funkcji
Bazując na specyfikacji przygotowanej podczas
preprodukcji oraz na strukturze kodu zapro-
jektowanej w UML, dalsza praca to już „buł-
ka z masłem”. Niestety, jednak podczas two-
rzenia gry bardzo często zmieniają się części
projektu, wprowadzane są udoskonalenia i po-
prawiona zostaje grywalność. Dlatego właśnie
pierwszym ważnym etapem programowania
jest przygotowanie grywalnej wersji gry. To ona
pozwoli ocenić całemu zespołowi, czy gra jest
fajna, czy może coś będzie trzeba zmieniać i
dopracowywać. To w tym etapie programista
powinien jak najwięcej czasu poświęcić na gry-
walność, a mniej przejmować się błędami.
Gdy okaże się, że pierwsza wersja to praw-
dziwy hit, pozostaje nic innego, jak zakasać
rękawy i przejść do programowania. Tutaj
praca jest już bardziej nudna. Bazując na spe-
cyfikacji, należy przygotować wszystkie me-
chanizmy pozwalające obsłużyć całą grę.
Warto pomyśleć także o nowinkach do gry,
które popularne są na iPhonie. Są to między
innymi:
• Facebook – obsługa konta facebook, ofi-
cjalna strona, zapisywanie wyników na
facebook itp.,
• iTunes library – funkcjonalność w aplikacji
pozwalająca na słuchanie plików muzycz-
nych zapisanych na swoim iPhone podczas
gry (zamiast oryginalnej muzyki z gry),
• More games – opcja pozwalająca graczowi
na zapoznanie się z ofertą gier producenta.
Zakończenie
• Testy i polishing gry.
• Stworzenie finalnej wersji gry.
• Wydanie gry na AppStore.
Bez wątpienia tworzenie gier na iPhone’a to do-
skonała zabawa, przygoda i szansa dla nieza-
leżnych developerów. Dziesiątki tysięcy (dane
wskazują, że już ponad 100!) aplikacji nie wzię-
ły się znikąd. Każdy szuka swojej niszy i prze-
błysku geniuszu. Powodzenia z projektami i do
zobaczenia na szczycie listy Top 10!
PATRYK BUKOWIECKI
Specjalista ds. PR i marketingu, manager, czujny
obserwator branży gier video, socjolog, redaktor
i wieloletni współpracownik Neo Plus, gracz, pił-
karz. W Vivid Games na stanowiskach producent
i PR and Marketing Manager.
JAROSŁAW WOJCZAKOWSKI
CTO w firmie Vivid Games, programista/project
manager z kilkunastoletnim doświadczeniem,
współwłaściciel firmy Vivid Games, wesoły i po-
godny człowiek, otwarty na nowe rozwiązania.
63
 Programowanie gier
Cyfrowa kreacja
Artystyczne projektowania gier
Niezależnie od tego, czy tworzymy film, spot reklamowy, efekty
specjalne, wizualizację czy grę, potrzebujemy narzędzi, które pozwolą
nam w produktywny i elastyczny sposób stworzyć to, co widzimy oczami
wyobraźni. Wtedy pojawia się konieczność wybrania oprogramowania
do tzw. cyfrowej kreacji.
Dowiesz się:
• Jakie są trendy w aplikacjach trójwymiaro-
wych
• Co najnoweszego znajdziesz na rynku
• Jak przyspieszyć proces tworzenia przy uży-
ciu nowoczesnych narzędzi 3D
Poziom
trudności
A
ktualnie największym producen-
tem tego typu software'u jest fir-
ma Autodesk, dlatego skupię się
na jej produktach i funkcjonalności jaką
oferują w zakresie animacji oraz wspoma-
gania procesu tworzenia gier. Oczywiście
lwią część pracy wykonuje zespół progra-
mistów, ale nie byłoby czego oprogramo-
wać, gdyby nie treść dostarczona przez
artystów tworzących animacje, postacie,
lokacje czy oprawę interfejsu. Autodesk
pokrywa wszystkie te dziedziny dzięki ca-
łej linii produktów ukierunkowanych na
wykorzystanie w danej dziedzinie kreacji.
Celowo nie wspominam tu o teksturach
i obróbce finalnej obrazu ruchomego, po-
nieważ z tego można byłoby napisać ko-
lejny artykuł, a są to rzeczy, które są tylko
częścią procesu. Skupię się na krótkich
opisach najważniejszych w dziedzinie gier
aplikacji z całego portfolio Autodesk. Nie-
które z poniższych produktów występują
jako samodzielne aplikacje, niektóre są czę-
ścią pakietów, bądź mają charakter uzupeł-
niający, niemniej jednak całość produkcji
gier jest procesem ciągłym i wymagającym
kompletnego systemu, a tym samym uzu-
64
Powinieneś wiedzieć:
• Jakie są podstawy terminologi 3D
pełniających się rozwiązań, dlatego podział
ma znaczenie dopiero po określeniu swoich
potrzeb.
Autodesk 3ds Max
Najpopularniejszy program służący do ge-
nerowania i obróbki grafiki trójwymiaro-
wej. Nie bez powodu nazywany kombaj-
nem – modułowa budowa pozwala na do-
wolne konfigurowanie oraz dodawanie i
odejmowanie funkcji przez system wty-
czek. Rozbudowany język skryptowy czę-
sto wykorzystywany jest do automatyzacji
zadań, a całkowicie konfigurowalny inter-
fejs ułatwia dostosowanie narzędzi do wła-
snych potrzeb.
Dla szefa studia graficznego na pewno
ma to duże znaczenie. Łatwo znaleźć wy-
kwalifikowanego człowieka, który z miej-
sca siada i zaczyna pracować. Ma to duże
znaczenie przy projektach, w których za-
soby ludzkie wykorzystuje się w zależno-
ści od potrzeb i obciążenia pracą na da-
nym etapie.
Graphite modeling tool - nowe narzędzia
do modelowania poligonowego zostały ukie-
runkowane na szybkie manipulowanie bryła-
mi i siatką – zwiększono ich ilość do niemal
stu nowych funkcji służących tylko do ope-
racji na obiekcie. Dodano długo oczekiwane
rzeźbienie oraz malowanie tekstur. Pozwala
to w krótkim czasie nanieść poprawki na mo-
del. Oczywiście aby szybko zobaczyć poten-
cjalny efekt końcowy okna podglądu, działają
w trybie DirectX z wyświetlaniem shaderów,
a xView Mesh Analyzer pozwoli po wszyst-
kim sprawdzić poprawność siatki wykona-
nego modelu.
Okno renderingu zostało zmodyfikowa-
ne tak, by można było dokonywać korekty
jakości i parametrów bezpośrednio w nim
bez każdorazowego otwierania dodatkowych
funkcji, pozwalając na szybkie podejrzenie
efektu wypalania tekstur przy różnych para-
metrach wejściowych.
Narzędzia UV w 3ds Max zostały spe-
cjalnie opracowane pod kątem tworzenia
gier i zawierają szereg elementów wskaza-
nych przez użytkowników w trakcie wie-
loletniego rozwoju aplikacji, wzbogacając
3ds Max o Material Explorer, dzięki któ-
remu skończyło się przebijanie przez kil-
kanaście poziomów materiału, na które na-
rzekali do tej pory użytkownicy. Wisien-
ką na torcie jest mental mill, zdobywają-
cy popularność moduł pochodzący z men-
tal images, a pozwalający tworzyć skompli-
kowane shadery z podglądem w czasie rze-
czywistym, co niesamowicie wpływa na
szybkość generowania tekstur i materiałów
obiektów w grach.
Wprowadzone kontenery ułatwiają pra-
cę z dużymi scenami, gdzie na jednym kom-
puterze można tworzyć postacie, na drugim
lokacje, na trzecim mapę, a na kolejnym łą-
czyć to wszystko razem, nie obciążając ma-
szyn, a tym samym uprzyjemniając i przy-
spieszając pracę.
Maya
Będący standardem w produkcji filmów pa-
kiet coraz częściej jest zauważany przez twór-
ców gier. Powodem jest fakt zbliżenia się tych
dwóch dziedzin rozrywki do tego stopnia, że
kino myśli o interaktywnych filmach, a prze-
mysł gier myśli o kinowej jakości obrazie i ani-
macji w grach.
02/2010
 Cyfrowa kreacja

Maya ze względu na swoja przeszłość łą- chu. Możliwość pobrania danych z systemów je spore możliwości, jednak na pewnym eta-
czy doskonale oba te światy, zapewniając po Motion Capture i późniejsza ich obróbka da- pie precyzji zaczyna brakować dbałości o de-
jednej i drugiej stronie wszechstronne i do-
skonałe narzędzia i często jest wykorzysty-
wana jako środowisko systemowe do dal-
szego rozwoju projektu. Pozwala na to dzię-
ki obsłudze języków C++ i Python oraz wła-
snego MEL.
W Polsce ma to zapewne mniejsze znacze-
nie, ale może być istotne przy pracy w obrę-
bie jednego podmiotu na różnych platfor-
mach. O ile 3ds Max jest przeznaczony tyl-
ko dla MS Windows, o tyle Maya działa rów-
nież na MacOS X oraz Linux. Jest to jedyny
komercyjny produkt zapewniający taką ela-
styczność.
Tak samo jak w przypadku 3ds Max spo-
ro materiałów w Internecie pomaga rozwijać
umiejętności, chociaż w Polsce jest mniej lu-
dzi znających na poziomie zaawansowanym
tę linię produktów, ale z reguły jak już ktoś tą
wiedzę posiada, to jest profesjonalistą. Rysunek 1. Autodesk 3ds Max 2010, przygotowanie skóry postaci

Softimage
Znany głównie z nazwy, ale rzadko od stro-
ny użytkowej program, który ma najdłuższą
tradycję ze wszystkich produktów gamy Au-
todesk. Uznany za standard w dziedzinie fil-
mowej animacji postaci, a w grach coraz czę-
ściej z tego powodu wykorzystywany do two-
rzenia modeli.
Posiada zintegrowaną platformę ICE
(Interactive Creative Environment), będącą
zbiorem narzędzi pozwalającym składać z
klocków efekty wizualne. Nowej generacji
silnik GigaCore zapobiega zawieszaniu się
programu przy obiektach składających się
z wielu milionów punktów, a przy okazji
znacznie przyspiesza obróbkę dużych scen
i plików.
Jedno z najciekawszych narzędzi to Face
Robot, będący do tej pory osobnym produk-
Rysunek 2. Autodesk Maya 2010, malowanie trójwymiarowej trawy bez modelowania
tem, teraz zintegrowany z Softimage, służą-
cy tworzeniu w pełni animowalnych siatek,
mimiki i realistycznie wyglądających twa-
rzy – szczególnie użyteczna funkcja, gdy w
grze trzeba stworzyć wielu różnych bohate-
rów, a na modelowanie każdego osobno nie
ma czasu.
Całość w pełni współpracuje z pozostałymi
produktami Autodesk – w Polsce jeden z naj-
większych producentów gier wykorzystuje
właśnie równolegle Softimage i 3ds Max.

MotionBuilder
Zaawansowana animacja postaci (nie tylko
humanoidów) wymaga często wielu godzin
spędzonych przed komputerem. Naprzeciw
oczekiwaniom animatorów wychodzą mo-
duły (Character Animation Toolkit i Character
Studio) do wspomagania tego procesu od two-
rzenia szkieletów, przez łączenie ich z siatka-
mi, aż po końcową sekwencję animacji ru- Rysunek 3. Autodesk Softimage 2010, miksowanie animacji ruchu

www.sdjournal.org 65
 Programowanie gier

tale animacyjne w dopasowaniu do konkret-
nej sytuacji.
Dlaczego warto zainwestować w dodat-
kowy program tylko do generowania ani-
macji ruchu? Jak zwykle odpowiedzią bę-
dzie to, czego oczekujemy od produktu fi-
nalnego i czasu (a tym samym kosztów), ja-
kie możemy poświęcić na proces produk-
cyjny.
Jeżeli wierzyć twórcom MotionBuilde-
ra – pozwala on skrócić czas przygotowa-
nia animacji o przeszło 250%! To wszyst-
ko dzięki prewizualizacji, automatycznym
modyfikacjom skali, układu kończyn, nie-
destrukcyjnej edycji kluczy i dopasowaniu
do modelu. Większość dużych game deve-
loperów na świecie używa właśnie Motion-
Buildera do animacji postaci – można by
rzec, że jest to industry standard.

Mudbox
W wirtualnym rzeźbieniu konkurencja jest
silna, a Autodesk nieśmiało od kilku lat sta-
wia w tej dziedzinie pierwsze kroki. Nie-
mniej jednak ma jedną niesamowitą zaletę
Rysunek 4. Autodesk MotionBuilder 2010, przygotowanie kinematyki człowieka – pełna integracja z pozostałymi produkta-
mi tej marki. Oczywiście kwestią gustu jest
przyzwyczajenie do interfejsu, ale funk-
cjonalność podstawowa narzędzi wszyst-
kich niezależnych producentów pozostaje
zbliżona. Narzędzia rzeźbiarskie, warstwy,
wypalanie tekstur – to cecha wspólna, ale
jednak jest coś ciekawego w Mudbox, co,
poza wspomnianą integracją, podnosi je-
go użyteczność (i to wysoko) ponad stan-
dard. Niespotykana gdzie indziej precyzja
podglądu czasu rzeczywistego tego, co two-
rzymy, dzięki której efekty naszej pracy wi-
dać od razu. Teraz już nie trzeba poprawio-
nego modelu, materiałów czy shaderów im-
portować do aplikacji 3D, żeby zobaczyć fi-
nalny efekt swojej pracy – wszystko widać
w MudBox i to bez renderingu!

Maya Composite i MatchMover

Rysunek 5. Autodesk Mudbox 2010, rzeźbienie trójwymiarowe Jak już stworzymy wspaniałą grę o nietu-
zinkowej fabule, zaczynamy się zastanawiać
nad opakowaniem jej w przepiękną anima-
cję intro. Wtedy zaczynają się schody. Są fir-
my, które zlecają takie rzeczy na zewnątrz,
ale są też takie, które mają tak dobry zespół
ludzi, że grzechem byłoby pominąć ich ta-
lent w tej części produkcji. Autodesk włą-
czył te dwie aplikacje w skład pakietu Maya
i dzięki temu stworzył kompleksowe rozwią-
zanie filmowe.
MatchMover jako narzędzie śledzące
ruch pikseli obrazu wideo potrafi stwo-
rzyć pełny ruch kamer i matrycę punktów
referencyjnych pozwalających skompono-
wać obraz wideo z animacją. Pomimo oczy-
wistych zalet w tworzeniu efektów filmo-
wych należy pamiętać, że coraz częściej w
grach kamery prowadzi się jak w hollywo-
odzkiej krainie snów, a MatchMover jest
najprostszym sposobem na uzyskanie efek-
Rysunek 6. Autodesk Maya 2010, MatchMover, śledzenie ruchu kamery w przestrzeni trójwymiarowej tu ujęcia kinowego.

66 02/2010
Rysunek 7. Autodesk Maya 2010, Composite, kompozycja obrazu
Maya Composite (znany wcześniej jako
Toxik) jako system kompozycyjny pozwoli
wykończyć animację i finalnie połączyć jej
elementy w jedną całość jak Photoshop – tyl-
ko w ruchu. Włączenie Maya Composite do
pakietu pozwoli nam zaoszczędzić kilka ty-
sięcy na dodatkowym oprogramowaniu przy
zachowaniu zgodności formatu. Całą ani-
mację można podzielić na „pasy” renderingu
i po złożeniu w Maya Composite uzyskać wy-
sokiej jakości końcowy efekt bez mozolnych
prerenderingów. Efekty specjalne, korekty
kolorystyczne, głębia ostrości i inne procesy
zajmujące wiele godzin obliczeń w tej aplika-
cji robione są niemal natychmiast.
Poza powyższymi, znanymi produktami,
należy zwrócić uwagę na kilka mniejszych
elementów układanki (co nie znaczy mniej po-
trzebnych), które w procesie tworzenia mogą
zapewnić zwiększenie wydajności, a z których
istnienia niewiele osób zdaje sobie sprawę.
• ImageModeler – na podstawie już kilku
zdjęć pozwala na wymodelowanie rze-
czywistych obiektów trójwymiarowych.
Im więcej zdjęć, tym dokładniej zostanie
wykonane modelowanie (w procesie au-
tomatycznym lub manualnym), a do ca-
łości zostanie dołączona tekstura z koor-
dynatami mapowania.
• Stitcher – skleja dowolną ilość zdjęć w
panoramy, sfery i hemisfery.
• Human IK – zaawansowane rozwiąza-
nie do tworzenia w czasie rzeczywistym
animacji humanoidów na potrzeby gier
z uwzględnieniem interakcji z otoczeniem.
• Kynapse – sztuczna inteligencja środo-
wiskowa pozwalająca między innymi na
generowanie zachowań postaci i tłumu
w zastanych warunkach lokacji gry.
www.sdjournal.org
• FBX – międzyplatformowy format wy-
miany danych, pozwala w jednym stu-
diu wykorzystywać całą gamę aplikacji
(nie tylko Autodesk!) i wymieniać mię-
dzy nimi (w zakresie funkcjonalności)
bezstratnie dane.
Oczywiście o każdym z programów moż-
na napisać osobny artykuł, a nawet książ-
kę, ale zebranie wszystkiego w jednym
miejscu z krótkim opisem pozwoli zo-
rientować się w sytuacji i wybrać wła-
ściwy zestaw dla siebie. Nie bez znacze-
nia jest również fakt popularności Auto-
desk w branży kreatywnej ze względu na
to, że nawet brak wiedzy na danym etapie
projektu pozwala na szybkie rozwiązanie
problemu dzięki tysiącom informacji za-
wartych na forach internetowych, stro-
nach pasjonatów 3D czy w tutorialach.
Popularność świadczy o sile oprogramo-
wania, ponieważ pozwala szybko rozwią-
zać skomplikowane problemy i nigdy nie
pozostaniemy bez pomocy, a to chyba jed-
na z najistotniejszych funkcji, jakiej po-
trzebujemy!
ARKADIUSZ WYCHADAŃCZUK
Pasjonat filmowych efektów specjalnych oraz
animacji 3D. Zajmuje się obrabianiem oraz two-
rzeniem grafiki i obrazu ruchomego od niemal
piętnastu lat. Zdobył doświadczenie zawodowe
współpracując ze większością polskich (i niektó-
rych europejskich) studiów postprodukcyjnych
oraz stacji telewizyjnych, zarówno jako twórca
wizualny jak i doradca oraz specjalista technicz-
ny. Pozwoliło mu to uzyskać wszechstronną wie-
dzę w każdej gałęzi twórczej związanej z nowy-
mi mediami.
 Programowanie gier
Programowanie
wizualne
Co to takiego?
Niniejszy tekst to informacje, przykłady i tutorial przybliżające
technologię Quest3D. Artykułem tym chcę pokazać, że można tworzyć
aplikacje 3D i gry szybko oraz bez znajomości języka programowania,
bibliotek DirectX czy OpenGL. Jeszcze raz – można. Jest do tego gotowe
narzędzie. Resztę znajdziecie poniżej.
Dowiesz się:
• Co to jest programowanie wizualne;
• Czym Jest Quest3D;
• Czym nie jest :);
• Jak szybko tworzyć aplikacje 3D bez znajo-
mości języka programowania.
Poziom
trudności
Z
apewne wiele razy spotkałeś się z listin-
gami programów pisanych w takich ję-
zykach jak C++, Java, C# czy innych.
Pojedyncze linie tworzą funkcje lub procedury,
z których składa się program. Jeżeli poznałeś je-
den z takich języków, na pewno wiesz, że dużo
pracy kosztuje poznanie nazw funkcji, składni ,
a potem pilnowanie, aby podczas pisania progra-
mu nie pojawiła się literówka czy też czeski błąd
albo parametry funkcji podane w odwrotnej ko-
lejności, co może spowodować, że programu nie
uda sie skompilować.
Z drugiej strony może niekoniecznie chcesz
być programistą. Ja np. nigdy nie chciałem nim
być. Chciałem po prostu móc wprowadzić inte-
rakcję do wykonywanych przez siebie scen i mo-
deli 3D. Z pomocą przyszło właśnie programo-
wanie wizualne.
Charakteryzuje się ono tym, że twój program
w wersji źródłowej nie jest już wieloma liniami
kodu. W programowaniu wizualnym źródło
twojego programu stanowią bloki (channels) i
połączenia między nimi, wizualizowane jako
graf. Głównym narzędziem nie jest klawiatura,
tylko myszka. Poszczególne klocki grafu możesz
68
Powinieneś wiedzieć:
• Co to jest aplikacja 3D.
łączyć ze sobą, po prostu przeciągając linię od
jednego do drugiego. Na liniach łączących widać
czarną strzałkę informującą, w którym kierun-
ku danego połączenia przekazywane są informa-
cje. Większe fragmenty grafu możesz zwinąć do
postaci folderu (patrz Rysunek 1), aby struktura
twojego programu była przejrzysta i czytelna dla
innych pracujących nad tym samym projektem.
W ten sposób programujesz wizualnie.
Metoda tworzenia w pełni funkcjonalnych
aplikacji Quest3D sprawia, że jest on narzę-
dziem dla wszystkich. Pracują w nim graficy-
3D, projektanci, inżynierowie i ludzie ze świata
rozrywki, bo każdy może po prostu usiąść i za-
cząć prace – bez wielomiesięcznych kursów na-
uki języka. To jest właśnie serce Quest3D.
Aplikacje 3D
programowane wizualnie
Quest3D jest jednocześnie wizualnym środo-
wiskiem programistycznym oraz wydajnym sil-
nikiem renderującym 3D. Służy do tworzenia
aplikacji 3D. Zarówno tych małych wirtual-
nych spacerów, prostych gier 3D, jak i większych
i sieciowych produkcji widzianych z różnych ka-
mer. Jednocześnie tworzymy w nim duże sy-
mulatory obliczane przez kilkanaście maszyn.
Jest zatem środowiskiem bardzo skalowalnym.
Wszystkie wymienione rodzaje aplikacji stwo-
rzysz bez wpisania choćby jednej linii kodu.
Wyobrażam sobie, że wielu rdzennych progra-
mistów może poczytać to jako minus aplikacji.
Kiedy prezentuję obraz znajomym firmom czy
też na targach, bardzo często słyszę ...acha, czyli
nie mogę programować tradycyjnie? I poprawiam
ich Nie w tym rzecz, że nie możesz, ale że nie musisz,
bo nie ma takiej potrzeby.
Mamy do dyspozycji channnele, które może-
my wypełnić za pomocą LUA Script i tam stwo-
rzyć swój mały kawałek kodu. Ponadto kiedy
ktoś się bardzo uprze, zawsze ma do dyspozycji
darmowe biblioteki SDK i może pisać w C++
swoje własne autorskie channele, a następnie
używać ich w środowisku Quest3D na takich sa-
mych zasadach jak wszystkie inne.
Dzięki temu możliwości nigdy się nie koń-
czą, a program rozwija się zarówno w pracowni
producenta, jak i w domach i firmach jego użyt-
kowników.
Programowanie wizualne
3D na przykładzie Quest3D
Wydajność wewnętrznego silnika 3D nie ugina
się pod sceną zawierającą wiele milionów trójką-
tów (face'ów). Najwiekszą jednak zaletą progra-
mowania wizualnego w Quest3D jest szybkość
budowania aplikacji. Ja nazywam to wydajnością
programowania, która zestawiona z mocnym sil-
nikiem renderującym pozwala na naprawdę wie-
Tutorial na płycie
Aby ułatwić początkującym i tym po prostu
ciekawym zaznajomienie się z podstawa-
mi Quest3D, przygotowałem videotutorial,
który przekazuję wraz z niniejszym nume-
rem SDJ. Jest to krótka lekcja ukazująca krok
po kroku stworzenie nieskomplikowanej
gry dla jednego gracza. Gatunek: western.
Każdy jest w stanie wykonać taką aplikację
, postępując za tutorialem w przeciągu kilku
godzin. Później pozostaje kwestia wymiany
obiektów na swoje. Zapraszam serdecznie
do zapoznania się z tutorialem.
02/2010
 Programowanie wizualne

le. Dla przykładu dość statyczna scena ukazana

na pierwszych dwóch obrazkach powstała po-
przez jedno przeciągnięcie zbioru Quest'owych
klocków zapisanych na liście Templates. Są to go-
towe do użycia większe i mniejsze grafy fragmen-
tów aplikacji. Wystarczy je przeciągnąć do grafu i
po prostu połączyć z resztą naszych klocków. To
jest ogromnie przyspieszenie i uproszczenie dla
programistów. Aby dodać do naszej sceny kame-
rę orbitującą wokół obiektu, wystarczy usunąć z
grafu nasze Basic Camera i zamiast tego przecią-

Rysunek 2. Efekt grafu powyżej – scena 3D w

czasie rzeczywistym

Rysunek 3. Fragment zbioru szablonów

Rysunek 1. Przykład grafu - prosta aplikacja 3D gotowych do użycia – Templates

R E K L A M A
 Programowanie gier

gnąć z listy Templates nowy zestaw klocków zapi-
sany pod nazwą Object Inspection Camera.
W Quest3D w bardzo prosty sposób możesz
oprogramować urządzenia do sterowania takie
jak klawiatura, mysz, joystick i inne, włączając w
to wirtualne rękawice czy chełmy. Co więcej, to
środowisko integruje w sobie elementy niezbęd-
ne w wielu grach (silnik fizyczny, generowanie
tłumu, szukanie drogi). Pisząc grę metodą tra-
dycyjną, sam musiałbyś je zintegrować. Modele
używane w tym środowisku można wykonać za
pomoćą dowolnego pakietu graficznego 3D, jak
chociażby 3ds max, maya, blender, cinema, a na-
stępnie zaimportować do Quest3D poprzez je-
den z uniwersalnych formatów: COLLADA, X,
a wkrótce również FBX.
Na Rysunku 1 widać graf przedstawiający pro-
stą scenę 3D. Każdy, kto spotkał się już z grafiką
3D i zasadami tworzenia takich obrazów, wie,
ze każda taka scena składa się z 3 grup elemen-
tów: obiekty 3D – w tym przypadku napis trój-
wymiarowy oraz podłoże, światło, które owe
obiekty oświetla abyśmy mogli je zobaczyć – w
tym przypadku zamknięte w folderze o nazwie
Rysunek 4. Agencje PR tworzą za pomoca Quest3D małe i sympatyczne gry reklamowe oraz prezentacje,
które całkowicie mieszczą się w jednym pliku EXE i można je łatwo przesyłać Internetem, a uruchomienie
aplikacji nie wiąże się z instalacją czegokolwiek. Po prostu jeden plik exe działający na zasadzie Click&Run
Directional Light, oraz kamera, która ową scenę
obserwuje z zadanego punktu widzenia – u nas
Basic Camera. Wszystko to podłączamy do kloc-
ka Render odpowiedzialnego za wyświetlenie na-
szego grafu jako obraz 3D w aplikacji. Na Rysun-
ku 2 widać efekt tej najprostszej aplikacji 3D.
Przykłady aplikacji
wykonanych w Quest3D
Jak pisałem wcześniej , środowisko to jest bardzo
skalowalne. Na kilku przykladach postaram się
przybliżyć najbardziej znanych albo zasługują-
cych na uznanie aplikacje wykonane przez róż-
ne firmy z bardzo rozbieżnych branż. Wiele firm
używa tego środowiska do celów promocyjno-re-
klamowych. Przykładowo, w branży dewelope-
rów mieszkań, domów i innych nieruchomości
jest to idealne rozwiązanie. Firma nie musi na-
wet zatrudniać programisty.
Możliwości silnika Quest3D
Środowisko Quest3D jest silnikiem komplet-
nym. Znaczy to, że zawarte w nim moduły i pod-
silniki wystarczają do zrobienia sporych rozmia-
rów gry. Do najważniejszych należy zaliczyć Sil-
niki fizyczne: ODE, Newton, jest też płatny do-
datek: PhysX. Możemy wybrać ten, który będzie
spełniał nasze oczekiwania. Są zintegrowane i go-
towe do użycia. Czeka na nas także mechanizm
oświetlenia słonecznego ustawianego za pomo-
cą godziny, pory roku i położenia geograficznego.
Mamy do dyspozycji również takie parametry jak
wiatr, deszcz czy zamglenie - słowem, kompletny
system pogodowy (Weather System).
W Quest3D można również tworzyć aplika-
cje sieciowe, i to na dwa sposoby. Pierwszy to ne-
tworking budowany na bibliotekach DirectPlay
wchodzących w skład DirectX. Drugi to tzw. soc-
kety. Z kolei do optymalizacji większych map te-
renów służy moduł Nature Painting, który po-
trafi doskonale zoptymalizować tereny miejskie
oraz wielkie zalesione połacie. Producent w ko-
lejnej wersji Quest3D zapowiada także rewolu-
cyjny edytor terenu. Wewnątrz programu Qu-
est3D mamy możliwość tworzenia własnych
shaderów w jęz. HLSL lub wczytywania plików
.fx. Dostępny jest również global shader.
Z działki animacji warto wspomnieć o ani-
macji szkieletowej, mikserze sekwencji aminacji
(tzw. motion blending), potrzebny może okazać
się wbudowany system tkanin (cloth rendering).
Jeżeli postaci będzie więcej, z łatwością będziesz
mógł skorzystać z generowania tłumu za pomo-
cą crowd rendering.
Do wyliczonego zbioru należy doliczyć jeszcze
gotową realistyczną wodę, zaawansowany system
cząsteczek, płynną zmianę ruchu (np. ze space-
ru w bieg), ekspozycję światła HDR, obsługę baz
danych (mySQL i ODBC), obsługę wielu forma-
tów dźwiękowych, oczywiście z dźwiękiem 3D,
renderowanie na wielu komputerach tej samej
sceny. Na koniec to wszystko możemy wyren-
derować jako aplikację 3D (stereorendering lub
anaglif). Pełne porównanie z opisem modułów
znaleźć można na stronie www.quest3D.pl.
Jak widzisz, jest w czym wybierać. To wszyst-
ko jest już w środku i nie wymaga dogrywania ja-
kichkolwiek pluginów czy innego rodzaju roz-
szerzeń. Zainstaluj i używaj.

Rysunek 5. Pełnowymiarowe gry 3D tworzą zarówno duże studia, jak i małe grupy. W tych drugich W Sieci
często nawet nie ma programisty, tylko kilku grafików 3D i animatorów
• quest3d.pl – strona główna i podstawowe
informacje o technologii i zastosowaniu;
• forum.quest3d.pl – podstawowe źró-
dło pomocy, jeżeli zaczniesz używać
Quest3D, również linki do tutoriali;
• support.quest3d.com – aktualna doku-
mentacja online w j. Angielskim.

ARKADIUSZ BRZEGOWY
Ekspert i certyfikowany trener Quest3D. Partner
holenderskiej firmy Act3D, producenta technolo-
gii. Właściciel firmy oferującej oprogramowanie
Rysunek 6. Ponadto jednymi z najczęściej wykonywanych aplikacji w Quest3D są konfiguratory, Quest3D oraz wsparcie techniczne dla twórców.
aplikacje szkoleniowe 3D (tzw. trenażery), symulatory i różnej maści aplikacje do wirtualnej Założyciel i opiekun Quest3d.pl.
rzeczywistości (m.in. projekcja na 4 ściany, obsługa rękawic i hełmów wirtualnych) Kontakt z autorem: arek.brzegowy@quest3d.pl

70 02/2010
 Programowanie gier
Producent
A kto to jest?
Rola producenta w procesie budowania gry komputerowej bywa,
szczególnie dla osób postronnych, dość niejasna. Czytając poniższy
artykuł, przekonasz się, kim jest producent i jaka jest jego rola we
wspomnianym procesie.
Dowiesz się:
• Jakie są codzienne obowiązki producenta;
• Z jakimi problemami producent boryka się
na co dzień;
• Jak wiele ról pełni producent;
• Jak producent postrzegany jest przez resztę
zespołu.
Poziom
trudności
G
ry komputerowe, czyli przemysł fil-
mowy XXI wieku. Coraz więcej z nas
gra w gry, coraz więcej z nas uczestni-
czy w ich tworzeniu. Gry przedostają się powo-
li do środków masowego przekazu, otrzymują
nagrody i oklaski za całokształt, doświadczenia
gracza oraz dziesiątki innych kategorii. Przemysł
filmowy ma swoje gwiazdy, są nimi aktorzy, re-
żyserowie, scenarzyści, okazjonalny operator.
Wszyscy znają ich nazwiska i prace.
Tak jak i w filmach, przemysł gier kompute-
rowych ma swoje gwiazdy. Tymi gwiazdami są
designerzy, artyści, programiści – ludzie, któ-
rzy tworzą rzeczy widoczne, rzeczy, do których
można się odnieść, tworzą elementy w pew-
nym stopniu namacalne. Tu przechodzimy do
pozycji producenta, która jest zazwyczaj moc-
no w cieniu.
Obiegowa opinia wśród zespołów projekto-
wych jest taka, że producent tak naprawdę nic
nie robi. Producent, wbrew nazwie, sam ni-
czego tak naprawdę nie produkuje, nie tworzy
grafiki, nie tworzy kodu, czasem przyjdzie po-
przeszkadzać designerowi, ale zazwyczaj się go
nie widzi. Siedzi przy arkuszu i tworzy jakieś ta-
belki, więc czemu miałby być pretendentem do
gwiazdy przemysłu gier?
Zastanówmy się więc: kim właściwie jest pro-
ducent? W dużym uogólnieniu, producent jest
odpowiednikiem Project Managera (czyli Kie-
72
Powinieneś wiedzieć:
• Co to jest gra komputerowa.
rownika Projektu) w biznesie gier komputero-
wych. Kim zatem jest w szczególe? W swoim
biznesie producent jest Project Managerem, pro-
gramistą, jasnowidzem, grafikiem, designerem,
testerem, głosem rozsądku, planistą, strażakiem,
facetem od pizzy, salesmanem, najlepszym kole-
gą i bezlitosnym szefem.
Przedstawmy pokrótce każdą z tych ról, co by
słów na wiatr nie rzucać.
• Project manager – zdawało by się, że głów-
na rola producenta. Pilnowanie harmo-
nogramu, regulacja zasobów, rozmowa z
klientem, czytanie poczty i dokumentacji.
Pozycje takie jak rozmowa z klientem po-
trafią urosnąć do rozmiarów, gdzie wyma-
gałyby osobnego etatu.
• Programista – nie każdy producent ma
wiedzę techniczną, w większości wypad-
ków nawet nie powinien, bo zarządzanie
projektem to nie jest dobre miejsce dla do-
brego programisty. Wiedza programistycz-
na jednak się przydaje, po pierwsze, poma-
ga producentowi zrozumieć, o czym pro-
gramiści do niego mówią. Po drugie, po-
zwala łatwiej ocenić, czy rzeczywiście na-
pisanie Hello World w OpenGL zajmie do-
świadczonemu programiście trzy dni ro-
bocze. Po trzecie, daje możliwość dialogu
z programistami w momentach impasu i
nieurodzaju intelektualnego.
• Jasnowidz – drugi, pełny etat producen-
ta. Trzeba umieć przewidzieć wszystko, co
może się stać w najbliższej przyszłości, i za-
cząć się do tego przygotowywać. Problemy
z oprogramowaniem, narzędziami, ciąża,
grypa, kreatywny klient, skrócenie deadli-
ne’u o połowę. Na to wszystko trzeba mieć
odpowiedź, im pełniejszą, tym lepiej.
• Grafik – Graficy dostają od designera gene-
ralne wytyczne co do tego, co mają wyko-
nać, a reszta jest tak naprawdę przejawem
ich własnej inwencji twórczej. Tutaj właśnie
wkracza producent, bo taka inwencja musi
podlegać kontroli. Często trzeba kontrolo-
wać, czy inwencje dwóch grafików, pracu-
jących równolegle nad projektem są zbież-
ne, bo nie chcemy skończyć z budowlami
rodem z Art Deco w środku wioski elfów.
Należy też zwracać uwagę na sposób wyko-
nania poszczególnych elementów, bo kulka
złożona z 10 tysięcy wielokątów nie poto-
czy się zbyt płynnie na urządzeniu, które-
go wydajność można w skrócie ocenić jako
dwa kalkulatory sklejone taśmą klejącą.
• Designer – producent, zwłaszcza przy ma-
łych projektach, pełni też rolę designera,
aby oszczędzić na kosztach, nigdy nie jest
to dobry pomysł. Przy większych projek-
tach zawsze deleguje się osobnego designe-
ra, ale jako że jest to etat posiadający licen-
cję na inwencję twórczą, należy go kontro-
lować. Designer, jak każdy artysta, chce być
unikalny i jedyny w swoim rodzaju. Dzięki
przypływowi takiej weny jest w stanie wy-
myślić takie elementy gry, o jakich nie bę-
dzie się śniło naszym dzieciom ani nasze-
mu budżetowi. Trzeba więc filtrować ta-
kie pomysły, aby na następnym spotkaniu
projektowym nie zorientować się, że zespół
przez ostatnie 2 tygodnie pracował nad
czymś, co zupełnie nie nadaje się do naszej
gry.
• Tester – mimo tego iż każdy projekt ma
swój zespół QA, świeże spojrzenie produ-
centa, nie tylko na błędy w grze, ale także
na grę jako całość ma zbawienny wpływ na
jakość końcowego produktu. Poszczególne
zespoły są tak zajęte swoimi zadaniami, że
nie są w stanie zauważyć faktu, iż niektóre
elementy, nawet sąsiadujące, nie współgrają
ze sobą.
• Planista i głos rozsądku – często zespół
chciałby coś dodać, odjąć czy zmienić, i za-
02/2010

daniem producenta jest ocena, czy dana
funkcjonalność wpłynie rzeczywiście do-
datnio na jakość produktu i czy trzy-tygo-
dniowy poślizg związany z implementacją
tej funkcjonalności jest dopuszczalny. Nie
mówiąc o tym, że na trzech tygodniach
może się to nie skończyć. Czasem trzeba
podjąć kilka niepopularnych decyzji, aby
projekt jednak miał szanse sukcesu.
• Strażak – jak sama nazwa wskazuje, stra-
żak gasi pożary. Pożarami nazywamy
wszystkie nagłe wypadki w projekcie, któ-
re w pośredni lub bezpośredni sposób
wpływają na wykonalność projektu w za-
mierzonym czasie, lub w ogóle. Dobrymi
przykładami jest odejście głównego deve-
lopera, zmiana terminu oddania projektu
lub odnalezienie krytycznej luki w zaku-
pionej technologii. W takich wypadkach
producent zaczyna robić wszystko, co tyl-
ko możliwe, aby załagodzić następstwa ta-
kich wydarzeń. Ekspresowa rekrutacja,
długie negocjacje z klientem lub telefony co
godzinę do dostawcy technologii, aby do-
wiedzieć się, czy błąd już został naprawio-
ny. Wszystko to zazwyczaj poza zasięgiem
wzroku całego zespołu.
• Facet od pizzy – najłatwiejszy z obowiąz-
ków. Jeśli już cały zespół musi siedzieć w
nocy, tak aby wyrobić się na określony ter-
min, to trzeba go nakarmić. Zamówić piz-
ze, podać, opłacić i uśmiechać się ładnie. Im
mniej developerzy muszą nad tym myśleć,
tym lepiej.
• Sprzedawca – tutaj producent współpracu-
je z innymi sprzedawcami w czasie wstęp-
nych negocjacji z klientem, aby ustalić listę
funkcjonalności, która jest wykonalna w
zamierzonym czasie i budżecie. Sprzedaw-
cy często mają problemy z oceną możliwo-
ści wykonania projektu, co najczęściej koń-
czy się ujemnymi budżetami oraz setkami
nadgodzin w projekcie, dlatego też należy
przypilnować tego, aby sprzedać klientowi
coś, co rzeczywiście jest wykonalne przez
nasz zespół. Koniec końców, jeśli coś nie
wyjdzie, to oczywiście jest to wina produ-
centa. Naturalnie.
• Najlepszy kolega – to właśnie producent.
Zawsze wysłucha swoich ludzi, poradzi im,
co mogą robić w krytycznych sytuacjach, i
da urlop przy nagłych wypadkach. Zrozu-
mie, jeśli ktoś przyjdzie później po bardzo
wesołej nocy.
• Bezlitosny szef – to także producent. Taki
tryb włącza się zazwyczaj pod koniec pro-
jektu. Godziny pracy są stałe i często bar-
barzyńsko wczesne. Urlopy zostały prze-
łożone na następny rok, a każde spóźnie-
nie kończy się wizytą na dywaniku i poga-
danką o tym, jak ważny jest projekt i jak za-
wiedliśmy wszystkich swoim nieodpowie-
dzialnym zachowaniem.
www.sdjournal.org
Mimo tego, że pozornie obowiązków tych wy-
daje się być dużo, wśród developerów panuje
obiegowa opinia, że producent to taki człowiek,
który nic tak naprawdę nie robi. Widzi się go z
rana na spotkaniu, pogada coś, a potem przy-
chodzi, tylko jeśli coś idzie nie tak. Podobnie jak
z administratorami sieci, praca producenta jest
najbardziej widoczna, kiedy on sam nie ma co
robić. Jeśli wszystko jest dopięte na ostatni gu-
zik i współgra ze sobą jak trybiki w zegarku, to
producent nie ma już czego poprawiać. Oczy-
wiście do czasu, kiedy wybuchnie następny po-
żar. Wtedy nasz bohater musi założyć swój ska-
fander, wziąć gaśnicę pod pachę i ratować swój
(a także nasz i wasz) projekt przed totalną ka-
tastrofą.
Katastrof jest co nie miara, uwierzcie mi. Na
każdym kroku w projekcie czyhają tylko, aby za-
atakować zespół i puścić projekt z dymem. Wte-
dy właśnie producent wkracza do akcji, aby wy-
konać swoją niewdzięczną akcję ratunkową, o
której mało kto tak naprawdę się dowie. O pro-
blemach nie mówi się w zespole, problemy dzia-
łają bardzo demotywująco. Programiści, graficy
i cała reszta ferajny nie musi wiedzieć o tym, że
klient miał kolejny genialny pomysł i chciał z na-
szej gry akcji zrobić puzzle. Takie informacje wy-
wołują nieprzyjemne pomruki dezaprobaty na
sali, a niektórym developerom podnoszą w bar-
dzo widoczny sposób ciśnienie. Takie skoki ci-
śnienia i pomruki są wrogiem najlepszej przy-
jaciółki producenta – produktywności, a bez
niej problemy zaczynają się mnożyć jak gremli-
ny karmione po północy.
Głównym problemem, wynikającym z braku
produktywności, są oczywiście opóźnienia. Jed-
nak zakres tych opóźnień często przybiera for-
mę wykładniczą. Z podstaw informatyki wie-
my, iż cały system działa tak szybko jak najwol-
niejsza jego część. Opóźnienie jednego zespo-
łu często oznacza opóźnienie innych zespołów,
przestoje i puste przebiegi. Dla przykładu, jeśli
zespół grafików nie dostarczy na czas potrzeb-
nych elementów, programiści nie będą w stanie
ich poprawnie zaimplementować, a zespół testo-
wy nie będzie w stanie zweryfikować poprawno-
ści tej implementacji. Cały moduł, a wraz z nim
cała gra zaczyna się obsuwać, a zespół generuje
puste godziny, na których cierpi budżet gry. Jeśli
taki okres się przeciągnie, to możemy znaleźć się
w sytuacji, gdzie nie będziemy mieć już budżetu
na ukończenie gry jako takiej.
Zadaniem producenta jest więc pilnowa-
nie wydajności i monitorowanie jakości całego
projektu. Producent jest swego rodzaju firewal-
l’em między zespołem projektowym a wszyst-
kimi czynnikami zewnętrznymi. Dba o to, aby
jedynym zmartwieniem programistów był ro-
dzaj algorytmu sortowania,jaki mają zastoso-
wać, a wszystkie problemy takie jak zmiany za-
kresu projektu, zmiany w terminach, zmiany w
zasobach, etc. były ponad ich głowami. Z drugiej
strony, producent jest odpowiedzialny za to, co
Producent
programiści oraz inne zespoły wykonają, i jeśli
jego zespół nie wyrabia się w czasie, to musi on
znaleźć kreatywne rozwiązania, skróty i sztucz-
ki, aby jednak osiągnąć cel w zamierzonym cza-
sie. Często przypomina to żonglerkę płonącymi
kotami podczas jazdy na monocyklu, ale za to w
końcu mu płacą.
Reasumując, życie producenta to nieustan-
na walka ze światem. Ekwilibrium przenosze-
nia zasobami, tak aby jednak wszystko się uda-
ło, mimo iż na papierze jasno widać, że czasu
jest o kilka tygodni za mało. To także, jak u każ-
dego managera, kompromisy między byciem
efektywnym kierownikiem a byciem przyjacie-
lem swoich ludzi i motywowanie ich w delikat-
ny sposób. Bycie producentem to także posiada-
nie wiedzy na każdy temat oraz części umiejęt-
ności każdego z członków zespołu, tak aby móc
wpasować się między nich, a także podejmować
decyzje poparte konkretną wiedzą. Najważniej-
szą jednak częścią jest posiadanie wizji projek-
tu i motywacji do jego ukończenia. Pracowni-
cy często bywają zagubieni, wiele rzeczy w pro-
jekcie bywa dla nich nie jasnych, i w takich wła-
śnie momentach oczekują od producenta ja-
snej wizji i odpowiedzi w 10 sekund. Taką od-
powiedź zawsze trzeba mieć, i mieć ją na każdy
możliwy temat.
Mam nadzieję, że dzięki temu artykułowi
część z Was spojrzy inaczej na swojego produ-
centa. Jeśli w Waszym projekcie pojawi się na-
gle dodatkowy kolega, przesunie się termin al-
bo stanie coś równie ciekawego, co ułatwi wam
pracę, to wiedzcie, że nie jest to do końca przy-
padkowe zrządzenie losu. Jeśli na kolejnym
spotkaniu producent będzie się opierał przed
wprowadzeniem kolejnej funkcjonalności do
gry, która jest akurat Waszym oczkiem w gło-
wie, to wiedzcie, że nie robi tego z czystej zło-
śliwości, ale ma plan, w który nie da się wpi-
sać wszystkiego. Mimo że pozornie czasu jesz-
cze zostało całkiem dużo, to często nie bierzecie
lub nie zauważacie pewnych czynników ryzyka,
które stoją na drodze projektu. Producent je wi-
dzi, w końcu jest także jasnowidzem...
ŁUKASZ SZCZEPAŃSKI
Pracuje na stanowisku Producenta w firmie Game-
lion, wchodzącej w skład Grupy BLStream. Łukasz
specjalizuje się w technologiach związanych z pro-
dukcją oprogramowania na platformy mobilne,
ze szczególnym naciskiem na tworzenie gier. Gru-
pa BLStream powstała, by efektywniej wykorzy-
stywać potencjał dwóch szybko rozwijających się
producentów oprogramowania – BLStream i Ga-
melion. Firmy wchodzące w skład grupy specja-
lizują się w wytwarzaniu oprogramowania dla
klientów korporacyjnych, w rozwiązaniach mobil-
nych oraz produkcji i testowaniu gier.
Kontakt z autorem: lukasz.szczepanski@game-
lion.com
73
 Efektywność pracy

Wspinaczka
do profesjonalizmu
Modelowa ścieżka rozwoju kompetencji – podejście
pragmatyczne
Model kompetencji Braci Dreyfus, który odnosi się nie tylko do umiejętności
technicznych, ale również do ogólnej aktywności każdego z nas. Model
pozwoli Ci uświadomić sobie swój aktualny poziom kompetencji w dowolnej
dziedzinie oraz zaplanować dalszą drogę ich rozwoju. Spojrzenie przez
pryzmat modelu na kolegów z zespołu pomoże Ci lepiej komunikować się.
moświadomości, a co za tym idzie na racjo-
Dowiesz się: Powinieneś wiedzieć: nalne działanie.
• Jak zmieniasz się wraz z rozwojem kompe- • „Co lubię w życiu robić?” Model jako taki z założenia odnosi się do
tencji; niemal każdej aktywności człowieka, któ-
• Jak zdiagnozować na jakim poziomie jesteś ra podlega rozwojowi. Jego główna koncep-
Ty i Twoi współpracownicy; cja opiera się na istnieniu 5 poziomów, wg
• Na co zwracać uwagę w komunikacji ze ko- których zmienia się nasza percepcja danego
legami z zespołu; problemu oraz sposób, w jaki budujemy jego
• Jak racjonalnie dobrać strategię swojego mentalną reprezentację.
rozwoju
1. Novice
Spotykasz się z daną sytuacją po raz pierw-
chy lub pilotowania samolotu. Mam nadzie- szy. Jesteś zorientowany na konkretne zada-
ję, że z uwagi na jego bliskość z naszą branżą nia, kroki i potrzebujesz kogoś, kto je Tobie
Poziom okaże się ciekawy i zachęcający do spojrzenia wskaże. Jeszcze nie masz pełnej świadomości
trudności we własne wnętrze. Mam również nadzieję, szerszego celu. Nie masz żadnej intuicji, za-
że zainspiruje on wszystkich czytelników do tem potrzebujesz jasnych, bezkontekstowych
refleksji nad własną drogą do osiągnięcia pro- reguł postępowania, aby nie pogubić się w no-
fesjonalizmu. wym środowisku.

C
zy potrafisz przypomnieć sobie
naukę jazdy na rowerze? To sku-
pienie, aby przejechać 10 metrów
prosto? Albo pierwszą jazdę samochodem
i skupienie na sprzęgle? I jego zgrzyt? A
czy teraz, po latach, potrafisz powiedzieć,
co należy zrobić, aby jechać bez trzyma-
nia kierownicy, rozmawiając jednocześnie
przez telefon i podziwiając inne uczest-
niczki ruchu (mam tu na myśli oczywiście
jazdę na rowerze)?
Tę właśnie drogę od nowicjusza z fioleto-
wymi kolanami do pewnego siebie eksperta
opisuje model rozwoju kompetencji opraco-
wany w latach '70 ubiegłego wieku przez bra-
ci Dreyfus.
Nie jest to bynajmniej czysto teoretycz-
ny model akademicki. Model powstał pod-
czas badań nad zastosowaniem sztucznej in-
teligencji (i jej ograniczeniami) do gry w sza-
Profesja i Rzemiosło (Craftsmanship) są
wartościami nabierającymi coraz większego
znaczenia w branży programistycznej – póki
co, niestety, szczególnie zachodniej. Zwykle
jednak postrzega się je jako metodyki, podej-
ścia i warsztat. W niniejszym artykule przyj-
rzymy się tym wartościom pod kątem świa-
domej i racjonalnej drogi rozwoju w kierun-
ku profesjonalizmu.
Model zdobywania kompetencji
Każdy, kto nie jest totalnym cyborgiem, za-
pewne ma świadomość, że kompetencje w
danej dziedzinie oraz sam ich charakter nie
są statyczne. Podlegają zmianom w czasie
– zwykle w długiej perspektywie czasu, przez
co mogą być trudne do zaobserwowania. Mo-
del Braci Dreyfus opisuje taką właśnie dro-
gę owych zmian, nazywając i charakteryzu-
jąc jej etapy. Pozwala to na zwiększenie sa-
2. Advanced begginer
Radzisz sobie coraz lepiej, zaczynasz for-
mułować proste zasady. Jednak są to zasady
ograniczone do wąskiego kontekstu, ponie-
waż nie masz jeszcze zdolności spojrzenia na
swą pracę z boku. Póki co, masz problem z
radzeniem sobie z pojawiającymi się trud-
nościami, dlatego potrzebujesz kogoś, kto
będzie podpowiadał Ci rozwiązania – naj-
lepiej szybko!
Co ważne, wciąż potrzebujesz kogoś, kto
powie Ci, co i jak powinieneś zrobić.
Boję się iść dalej
Dwa pierwsze poziomy kompetencji w
przedstawianym modelu charakteryzują
się tym, że ktoś mówi nam CO – i najważ-
niejsze JAK musimy zrobić. Potrzebujemy
zadań, których jesteśmy jedynie wykonaw-

74 02/2010

cą. Towarzyszy temu oczywiście przyjem-
ne uczucie zwolnienia z odpowiedzialno-
ści – ja tylko wykonywałem rozkazy. Pamię-
tajmy jednak, że dla niektórych z nas strach
przed podjęciem odpowiedzialności za wła-
sne poczynania może być blokadą przed dal-
szym rozwojem.
3. Competent
Przestałeś borykać się ze szczegółami tech-
nicznymi problemu, wszystko to, co na po-
czątku zgrzytało, teraz działa dosyć gładko.
Pozbycie się tych problemów spowodowa-
ło, że jesteś już nastawiony na cel i sam decy-
dujesz, jak do niego dotrzeć. Dzięki świado-
mości celu sam planujesz kroki i zadania pro-
wadzące Cię do niego. Robisz to, ponieważ je-
steś już w stanie tworzyć modele koncepcyj-
ne problemu, co z kolei pozwala na myśle-
nie bardziej długofalowe – planowanie. Two-
je rozwiązania nie są może jeszcze najlepszy-
mi z możliwych, ale działają. Wypracowujesz
swoje własne zasady, ale starasz się jednocze-
śnie je weryfikować.
Ponieważ przewidujesz, że mogą istnieć
lepsze rozwiązania, że ktoś opracował dobre
praktyki i sprawdzone rozwiązania, to szu-
kasz informacji u Ekspertów. Prawdopodob-
nie nie dowiesz się od nich niczego, ale o tym
za chwilę...
Już się zmęczyłem
Wszyscy mamy tendencję do niewysilania się
ponadto, co konieczne. Jest to jak gdyby we-
wnętrzny mechanizm mózgu chroniący go
przed śmiertlenym przegrzaniem. Dlatego
chętnie zatrzymujemy się na poziomie Com-
petent. Radzimy sobie już całkiem dobrze i je-
steśmy generalnie zadowoleni z rezultatów.
Inni są również z nich zadowoleni. Czego
chcieć więcej? Czy nie zrobiłem już wszyst-
kiego, co można, i nie mogę wreszcie oddać
się czynnościom wegetatywnym typu oglą-
danie TV?
4. Proficient
Wejście na ten poziom i osiągnięcie pozio-
mu biegłości w danej dziedzinie wymaga
wysiłku intelektualnego. Przede wszystkim
musisz chcieć. O ile poprzednie poziomy
osiągamy liniowo – po prostu powtarzając
pewne czynności wielokrotnie – to w przy-
padku Proficient samo powtarzanie nie wy-
starczy. Mamy tutaj do czynienia z ogrom-
nym skokiem jakościowym. Skokiem, który
polega na całkowitym zaangażowaniu w da-
ny temat i zgłębianiu jego natury poprzez
szersze poszukiwania. Poszukiwania te po-
legają na kojarzeniu analogii do innych za-
gadnień, pogłębianiu zasobów tychże sko-
jarzeń.
Na tym poziomie nie jesteś już nastawio-
ny na sam cel, ale na zrozumienie celu w róż-
www.sdjournal.org
Wspinaczka do profesjonalizmu
nych kontekstach. Ujrzałeś tak zwany big- tyczy zdobywania konkretnej, mniej lub bar-
ger picture i masz problem... Do tej pory by- dziej ogólnej kompetencji. Czyli w pewnych
łeś kompetentny w swoim malutkim świe- nielicznych aspektach możemy być eksperta-
cie, jednak gdy zobaczyłeś, o co tak napraw- mi, a w innych np. nowicjuszami.
dę chodzi i zrozumiałeś, że jest to jednak Warto zwrócić uwagę na kilka kwestii
bardziej skomplikowane niż się wydawało. związanych z naszą postawą w zależności od
Wiem, że nic nie wiem – chichocze za Twymi poziomu kompetencji w danej dziedzinie.
plecami sam wielki Sokrates. Jesteś po pro-
stu skazany na dalsze samodoskonalenie w Najpierw ogólnie
tej dziedzinie. Niektórzy z nas, poznając nowe zagadnie-
Frustrują Cię zbytnie uproszczenia, które nia z ogólnie znanego już zakresu, prefe-
widzisz dookoła. Stałeś się zapewne dener- rują rozpoczęcie od trzeciego poziomu –
wującym typkiem w zespole, który wciąż za- Competent. Dzieje się tak, gdy nasze nawy-
daje pytania. Pytania, których nikt nie lubi ki kognitywne kierują nami, aby najpierw
– zaczynające się od A dlaczego...?. poznać ogólnie problem i zrozumieć, o co
chodzi. Dopiero później będziemy szukać
5. Expert przykładów, tutoriali itp. Najpierw musi-
Wiedziony wrodzoną ciekawością zgroma- my poznać całość oraz metodyki obowiązu-
dziłeś na poprzednim etapie niemal całą wie- jące w danej dziedzinie, aby zdecydować w
dzę z danej dziedziny. Cały czas poszerzasz ją ogóle, czy to nas interesuje i czy chcemy za-
- szukasz jednak w innych miejscach niż po- głębiać się dalej.
przednio. Szukasz analogii i skojarzeń z zu-
pełnie odrębnymi domenami. Być może in- Błędna samoocena
spiruje Cię biologia, mechanika, architektura Będąc na niższych poziomach, mamy tenden-
budowli? Syntezujesz pojęcia na wyższym po- cję do zawyżania swej samooceny. Nawiasem
ziomie abstrakcji. mówiąc, niektórzy mają chyba do tego wro-
Zrozumiałeś, że wszystko zależy od kon- dzone skłonności.
tekstu, dlatego posługujesz się głównie me- Natomiast będąc na wyższych pozio-
taforami, mówiąc o swej dziedzinie. Paradok- mach, przychodzi pokora i zaniżamy swe
salnie to właśnie metafory są najbardziej traf- kompetencje. Najbardziej niebezpieczni dla
ne, ponieważ można je interpretować na róż- siebie samych, tudzież otoczenia jesteśmy na
ne sposoby w zależności od kontekstu. Nie- poziomie Advanced Begginer. Wydaje nam
ustannie poszukujesz lepszych metod. się, że osiągnęliśmy wówczas mistrzostwo,
Co gorsza – zapytany o argumentację ponieważ nie mamy jeszcze wyrobionego
swych decyzji, często nie potrafisz jej podać, szerszego poglądu. Przypomnijcie sobie, kie-
ponieważ myślisz intuicyjnie. Rozwiązania dy zaliczyliście najwięcej upadków z rower-
same pojawiają się w głowie, po prostu wiesz. ka; a z drugiej strony, kiedy ostatnio do te-
go doszło?
Warto zwrócić uwagę
Ogólnie rzecz ujmując, model zakłada zmia- Test na eksperta
nę nastawienia. Z początkowej orientacji na Dave Thomas – autor klasycznej już książ-
procedury i konieczność na późniejsze na- ki Pragmatyczny programista przedstawia w
stawienie w kierunku poszerzenia wachla- swych prezentacjach oparty o model Mo-
rza możliwości. Czyli z tego, co musi być na del Braci Dreyfus humorystyczny, ale da-
to, co może być. jący do myślenia test na Eksperta. Jeżeli
Należy jasno podkreślić, że model nie opi- weźmiesz dwóch ekspertów mających od-
suje naszego rozwoju jako całości. Model do- mienne zdanie na dany temat, to zaczną
Poziomy kompetencji wg Modelu Braci Dreyfus
• Novice – robisz coś po raz pierwszy, nie do końca wiesz, o co chodzi. Jesteś nastawiony
na szybką realizację prostego zadania, czegoś, co działa;
• Advanced Begginer – powoli zaczynasz rozumieć, o co mniej więcej chodzi. Twój mózg
zaczyna zauważać powtarzalne wzorce i nie da się tego w żaden sposób wyłączyć. Jed-
nak w dalszym ciągu potrzebujesz kogoś, kto powie Ci, co trzeba zrobić;
• Competent – całkiem dobrze orientujesz się w wyuczonej domenie, a samodzielne my-
ślenie pozwala Ci na planowanie działań na przyszłość. Dzięki temu możesz przejść z wy-
konywania zleconych zadań na samodzielną realizację celów;
• Proficient – odkryłeś, że jest jeszcze coś więcej i zrozumiałeś, że tak naprawdę nic nie
wiesz. Zaczynasz syntezować wiedzę z innych dziedzin, aby rozumieć więcej i lepiej. Za-
dajesz trudne pytania;
• Expert – w większości podejmujesz decyzje intuicyjnie, po prostu wiesz, co trzeba zrobić.
Posługujesz się metaforami. Nieustannie szukasz lepszych metod, czerpiąc jednak inspi-
rację z innych dziedzin.
75
 Efektywność pracy

się spierać. Właściwie to dyskutować, uży-
wając merytorycznych argumentów w ce-
lu przekonania adwersarza. Z czasem po-
winni się nawzajem przekonać do swych ra-
cji – czyli niejako wymienić poglądami. Po
tym wciąż będą się spierać, aby nawzajem
się przekonać do tego, o czym wcześniej by-
li przekonani.
Intuicja – czy jest dozwolona?
W modelu Braci Dreyfus istnieją dwa nie-
jawne atrybuty: potrzeba_reguł oraz opar-
cie_na_intuicji. Na pierwszych szczeblach
potrzebujmy jasnych reguł, które z cza-
sem stają się mniej istotne, a wręcz zaczy-
nają przeszkadzać. Ich miejsce zajmuje tak
zwana intuicja. Oczywiście nie mamy tu
na myśli jakiejś magicznej formy objawie-
nia prawdy.
Chodzi o naturalne procesy kognitywne
zachodzące w mózgu każdego z nas. Mózg
optymalizuje wydatek energii, ucząc się wy-
bierania istotnych danych do przetwarzania.
Z czasem pobudzenia neuronów sięgają co-
raz to niższych warstw kory nowej. W rezul-
tacie ekspert wcale nie myśli szybciej czy w ja-
kiś sposób lepiej. Myśli po prostu mniej, a co
za tym idzie bardziej wydajnie. Po prostu sku-
pia się na istotnych danych, różnica polega na
tym, że jego mózg dokładnie wie, które dane
są istotne.
Normalni ludzie nazywają to zjawisko w
skrócie: intuicja.
Czy w branży technicznej jest w ogó-
le miejsce na coś takiego jak intuicja? Coś,
czego nie da się ująć w ścisłe ramy, zmie-
rzyć i opisać, może wydawać się wręcz nie-
pożądane. Oczywiście decyzji intuicyjnych
nie można uzasadnić i nie można zweryfi-
kować formalnie. Nie da się również opisać
jej w formie powtarzalnej procedury w celu
wdrożenia przez innych. Wady podejścia in-
tuicyjnego są bezdyskusyjne, ale musimy się
z nimi pogodzić, ponieważ (o ile model Bra-
ci Dreyfus jej poprawny) jesteśmy na nie po
prostu skazani.
Model w kontekście IT
Zakładam, że skoro sięgnąłeś po ten artykuł,
to interesujesz się własnym rozwojem. Zakła-
dam też, że skoro doszedłeś do tego rozdziału,
to Model Braci Dreyfus wydaje Ci się w miarę
sensowny. Przyjrzyjmy mu się zatem pod ką-
tem strategii rozwoju kompetencji technicz-
nych w kontekście naszej branży. Zrobimy to
zarówno z perspektywy osobistej, jak i zespo-
łu – jako systemu ludzkiego.
Zacznijmy od oczywistych oczywistości:
oprogramowanie piszą ludzie, nie platfor-
my korporacyjne, języki, narzędzia, meto-
dyki czy frameworki (najlepiej webowe i
najlepiej z zaokrąglonymi rogami każdej,
nawet z natury kanciastej formy). Owszem
są to bardzo ważne elementy całości, ale nie
wystarczające. Głównym elementem proce-
su produkcji czy zespołu w ujęciu systemo-
wym są ludzie.
Zimna metodyka zorientowana na staty-
stycznie optymalne wykorzystanie zasobów
ludzkich (piękne sformułowanie, niepraw-
daż?) będzie, owszem, działać. Przyjrzenie
się każdemu człowiekowi jako jednostce i ele-
mentowi większego systemu ludzkiego mo-
że zwiększyć produktywność tegoż systemu i
przede wszystkim zwiększyć jakość pracy (w
sensie spędzania czasu) – a co za tym idzie,
jakość życia.
I co ja robię tu
Jesteś Nowicjuszem – zwykle jest to Twoja
pierwsza praca i wszystko wygląda zupełnie
inaczej niż na studiach. Aż palisz się, aby za-
kodować w jakimś niskopoziomowym języku
Transformatę Cosinusową, ale zamiast tego
zostajesz wrzucony w sam środek katastrofy
Titanica, który na jutro ma zostać wydobyty
z dna i do tego ma lśnić na prezentacji przed
zarządem lub klientem.
Nie wiesz, od czego zacząć ani po czym po-
znać, że już skończyłeś.
Znając Model Kompetencji Braci Dreyfus,
wiesz co robić: domagaj się małych, krótkich,
dobrze określonych zadań, ponieważ potrze-
bujesz malutkich sukcesów, które zmotywu-
ją Cię do dalszego rozwoju. Chcesz po prostu
zrobić coś, co działa. Jesteś teraz zbyt obcią-
żony, aby dodatkowo jeszcze pogłębiać wie-
dzę na temat specyfikacji – po prostu nie w
tym momencie. Jeżeli Twój przełożony tego
nie wie, to najprawdopodobniej w swoim fa-
chu jest na takim samym poziomie jak Ty w
swoim.
Rozsądny manager nie powinien wrzucać
nowicjusza na głęboką wodę – a przynajm-
niej nie każdego. Taki ktoś zacznie paniko-
wać, co jest zaraźliwe.
Pistolet
Okiełznałeś już nieco chaos techniczny wo-
kół siebie – jesteś Zaawansowanym Początku-
jącym. W dalszym ciągu potrzebujesz zadań
zamiast celów, ale radzisz sobie z nimi cał-
kiem dobrze. Zbyt dobrze, nie masz jeszcze
pokory. Wystarczy nieco piachu na zakręcie,
a rowerek pojedzie w swoją stroną, podczas
gdy Ty przyciągany efemeryczną siłą grawita-
cji z mniejszą lub większa gracją spotkasz się
z ziemią. Niestety w naszej branży efekt prze-
cenienia swych kompetencji nie jest widocz-
ny natychmiastowo.
Błędy wynikające z braku postrzegania
szerszego kontekstu problemu wychodzą na-
wet dopiero po miesiącach. Zły projekt, krót-
kowzroczna architektura, bałagan w kodzie,
brak testów – to boli, ale nie od razu.
Kuszą Cię różnego rodzaju obietnice efek-
tywnych narzędzi, generujących gotowe roz-
wiązania, bez zbędnych konstrukcji, które po-
zwalają na uniknięcie przykrej czynności za-
stanowienia się nad konsekwencjami ich za-
stosowania.
Jeżeli jest taka możliwość, to Zaawanso-
wany Początkujący powinien rozwijać się pod
okiem doświadczonego mentora, aby jak naj-
szybciej opuścić ten poziom, zanim narobi bi-
gosu. Jeżeli natomiast nie masz takiej możli-
wości, to najlepszą radą będzie uświadomie-
nie sobie beznadziejności swego aktualnego
położenia, aby jak najszybciej wskoczyć na
następny poziom kompetencji.

Strategie dla managerów Rzetelny rzemieślnik

• Zlecając zadania Nowicjuszowi, pamiętaj, aby były małe i jasno sformułowane. Powin-
Odważyłeś się samemu podejmować decy-
ny też pozwalać mu na osiągnięcie szybkiego sukcesu, dzięki czemu zwiększa się mo- zje i brać za nie odpowiedzialność. Jesteś na-
tywacja; stawiony na cele i samodzielnie dobierasz
• Podchodź krytycznie do rozwiązań Zaawansowanego Początkującego. Nie ma on jeszcze sposób ich rozwiązania. Definiujesz własne
dostatecznego obrazu, aby uświadomić sobie słabe strony swoich pomysłów. Ważne jest standardy, jednocześnie szukając potwier-
dla niego, że w końcu działa;
dzenia poprawności u bardziej doświadczo-
• Przed Kompetentnym stawiaj cele i pozwól mu na samodzielną ich realizację. Zachęcaj go
również do poszerzania zakresu kompetencji; nych. Jesteś po prostu osobą, na której moż-
• Bądź cierpliwy dla Biegłego i uszanuj jego pęd do samodoskonalenia. Rozwój i ambitne na polegać.
problemy są dla niego teraz ważniejsze niż np. podwyżka; Oczekujesz problemów postawionych ja-
• Wybacz Ekspertowi jego różne dziwactwa. Jeżeli któryś raz z kolei miał rację, to warto mu ko cele oraz autonomii w ich osiąganiu.
zaufać i dać większą autonomię; Konkretne zadania wykopania dołka w da-
• Zachęcaj Ekspertów, aby przeszli do poziomu Guru. Tak, nie każdy będzie miał odpowied-
nie cechy osobowości, ale warto spróbować – to zawsze się opłaca w skali zespołu lub
nym miejscu o zadanych wymiarach są już
firmy. dla Ciebie deprymujące. Jeżeli przełożony
wciąż traktuje Cię jakbyś był Advanced Beggi-

76 02/2010

ner, to musisz zakomunikować swe aspiracje.
Komunikacja to podstawa, a brak komunika-
cji to źródło większości problemów, więc nie
trać czasu ani swego potencjału.
Masz własny styl, ale niestety tylko jeden i
do tego na każdą okazję. Szukaj najlepszych
praktyk i sprawdzonych wzorców, aby nie
utknąć w grząskim gruncie własnych wydaje
mi się, że wiem najlepiej.
Zastanów się dobrze, czy to, co robisz, jest
twoją pasją. Jeżeli tak, to będziesz miał moty-
wację i znajdziesz czas, aby się doskonalić i
przejść na kolejny poziom. Jeżeli jednak nie,
to nie ma potrzeby, aby zbytnio się frustro-
wać, nie wszyscy przecież muszą zajmować
się zawodowo tym, czym się pasjonują.
Pan „dlaczego”
Na poprzednim poziomie byłeś dobry w swo-
im fachu – dosyć dobrze udało Ci się go zgłę-
bić i wypracować dobre metody. Teraz za-
miast w głąb, szukasz wszerz. Kwestionu-
jesz najlepsze praktyki, gdy widzisz, że Cię
ograniczają.
Rozglądaj się w poszukiwaniu szerszych
problemów i ucz się dobierać do nich rozwią-
zanie. Szukaj skojarzeń i paraleli do innych
dziedzin. To poszerzy Twój wachlarz możli-
wości i nauczy Cię zaliczać problemy do pew-
nych klas problemów. Okaże się, że nie każda
aplikacja musi być być np. webowa, dany fra-
mework nie jest uniwersalnym młotkiem do
wszystkiego, a pewien styl architektoniczny
nie nadaje się do każdego projektu. Wszystko
zależy od klasy problemu. Jeżeli jesteś progra-
mistą, to uświadomisz sobie, że języki progra-
mowania, o których palmę zwycięstwa spie-
rałeś się na studiach, należą tak naprawdę do
pewnej wspólnej klasy – różnią się jedynie lu-
krem składniowym i detalami technicznymi.
Tu chodzi o coś innego, większego.
Możesz mieć problem z irytacją wynikają-
cy z otaczających Cię uproszczeń i błędnych,
niepodważalnych założeń. Zaczynasz zada-
wać pytania podważające firmowe dogmaty.
Dlaczego używamy tego podejścia czy roz-
wiązania do tego problemu? Dlaczego robi-
my to akurat tak? Uważaj... jesteś pierwszy
do zwolnienia.
Jeżeli jesteś przełożonym kogoś, kto za-
czyna być biegły, to wykorzystaj jego poten-
cjał. Przydziel mu ambitną misję wymaga-
jącą przekrojowego wysiłku i raczej syntezy
niż analizy.
Ale przede wszystkim wybaczaj jego nad-
mierne zastanawianie się na błahymi (z Two-
jej perspektywy) sprawami. Szanuj biegłego
W Sieci
• strona http://www.infoq.com/presentations/Developing-Expertise-Dave-Thomas;
• strona http://www.infoq.com/articles/better-best-practices.
www.sdjournal.org
podwładnego, bo oto na Twoich oczach po-
woli rodzi się Ekspert, który po pewnym cza-
sie wniesie ogromną wartość dodaną do fir-
my.
Po prostu Ekspert
Swoje decyzje podejmujesz intuicyjnie
– gdzieś w pokładach nieświadomości. Jest
to jedyny sposób Twojego mózgu na radze-
nie sobie z ogromem informacji zdobytych
podczas wieloletniego doświadczenia. Zro-
zumiałeś, że wszystko zależy od kontekstu,
dlatego chętnie posługujesz się metafora-
mi, które wg Ciebie najbardziej trafnie od-
dają sytuację. Możesz mieć problemy z po-
daniem merytorycznych powodów, dla któ-
rych powinno postępować się zgodnie z
Twoimi pomysłami.
Z tego powodu koledzy będący na pierw-
szych szczeblach kompetencji w Twojej do-
menie mogą mieć problem ze zrozumieniem,
o czym do nich mówisz. Zwróć uwagę, czy
gdy wydajesz im polecenie, nie kiwają jedynie
głowami – poproś o opisanie zadań w mailu.
Bądź miły i uważaj, aby nie sprawiać, że Twoi
współpracownicy będą kończyć rozmowę ze
łzami w oczach – nic w ten sposób nie osią-
gniecie jako zespół.
Jeżeli jesteś przełożonym eksperta, to masz
pewien problem – musisz postępować z nim
niczym ze świętą krową. Ekspert bardzo do-
brze zdaje sobie sprawę ze swej wartości na
rynku, bywa zarozumiały, więc nie będzie
się zbyt długo zastanawiał nad zmianą barw
klubowych.
Przede wszystkim musisz zapewnić mu
tak zwany bigger picture. Zdawkowe po prostu
zrób to jest dla Eksperta obraźliwe. Nie zmu-
szaj go do podążania wg standardowych pro-
cedur – to go spowalnia i irytuje. Nie zawra-
caj mu głowy formalnościami typu raporty z
wykonanej pracy. Ekspert wie, że to, co robi,
robi dobrze, więc okaż mu zaufanie i pozwól
na autonomię.
Jeszcze jedna dobra rada, której udziela
Dave Thomas na temat ekspertów: Nie zlecaj
mu opracowania architektury nowego syste-
mu. Znudzony Ekspert wykreuje monstrum
integrujące różne rozwiązania i technologie
tyko po to, aby się zabawić i sprawdzić, jak to
wszystko będzie ze sobą działać.
Należy również uważać na tak zwanych eks-
pertów. Czyli ludzi na poziomie Competent w
pewnej materii, którzy nie mają jeszcze szer-
szej perspektywy. Nie przeszkadza im to jed-
nak w lansowaniu swoich rozwiązań (jedy-
nych, jakie znają) w każdej możliwej sytuacji.
Wspinaczka do profesjonalizmu
Częstym przykładem jest np. sugerowanie sil-
nika bazodanowego jako kompleksowej plat-
formy developmentu całego systemu – pomi-
jając problemy oraz ignorując rozwiązania le-
piej nadające się do niektórych zastosowań.
Tak więc strzeżmy się ekspertów o ograni-
czonym zasobie skojarzeń oraz tych nieprak-
tykujących – samozwańczych. Łatwo też wy-
obrazić sobie, ile może być warta jedna słusz-
na strategiczna decyzja prawdziwego Eks-
perta.
Guru
Co prawda nie opisany w standardowym mo-
delu braci Dreyfus, ale niektórzy wyróżniają
tę specjalną klasę Ekspertów. Guru to taki eks-
pert, który ma dobry interfejs ludzki (sprzęg,
jak mawiano w erze krzemu łupanego). Dzię-
ki wysokiej empatii potrafi dostosować swój
przekaz do aktualnego poziomu odbiorcy. Po-
trafi również operować sugestywnymi przy-
kładami oraz prowokować do zadawania wła-
ściwych pytań. Dzięki temu każdy, kto uda
się do Guru po radę, wraca z jakąś odpowie-
dzią – a przynajmniej z natchnieniem. Ema-
nuje on aurą, dzięki której wszyscy wokół roz-
wijają się szybciej i w dobrym kierunku.
Jeżeli jesteś ekspertem, to warto popraco-
wać nad przepoczwarzeniem się do formy
Guru, ponieważ tylko wówczas zyskasz sza-
cunek i staniesz się bohaterem opowieści snu-
tym wnukom przez twych uczniów.
Liczy się doświadczenie
Przedstawiony model kompetencji zakłada
liniowy rozwój do trzeciego poziomu – od
Novice, poprzez Advanced Begginer po Com-
petent. Liniowy, czyli odbywający się propor-
cjonalnie do czasu powtarzania (trenowania).
Natomiast dalszy rozwój – poprzez Proficient
do Expert – nie jest już liniowy, ponieważ wy-
maga skoku jakościowego naszej aktywności.
Skoku polegającego na poszerzeniu zakre-
su zainteresowań w celu rozwinięcia ogólne-
go obrazu.
Dlatego warto zastanowić się nad naszym
x lat doświadczenia w branży. Czy jest to x lat
różnych doświadczeń, czy tak naprawdę je-
den rok, powtórzony x razy?
SŁAWOMIR SOBÓTKA
Konsultant w firmie BNS IT. Interesuje się szeroko
pojętą inżynierią oprogramowania: architekturą
systemów JEE, Domain Driven Design, wzorcami,
procesem wytwórczym. Hobbystycznie interesuje
się psychologią i kognitywistyką. Oprócz dosko-
nalenia rzemiosła stara się odnaleźć w progra-
mowaniu również pierwiastek sztuki.
Autor bloga poświęconego całościowemu ujęciu
inżynierii oprogramowania: http://art-of-softwa-
re.blogspot.com
Kontakt z autorem: ssobot@gmail.com
77
Roczna prenumerata

tylko
256,-
Software Developer’s Journal (poprzednio Software 2.0)
jest miesięcznikiem głównie dla programistów, którzy li-
czą, że dostarczymy im gotowe rozwiązania, oszczędza-
jąc im czasu i pracy. Jesteśmy czytani przez tych, któ- UWAGA!
rzy chcą być na bieżąco informowani o najnowszych osią-
gnięciach w dziedzinie IT i nie chcą, żeby jakiekolwiek
istotne wydarzenia umknęły ich uwadze. Aby zadowolić Zmiana danych
kontaktowych
naszych czytelników, prezentujemy zarówno najnowsze
rozwiązania, jaki starsze, sprawdzone technologie.

Obsługa prenumeraty
Software Press Sp. z o.o. Spółka Komandytowa
1. Telefon
(022) 427 37 59
2. Fax
(022) 244 24 59
3. Online
pren@software.com.pl
4. Adres
Software Press Sp. z o.o. Spółka Komandytowa
ul. Bokserska 1
02-682 Warszawa
 Prenumerujesz
– zyskujesz
l oszczędność
pieniędzy
l szybka dostawa
l prezenty
l bezpieczna płatność
on–line

Zadzwoń
lub
zamów
mailowo!

Ilość Od
Ilość zama- numeru
Tytuł nume-
rów
wianych pisma
prenu- lub mie-
Cena

merat siąca
Software Developer’s
Journal (1 płyta DVD) 12 256
– dawniej Software 2.0 PLN
 KLUB PRO
Oferta skierowana dla firm
Jeżeli Twoja firma jest prenumeratorem Software Developer’s Journal za comiesięczną
dopłatą 50 PLN +VAT możesz dodatkowo otrzymać reklamę.
Wystarczy tylko, aby profil Twojej firmy pokrywał się z naszym magazynem.
Wyślij do nas: logo firmy, dane kontaktowe i informację o firmie
Reklama przez 12 kolejnych numerów tylko za 600 PLN +VAT.
Jeżeli nie posiadasz jeszcze prenumeraty możesz ją zamówić w atrakcyjnej cenie.
Dla nowych prenumeratorów specjalna oferta – 690 PLN.

Skontaktuj się z nami:

tel. +48 22 877 20 80
fax: +48 22 877 20 70
software@europress.pl

Opera Software Architektury systemów IT

Opera Software’s vision is to deliver the best In-
ternet experience on any device. We are offering
browser for PC/desktops and embedded pro-
ducts that operates across devices, platforms
and operating systems. Our browser can deliver
a faster, more stable and flexible Internet expe-
rience than its competitors.
http://www.opera.com
Twórca frameworków JUVE i serwera aplikacji
AVAX oferuje usługi, doradztwo, rozwiązania do
tworzenia nowoczesnych, dużych systemów i roz-
wiązań informatycznych/internetowych, integrujące
architektury ery post-J2EE/.NET, wykorzystujące
MDD/MDA dla dziedzin – bankowość, telekomuni-
kacja, handel, e-commerce, ERP/Workflow/CRM,
rozwiązania internetowe, portalowe.
www.mpsystem.com mpsystem@mpsystem.com

Kei.pl Future Processing

Kei.pl działa na rynku usług hostingowych od 2000
roku. Do naszych zadowolonych Klientów z du-
mą możemy zaliczyć wiele przedsiębiorstw sekto-
ra MSP, instytucji oraz osób prywatnych. W ofer-
cie Kei.pl znajdują się pakiety hostingowe, a także
usługi dla wymagających Użytkowników – platfor-
my e-Biznes oraz serwery fizyczne.
Future Processing to dynamiczna firma technolo-
giczna działająca na globalnym rynku oprogramo-
wania. Jesteśmy zespołem wysokiej klasy specja-
listów posiadających wiedzę i doświadczenie nie-
zbędne do realizacji ambitnych projektów informa-
tycznych. Jeśli programowanie to Twoja pasja do-
łącz do nas! (możliwość pracy zdalnej).

http://www.kei.pl http://www.future-processing.pl

Playsoft WSISiZ w Warszawie

Playsoft jako lider portowania aplikacji na plat-
formy mobilne wciąż powiększa bazę swo-
ich klientów: EA Mobile, Sega, THQ, Kona-
mi. W ramach rozszerzania swojej działalno-
ści, poszukujemy doświadczonego programi-
sty, który byłby odpowiedzialny za tworzenie
aplikacji na platformy Iphone, Windows Mobi-
le, Android.
http://www.playsoft.fr
INFORMATYKA ZARZĄDZANIE
studia stopnia I i II (stacjonarne i niestacjonar-
ne) specjalności: inżynierskie, magisterskie
i licencjackie. Szczegółowe plany studiów, opi-
sy poszczególnych specjalności – zapraszamy
na stronę uczelni.
http://www.wit.edu.pl
 KLUB PRO
INFOTEX SP.J
Śmietanowski i Wsp.
Dystrybutor XP Unlimited – Serwer Terminali dla
Windows XP i VISTA. Program umożliwia łącze-
nie się z dowolnego klienta Windows, Linux z wy-
korzystaniem protokołu RDP. Cena wersji Classic
dla 5 użytkowników - 165€, dla nieograniczonej
liczby - 235€. Ponadto oferujemy opiekę serwiso-
wą i aplikacje internetowe na zamówienie.
http://www.infotex.com.pl
IT SOLUTIONS
Wdrożenia i szkolenia z zakresu:
• SQL Server
• SharePoint Services
IT SOLUTIONS • MS Project / Server
• Tworzenie aplikacji w technologii .NET
http://www.itsolutions.biz.pl
marcin.pytlik@itsolutions.biz.pl
Proximetry Poland Sp. z o.o.
Proximetry Poland Sp. z o.o. jest polskim od-
działem amerykańskiej firmy Proximetry Inc. –
dostawcy systemów zarządzania sieciami bez-
przewodowymi opartymi na technologiach WiFi
i WiMAX. Naszą misją jest dostarczenie klien-
tom rozwiązań poprawiających jakość usług
(QoS) dostarczanych drogą radiową. Dołącz do
najlepszych i zostań członkiem naszej ekipy!
http://www.proximetry.com
TTS Company Sp. z o.o.
Sprzedaż i dystrybucja oprogramowania komputero-
wego. Import programów na zamówienie. Ponad 200
producentów w standardowej ofercie. Chcesz kupić
oprogramowanie i nie możesz znaleźć polskiego do-
stawcy? Skontaktuj się z nami – sprowadzimy nawet
pojedyncze licencje.
http://www.OprogramowanieKomputerowe.pl
Softline rozwiązania mobilne
Wiodący producent systemów mobilnych, do-
stawca aplikacji użytkowych dla biznesu (Sym-
bian OS, Windows Mobile, J2ME ) zaprasza do
współpracy. Zostań naszym partnerem. Dołącz
do zespołu.
http://www.softline.com.pl
Systemy bankowe, ISOF
HEUTHES istnieje na rynku od 1989 r. Obok
systemów informatycznych dla banków, ofe-
ruje nowoczesne oprogramowanie do obsługi
firm. System ISOF jest udostępniany klientom
w trybie SaaS lub licencji. Pracuje na platfor-
mie Linux i zawiera m.in. takie moduły jak
CRM, DMS, Magazyn, Sprzedaż, Logistyka
oraz Rachunkowość.
http://www.isof.pl
 Felieton
M
iło nam poinformować, iż Software Developer's Journal
został patronem medialnym drugiej edycji międzynaro-
dowej konferencji GeeCON, która odbędzie w dniach 13-
14 maja 2010 r. w Poznaniu.
GeeCON to konferencja poświęcona technologiom, u podstaw
których znajduje się język Java wraz z platformą, jaką jest Wirtual-
na Maszyna Java. Organizatorami konferencji są Poznańska i Pol-
ska Grupa Użytkowników Języka Java oraz stowarzyszenie Gru-
pa Informatyczno-Kulturalna. Organizatorzy chcą promować roz-
wiązania zwiększające produktywność programistów takie jak ję-
zyki dynamicznie typowane (m.in. Groovy, Ruby) czy nowocze-
sne szkielety aplikacyjne (m.in. Grails, Apache Wicket). W tym roku
chcą położyć nacisk również na technologie mobilne (wśród nich
Android oraz JME) i rozwiązania do tworzenia Rich Internet Appli-
cation (Flex i JavaFX).
Poprzednia edycja konferencji GeeCON odbyła się w ma-
ju 2009 w krakowskim Multikinie. Odwiedziło ją wielu specjali-
stów z kraju i świata, m.in. Austrii, Czech, Niemiec, Wielkiej Bryta-
nii, Francji, Stanów Zjednoczonych. Wśród prelegentów znaleź-
li się m.in.: Adam Bien, Alef Arendsen, Antonio Goncalves, Bru-
no Bossola, Corneliu Creanga, Giorgio Natili, Jacek Laskowski,
Luc Duponcheel, Miško Hevery, Paweł Wrzeszcz, Piotr Walczy-
szyn, Simon Ritter, Stephan Janssen, Szczepan Faber, Thomas
Enebo, Václav Pech, Waldemar Kot. W konferencji uczestniczyło
prawie 400 gości, którzy ocenili wysiłki organizacyjne i poziom
merytoryczny bardzo wysoko – interesujące prezentacje, świa-
towej sławy prelegenci i niepowtarzalna atmosfera, a wszystko
to przy zachowaniu bardzo niskiej opłaty za uczestnictwo. Dzień
82
GeeCON 2010
przed właściwą konferencją, w ramach GeeCON University Day,
we współpracy z firmą Sun Microsystems, udało się zorganizo-
wać serię dedykowanych szkoleń. Nie zabraknie ich również w
tym roku (12 maja).
Kolejnym miastem, do którego zapraszają nas organizatorzy,
jest Poznań – miasto tętniące życiem, miejsce, gdzie tysiąclet-
nia historia spotyka się z nowoczesnością. Tu co roku organizo-
wanych jest wiele imprez kulturalnych i targowych, które od-
wiedzają goście z całego świata. Poznań oferuje przyjazną at-
mosferę dla biznesu, ale również przestrzenie, w których ro-
dzą się innowacyjne pomysły. Wystarczy wspomnieć tylko o
obecności ośrodków badawczo-rozwojowych wielkich kon-
cernów takich jak Microsoft, Carlsberg, Dalkia, GlaxoSmithKli-
ne czy Roche.
GeeCON w Poznaniu to nie tylko dwa dni konferencji i możli-
wość uczestnictwa w szkoleniach, to również spotkania towarzy-
szące, podczas których uczestnicy mają okazję do nawiązywania
licznych kontaktów. To wyjątkowa okazja, aby porozmawiać ze
światowej klasy specjalistami, których nie zabraknie podczas te-
gorocznej edycji. To również szansa podzielania się swoją wiedzą
lub prezentacji własnych rozwiązań – do grona prelegentów mo-
że bowiem dołączyć każdy, kto zgłosi temat prezentacji w języku
angielskim i zostanie przyjęty przez komitet organizacyjny konfe-
rencji.
Rejestracja na GeeCON właśnie się rozpoczęła! Do końca marca
obowiązują promocyjne ceny. Po więcej szczegółów zapraszamy
na strony konferencji – www.geecon.org. Organizatorzy gwarantu-
ją, że będzie to niezapomniane wydarzenie!
02/2010