O MMORPG słów kilka AKA "Dlaczego WoW ssie"

Jako, że temat popularny, kilka słów o różnych MMO warto napisać. Krótkie podsumowanie, wytknięcie wad i zalet z punktu widzenia osoby mojego typu - programisty i człowieka, wychowanego na grach z epoki 1996-2001. Jako przykład (będzie to opis porównawczy) wezmę dwa znacznie różne MMORPG: World of Warcraft (by Blizzard) oraz EVE Online (by CCP). W obie te gry grałem, zatem sądzę, że ich użycie będzie w tym przypadku najlepszym rozwiązaniem.

XNA

XNA zostało przygotowane głównie, żeby 'mali' też mogli pisać na XKlocka. Niby wolniejsze niż DirectX, niby korzysta z 'niewygodnego' C#, niby gorsze, mniej fajne itd. - ale jednak całkiem przyjemne w pisaniu.

Statsy

Lubimy liczby. Statystyki, liczniki, wskaźniki. Użyte do mierzenia pracy pokazują nam, ile obiektywnie zrobiliśmy – przynajmniej w jakimś aspekcie. Wśród programistów popularny jest jeden rodzaj licznika: licznik linii kodu w projekcie.

Skrypty

Niewiele jest nowych gier, które radzą sobie bez jakiegokolwiek silnika skryptowego. Samych skryptów i silników skryptowych też jest dużo. Co to w efekcie daje? Nie wiadomo czy pisać, nie wiadomo co wybrać, nie wiadomo jakie kryteria wyboru będą właściwe.

Tablet PC

Post za postem, ale tego wymaga sytuacja. Ostatnimi czasy nie miałem okazji napisać i pochwalić się czymkolwiek nowym.

Runtime property

Patrząc na dowolną bazę danych ustawień (np. rejestr Windows) mamy przed oczami następujący obraz: aplikacja wywołuje funkcję i zmienia dane, gdy dane gdzieś są potrzebne, są odczytywane i używane. Niby wszystko ładnie, co jednak, gdy potrzebujemy użyć zmienionych danych natychmiast po ich użyciu? Albo gdy chcemy zapewnić dostęp do konkretnych danych tylko i wyłącznie, gdy są w użyciu (np. pobieranie aktualnej rozdzielczości, pozycji okna)? Zwykle w takim przypadku stosuje się albo ręczne powiadomienia, albo odpytania. Jedno i drugie z elegancją wspólnego ma tyle, co garbage collector z C. Ostatnio, pracując nad własnym systemem opcji, znalazłem rozwiązanie ładniejsze i zdecydowanie sprawniejsze.

Mobile Web - DO-s i DON'T-s

Pisanie aplikacji na smartphone to sprawa niełatwa. Wbrew pozorom, napisanie strony internetowej wyglądającej dobrze i na komputerze, i na smartphone - to sprawa jeszcze trudniejsza. Jest kilka ograniczeń w używaniu telefonów komórkowych, które odbijają się też w webdev. Na potrzeby tego posta zakładam, że nie robimy osobnej, mobilnej wersji, a tylko dostosowujemy główną do przeglądania z poziomu telefonu.
Stąd wzięło się 10 przykazań: trzy nakazy i siedem zakazów, ku chwale developera i wygodnemu życiu użytkowników zmobilizowanych ;-)

Test them all!

