Archive for Thoughts

Przemożna chęć regulacji

2009-02-01 17:53

Przedwczoraj na forum Warsztatu rozpoczęto dyskusję na temat gier zrobionych w tzw. klikach, które podobno coraz częściej pojawiają się wśród projektów zamieszczanych w serwisie gamedev.pl. Wątek zdążył szybko urosnąć w kilkadziesiąt postów, w których jedni postulują zwalczanie tego zjawiska, a drudzy (nieśmiało) proponują włączenie klikowców do warsztatowego mainstreamu.

Niejako automatycznie powstał więc dylemat: “Co z tym zrobić?”, na rozwiązanie którego daje się te właśnie dwa wyjścia. Którekolwiek z nich się wybierze, najważniejsze jest to, że coś ma być zrobione. Koniecznie przecież trzeba coś z tym zrobić, jakoś to ogarnąć, opanować, zorganizować, uregulować…
A ja zadaję wtedy proste pytanie: po co? Dlaczego niby należy każde zjawisko od razu łapać w regulamin, FAQ czy inny rodzaj mniej lub bardziej formalnych zasad? Od kiedy to w naszym narodzie – mającym bogatą, ponaddwustuletnią tradycję omijania wszelkich nakazów i zakazów – nagle zrodziła się taka wiara w nieuchronną konieczność odgórnej regulacji wszystkiego?…

Wydaje mi się to cokolwiek dziwaczne.

Tags:
Author: Xion, posted under Thoughts » 11 comments

Znów o testach jednostkowych

2008-12-18 21:04

Poprzednia notka o “rootkitach i innych nieszczęściach” zdołała utrzymać się długo, więc mogła stworzyć wrażenie, że cały czas źle się u mnie dzieje :) Nieprawda to oczywiście, więc wypadałoby w końcu coś na tę dezinformację poradzić.
Ostatnio cierpię na niewielki brak czasu spowodowany koniecznością dokładania nieco poważniejszych wysiłków co do pewnego dzieła, które docelowo ma zapewnić mi otrzymanie tytułu inżyniera informatyki. Z pewnych względów nie zdradzę, czym ono jest, ale pozwolę sobie wspomnieć o pewnych wnioskach, które przy okazji mi się nasunęły.

Parę miesięcy temu wypowiadałem się pochlebnie na temat testów jednostkowych, mając wtedy raczej niezbyt duże doświadczenie w ich stosowaniu. Dzisiaj jest już ono zdecydowanie większe i w związku z tym stwierdzić muszę, że… Nie, nie chcę powiedzieć, że wtedy myliłem się całkowicie ;P Chodzi raczej o równowagę zalet i wad.
To prawda, że unittesty dobrze sprawdzają się jako narzędzie znajdowania błędów i zapobiegania im. Do pewnego stopnia pomagają też w poprawianiu interfejsu tworzonych klas, tak aby ich użycie było wygodniejsze i bardziej intuicyjne. Te korzyści mają jednak swoją cenę, którą jest przede wszystkim czas poświęcony na pisanie owych testów – zwłaszcza w niektórych metodykach wytwarzania oprogramowania, które kładą na nie ogromny nacisk. Całkiem normalna jest bowiem sytuacja, że kod testowy jest dłuższy niż testowany (czasem nawet kilkakrotnie). Dodatkowo nie mamy przecież znikąd żadnej gwarancji, że ów testowy kod sam nie zawiera jakichś błędów… W sumie więc dochodzi nam sporo dodatkowej pracy w zamian za większą niezawodność tworzonego oprogramowania.
Drugi wniosek jest bardziej – że tak powiem – filozoficzny :) Otóż programowanie wedle zasady:

  1. while (!ProgramGotowy())
  2. {
  3.     NapiszTest();
  4.     do
  5.     {
  6.          NapiszLubPoprawKod();
  7.          UruchomTest();
  8.     } while (!TestPrzeszedl());
  9. }

