Składanie frameworka

Kończąc powoli prace nad systemem GUI (a przynajmniej jakimiś sensownymi podstawami tego systemu), zakańczam jednocześnie prace nad “płaską” częścią silnika. Innymi słowy, już wkrótce nie będzie żadnej wymówki i trzeba będzie zabrać się za dodanie upragnionego, a zarazem niezwykle komplikującego życie trzeciego wymiaru :)

Pomyślałem jednak, że najpierw dobrze byłoby poskładać napisane już w cegiełki w sensowną całość i stworzyć coś w rodzaju frameworka. Chodzi tutaj o tę warstwę pośrednią między kodem silnika a użytkownikiem i systemem, czyli szkielet umożliwiający wygodne tworzenie rzeczywistych aplikacji.
W wielu bibliotekach różnie to rozwiązano. Z jednego strony DirectX czy OpenGL zostawiają to całkowicie w gestii programisty. Musi on samodzielnie przygotować chociażby to okienko, w którym będzie się odbywało rysowanie. Z kolei np. SDL bardzo głęboko ingeruje w kod programu, narzucając nawet określoną formę funkcji main.

Najlepsze jest oczywiście takie rozwiązanie, które zapewnia zarówno dużą elastyczność, jak i nie zmusza do napisania kilkuset linijek w celu zobaczenia czegokolwiek. Wydaje mi się, że bliski ideałowi jest pomysł zamknięcia funkcjonalności frameworka w klasę w rodzaju Application, zawierająca metody pozwalające na inicjalizację programu i późniejsze sterowanie nim. Metody tej klasy byłyby wywoływane w funkcji startowej programu, czyli main lub WinMain. Tak to wygląda na przykład w Windows Forms czy w VCL (Delphi):
[delphi]program SomeProject;

uses
Forms,
MainFrm in ‘MainFrm.pas’ {Form1};

{$R *.res}

begin
Application.Initialize;
Application.CreateForm(TMainForm, MainForm);
Application.Run;
end.[/delphi]
Według mnie najlepiej jest, gdy obiekt głównej klasy programu jest albo statycznie tworzonym singletonem, albo zostaje wykreowany przez programistę przy rozruchu aplikacji. Najważniejsze, aby nie zmuszać do dziedziczenia po klasie Application – po to na przykład, by nadpisując metody wirtualne zapewnić możliwość reakcji na zdarzenia (jak wciśnięcia klawiszy czy ruch myszy). Dzięki delegatom, choćby tym z biblioteki FastDelegate, można to zrobić dokładnie tak, jak w “bardziej cywilizowanych” językach programowania.

Prawie wszystko o przycinaniu 2D

Rysując grafikę dwuwymiarową dość często chcemy, aby była ona wpasowana tylko w ograniczony obszar ekranu. Jeśli większość obrazu ma być wyrenderowaną trójwymiarowa scena, grafika HUDa nie może zajmować zbyt dużo miejsca. Wielkość rysowanych sprite’ów można kontrolować na wiele sposobów, począwszy od zabawy z macierzami (projekcji i/lub świata), a skończywszy na programowym skalowaniu wielokątów.
Podobnie jest z innym aspektem tego ‘ograniczania’ wyświetlanej grafiki, czyli przycinaniem. Tutaj jednak dużo zależy od tego, jakie kształty chcemy przycinać oraz czym jest region przycinania.

Najprostszy przypadek dotyczy ograniczenia prostokąta przez inny prostokąt. Przycinanie, czyli wyznaczenie ich części wspólnej, to w tym przypadku tylko kilka porównań współrzędnych tych prostokątów:

Ponadto trzeba jeszcze tylko sprawdzić, czy powstały prostokąt jest poprawny – czyli czy spełnione są warunki: left mniejsze od right i top mniejsze niż bottom. W przeciwnym wypadku wyjściowe prostokąty nie mają części wspólnej.

Kiedy prostokątem chcemy uciąć coś o innym kształcie, wówczas sprawa znacznie się komplikuje z matematycznego punktu widzenia. Można jednak skorzystać z przydatnego narzędzia wbudowanego w Direct3D i znanego jako scissor test. Jest to specjalna, późna faza potoku renderowania, która odrzuca wszystkie piksele poza tymi mieszczącymi w podanym regionie (w przypadku DirectX 9 chodzi o prostokąt). Skorzystanie z tego mechanizmu jest bardzo proste i ogranicza się do:

