Archive for Thoughts

10 lat w sieci

2009-12-25 20:46

Tegoroczny koniec grudnia to czas podsumowań tego, co działo się nie tylko w ciągu ostatnich 12 miesięcy, ale i całej ostatniej dekady. A przypadkiem właśnie dekadę temu zyskałem dostęp do globalnej sieci zwanej Internetem… Jest to więc ciekawa okazja na podzielenie się paroma moimi obserwacjami tego, jak na przestrzeni ostatnich 10 lat Internet się zmieniał.

Rok 1999 to nie były jakieś zamierzchłe czasy sieci w Polsce (nie wspominając już o sieci w ogóle), lecz mimo to podejrzewam, że niezbyt duża część obecnych jej użytkowników dobrze je pamięta. Cechą wyróżniającą Internetu w tamtym okresie była przede wszystkim oszczędność. Szerokopasmowe łącza nikomu się wtedy nie śniło, a część internautów musiała płacić za sam czas spędzony w sieci (sławetny numer 0202122). Dlatego też podstawową zasadą netykiety było możliwie najskuteczniejsze zmniejszanie rozmiarów przesyłanych danych. Objawiało się to dość spartańskim wyglądem ówczesnych stron, z rzadka składającym się z większej ilości obrazków, a często wykorzystującym takie niefortunne wynalazki HTML jak choćby ramki.
Jak nietrudno zauważyć dzisiaj jest zupełnie inaczej. Główna strona typowego portalu może spokojnie ważyć kilka megabajtów i być okraszona kilkoma reklamowymi animacjami typu Flash, często zresztą niczym nie różniących się od spotów telewizyjnych. Wymaga ona więc znacznie większej przepustowości łącza, a także o wiele lepszej i efektywniejszej przeglądarki.

To też zresztą znak rozpoznawczy Internetu końca dekady: jest on niemal tożsamy z WWW, a inne protokoły komunikacji są w głębokim odwrocie. Kilka lat wcześniej było pod tym względem inaczej. Przeglądanie stron było tylko jedną z wielu sieciowych aktywności, do których należało też korzystanie z e-maila, ściąganie plików przez FTP, czytanie grup dyskusyjnych (Usenet) czy pogaduszki za pośrednictwem IRC. Dzisiaj prawie każdy z tych kanałów komunikacji został pochłonięty lub zastąpiony przez tzw. aplikacje webowe, czyli po prostu trochę bardziej interaktywne wersje stron WWW.

I wreszcie trzeci aspekt zmian, jakie w sieci się dokonały: jej umasowienie. Nie chodzi tu tylko o sam wzrost liczby osób korzystających z sieci, który w ciągu ostatnich 10 lat był prawie czterokrotny. Chodzi o pewne zmiany w samej “strukturze” sieci, które są przynajmniej częściowo jego wynikiem.
Kiedyś w Przekroju czytałem artykuł reklamowany na okładce wiele mówiącą frazą: “Jak idioci zepsuli nam Internet”. Dotyczy ona oczywiście całego sieciowego trendu znanego pod ogólnym określeniem Web 2.0, nad którym zresztą pastwiłem się już przy innej okazji. W skrócie chodzi mniej więcej o to, że połączenie masowości dostępu do Internetu (w krajach rozwiniętych to już przynajmniej połowa populacji) z łatwością umieszczania w nim nowych treści (coraz mniejsza konieczność znajomości takich “technikaliów” jak choćby HTML) powoduje zalanie sieci contentem bez żadnej wartości, czyli jej zwyczajne zaśmiecenie.
W sumie jednak jest to nic nowego; już przed 10 laty mówiło się, że zawartością Internetu są w większości bzdury. Różnica między stanem z tego czasu a dniem dzisiejszym jest jednak taka, że mimo bezwzględnego (a pewnie i względnego) wzrostu ilości treściowych odpadów znalezienie poszukiwanych informacji jest paradoksalnie łatwiejsze niż kiedykolwiek wcześniej. Zawdzięczamy to jednak tylko i wyłącznie gwałtownemu rozwojowi internetowych wyszukiwarek.

Ogólny bilans tej dekady w sieci nie jest więc jednoznaczny. Z jednej strony stoją rzecz jasna MySpace, Facebooka, 4chana czy inne sieciowe szkodniki, ale z drugiej jest przecież Google, Wikipedia i całe mnóstwo wartościowych serwisów tematycznych, z których część nie powstałaby pewnie w warunkach “elitarnego” Internetu sprzed dekady.
Jesteśmy więc w innym miejscu – lecz niekoniecznie gorszym. Trzeba się do niego po prostu przyzwyczaić :)

