Slick

W jednym z poprzednich postów napisałem, że Slick udostępnia biblioteki natywne tylko dla Windowsa. Otóż dzisiaj przyjrzałem się temu dokładniej i okazało się, że po prostu Windowsowe nativy są w głównym katalogu natomiast pozostałe są popakowane w archiwa JAR i wrzucone do katalogu lib. Wcześniej ich po prostu nie zauważyłem.

W związku z poczynionym odkryciem uruchomiłem netbeansa na nowo zainstalowanym OpenSUSE i rozpocząłem poszukiwanie tutoriali w internecie. Tutaj niestety nie jest tak fajnie jak w GTGE. Dostępne są głównie przykładowe kody źródłowe. Udało mi się jednak znaleźć jeden tutorial ( http://thejavablog.wordpress.com/2008/06/08/using-slick-2d-to-write-a-game/ ), który pozwala załapać jak to mniejwięcej wygląda.

Prawdę mówiąc sam szkielet jest prawie taki sam jak to było w przypadku GTGE. Mamy metody init, update, render, których znaczenia i funkcji raczej nie trzeba tłumaczyć

Slick jest pierwszym silnikiem 2D w Javie, w którym odkryłem możliwość dowolnego obracania obrazków. Dodatkowo przeglądając API zauważyłem, że posiada różne algorytmy wyszukiwania trasy, silnik cząsteczkowy (wraz z edytorem) oraz wsparcie dla tile-map rysowanych w programie Tiled.

Myślę że spędzę na tym silniku kilka ładnych godzin ponieważ zamierzam wziąć udział w tegorocznym WSOC! To chyba będzie pierwsza praca na WSOC napisana w Javie

Object Oriented Programming

Czasem zaczynam myśleć, że programiści traktują zasady obiektowości jako święte i bez znaczenia jest czy to co tworzą będzie wygodne w użyciu. Przecież musi być zgodne z regułami OOP!

Ostatnio na forum widziałem gdzieś prawie odrazę dla stosowania zmiennych globalnych – pomimo tego ze 90% obiektów potrzebowała właśnie tej jednej zmiennej.

Chodzi mi o wskaźnik na urządzenie D3D. W temacie poruszany był problem umieszczenia tego w kodzie i jedyne rozwiązania widziane przez autora to:

• wcisnąć wskaźnik do jednej klasy w sekcji private i chyba uczynić go jeszcze statycznym i zaprzyjaźnić z nią 3/4 innych klas
• skutecznie przekazywać wskaźnik do urządzenia kolejnym klasom które go wymagają.

Nie trzeba być super programistą żeby domyślić się, że pierwsze rozwiązanie jest raczej naciągane przez duże `N`, a drugie po prostu nie wygodne.

A nie łatwiej/szybciej/elastyczniej jest po prostu dać ten wskaźnik jako zmienną globalną? Ja zastosowałem właśnie takie rozwiązanie w AGE. Zyskałem na tym łatwość w dodawaniu nowych części, które potrzebować będą tego wskaźnika, no i najważniejsze – wygodę. Nie mam miliona wskaźników tylko jeden z którego korzystają wszyscy oraz nie muszę przekazywać tego wskaźnika każdemu nowemu obiektowi z osobna.

IMHO reguły OOP to tylko dobre wskazówki i nie można ich traktować jako wyznacznika tworzenia nowego kodu… Przynajmniej ja nie będę dopóki rozwiązanie zgodne z OOP będzie strasznie niewygodne w późniejszym użyciu.