może i jest efektywne, ale na dłuższą metę zaczyna się robić nużące i trochę zniechęcające. Pomyślmy jak łatwo jest pisać kod “rozgrzebany”, którego nie planujemy od razu kompilować i poprawiać tych wszystkich pomyłek, których kompilator nam zasygnalizuje. Porównajmy to z pisaniem kodu, który nie tylko jak najczęściej kompilujemy, ale i regularnie przepuszczamy przez własnoręcznie napisane testy! Toż to straszne, tak samemu kręcić na siebie bat :) Gdzie tu koderska wolność artystyczna? :D
Ale nie ma rady, czasami trzeba zakasać rękawy i testować…

Tags:
Author: Xion, posted under Programming, Studies, Thoughts » 6 comments

Grzechy grafiki

2008-11-14 22:22

Karty graficzne mogą podołać renderowaniu coraz większej liczby wierzchołków, więc grafika w grach jest coraz bardziej szczegółowa – to oczywiste. Niezbyt oczywiste jest jednak to, czy jest ona faktycznie lepsza, bowiem nawet mając bardzo dobrze zrobione modele i tekstury niekoniecznie można złożyć je w przyzwoicie wyglądający świat.
Według mnie jest kilka głównych grzechów, jakie można przy tej okazji popełnić:


  • Model postaci ładny,
    ale co to za teren?

    Syndrom pustyni z drzewkami. Nazywam w ten sposób wrażenie, że na scenie obiekty niespecjalnie pasują do siebie. Przykładem czegoś takiego jest heightmapa pokryta niezbyt urozmaiconą teksturą (stąd ‘pustynia’), do której “przyklejone” są wyraźnie odcinające się drzewa. Taki teren jest jak najbardziej poprawny w demie silnika, ale w grze oczekiwalibyśmy trochę więcej urozmaicenia i trochę więcej spójności. Może jakieś trawy i krzaczki? ;)

  • Ocean w kałuży. Woda to okazja do wielu ciekawych efektów, z refleksami światła i odbiciami na czele. Jednak inaczej wygląda duży zbiornik wodny, a inaczej małe jeziorko. Dlaczego więc tak często widzimy oceany płaskie jak stół i stawy, w których wręcz szaleją sztormy? Czyżby tak trudno było dobrać wagi dla używanej w vertex shaderze funkcji sinus? :)

  • Uwaga na słońce! ;P

    Za dużo blooma. Odpowiednie efekty typu post-process to, oprócz upiększania sceny, także dobry sposób na to, by przyciągnąć uwagę do wybranych miejsc (w domyśle: tych lepiej zrobionych niż inne). Jeśli jednak przesadzi się z bloomem, lens-flare i innymi pseudorealistycznymi upiększaczami, to całość robi się mniej imponująca, a bardziej męcząca.

To na pewno nie wszystkie błędy, które dają się w miarę łatwo zauważyć. Wydaje mi się jednak, że te należą do jednych z łatwiejszych do popełnienia. W końcu skoro już napisaliśmy jakiś fajny shader, to warto go wcisnąć, gdzie się da, prawda? :) No cóż, nie zawsze jest to dobry kierunek postępowania…

Tags: , ,
Author: Xion, posted under Games, Thoughts » 5 comments

Engine jest wielki, a ja malutki

2008-10-31 18:03

Zapewne niespotykana często koniunkcja planet sprawiła, że na forum Warsztatu pojawiło się ostatnio kilka przypadków dość specyficznych pytań. Ich autorzy chcieli dowiedzieć się, czy – najogólniej mówiąc – są w stanie coś konkretnego w dziedzinie programowania osiągnąć. “Czy dam radę napisać taką-a-taką grę?” jest przykładem takiego właśnie pytania.

