To zaskakujące jak mało materiałów w Internecie jest poświęcone konstrukcjom programów opartych o Data Driven (przykładem jest chociażby porównanie ilości tekstu na wikipedii w haśle Data Driven Design http://en.wikipedia.org/wiki/Data-driven_design oraz w haśle dotyczącym Object Oriented Design http://en.wikipedia.org/wiki/Object_oriented_design ). Tłumacząc na język polski, Data Driven Design jest sposobem tworzenia programów sterowanych całkowicie za pomocą danych wprowadzanych z zewnątrz.

Tak małą ilość informacji o tej metodzie, tłumaczy za pewne fakt, że programowanie DD ma dość małe zastosowanie jeśli chodzi o powszechnie używane aplikacje. Największą wadą tego rozwiązania jest z pewnością to, że wymaga dość abstrakcyjnego podejścia do programowania. Zamiast tworzyć kod wykonujący z góry określone działanie, trzeba stworzyć kod który do działania będzie wymagać wiele innych zewnętrznych, pozornie nie powiązanych ze sobą elementów. Przykładem będzie np. główna postać gry. W przypadku pisania w OO, stworzymy klasę „CPlayer” w której zawrzemy potrzebną nam funkcjonalność. Będzie to reakcja na sterowanie klawiaturą, uruchamianie odpowiednich animacji, ekwipunek jaki postać posiada, listę umiejętności itp. To jest typowe postrzeganie świata przez wielu programistów i jest ono dość naturalne. Nie mniej ma sporo wad. Po pierwsze jest wbrew zasadzie re-usable code czyli możliwości użycia kodu dla innych podobnych zastosowań. Oczywiście nie wyklucza tego zupełnie, ale to prowadzi do sytuacji np. takiej jak np. opisana tutaj http://www.gamasutra.com/features/20000628a/fristrom_01.htm . W kodzie do gry Tony Hawk, znajduje się klasa gracza o nazwie CBruce, a swoją nazwę odziedziczyła po poprzedniej grze (na tym silniku) Apocalypse w której główną postacią był Bruce Willis. Aż strach pomyśleć jakie inne cechy oprócz nazwy, odziedziczyła postać Tony Hawk’a po Willisie. Inną złą cechą OO jest duża odporność na wprowadzanie zmian. Ponieważ spora część funkcjonalności gracza zostaje zawarte bezpośrednio w kodzie, wprowadzenie każdej zmiany której zażyczy sobie designer lub grafik, musi być dokonane przez programistę który staje się narzędziem typu Notepad i który przyjmuje coraz to nowe życzenia zamiast rozbudowywać kod o nowe możliwości. Problem ten został opisany w prezentacji http://www.gamasutra.com/features/20060327/woodard_01.shtml o dość przewrotnym tytule „Jak lewa i prawa półkula mózgu nauczyły się pracować razem”. W prezentacji jest przestawione, jak użycie silnika opartego o DD pozwoliło designerom i grafikom na stworzenie realistycznie wyglądającego świata oraz umożliwiło programistom na skupienie się na tym co lubią najbardziej czyli pisaniu kodu.

To oczywiście część problemów z długiej listy wad rozwiązań opartych na OO. Prawie każdy kto napisał jakąś grę opartą o OO, patrzy w cały kod który stworzył i łapie się za głowę widząc duży chaos tam panujący. Postanawia napisać kod od nowa i… popełnia te same błędy. Niestety dość często byłem tego świadkiem. Nowy, kolejny, wspaniały silnik, okazywał się na końcu powieleniem tych samych rozwiązań i problemów jakie były w poprzednim. Siła przyzwyczajenia jest niestety czasami zbyt duża.

Pierwszą rzeczą jaką należy sobie zdać sprawę jest fakt, że taka właściwość postaci gracza jaką jest np. ekwipunek, może być użyta w wielu innych miejscach. Właściciel sklepu, skrytka w dziupli drzewa, wrak statku, zawartość listu w skrzynce pocztowej jak i sama skrzynka pocztowa. Przykłady można by mnożyć i najważniejszą istotą sprawy jest to że nikt (włącznie z programistą) nie jest w stanie wyobrazić sobie ilości zastosowań ekwipunku. Kiedy uzmysłowimy sobie ten prosty fakt, będziemy dążyć do sytuacji w której ekwipunek będzie mógł stać się częścią dowolnego obiektu w świecie gry. Oczywiście z punktu widzenia optymalizacji, najgorszą rzeczą jaką możemy w tym momencie zrobić to dodać właściwość „Ekwipunek” do wszystkich obiektów w świecie. Z dość prostego powodu. Oprócz ekwipunku takich uniwersalnych elementów można namnożyć setki (możliwość prowadzenia dialogu z graczem, możliwość walki, możliwość poruszania się itd.). Na końcu tworzenia gry, skończylibyśmy z jedna klasą CObject która by zawierała wszystko, a plik źródłowy tej klasy miałby kilka megabajtów. Jednym z rozwiązań jakie wspomagają programowanie DD jest programowanie oparte o komponenty. Ale o tym w następnej części.

Projektowanie Data Driven cz. 1
0 votes, 0.00 avg. rating (0% score)