• ustawienia stanu renderowania D3DRS_SCISSORTESTENABLE na TRUE
• ustawienia prostokąta przycinania za pomocą metody SetScissorRect urządzenia (współrzędne prostokąta liczone są w pikselach według viewportu)

A co zrobić w najbardziej skomplikowanym przypadku: gdy zarówno przycinane figury, jak i region przycinania są niestandardowymi kształtami? Cóż, DirectX to nie GDI i nie można oczekiwać, że będzie miał wszystko :) Nie jest to aczkolwiek sytuacja bez wyjścia, gdyż można ją rozwiązać przy pomocy stencil buffera (‘bufora szablonu’ lub ‘bufora matrycy’, że wymienię co ciekawsze tłumaczenia, jakie dotąd spotkałem). Wymaga to jednak nieco zabawy ze stanami urządzenia, a przede wszystkim renderowania regionu przycinania w postaci prymitywów od nowa w każdej klatce.

Domykanie klas i metod

W teorii dziedziczenie to niezbyt skomplikowana relacja między klasami, ale w praktyce potrzeba czasem niestandardowych rozwiązań. Niekiedy bowiem możliwość rozszerzenia hierarchii klas w nieskończoność nie jest wcale pożądana. Zazwyczaj chodzi tu o względy projektowe, rzadziej o efektywność.
Pytanie brzmi: czy można jakoś zabezpieczyć konkretną klasę przed dziedziczeniem (czyli zabronić w tworzenia opartych o nią klas pochodnych)?

W C# i Javie jest to możliwe za pomocą specjalnych słów kluczowych – odpowiednio sealed (‘zapieczętowany’) i final. Wystarczy opatrzyć nimi definicję klasy, by kompilator odmówił skompilowania kodu, który wykorzystywałby taką klasę jako bazową:

Modyfikatory sealed/final można też stosować do metod wirtualnych. W tym przypadku sprawiają one, że dana metoda wirtualna nie może być nadpisywana w klasach pochodnych. Chwilowo nie przychodzi mi do głowy żaden pomysł na pokazanie przydatności takiego triku, ale zapewne takowy przykład istnieje :)

W C++ nie mamy rzecz jasna wspomnianych słów kluczowych (ani żadnych, które działałyby podobnie), ale istnieje sposób na zabezpieczenie klasy przed dziedziczeniem. Jest on jednak brzydki. A nawet bardzo brzydki. Mimo to zaprezentuję go.
Jak to często bywa w takich sytuacjach, sztuczka polega na kreatywnym wykorzystaniu pewnego mechanizmu językowego unikalnego dla C++, który generalnie służy do czegoś zupełnie innego. Tutaj chodzi o dziedziczenie wirtualne – a dokładniej o to, że wirtualna klasa bazowa musi być bezpośrednio inicjalizowana przez każdą klasę pochodną; nawet tą w setnym pokoleniu niżej. Do tego dodać należy jeszcze prywatne konstruktory i deklarację przyjaźni, a następnie zamieszać i doprawić do smaku, by ostatecznie upichcić coś w tym stylu:

Klasa pomocnicza CFoo_Lock ma prywatny konstruktor domyślny, więc generalnie nie może być on wywoływany. W szczególności nie może być on wywołany przez konstruktor CBar – a jest to konieczne, gdyż CFoo_Lock jest wirtualną klasą bazową i musi być zainicjalizowana bezpośrednio przez dowolną klasę pochodną (nawet niebezpośrednio pochodną). Dlatego też próba dziedziczenia CFoo skończy się błędem mówiącym o braku dostępu do prywatnego konstruktora CFoo_Lock.
Dlaczego zatem CFoo działa? To już zasługa deklaracji przyjaźni umieszczonej w klasie-blokadzie. Przyjaźń międzyklasowa nie jest jednak dziedziczna, więc nasza blokada odmawia dostępu do prywatnych składowych (czyli konstruktorów) klasom pochodnym CFoo. Dzięki temu (i niuansom dziedziczenia wirtualnego) cały ten trik działa.

To rozwiązanie można naturalnie uczynić bardziej automatycznym – wystarczy zaprząc do pracy szablony i preprocesor, by uzyskać prawie to samo co sealed/final w C#/Javie. Trudno będzie jednak uznać to kombinowanie za eleganckie.
Wygląda więc na to, że najlepszym sposobem na zabezpieczenie klasy przed dziedziczeniem w C++, to po prostu… pokazać na nią palcem (tj. komentarzem) i powiedzieć “Nie dziedzicz mnie!”. No i mieć nadzieję, że ktoś nas posłucha.