Skrajnie zresztą dziwnego, moim skromnym zdaniem. Nie chodzi tu nawet o fakt, że odpowiedź na podobne pytanie jest niemożliwa do udzielenia. Bardziej zdumiewa mnie to, iż obecni adepci sztuki koderskiej jakoś lubią wynajdywać sobie różne potencjalne przeszkody. A może za mało wiem o programowaniu? Może za słabo znam matematykę? Albo jestem po prostu za młody?… Takie i podobne “argumenty” są bowiem przytaczane przy okazji wspomnianych pytań.
Jest dla mnie dosyć zaskakujące, że dzisiejsi ‘młodzi’ (raczej w sensie umiejętności) tak szybko się “starzeją”. Jeszcze całkiem nieźle pamiętam, że będąc początkującym prawie w ogóle nie przejmowałem się realnością podejmowanych amatorskich projektów. Gra 3D, strategiczna czy sieciowa (MMORPG-ów raczej wtedy nie było) z innowacyjnym gameplayem i nowatorskimi rozwiązaniami technicznymi? Ależ oczywiście, toż to praca najwyżej na tydzień ;D Jak się kończyły takie zamiary, nietrudno zgadnąć. Ani mi, ani podobnym do mnie ‘kolegom po fachu’ nie przeszkadzało to jednak próbować.

Co więc zmieniło się, że teraz widzę coraz więcej nowicjuszy pełnych wątpliwości? Czy chociażby programowanie gier stało się trudniejsze? Powiedziałbym raczej, że wręcz przeciwnie (weźmy np. coraz więcej gotowych silników i coraz lepsze wersje graficznych API), a trend ten wydaje się przy tym stabilny. Ale nawet gdyby tak nie było, to jaki sens zadawanie niedorzecznych pytań w stylu “Czy mi się uda?”. Nie, nie uda ci się – to mogę ci powiedzieć w ciemno. Z każdego nieudanego projektu można jednak wyciągnąć wnioski i nauczyć się pożytecznych rzeczy. I dlatego nie ma co przerażać się, że to trudne, niezrozumiałe czy wymagające napisania wielkich ilości świetnie działającego kodu. Wszystko przecież przychodzi z czasem, a porażki są nieodłączną częścią postępów w nauce.
Zatem – motyki w garść, Słońce czeka ;)

O kompatybilności wstecz

2008-10-20 9:47

Użytkownicy zawsze lubią, gdy nowe wersje programów współpracują ze wszystkim, z czym współpracowały stare wersje. Niemal każdy system operacyjny zachowuje na przykład kompatybilność binarną w swoich kolejnych edycjach. Dzięki niej programy napisane dla poprzednich wersji systemu mogą działać i z nowszymi wersjami.

W programowaniu pewnym odpowiednikiem takiego zachowania jest kompatybilność źródeł. Objawia się ona tym, że nowa wersja biblioteka daje się używać bez modyfikacji źródeł programu, który korzysta ze starej wersji. Dla jego autora może być to początkowo wygodne, ale na dłuższą metę powoduje też pewne problemy.
Zachowanie zgodności ogranicza bowiem możliwość zmian w interfejsie biblioteki, pozwalając głównie na dodawanie nowych funkcji, klas, metod, itp. To właśnie tutaj leży przyczyna istnienia paru małych absurdów Windows API, jak choćby funkcje z przyrostkiem Ex czy obecne prawie w każdej strukturze pole cbSize, które należy ustawić na jej wielkość.

Usilnie utrzymywana kompatybilność nie pozwala też naprawić ewentualnych błędnych decyzji projektowych. Dlatego czasami warto się od niej uwolnić; choć jest to najpierw bolesne, korzyści zwykle przewyższają koszty. Wystarczy spojrzeć na przykład na DirectX 10, a już zwłaszcza na całą platformę .NET.

Tags:
Author: Xion, posted under Computer Science & IT, Thoughts » 2 comments

Małe algorytmy

2008-10-08 13:44

Informatyka zna świetne rozwiązania wielu złożonych problemów, takich jak sortowanie czy wyszukiwanie najkrótszej drogi. Użycie tych powszechnie znanych algorytmów – nawet tych najbardziej skomplikowanych – jest zwykle całkiem proste. Albo bowiem dysponujemy już gotową implementacją, albo bez większych problemów możemy takową samodzielnie popełnić – z ewentualnymi usprawnieniami własnymi.