Tags: ,
Author: Xion, posted under Internet, Life, Thoughts » 1 comment

Dlaczego nie lubię typów referencyjnych

2009-12-16 11:54

Jeśli chodzi o C++, to nietrudno zauważyć, że często pozwalam sobie na sporo uwag krytycznych pod adresem tego języka. Oczywiście zawsze jest to krytyka konstruktywna :) Tym niemniej wiele jest tu rzeczy, o których można powiedzieć, że w innych językach zostały pomyślane lepiej (łącznie z takimi, których w C++ nie ma, a przydałyby się).
Dlatego dzisiaj będzie trochę nietypowo. Chcę bowiem wspomnieć o problemie, który w językach pokroju C# czy Javy potrafi doprowadzić do powstawania trudnych do wykrycia błędów – i który jednocześnie w C++ w zasadzie nie występuje wcale.

Mam tu na myśli semantykę referencji, czyli pewien szczególny sposób odwoływania się do szeroko rozumianych obiektów w kodzie. Klasy, a właściwie to prawie wszystkie typy poza podstawowymi (jak liczby czy znaki), są w C# i Javie obsługiwane w ten właśnie sposób; dlatego czasami nazywa się je typami referencyjnymi.
Najważniejszą cechą takich typów jest fakt, że należące do nich zmienne nie zawierają bezpośrednio instancji obiektów. Jeśli na przykład Foo jest klasą, to deklaracja:

  1. Foo x;

nie sprawi, że pod nazwą x będzie siedział obiekt typu Foo. x będzie tutaj zaledwie odwołaniem do takiego obiektu – w tym przypadku zresztą odwołaniem pustym, niepokazującym na nic.
Jest to zachowanie diametralnie różne od typów podstawowych, jak choćby int. Ale idźmy dalej – skoro mamy zmienną mogącą trzymać odwołanie (czyli referencję) do obiektu, to pokażmy nią na jakiś obiekt, na przykład taki zupełnie nowy:

  1. x = new Foo();

A że w prawdziwym programie zmiennych i obiektów jest zawsze mnóstwo, to wprowadźmy na scenę jeszcze parę:

  1. Foo y = x;
  2. y.SomeValue = 4; // hmm...

No i zonk, można powiedzieć… Nikt aczkolwiek tego nie powie, bo dla każdego programisty C#, Javy itp. istnienie wielu referencji do tego samego obiektu jest rzeczą całkowicie naturalną. Jednak wiem, że podobny kod dla dowolnego typu liczbowego (zastąpiwszy ostatnią linijkę przez y += 4; lub coś tym w guście) zachowałby się zupełnie inaczej. Wiem też, że kiedyś byłem zmuszony wykonać kilka empirycznych testów, by się o tym naocznie przekonać; było to jeszcze w Delphi, a powodem były oczywiście jakieś “dziwne” błędy, na które natrafiłem w jednym ze swoich programów. Źle użyte typy referencyjne łatwo mogą być bowiem przyczyną takich błędów, które zresztą bywają potem trudne do wykrycia.

Bez jakiegoś rodzaju referencji nie da się rzecz jasna wyobrazić sobie użytecznego języka programowania. Sęk w tym, że w C# czy Javie używanie ich nie jest opcją do stosowania w tych przypadkach, które tego wymagają – jest koniecznością wymuszoną przez sam fakt programowania z użyciem klas i obiektów. To całkiem inaczej niż w C++, gdzie w tym celu trzeba wyraźnie zaznaczyć swoje intencje (najczęściej poprzez użycie typów wskaźnikowych).
W tworzeniu oprogramowania istnieje tzw. zasada najmniejszego zdziwienia (principle of least astonishment). Mówi ona, że przy alternatywie równoważnych przypadków powinno się wybrać ten, który u użytkownika końcowego będzie powodował mniejsze zdziwienie. Czy typy referencyjne zachowujące się zupełnie inaczej niż typy podstawowe i “same” zmieniające swoją zawartość nie są przypadkiem złamaniem tej reguły?…

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

I co się w tej grze robi?…

2009-12-04 21:14

