ajaxQuake?

2 sierpnia 2006

Przeczytałem niedawno w PCWK serię artykułów poświęconych zdobywającej coraz szersze uznanie technologii AJAX. Obcowanie z GMailem robi niesamowite wrażenie. Co więcej – nieomal szokujące, jeśli zna się wszystkie meandry tworzenia systemów sieciowych. Podstawowa przewaga aplikacji typu „desktop” - szybkość przetwarzania nagle przestaje się liczyć, wszak Google Suggests podpowiada frazy z rozsądną prędkością...    Oczywiście, AJAX jest obecnie technologią wznoszącą się, i obserwując rozwój innych mechanizmów w informatyce można próbować przewidzieć jej przyszłość. Podobnie jak miało to miejsce w przeszłości, dobry pomysł i rozsądne pieniądze zainwestowane teraz w AJAXa mogą przynieść szybkie bogactwo i sławę. Z drugiej jednak strony, niebawem będziemy świadkami kilku spektakularnych bankructw firm powiązanych z tą nową technologią. To zupełnie normalny bieg rzeczy, charakterystyczny dla technologii wschodzących. Gdy ostatecznie AJAX okrzepnie, gdy stanie się technologią dojrzałą, wtedy kolejne pojawiające się ajaksowe aplikacje nie będą budziły sensacji, lecz będą oceniane chłodnym okiem, a firmy przed rozpoczęciem przedsięwzięć będą brać pod uwagę technologię AJAX w ten sam sposób, w jaki dziś rozważają użycie Delphi lub EJB.    Dojrzałość technologii pociąga za sobą kilka ciekawych kwestii. Po pierwsze, okazuje się wtedy do czego dana technologia się absolutnie nie nadaje. Pomimo poprawek i rozwoju bywa czasami tak, że pewne zastosowania pozostają na zawsze zamknięte – przykładem może być pisanie aplikacji internetowych w Delphi, czy też klientów desktopowych w Javie. Owszem, można to robić lecz praktyka pokazuje, że rozwiązania takie mają znikomy udział w rynku. Czego AJAX na pewno nie będzie potrafił, tego na razie nie wiemy. Osobiście uważam, że głównym problemem tej technologii będzie ... język stanowiący jej podstawę. JavaScript nie jest bowiem narzędziem wysoce produktywnym, zaś tworzony w nim kod jest po prostu brzydki. Owszem, wielu webmasterów oburzy się na te słowa ale, mimo wszystko daleko mu do elegancji i spójności języków takich jak Java, C# czy Object Pascal. O ile jednak dla budowy strony domowej czy pojedynczych rozwiązań JavaScript nie jest problemem, o tyle w skali światowej brzydota języka oznacza często problem, którego boją się jak ognia inżynierowie oprogramowania: trudność konserwacji. Niestety, aby technologia była użyteczna, tworzony w niej kod musi być prosty w utrzymaniu i tworzeniu. Dlatego właśnie takie tryumfy święci Java czy platforma .NET i dlatego coraz mniej oprogramowania pisze się w czystym C. Oczywiście, wiele systemów pisze się zarówno w C jak i nawet w asemblerze, jednak robi się to z uwagi na ich szybkość, zdając sobie sprawę że taka szybkość kosztuje dużo więcej czasu programistów...    Patrząc na AJAX w dłuższej perspektywie paskudność JavaScriptu może się okazać jedynie przejściowym problemem. Nie istnieje bowiem żadna przeszkoda, aby w przyszłości jego miejsce zajęły lepsze i bardziej nadające się do tych celów języki skryptowe. Dogadanie się między producentami przeglądarek nie wchodzi w grę, jednak prędzej czy później należy się spodziewać jakiś zmian. Być może tym nowym językiem będzie nawet odmieniony JavaScript, dla którego AJAX jest nadzieją na wyjście ze ślepej uliczki narzędzia do robienia wodotrysków na stronie...    Kiedy już AJAX pokona ograniczenia techniczne można zastanawiać się, do czego uda się tej technologii dojść. Oczywiście w obecnej postaci nie potrafi ona wiele – naprawdę ciekawe obszary dopiero czekają na penetrację. Takie pola zastosowania jak karty graficzne pozostają wciąż niezdobyte, a przecież w kartach graficznych tkwi klucz do nowoczesnej rozrywki. AJAX mógłby przecież wyświetlać trójwymiarową grafikę, wczytując z serwera parametry obrazu, a stąd już tylko krok do stworzenia trójwymiarowych gier. Aby do tego doszło, producenci muszą najpierw przeskoczyć wiele barier mentalnych, bo technologia już czai się za płotem. W przeciwieństwie do lat 90tych coraz więcej gier korzysta z tych samych engine'ów graficznych, podmieniając jedynie pewne ich cechy i dodając swoje rozszerzenia. Ujednolicenie w tej kwestii może wręcz spowodować, że pojawią się w sieci nowe możliwości biznesu: dostarczyciele bibliotek do gier. W połączeniu z serwisami dostarczającymi „etapy” (poziomy, mapy) do gry, można będzie w końcu stworzyć ajaksowego Quake... W praktyce pozostaje tylko jeden problem: tekstury i bryły, bez których nie da się zbudować żadnej trójwymiarowej gry, ale ten właśnie problem staje się trywialnym, gdy tylko uwolni się swój umysł...    Wyobraźmy sobie płytę DVD (albo jej mniej lub bardziej hipotetycznych następców) zawierającą tylko i wyłącznie tekstury, poligony, źródła światła i bitmapy potrzebne do konstrukcji wirtualnych światów. Wyobraźmy sobie, że płyty takie są powszechnie dostępne za symboliczną opłatą. Zawierają one gigabajty surowca dla karty graficznej, który po skopiowaniu na wciąż taniejące twarde dyski leży sobie czekając na chwilę, gdy gracz połączy się z serwisem swojej ulubionej gry. AJAXowa aplikacja połączy się z dostarczycielem engine, engine na podstawie informacji o świecie gry skorzysta z dyskowej biblioteki i przedstawi graczowi oszałamiające widoki i zadowoli go fascynującą fabułą... Po zakończeniu gry gracz zapłaci twórcom swojej ulubionej gry odpowiednią stawkę, a jego pieniądze zostaną podzielone pomiędzy dostarczycieli treści i (w dużo mniejszym stopniu) dostarczycieli mechaniki świata gry.    Firmy tworzące engine sprzedawać będą go setki tysięcy razy dziennie, w ten prosty sposób tworząc swój biznes, więc szeroka dostępność bibliotek „graficznych” będzie dla nich po prostu źródłem zysku. Biblioteki ulegną standaryzacji, po to aby twórcy fabuły gier mieli stabilną platformę do pracy. W ten sposób architektura gier stanie się trójwarstwowa: począwszy od najważniejszych ludzi, czyli twórców fabuły, poprzez techniczną warstwę pośrednią, wprawiającą wszystko w ruch, aż po grafików i „projektantów wnętrz” którzy tworzyć będą dla całej tej machiny potrzebne jej tekstury. Im większą różnorodność i możliwości zapewnią warstwy niższe, tym bardziej wyobraźnia twórców fabuły będzie mogła zamieniać się w cudowne światy gier.    Taki model sieciowej rozrywki, gdzie to, co dotąd w grach najważniejsze, czyli engine, zostanie zepchnięte do roli pomocniczej, ma szansę na realizację z jednego, najważniejszego chyba powodu: gry w trybie on-line nie da się sprzedać na bazarze... Przejście z modelu produktu na model usługi, jest tym co najbardziej kręci menadżerów z rynku IT.    Czy więc AJAX i jego następcy zmienią model rozrywki komputerowej? Czy nadejdzie rewolucja? Czy piraci zbankrutują? Cóż... czas pokaże.

Ostatnia modyfikacja: 8 sierpnia 2006 (c) Michał Bielamowicz, Kraków 2005 - 2006 e-mail: michal(at)bielamowicz.info