Tak się złożyło, że przez większość czasu jaki spędziłem w game developingu, zajmowałem się projektowaniem i tworzeniem narzędzi i edytorów. Przez wiele lat, moje podejście do nich ewaluowało zarówno od strony obsługi jak i zasady ich pisania i myślę, że można by napisać nie jedną książkę o tym. W tej chwili jednak skoncentruję się na głównych elementach takich edytorów. Obecnie jestem zwolennikiem nowego trendu, aby pisane edytory były typu modeless (czyli bez okien dialogowych blokujących pracę na innych oknach) oraz aby edytor był zorganizowany w tzw. Inductive UI czyli aby edytor był zorientowany zadaniowo (polega to na dostosowywaniu widoku UI do aktualnego wykonywanego zadania). Chodzi głównie o zrezygnowanie z wielopoziomowych menu i pokazywania setek okien tylko po to aby wykonać banalnie prostą czynność. Złożoność edytora może być bardzo duża, ilość dostępnych funkcji ogromna, przez co dość łatwo jest stworzyć bardzo powolny i ciężki w obsłudze interface. Przykładem nowego podejścia i zastosowania Inductive UI jest najnowsza wersja Microsoft Office 2007 (w chwili obecnej jeszcze w fazie beta). Jedną z głownych zasad Inductive UI jest, że im mniejsza ilość kliknięć myszką tym lepiej można wykorzystać narzędzie i tym szybsza jest w nim praca. Ta zasada wymaga wprowadzenia dość poważnych zmian w aktualnych frameworkach narzędzi oraz użytych kontrolkach. Ale tym zajmę się innym razem. Teraz chciałbym omówić konstrukcję typowego edytora. Edytor służący tworzeniu gier, składa się z 4 głównych elementów:- Widok renderujący. Jest to widok w którym przedstawiony jest poziom gry w sposób możliwie najbardziej zbliżony do tego jaki będzie w samej grze. Chodzi głównie o to, żeby ktoś tworzący poziom gry (nie ma znaczenia czy to gra 2D czy też 3D) widział jak składane elementy poziomu będą wyglądać w grze bez konieczności ciągłego uruchamiania gry. Dobrze jest jeśli widok renderujący posiada kilka trybów wyświetlania i umożliwia oprócz widoku gry (Game View) również pokazanie widoków związanych głównie i tylko z edycją. Mogą to być nazwy obiektów, obszary kolizji, selekcja (specjalny tryb wyświetlania elementów/obiektów, które są aktualnie zaznaczone i na których możemy w danej chwili przeprowadzić operacje).
- Widok zasobów. Widok w którym widać wszystkie dostępne w grze zasoby (ang. assets) z których można skorzystać podczas układania poziomu gry. Dobrze jeśli widok zasobów pozwana na szybki podgląd zasobu jak np. obejrzenie tekstury, odegranie dźwięku, obejrzenie obiektu/modelu. Bardzo dobrze również, jeśli zasoby dają się łatwo segregować (automatycznie lub ręcznie) w różne kategorie, np. kategorię dźwięki, która dzieli się z kolei na podkategorie; dźwięki otoczenia, dźwięki broni, dźwięki postaci itd. Bardziej zaawansowany i uniwersalny widok, umożliwia przydzielenie zasobu do kilku kategorii jednocześnie (np. dźwięk ptaków, może się znajdować a kategorii dźwięków otoczenia jak i w kategorii dźwięków dziennych) Projektując oraz implementując widok zasobów trzeba mieć na uwadze, że w już w średniej wielkości grach liczba zasobów sięga kilka lub kilkanaście tysięcy, więc nie tylko wygoda, porządek ale i również prędkość działania widoku zasobów ma tutaj spore znaczenie.
- Widok zasobów planszy. Jest to lista zasobów, które zostały aktualnie wczytane i użyte na aktualnie edytowanej planszy. W tym widoku dość ważna jest łatwość szybkiego zaznaczania elementów planszy oraz podglądanie i edycja parametrów tych elementów. Dobrze, jeśli ten widok pozwala na segregowanie elementów niezależnie od ich kategorii w widoku zasobów. Często w widoku zasobów planszy ważniejsze jest np. układanie elementów wg obszarów na których się znajdują lub sposobu w jaki w grze będą prezentowane. W tym widoku można wprowadzić dodatkowy wirtualny podział za pomocą warstw (ang. Layers). Można wtedy umieszczać elementy planszy, oddzielnie na warstwie przeciwników AI, oddzielnie na warstwie obiektów tła, oddzielnie na warstwie dźwięków itd. Dobrze jeśli na warstwach można przeprowadzać operacje takie jak typowych w programach 3D, czyli zamrożenie (warstwa jest widoczna, ale nie można edytować znajdujących się na niej elementów), chowanie całej warstwy itd. Bardzo ważne jest, abyśmy pamiętali podczas tworzenia widoku zasobów planszy, że widok ten będzie przedstawiać nie tylko elementy wczytane z zasobów, ale także elementy stworzone tylko w edytorze i często nie mające swojego odpowiednika w plikach zasobów.
- Okna z narzędziami i parametrami. Zgodnie z ideą Inductive UI należy rezygnować z tworzenia rozrośniętych menu zawierających wszystkie możliwe funkcje programu oraz zajmujących 50% powierzchni ekranu, toolbarów. W tej chwili wygląd interface’u oraz lista dostępnych narzędzi zmienia się wraz z czynnością, którą użytkownik w danym momencie wykonuje. Gdy np. w danej chwili zajmujemy się ustawianiem obiektów na planszy, to nie ma potrzeby zaśmieciania ekranu toolbarami czy też oknami, dotyczącymi np. rysowania terenu albo tworzenia obiektów aktywnych związanych z AI lub scenariuszem. Dostępne funkcje powinny być czytelnie przedstawione tak aby bez zbędnego „odrywania” się od wykonywanej czynności, można było łatwo znaleźć interesującą nas funkcję. Ponadto kontrolki powinny przedstawiać dane w możliwie jasny i zrozumiały sposób. Wiadomo, że np. lepiej aby parametr koloru przedstawić za pomocą paska lub kwadratu z wybranym kolorem, zamiast pokazywać ciągi liczb. Nawet jeśli użytkownik rozumie zasadę działania parametrów R,G,B to znacznie szybciej i wygodniej mu będzie sprawdzić kolor gdy poprostu spojrzy na zielony lub żółty kwadrat.
Tak oto można podzielić edytor służący tworzeniu gier. Każdy z tych elementów jest wbrew pozorom trudny do zaprojektowania i jego forma i sposób działania w dużej mierze wpływa na wewnętrzną organizację danych oraz funkcji. W kolejnych postach zajmę się omawianiem każdego z tych elementów.