Przeglądając znalezione niedawno czasopisma o grach sprzed kilku lat, zauważyłem ciekawy schemat pojawiający się w ówczesnych recenzjach. Wiele z nich wskazywało mianowicie na liniowość jako cechę bardzo niepożądaną w każdej właściwie grze, niekoniecznie przygodówce czy RPG-u (gdzie istotnie byłaby ona zbrodnią). Gracz miał bowiem mieć jak najwięcej swobody i jak najwięcej możliwości dokonywania znaczących wyborów – wtedy rozgrywka uznawana była za interesującą.

Gdy przyjrzymy się teraz tytułom wychodzącym obecnie, to da się zauważyć, że lata forsowania tej idei zrobiły swoje. Już niewiele jest jakich gier, w których trzeba przechodzić kolejne etapy/misje/poziomy/itp. w dość ściśle określonej kolejności. Zamiast tego mamy coraz więcej produkcji, gdzie właściwie cały rozwój rozgrywki znajduje się w rękach gracza.
Przykłady? Chociażby cały podgatunek MMORPG: zwykle poza jedną linią głównych questów (zadań) wszystkie pozostałe są poboczne, a gra polega generalnie na współpracy z innymi graczami, by osiągnąć wyznaczone grupowo cele. Podobny schemat występuje też niekiedy w rozgrywce single player (np. cała seria Grand Theft Auto). W końcu mamy całą paletę gier symulacyjnych, z ikonicznymi “simsami” na czele.

Można więc przypuszczać, że liczba gier z dużym stopniem swobody dla gracza będzie się zwiększać. Po części jest tak może dlatego, że ciężko usłyszeć opinie, aby ten kierunek rozwoju był złym. Kto wie, może faktycznie tak nie jest? :)
Jednak mam pewne wątpliwości. Wysoka nieliniowość gry może bowiem oznaczać tyle, że jej twórcy poszli na łatwiznę i tak naprawdę nie zainteresowali się tym, jak będzie ostatecznie przebiegać rozgrywka. Postawienie na samą mechanikę i uczynienie jej maksymalnie elastyczną może z początku wyglądać na działanie wielce innowacyjne, ale po bliższym przyjrzeniu się na wierzch mogą wyjść duże zaniedbania od strony fabularnej. (Wydaje mi się na przykład, że to właśnie była przyczyna chłodnego przyjęcia długo oczekiwanej gry Spore).

Achievement unlocked :)Jest jeszcze jeden aspekt tej sprawy: czy wysoce nieliniowe gry są tym, czego gracze faktycznie oczekują? Nie byłbym tego taki pewien, a poważnym argumentem, który za tym przemawia, jest “ostatni krzyk mody” w grach wszelakich, czyli tzw. osiągnięcia (achievements). Twór ten przyszedł z produkcji konsolowych, a jego oczywistą funkcją jest przedłużanie czasu życia gry poprzez wskazywanie graczowi, co jeszcze mógłby w niej zrobić (i jak mógłby być lepszym od innych).
Popularność tego mechanizmu dowodzi, że jego wprowadzanie jest zazwyczaj dobrym krokiem. Dlaczego? Poza widocznym wyraźnie czynnikiem rywalizacji z innymi (zawsze pożądanym), osiągnięcia mogą organizować przebieg rozgrywki i subtelnie wskazywać jej właściwy kierunek.

Inaczej mówiąc, jest to sposób na ponowne wprowadzenie do gier liniowości – tym razem w wersji light, jako opcji. Czy oznacza to więc cofanie się w rozwoju? Otóż nie wydaje mi się; to raczej odpowiedź na zapotrzebowanie. Bo po co nam gry, w których można robić wszystko, skoro w rzeczywistości oznacza to, że niczego robić nie warto?…

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

Piątek, trzynastego

2009-11-13 18:00

W takim dniu jak dziś można zadać pytanie: czy programiści są przesądni? Wydaje się, że raczej nie – przynajmniej w porównaniu z niektórymi innymi zawodami (np. aktorzy teatralni mają tyle przesądów, że to cud, iż w ogóle wychodzą na scenę :]).