Okno na pingwina

Czasami przydaje się posiadanie więcej niż jednego operacyjnego na jednym komputerze. Jeżeli oba używają tego samego systemu plików, to zwykle nie ma problemu z wymianą danych.

A co zrobić, jeżeli tak nie jest – czyli na przykład chcemy dostać się z poziomu Linuxa do plików używanych w Windows lub odwrotnie? W jedną stronę jest łatwo: większość dystrybucji Linuxa obsługuje przynajmniej odczytywanie z partycji NTFS, a niektóre automatycznie montują znalezione woluminy, które korzystają z tego systemu plików.
Jeżeli zaś chodzi o operację odwrotną, to naturalne Windows nie patrzy tak przychylnie na inny system operacyjny. Wbudowana w okienka obsługa różnych systemów plików nie obejmuje ext2 i ext3, czyli tych używanych w ogromnej większości Linuksów. Tutaj mogą pomóc tylko zewnętrzne narzędzia.

Jednym z nim jest Ext2 IFS. Ma on tę zaletę, że działa jak sterownik, a nie np. wtyczka do Eksploratora, Total Commandera czy innego menedżera plików. Dzięki temu podmontowane partycje linuksowe są widoczne w całym systemie.

Można z nich korzystać właściwie tak samo jak z dysków NTFS, czyli odczytywać i zapisywać pliki, katalogi, zmieniać etykiety woluminów, itp. Nie trzeba też kopiować plików tam i z powrotem, aby je modyfikować.

Sam nie używam Linuksa zbyt często, ale taki sterownik jest bardzo wygodny. Chociaż prawdopodobnie dostęp do partycji ext3 z Windows sprawia, że Linuksa uruchamiam nawet jeszcze rzadziej niż wcześniej ;)

System GUI #6 – Pole wyboru i przycisk opcji

Zwykłe przyciski (buttons) można tylko wciskać jak guziki na monitorze lub klawisze na klawiaturze. Wydawałoby się, że nie mają one wiele wspólnego z bardziej zaawansowanymi elementami interfejsu: polami wyboru (checkboxes) czy przyciskami opcji (radio buttons).
Te pierwsze to proste przełączniki: mogą być zaznaczone lub nie, swój stan zmieniają po kliknięciu i zazwyczaj odwzorowane są na jakieś funkcje programu, które mogą być włączane i wyłączane. Te drugie oferują z kolei wybór z większej liczby wariantów, z których tylko jeden może być aktywny w danej chwili. Z punktu widzenia użytkownika największa różnica polega jednak na tym, że pola wyboru mają obok etykiet tekstowych kwadraciki, zaś przyciski opcji – kółka :)

Podobieństwo tych dwóch kontrolek do zwykłych przycisków polega na tym, że w identyczny sposób reagują na zdarzenia od myszy – czyli przede wszystkim kliknięcia. Podobieństwo okazało się na tyle duże, że sensowne okazało się połączenie wszystkich tych trzech rodzajów kontrolek wspólną klasą bazową. Nie lubię nadużywania dziedziczenia, ale akurat tutaj rozciągnięcie hierarchii klas wydaje się rozsądne.

Z tych trzech typów kontrolek prawdopodobnie najbardziej interesujący jest przycisk opcji, czyli ten z kółeczkiem :) Trzeba bowiem zastanowić się, w jaki sposób zrealizować grupowanie tych obiektów w zestawy, w ramach których tylko jeden radio button może być zaznaczony. Spotkałem tutaj dwa rozwiązania:

• Wprowadzenie specjalnej kontrolki-kontenera nazywanej zwykle RadioGroup. Kontener ten może zawierać tylko przyciski opcji, które wówczas nawet nie muszą być samodzielnymi kontrolkami (ale cały czas powinny oczywiście sprawiać takie wrażenie). Taka ‘grupa radiowa’ jako pojemnik może, ale nie musi być widoczna na ekranie. Przy takim rozwiązaniu spełniony jest zawsze warunek, że spośród wszystkich przycisków opcji będących bezpośrednio zawartych w jakimkolwiek kontenerze (RadioGroup lub innym) zaznaczony jest tylko jeden.
  Ten wariant występuje na przykład w bibliotece VCL (Delphi).