Testowanie - nieprzyjemna sprawa. Piszesz program, wszystko wygląda ładnie, schludnie, a tu nagle okazuje się, że coś nie działa. Dodatkowe kilka godzin/dni szukania błędu, szukania przyczyny błędu, poprawiania. Testy są ważne, bo bez tego - jak wiadomo - program nie działa właściwie, użytkownicy wściekli, ogólnie nieprzyjemna sprawa.
Z testowaniem zawsze jest jedna nieprzyjemna sprawa: często można znaleźć przypadek tak ekstremalny, w którym nawet wyglądający na idealny kod nie będzie działał poprawnie. Coś nie działa zaraz po starcie programu, coś przy pewnej specyficznej konfiguracji nie uruchamia się właściwie. Co najzabawniejsze, czasem zdarzy się, że przyczyna wkurzającego błędu znajduje się w dawno napisanej części kodu, który do tego sam w sobie działa idealnie. Weźmy taki przykład: przebieg programu jest następujący: inicjalizacja modułu sieciowego, inicjalizacja i wczytanie do pamięci bazy danych, rozpoczęcie nasłuchu na sockecie. Niby wszystko w porządku... dopóki taka aplikacja nie trafia do autostartu. Tam nagle okazuje się, że pierwszych kilka połączeń jest odrzucanych, ponieważ... aplikacja jeszcze nie nasłuchuje.
Powód? Jak się teraz na to patrzy, powód jest oczywisty - wczytywanie bazy danych blokuje program i opóźnia rozpoczęcie nasłuchu. Każdy z komponentów z osobna działa poprawnie, natomiast razem produkują nieciekawy błąd. Naprawa jest prosta - rozpoczynamy wczytywanie bazy danych, a jednocześnie (np. w osobnym wątku) uruchamiamy nasłuch.
Wniosek z tego jest prosty: testujemy nie tylko każdy komponent z osobna po jego ukończeniu; po kilku zmianach przetestować trzeba ponownie cały program - zwykle ilość wzajemnie na siebie wpływających elementów jest na tyle duża, że nie można wykluczyć różnych dziwnych oraz nieprzewidzianych zachowań. Czyli: poza unit-testami i testami komponentów warto robić też cyklicznie testy całościowe. Zapewniam, oszczędzi to stresu i problemów.

Prywatna bramka SMS

Windows Mobile to platforma, na którą pisanie prostych aplikacji narzędziowych jest zupełnie bezproblemowe. Brak certyfikatów, idealne wsparcie ze strony .NET Compact Framework, masa gotowych przykładów i bibliotek. Dzisiaj, wręcz z konieczności, stworzyłem prosty program do łatwego wysyłania SMSów.

Idea programu jest prosta: aplikacja na komórce nasłuchuje na konkrentym porcie. W momencie nawiązania połączenia i nadejścia pakietu z numerem telefonu oraz treścią SMSa, korzystając z Assembly Microsoft.WindowsMobile.PocketOutlook tworzy, a następnie wysyła wiadomość SMS do odbiorcy. Część PCtowa aplikacji natomiast umożliwia połączenie się (z interfejsu konsoli) z konkretnym urządzeniem i wysyłanie SMSów na zasadzie wpisania numer_telefonu treść_wiadomości. Jeśli ktoś potrzebuje automat do wysyłania SMSów/maili na Windows Mobile - polecam zapoznanie się ze wspomnianym namespace.

Aplikacji nie publikuję ze względów bezpieczeństwa - połączenie nie jest autoryzowane, więc nie chcę w żaden sposób zdradzać ani portu, ani formatu wiadomości ;-)

Project Natal

Tutaj znajduje się film prezentujący możliwości nowego pomysłu MS do XBOX 360. Normalnie o konsolach bym słowem nie wspomniał, ale z tego patentu tworzy się nam świetna opcja sterowania multimediami bez ruszania się z fotela. Polecam obejrzeć.

Touch the Dream - kilka słów o Google G1

Będąc wieloletnim użytkownikiem różnego rodzaju smartphone'ów, nie mogłem oczywiście przegapić Google G1 (a właściwie: HTC Dream). O samym telefonie (jak i o systemie Android, na którym jest oparty) było głośno już od dawna. Do tego dołożyła się dość agresywna reklama Ery, chwaląca G1 jako "telefon stworzony do Internetu". Krótko: wstyd byłoby nazywać się osobą obeznaną w aktualnościach na rynku telefonów i nie mieć okazji pozać G1.