7 lat nieszczęścia ;-)A jednak nie jest to wcale takie pewne. To przecież w informatyce ogóle, a w programowaniu w szczególności, wyeksponowaną pozycję zajmują wszelkiego rodzaju ‘zalecenia’, ‘dobre praktyki’ (best practices) i inne ‘rady’. Naturalnie, konsekwencje ich nieprzestrzegania nie są (zwykle) takie straszne – użycie dynamic_cast czy goto pewnie nie sprowadzi na nas siedmiu lat nieszczęść :) Mimo to da się odnaleźć sporo analogii.
Największą jest prawdopodobnie fakt, że w obu przypadkach nierzadko nie da się znaleźć sensownego, racjonalnego wytłumaczenia. Dotyczy to zwłaszcza tych zaleceń, w których sformułowaniu pojawiają się takie słowa-klucze jak ‘czytelność’, ‘przejrzystość’, ‘łatwość konserwacji’, a nawet ‘elegancja’. Żadnej z tych wartości nie da się obiektywnie zmierzyć i dla każdego mogą one mieć inne znaczenie. Pomimo tego faktu wiele osób skłonnych jest opierać o nie swoje kategoryczne twierdzenia o tym, jak programować należy lub nie należy. Jeśli dodatkowo osoby te cieszą się w środowisku autorytetem, to mają spore szanse na stworzenie ze swoich opinii pewnego rodzaju programistycznych przesądów, akceptowanych przez rzesze koderów bez większego zastanowienia.

Czy to jednak źle? Otóż wydaje mi się, że nie do końca. Tak jak każdy przesąd zawiera w sobie ziarnko prawdy (bo tłuczenie luster trudno uznać za bezpieczne zajęcie), tak owe dobre praktyki też mają na pewno wartość edukacyjną, zwłaszcza dla początkujących programistów. W najgorszym razie mogą nam służyć jako wskaźnik naszego poziomu umiejętności – odrzucenie naiwnej wiary, że od jednego goto cały kod zamieni się nam w spaghetti to dobry znak, że nabrało się już w kodowaniu pewnego doświadczenia :)

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

Wartość pomysłów

2009-11-05 22:22

Żarówka z pomysłem :)Podobno w informatyce najcenniejszym zasobem są pomysły. Bo o ile zrealizowanie gotowej idei to praca czysto rzemieślnicza i – przynajmniej teoretycznie – możliwa zawsze do wykonania przy odpowiednim czasie i przy właściwej liczbie osób, to z kolei “wzięcie skądś” pomysłu nie jest taką prostą sprawą. W końcu, jak to ktoś powiedział, pomysły nie rosną przecież na drzewach :)

Tak to zwykle wygląda z rynkowego punktu widzenia. Dlatego bardzo ciekawy jest fakt, że np. na Warsztacie wygląda to – jak się wydaje – zupełnie odwrotnie. Objawem tego jest choćby fakt, że działy z pomysłami i projektami na forum są jednymi z większych i bardziej aktywnych. Jak to możliwe?
Wydaje mi się, że przyczyny są co najmniej dwie. Po pierwsze, na Warsztat trafiają osoby zainteresowane programowaniem gier i przynajmniej część z tych (a w rzeczywistości pewnie całkiem spora część) chcę zająć się tym tematem między innymi dlatego, że mają w głowie pomysł na jakąś grę. Albo na kilka od razu. A że na początkowym etapie nauki nijak nie da się tego zrealizować, owe genialne idee lądują we wspomnianym dziale forum.
Poza tym, nie ma co ukrywać: większość z nich jest w istocie marnej jakości – nawet jeśli litościwie odsiejemy projekty kolejnych MMORPG-ów, jakie dość często się pojawiają :) Oczywiście dla swoich autorów są one zawsze niezwykle innowacyjne i warte zrealizowania, ale nie łudźmy się: tak naprawdę podobne epitety można przypisać tylko ich małemu ułamkowi.

Innymi słowy, jest duża różnica pomiędzy pomysłem a dobrym pomysłem. Tych pierwszych każdy z nas ma pewnie dziesiątki tygodniowo. Nieuchronnie trzeba więc wybierać z nich tylko te najbardziej wartościowe. Do pozostałych najlepiej jest zaaplikować garbage collector :)

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

Powtórka z DirectX

2009-10-29 20:58

Za sprawą przedmiotu o nazwie Grafika Komputerowa 3D musiałem ostatnio przypomnieć sobie, jak tak naprawdę i w praktyce koduje się w DirectX. Pewnie brzmi to dziwnie, ale w rzeczywistości przez ładnych kilka miesięcy nie pisałem większych ilości kodu, który by z tej biblioteki korzystał.

GK3D - screen
Piękna scena ;-)