• Dodanie do radio buttona właściwości określającej grupę przycisków, jak choćby jej nazwa (napis) lub indeks (liczba). Wtedy należy zapewnić, że zaznaczenie będzie unikalne w ramach przycisków z tego samego kontenera oraz z tej samej grupy.
  To rozwiązanie występuje w Windows Forms.

Ostatecznie zdecydowałem się na wariant drugi. Z punktu widzenia implementacji najważniejszego elementu – czyli dbania o to, by tylko jedna opcja była zaznaczona – oba rozwiązania są bardzo podobne. Tak czy owak trzeba zawsze najpierw odznaczyć wszystkie przyciski, a potem zaznaczyć ten kliknięty. Jest to przy tym jedna z tych sytuacji, w których bardzo ułatwia życie przeklinany operator rzutowania dynamic_cast :]

Rzut okiem na Second Life

Podobno dzisiejszy świat cierpi na ogromny deficyt prawdziwej rzeczywistości, a zdecydowany nadmiar tej wirtualnej – i to już od kilkudziesięciu lat. Tak przynajmniej twierdził zmarły kilka miesięcy temu francuski socjolog Jean Baudrillard. Co więcej, odróżnienie owej prawdziwej rzeczywistości od symulacji już dawno przestało być możliwe. Cóż, filozofowie nigdy nie byli zbytnimi optymistami :)
Osobiście nie mam na przykład najmniejszego problemu z rozdzieleniem przynajmniej jednego rodzaju wirtualnej rzeczywistości od ‘prawdziwego’ świata (cokolwiek to znaczy). A niektórzy, jak ostatnio lubią donosić media, mają z tym pewien problem…

Nietrudno się domyślić, co mam na myśli. Zgadza się, chodzi o to.. coś (chwilowo nie mam dobrego określenia) o nazwie Second Life. Usłyszeć można o tym dość często, zwłaszcza wtedy gdy jakaś mniej lub bardziej znana firma tudzież instytucja poszerza swoją działalność o obecność w tym wirtualnym świecie. W nazywaniu SL światem nie ma zresztą żadnej przesady, skoro jego twórcy podają, że obecnie gości on już ponad 9 milionów użytkowników (choć tylko półtora miliona aktywnych, tj. takich, którzy zalogowali się w ciągu ostatnich dwóch miesięcy).
Pomyślałem więc, że warto chociaż sprawdzić, co w trawie piszczy… Bezpośrednim powodem był aczkolwiek ten wątek na forum Warsztatu. Tym aspektem, który został w nim poruszony, zajmę się jednak nieco później.

Zacznijmy więc od początku. Dołączenie do społeczności Second Life nie jest trudne i przypomina tworzenie konta w każdej typowej grze MMO. Pewnym odstępstwem od standardu jest jedynie konieczność podania imienia dla swojej postaci i wyboru jednego z kilkudziesięciu dostępnych nazwisk. Potem zabieramy się oczywiście za ściąganie klienta – i tu spotkała mnie pierwsza niespodzianka.
Słyszałem oczywiście o tak zachwalanej dowolności w kreowaniu świata SL przez jego mieszkańców. Sądziłem jednak, że jest ona albo ograniczona do pewnego zestawu elementów (modele, tekstury), albo że przynajmniej istnieje jakiś “zestaw podstawowy”. Nic z tych rzeczy: sam klient zajmuje tylko trochę ponad 30MB, więc wszystko jest po prostu na bieżąco ściągane w czasie rzeczywistym. Sprawia to, że klient zużywa każdy wolny megabit łącza, jaki dostanie do dyspozycji. I mówienie o megabitach bynajmniej nie jest przypadkiem.
A skoro zacząłem do spraw technicznych, to wypada też wspomnieć o tym, co widać z wierzchu i trochę głębiej. Jakość grafiki w Second Life wydaje się być rachunkiem płaconym za tę dowolność tworzenia wszystkiego przez wszystkich. Plasuje się ona mniej więcej na poziomie trzeciej części Grand Theft Auto i straszy zarówno klockowatymi modelami, jak i niską rozdzielczością tekstur – że o jakości oświetlenia nie wspomnę.
Muszę jednak pochwalić interfejs programu, i to zarówno jeśli chodzi o jego wygląd (prosty ale bardzo przyjemny), jak i funkcjonalność. Okna zachowują się dokładnie tak, jak w każdym porządnym systemie operacyjnym, a intuicyjne dodatki w rodzaju przeciągania i opuszczania są solidnie zaimplementowane. Może całość nie ma on uroku zakładek z Office 2007, ale dobrze spełnia swoją funkcję.