Często jednak zdarza się, że trzeba wymyślić coś znacznie mniejszego, rozwiązującego mniej modelowy, ale za to bardziej praktyczny problem. Niepotrzebne jest wtedy arcydzieło algorytmiki, lecz coś, co po prostu będzie dobrze działać. Osobiście uważam, że opracowywanie właśnie takich małych rozwiązań jest jedną z najciekawszych rzeczy w programowaniu w ogóle.
Przykłady? Jest ich tak dużo i są tak odmienne od siebie, że chyba niemożliwe jest podanie choćby kilku odpowiednio reprezentatywnych. Może to być krótki kod parsujący jakiś prosty tekst i wyciągający z niego pewnie informacje. Może to być metoda na przeskalowanie obrazka z zachowaniem jego aspektu (ilorazu szerokości do wysokości). Może to być również kod pozycjonujący jakąś kontrolkę wewnątrz okna o zmiennym rozmiarze. Może też chodzić o wyznaczenie rezultatu pojedynczego ataku w turowej grze strategicznej czy RPG. A nawet o, jak to ktoś ładnie nazwał, “silnik do pauzy” w owej grze ;] I tak dalej…

Niby nic skomplikowanego, czasami wręcz oczywistego – a jednak przecież trzeba to w miarę potrzeb wymyślać i zakodowywać. Bo gotowych rozwiązań problemów tak specyficznych po prostu nie ma. A bez takich małych algorytmów nie działałby żaden program – także ten, który musi używać również i tych “dużych” rozwiązań.
Może więc właśnie tutaj tkwi istota programowania?… Kto wie :)

Tags:
Author: Xion, posted under Programming, Thoughts » 5 comments

Wszystko działa w tle

2008-09-29 15:17

W bardzo dawnych czasach systemy operacyjne słabo radziły sobie z wielozadaniowością (niektóre zgoła wcale). Ostatnio jednak zmieniło się całkowicie; teraz niemal cała funkcjonalność systemu w rodzaju Windows czy Linux opiera się na działających w tle procesach (zwanych usługami lub demonami).
O ile w tych przypadkach ma to najczęściej sens, o tyle ciężko jest mi zrozumieć, dlaczego coraz więcej zupełnie zwyczajnych aplikacji “upiera się”, aby także działać w sposób ciągły. Owszem, w niektórych przypadkach jest to jak najbardziej uzasadnione – weźmy chociażby internetowe komunikatory. Wydaje mi się jednak, że widoczny tu trend idzie zdecydowanie zbyt daleko.

Mam mianowicie wrażenie, że obecność ikonki prawie każdej aplikacji w systemowym zasobniku (tray) stała się niemal obowiązkowa. Nie ma przy tym znaczenia, czy dany program (albo raczej jego główna część) jest uruchomiony czy nie. Dobrym pretekstem do takiej obecności bywa nawet czynność tak absurdalna, jak pilnowanie skojarzeń określonych typów plików z macierzystą aplikacją (domyślnie robi tak np. odtwarzacz Winamp. Najważniejsze jest bowiem to, aby po jedno- lub dwukrotnym kliknięciu w taką ikonkę uruchomił się właściwy program. Zupełnie jakby posiadanie skrótów na Pulpicie czy w menu Start nie było całkowicie wystarczające.
Co więcej, raz wystartowana aplikacja zwykle też nie daje się tak łatwo zamknąć. Bardzo popularna jest, przykładowo, zmiana zachowania przycisku Zamknij (lewy górny róg okna), który wcale aplikacji nie zamyka, a jedynie minimalizuje ją do ikonki we wspomnianym już zasobniku. Dopiero jawne wybranie opcji z menu pozwala faktycznie program zakończyć; w innym przypadku jest to po prostu zamknięcie udawane.

Jakie są tego skutki? Ano takie, że nawet czterordzeniowy procesor z gigabajtami pamięci operacyjnej może mieć ciężkie chwile w obsłudze kilkudziesięciu procesów i kilkuset wątków naraz, z których większość stanowią “niedomknięte” aplikacje. Prawdziwe kłopoty zaczynają się zaś wtedy, gdy chcemy uruchomić naprawdę wymagający program, jak choćby pełnoekranową grę.
A wszystko to dlatego, że aplikacje chcą być mądrzejsze od swoich użytkowników…


Author: Xion, posted under Applications, Thoughts » 10 comments
 


© 2017 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.