Projekt, który musiałem teraz napisać, nie był ani trochę ambitny, bo polegał li tylko na wyświetleniu zupełnie statycznej sceny z kilkoma modelami, oświetleniu jej i zapewnieniu możliwości poruszania się w stylu strzelanek FPP. Oczywiście nie było też mowy o żadnych shaderach.

Niby banalne, ale jednak rzecz zajęła mi w sumie jakieś cztery znormalizowane wieczory (czyli od 3 do 4 godzin każdy). Częściowo było tak pewnie dlatego, że pokusiłem się jeszcze o teksturowanie, możliwość regulacji paru opcji renderowania czy bardzo, bardzo prosty menedżer sceny – czytaj: drzewko obiektów + stos macierzy ;)
Wydaje mi się jednak, że ważniejszą przyczyną był nieszczęsny fixed pipeline, którego byłem zmuszony używać. Jeszcze kilka lat temu nigdy bym nie przypuszczał, że to powiem, ale… shadery są po prostu łatwiejsze w użyciu. Porównując chociażby trywialne mieszanie koloru diffuse wierzchołka z teksturą przy użyciu pixel shadera:

  1. psOut.color = psIn.diffuse * tex2D(tex0, psIn.Tex0)

oraz stanów urządzenia:

  1. device->SetTextureStageState (0, D3DTSS_COLORARG1, D3DTA_CURRENT);
  2. device->SetTextureStageState (0, D3DTSS_COLORARG2, D3DTA_TEXTURE);
  3. device->SetTextureStageState (0, D3DTSS_COLOROP, D3DTOP_MODULATE);

nietrudno jest ocenić, w której znacznie lepiej widać, co faktycznie dzieje się z kolorem piksela. No, chyba że dla kogoś multum stałych w rodzaju D3DABC_SOMESTRANGEOPTION jest czytelniejsze niż po prostu mnożenie ;P

Inną sprawą jest też to, że w DirectX napisanie aplikacji od podstaw jest stosunkowo pracochłonne. Brak “złych” funkcji typu glVertex* ma rzecz jasna swoje zalety, lecz jest też jednym z powodów, dla których tak opłaca się posiadanie własnego frameworka, a może nawet i – tfu tfu – silnika ;-)

Uczę się pilnie…

2009-04-28 16:40

Dość powszechne na forum Warsztatu jest pytanie: z czego się uczyć? – programowania w ogóle i gamedevu w szczególności. Chodzi tu po prostu o źródła wiedzy. I chociaż (częściowa) odpowiedź znajduje się w warsztatowej Wiki, to pewnie podobne zapytania wciąż będą się pojawiać. Nie ma się tu specjalnie czemu dziwić.

Zupełnie inaczej jest, jeśli owo ‘uczenie się’ występuje w trochę innym kontekście. “Czy mogę nauczyć się programowania, jeśli …?”, “Czy powinienem wykonywać ćwiczenia z książki X?” albo najgorsze z tych pytań: “Ile czasu poświęcacie dziennie na naukę programowania?”. Natychmiast służę oczywiście odpowiedzią na nie: dokładnie trzy godziny, między 19 a 22, przez dwa dni w tygodniu, tj. we wtorki i piątki. I bardzo, bardzo przy tym pilnuję, aby tego czasu nauki nie skracać nawet o minutę!… Czy ta odpowiedź jest satysfakcjonująca? Przypuszczam, że niezbyt ;]
A mówiąc już trochę poważniej… Jeśli nie zajmujemy się programowaniem zawodowo, to jest to pewnie nasze hobby – czyli coś, co robimy dla przyjemności. Chodzi o tworzenie czegoś własnego, eksperymentowanie z różnymi technologiami, a także – nie ma co ukrywać – uczenie się czegoś nowego. Jednak mówimy tu o uczeniu się rzeczy, które chcemy, kiedy chcemy i jak długo chcemy – wedle naszego własnego uznania, a nie czegoś w rodzaju “planu treningowego'”, ułożonego na podstawie odpowiedzi ludzi z jakiegoś forum internetowego (z całym szacunkiem dla Warsztatu oczywiście). Trudno przecież oczekiwać, że powiedzą nam oni, co będzie nam bardziej odpowiadało; do tego trzeba dojść samodzielnie.

Czy więc właściwa odpowiedź na wspomniane pytanie istnieje? Oczywiście, że tak. Brzmi ona: na naukę programowania przeznaczamy tyle czasu, ile chcemy i/lub możemy. Tak po prostu.

Tags:
Author: Xion, posted under Internet, Programming, Thoughts » 10 comments
 


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