Nowi użytkownicy SL zaczynają w rejonie zwanym Orientation Island i ich pierwszym zadaniem jest… ukończenie kilku tutoriali. Większość z nich dotyczy poruszania się – służą do tego strzałki lub klasyczny WSAD, można też prowadzić pojazdy (w dość prymitywny sposób), a nawet swobodnie latać. Można też nauczyć się interakcji z obiektami w świecie, działania czata oraz gestów, a także zmiany wyglądu swojej postaci (czyli tzw. awatara). Te ostatnie są bardzo szerokie i możliwe do wykonania w każdej chwili.
Po ukończeniu samouczków otrzymujemy klucz i możemy teleportować się na drugą z wysp dla początkujących, czyli Help Island. Tam z kolei możemy dowiedzieć się co nieco o sposobach na tworzenie własnego kawałka wirtualnego świata, co obejmuje na przykład kreację nowych obiektów i sterowanie ich zachowaniem za pomocą skryptów. Można też zrobić “zakupy” w specjalnym sklepie, gdzie wszystko jest za darmo, co pozwala chociażby na zmianę domyślnego stroju. Walutą w Second Life są linden dolary (L$), które można wymieniać na te amerykańskie w jedną i drugą stronę. Obecny kurs to około 270 wirtualnych dolarów za jeden prawdziwy. Taka możliwość jest bardzo zachęcająca, jako że nie dostajemy nic na start – nasze konto z początku świeci pustkami.

Po zakończeniu zabawy na Help Island możemy wreszcie dostać się do właściwego świata SL. Trudno powiedzieć o nim cokolwiek konkretnego w jednym zdaniu. Na pierwszy rzut oka wygląda on trochę jak sen wykreowany przez nie do końca normalny umysł. Brakuje tu jakiegokolwiek śladu zorganizowania; można by go określić jako jedną wielką samowolkę “budowlaną”. Jest to zapewne skutkiem faktu, że większość parceli gruntu ma tu właścicieli, a prawo własności jest święte i oznacza wolność postawienia właściwie czegokolwiek gdziekolwiek. Zwłaszcza, że nie trzeba się przejmować takimi błahostkami jak np. prawa fizyki :) Własność pozwala też na ograniczenie innym dostępu do swojej działki, lecz na szczęście większość właścicieli nie korzysta z tego prawa.
W ten sposób, dzięki zbiorowej wyobraźni swoich mieszkańców (zasilanej wirtualnymi i prawdziwymi dolarami), powstaje i funkcjonuje świat tej… tego…

No właśnie – czym w zasadzie jest Second Life? Widać w nim pewne podobieństwa do gier MMORPG, zwłaszcza gdy rozwiniemy ostatnie trzy litery skrótu – Role Playing Game. Nie bardzo jednak pasuje do rzeczywistego punktu nacisku tych gier, czyli rozwoju postaci. W SL nie zdobywa się przecież doświadczenia ani nie wykonuje ustalonych z góry zadań. Tutaj świat tworzą sami “gracze”, którzy wchodzą ze sobą w interakcje, więc to raczej pierwsze trzy litery (Massive Multiplayer Online) mają tutaj większe znaczenie. Można przyjąć, że to coś w rodzaju wieloosobowej, sieciowej wersji The Sims. Albo po prostu gra, w której aspekt społeczny i ekonomiczny został tak rozbudowany, że nie zostało już miejsca na nic innego.
Ostatecznie wyszedł z tego po prostu niewyobrażalnie rozbudowany czat. Nic więc dziwnego, że Second Life okazał się dla wielu bardzo uzależniający. W końcu to właśnie komunikacja z innymi graczami połączona z rywalizacją i stawianiem czoła kolejnym wyzwaniom jest tym, co najsilniej utrzymuje przy klasycznych MMORPGach. Dodatkowo w SL żaden z tych elementów nie jest narzucony z góry, a określenie iż “ten świat żyje” nabiera tam zupełnie nowego znaczenia.