Biorąc G1, zależało mi przede wszystkim na urządzeniu, które ma służyć za coś w rodzaju stale połączonego z Internetem, kieszonkowego netbooka. Z tego też powodu pomijam tak nieistotne sprawy jak jakość rozmów, sposób obsługi MMSów (prawdę mówiąc: G1 mam już dwa miesiące, a do tej pory nie wysłałem i nie odebrałem ani jednego MMSa) czy inne, podobne bzdury. Wyjątkowo też nie wspomnę o programowaniu pod to urządzenie (to temat na innego posta).

Zaczynając od tego, co w "telefonie stworzonym do Internetu" najważniejsze, czyli przeglądarki: ogólne wrażenie jest pozytywne. Obsługa wielu otwieranych stron, dobra nawigacja, poprawne wyświetlanie stron, radzenie sobie z cookies itd. Nieco brakuje działającego flasha, który na tym zbliżonym sprzęcie pod Windows Mobile (HTC Touch Pro) śmiga aż miło. Pewne problemy zauważyłem też przy otwieraniu dużych stron, zawierających sporo elementów graficznych - tnie przy przewijaniu. Ponadto wykrywanie miejsca dotknięcia często (przy niewielkim powiększeniu) działa dość kiepsko - często przypadkiem wciskałem przycisk będący obok pola formularza.

Kolejną internetową funkcją jest konto pocztowe. Android domyślnie używa konta Google Mail (konto główne, pod które podpięty jest też GTalk i inne usługi Google), ponadto pozwala na podpięcie kilku innych kont. O ile z samym Google Account nie zauważyłem żadnych problemów (nawet z moją wiecznie zaspamowaną skrzynką radzi sobie koncertowo), o tyle z IMAP już średnio sobie radzi. Często przez kilka dni(!) nie potrafił załapać oznaczenia wiadomości jako przeczytanej z poziomu np. Outlooka. W kwestii redagowania i wysyłania maili: nie udało mi się zmusić urządzenia do obsługi polskich znaków, poza tym wszystko działa idealnie.

Internet nie jest tym samym bez komunikatorów. Przetestowałem GTalk i oficjalne Gadu-Gadu. Oba komunikatory zrobione są dobrze, działają stabilnie, można je zminimalizować (iPhone się chowa), korzystają (w przypadku Gadu-Gadu zaskakujące, to chyba pierwsza taka platforma) z wszystkich udogodnień i "oczywistości" systemu. Naprawdę trudno znaleźć tu coś do zarzucenia - może poza faktem, że nie da się wysyłać wiadomości naciskając "Enter" i brakiem archiwum w przypadku GG. Poza tymi drobnymi niedogodnościami jest bardzo dobrze.

Na dalszy ogień idzie YouTube. W tym przypadku: porażka na całej linii. Niestety, wykonanie aplikacji do odtwarzania filmów woła o pomstę. Pomijając fakt, że film nie jest cache'owany w całości i ponowne jego obejrzenie ponownie go ściąga, w przypadku, gdy łącze nie wyrabia z pobraniem filmu (co jest bardzo częste, gdy jest się w ruchu - jak np. w czasie jazdy autobusem), zamiast zapauzować i zaczekać aż się pobierze, po dobrnięciu do końca tego, co jest zcache'owane pojawia się komunikat "nie można odtworzyć filmu". W praktyce: około połowa filmów, które próbowałem otworzyć poprzez GSM, kończyła w ten sposób. Nawet Apple umiało wykonać odtwarzacz lepiej.

Podsumowując: Google G1 jest wart swojej ceny jako mobilny laptop. Ma sporo zalet (przede wszystkim wielozadaniowość), które stawiają go ponad iPhone, ponadto fizyczna klawiatura i (moim zdaniem) nieco lepsza przeglądarka niż w przypadku wspomnianego okazują się być przydatne. Mimo wszystko, gdyby nie zdecydowanie wygodniejsza obsługa (za pomocą palca, zamiast rysika), telefon znacznie by ustępował pola HTC Touch Pro. W mojej ocenie te dwa urządzenia są porównywalne - o wyborze decydować powinien raczej osobisty gust niż konkretne parametry czy możliwości.