Przynajmniej teoretycznie. W praktyce Second Life wydało mi się śmiertelnie nudne i jednocześnie trochę niepoważne. Jest naturalnie prawie pewne, że zdołałem tylko liznąć powierzchnię tego cukierka, nie mając większego pojęcia o tym, co mógłbym znaleźć w środku.
Lecz prawdę mówiąc, wcale nie mam ochoty szukać i rozpoczynać swojego własnego Drugiego Życia. Tym bardziej, że w moim przypadku musiałoby by ono być już trzecie lub czwarte ;]

Z życia moderatora

Funkcjonowanie dużego i otwartego community – takiego jak forum Warsztatu – wymaga zawsze istnienia pewnych zasad, nawet jeśli byłyby one niepisane. Zebranie ich w formie osobnego dokumentu, na przykład regulaminu, nadaje im większą rangę i przede wszystkim stanowi jasną podstawę dla działań służb porządkowych; w przypadku forum są to oczywiście moderatorzy.

Decyzje (“wyroki” ;)) przez nich wydawane są rzecz jasna zawsze w pewien sposób subiektywne. Najprawdopodobniej nie ma bowiem dobrej metody na radzenie sobie z najbardziej powszechnym naruszeniem regulaminu forum, czyli tzw. lamerskimi wątkami. Są one zazwyczaj zakładane przez osoby dopiero co pojawiające się w społeczności i bywa, że równie szybko z niej znikające :)
Co robić z takimi wypryskami radosnej i mało zachwycającej twórczości? Rozwiązań jest przynajmniej kilka, wśród którym można wymienić:

• Usunięcie problematycznego wątku, ewentualnie z powiadomieniem autora. Zaletą jest fakt, że wątek przestaje straszyć innych użytkowników :) Wadą jest to, że skutek może okazać się odwrotny do zamierzonego i powodować eskalację niepożądanych zachowań. Poza tym trzeba przyznać, że takie szafowanie przyciskiem Delete jest bądź co bądź odrobinę nieeleganckie.
• Zablokowanie wątku, poprzedzone odpowiednim komentarzem wyjaśniającym, w jaki sposób narusza on regulamin i/lub inne zasady panujące na forum. Dzięki temu można utworzyć przykład złego zachowania, klarownie pokazujący jego skutki. Wiadomo jednak, że nadmiar złych przykładów szkodzi. Po jakimś czasie może się też okazać, iż sensowne i wartościowe wątki są gęsto przedzielone tymi, które nie powinny się pojawić. Utrudnia to korzystanie z forum i jest nieco irytujące.
• Przeniesienie wątku do specjalnego, wydzielonego działu “złych przykładów”. To wyjście obecnie powszechnie stosujemy na forum Warsztatu, gdzie istnieje specjalnie do tego stworzony Poprawczak. Lądujące tam tematy są automatycznie blokowane i zwykli użytkownicy nie mogą się już w nich wypowiadać. Autor potraktowanego tak wątku może jednak go poprawić i wówczas może on wrócić w poprzednie miejsce. Jest to aczkolwiek czysta teoria, bo jakoś ciężko mi sobie przypomnieć jakikolwiek przypadek takiej korekty :)

Te trzy metody mają jedną wadę: są metodami siłowymi i wymagają interwencji owych służb porządkowych. Innym wyjściem jest prosta zasada Don’t feed the trolls, czyli zwyczajne… ignorowanie. Praktyka ta wywodzi się jeszcze z czasów, gdy najpopularniejszą formą komunikacji “ogłoszeniowej” były grupy i listy dyskusyjne. W myśl tej reguły, wątek lub post, który w rażący sposób nie narusza zasad netykiety (czyli nie zawiera np. treści obraźliwych), a jedynie obniża poziom dyskusji – mówiąc wprost: jest lamerski – powinien zostać zwyczajnie zignorowany. Wówczas umrze on śmiercią naturalną, a community będzie niejako regulowało się samo.
Widać już, że to dość utopijne. Im społeczność jest większa i bardziej zróżnicowana, tym ciężej o taką jednomyślną postawę. Dodam jeszcze do tego swoją osobistą refleksję: w czasach panowania tak modnego hasła Web 2.0, zakładającego współtworzenie serwisów przez odwiedzających i nawyk komentowania wszystkiego przez wszystkich, powstrzymywanie się od wypowiedzi jest coraz trudniejsze i rzadsze. Także dlatego troll zawsze zostanie w końcu nakarmiony i będzie grasował dopóty, dopóki jakiś moderator go nie ustrzeli :)