Dyskusja:Icy Tower

message: Dziękuję za głosy (wszystkim) i poprawki (szczególnie Polimerkowi)! :)
Ale z jedną z nich pozwolę się nie zgodzić: Usunięta ciekawostka "była uźródłowiona jednym postem z mało wiarygodnego forum internetowego". Forum, na którym ją znalazłem, to oficjalne forum gry, ale to samo w sobie nie jest jeszcze takie istotne, bo wypowiedź jest autorstwa twórcy gry. :) (johanp to inaczej Johan Peitz) Dlatego wolę ją przywrócić, bo nadaje trochę "rysu historycznego". Vinyanov 16:34, 26 lis 2006 (CET)
replies: text: Problem w tym, że na forum każdy może się podpisać jako rzekomy autor programu - fora nie są dobrym źródłem. Trzeba poszukać czegoś innego. Polimerek 16:42, 26 lis 2006 (CET)
replies: text: : Akurat na tym forum fałszerstwo jest niemożliwe - autor tej wiadomości zalogował się jako administrator serwisu (a serwis znajduje się w oficjalnej domenie autora gry). Ale faktycznie takie weryfikowanie wypowiedzi jest niewygodne. Poszperałem i znalazłem lepsze źródło (wywiad). Dzięki raz jeszcze! Vinyanov 16:59, 26 lis 2006 (CET)
thread_title:  Podsumowanie i drobiazg 

message: Jestem rozczarowany występowaniem w artykule słów takich jak "hacki" i "kombosy". Ale "jaki pan, taki kram" i nie zamierzam rozpoczynać wojny edycyjnej.
replies: text: Może zaproponujesz zamienniki? ;) petr✉ 00:52, 3 kwi 2007 (CEST)

text: Wojny edycyjnej oczywiście nie, ale chyba na jakieś zmiany liczysz, skoro w innych artykułach też walczysz o jasność sformułowań? :) Combo to określenie wybrane przez autora gry i nie ma chyba sensu go tłumaczyć (pomijając spolszczenie). Oprócz tego zdaje się, że to zwyczajne angielskie słowo o wielu znaczeniach. (:en:Combo) Hack - prawdę mówiąc ja też dzisiaj się nad nim zastanawiałem. Właściwie można zmienić hacki oraz mody np. na modyfikacje fizyczne oraz modyfikacje graficzne. Może to i lepiej brzmi. Vinyanov 01:26, 3 kwi 2007 (CEST)
replies: text: : Tak się jakoś stało, że obecnie obydwa twoje postulaty zostały wprowadzone w życie. :) viny.tell // 17:56, 15 mar 2008 (CET)
w artykule jest błąd noob nie oznacza nowego gracza tylko no nie wiem jak to opisać newbie to nowy graczMarciniak99 (dyskusja) 13:20, 22 mar 2010 (CET)
thread_title:  Slang 

message: czy można tak po prostu zrobić screena z gry i umieścić go na wiki?? jesli tak to poprosze o wyjasnienie bo nie rozumiem tego- tyle sie tu mowi o prawach autorskich. oczywiscie artykuł bardzo mi sie podoba
--Ignacy 21:18, 9 kwi 2007 (CEST)
replies: text: Hm, nigdy nie zajmowałem się grafikami na dłużej, ale generalnie chyba nie można. Ta sprawa jest wyjątkowa, bo na stronie zrzutu jest zastrzeżenie:
replies: text: : Dostałem zgodę Johana Peitza z Free Lunch Design (info@freelunchdesign.com) na udostępnianie w Wikipedii screenów z gry Icy Tower na licencji GNU FDL

text: Więc najwidoczniej autor gry zmienił licencję zrzutów z Icy Tower wyłącznie na potrzeby Wikipedii. :) Na wszelki wypadek doinformuj się u autora zdjęcia w kwestii brzmienia tego listu. Nawiasem, jeżeli zgoda obejmuje wszystkie screenshoty, także przyszłe, a nie tylko ten jeden, to może warto byłoby wzbogacić nimi ten artykuł jeszcze odrobinę... Vinyanov 01:28, 10 kwi 2007 (CEST)
thread_title:  Prawa autorskie 

message: Z ważniejszych: dodałem infoboks Icy Tower Mobile i tabelkę długości schodków. Oprócz tego, usunąłem wzmianki o paru pojęciach, które zostały zapomniane, usystematyzowałem wiadomości (gdzie było można, IMO) i skondensowałem tekst. Oprócz tego, mam wrażenie, że odPOVizowałem go jeszcze bardziej… to dziwne, i niepokojące. ;) viny.tell // 06:10, 26 gru 2008 (CET)
thread_title:  Zmiany świąteczne 

message: 10marek.n,
W sprawie źródła, które w ma potwierdzać prawdziwość progów wymaganych przez rangi. Usunąłem je, ponieważ nie zawiera ono nic, co wskazywałoby, że jest ono poparte jakimkolwiek autorytetem. Ja i ty wiemy, że ten dokument w Google Docs został stworzony przez Johana Peitza na potrzeby beta testów 1.4, ale ponieważ tematy omawiające wersje beta Icy Tower są w tej chwili niedostępne, nikt już tego nijak nie udowodni. W tej chwili dokument ten może równie dobrze sprawiać wrażenie, że to on został utworzony na podstawie artykułu na Wikipedii… :)
Zmieniłeś też, w miejscach, gdzie przedstawiamy ramy czasowe określonych funkcjonalności, znaki nierówności na znaki zakresu, argumentując, że te pierwsze „przeszkadzają”. Możliwe, że znaki nierówności są niewielkie i trudno je zauważyć, ale mają one taką zaletę, że ich użycie przypomina czytelnikowi, iż zakresy „od” (np. „od 1.2” albo „od 1.4”) są, przynajmniej na stan dzisiejszy, nieskończone (tzn. dotyczą wspomnianej wersji oraz wszystkich potencjalnych wersji późniejszych). Tymczasem twoja notacja sugeruje, że wersja kończąca zakres jest jednocześnie ostatnią wersją, w której on obowiązuje, w ogóle. Zapisywanie obydwu granic zakresu bywa zresztą niepożądane także z innego powodu, mianowicie jest związane z powielaniem danych. Jeśli piszesz, że schodki 4-4 występują na piętrach 1500. - 1999., to oczywiste jest, że kolejny zakres będzie rozpoczęty na 2000. piętrze (a dwukrotne umieszczenie w artykule tak zbliżonych i tak dużych liczb obniża jego estetykę). Zmieniłem pod tym kątem także treść tabelki z nagrodami za kombosy.
Ponadto mój zapis ma też tę zaletę, że w momencie wydania łaty do 1.4, np. 1.4.1, która nadpisałaby wersję poprzednią, nie będziemy musieli aktualizować wszystkich jego wystąpień. Ale zauważyłem, że gdzieniegdzie zakresy przedstawione poprzez nierówności zamieniłeś na odpowiedniki słowne, „od wersji x”. Jeszcze wczoraj byłbym przeciwny takiemu rozwiązaniu, ponieważ są one najczęściej umieszczane w tabelach, a wprowadzenie go spowodowałoby ich znaczne rozszerzenie (i zarazem zawężenie treści artykułu). Ale dzisiaj, kiedy tabele te zostały przeniesione do szablonów ze spoilerami, ich szerokość nie ma już większego znaczenia. Więc wprowadziłem wszędzie zapis wyrazowy. Zamiast zwrotu „do x” będę tylko używał „przed x”, aby uniknąć wątpliwości w kwestii obecności lub nieobecności x w danym zakresie.
PS. Warto stosować konsekwentną interpunkcję w ramach artykułu. Nie mówię, że sam piszę na tym polu idealnie, dzisiaj zauważyłem, że także popełniałem błędy (używałem myślnika nie otaczając go jednocześnie odstępem). (Poprawiłem je dzisiaj). Ale wykorzystywanie w jednym miejscu myślnika i łącznika jest raczej nieatrakcyjne. Przejrzałem dzisiaj poradnię językową PWN i uznałem, że najlepiej będzie chyba stosować wariant 1., łącznik bez spacji. Oprócz tego po liczebnikach porządkowych (np. numerach pięter) stawiamy IMO kropki.
PPS. Dzięki za usunięcie przekierowań. viny.tell // 19:39, 6 cze 2009 (CEST)
replies: text: Za Poradnią Językową PWN: po liczebnikach porządkowych można umieścić kropkę, lecz gdy z kontekstu jasno wynika, że chodzi właśnie o taki liczebnik, kropkę można pominąć - jest to polecane rozwiązanie. ThomasAnderson (dyskusja) 12:50, 30 cze 2009 (CEST)
replies: text: : Tak, wiem. Ale nie lubię zastanawiać się, kiedy kontekst sugeruje, że coś wolno zrobić, a kiedy nie – wolę stosować daną zasadę do wszystkich możliwych przypadków. Szczególnie zaś w momencie, kiedy zysk z mniej rygorystycznego jej przestrzegania jest tak niewielki, jak jeden znak (kropka). :) viny.tell // 22:31, 30 cze 2009 (CEST)
thread_title:  Progi i zakresy 

message: # Proszę o nie zmienianie lepszych wyrażeń językowych na gorsze. "[W]ymagania stawiane przez każdą rangę" brzmi lepiej niż "wymagania na każdą rangę" i tego rodzaju kolokwialne "ulepszenia" będę się starał rewertować. Nieważne, czy formy takie są krótsze, zwięźlejsze, prostsze do zrozumienia itd. Styl formalny narzuca czasami stosowanie form dłuższych, lecz takich, które spełniają wymagania stylistyczne stawiane przez encyklopedię.
# A także o unikanie dywagacji o istocie grafik Icy Tower. Schodki 1000+ w 1.3 powinny być nazywane szklanymi, ponieważ pojęcie "schodki łańcuchowe" jest bezsensowne z punktu widzenia spójności świata wyobrażonego. Jak postać miałaby móc po nich skakać? Wyrażenie takie jak, np., "schodki chmurowe" ma sens, ponieważ chmury jako takie wielokrotnie były w grach komputerowych przedstawiane jako substancja, po której jej bohater może się poruszać. Ale "schodki łańcuchowe" ani nie jest logiczne, ani uzasadnione poprzez jakąkolwiek konwencję. Natomiast schodki "szklane" są przykładem nazwy, którą wywnioskowano na podstawie rozsądnych przesłanek. Po pierwsze, wyrażają, zgodnie z duchem Icy Tower polegającym na stopniowym utrudnianiu rozgrywki, typ schodków w zasadzie identyczny z poprzednim ("tęczowym"), lecz poddany drobnej modyfikacji (uczyniony przejrzystym) w celu uczynienia gry nieco trudniejszą. Po drugie, bardziej intuicyjna jest przecież interpretacja kolorowych obwiedzeń schodków 1000+ jako refleksów świetlnych na tęczowej, jednolitej płaszczyźnie, niż jakiegokolwiek rodzaju "łańcuchów"! To po prostu bardziej sensowne. Ale nie chcę nawet o tym rozmawiać. Powyższe rozważania mają tylko stanowić przykład, że nazwy zaproponowane przeze mnie mają zazwyczaj parę uzasadnień. Jeśli ktokolwiek zamierza zmienić je ponownie, proszę o wyjaśnienie swoich motywów na stronie dyskusji.
# A także o nie umieszczanie nieistotnych informacji. Informacja o tym, że w wersji 1.4 tło wieży zostało zmienione na najmniejszą wzmiankę nie zasługuje. Dlaczego? Otóż jeśli pożądane jest umieszczanie w tym artykule wiadomości o podobnym stopniu drobiazgowości, i jeśli wszystkie równie trywialne fakty faktycznie zostałyby w nim umieszczone (bo przecież skoro opisaliśmy szczegółowo wygląd wieży w Icy Tower 1.4, to to samo musimy zrobić także dla wersji poprzednich!), to prawdopodobnie byłby on ok. 10 razy dłuższy, niż jest teraz! Taka długość byłaby niedopuszczalna dla jakiegokolwiek artykułu, nie tylko medalowego.
# A także o weryfikowanie informacji umieszczanych. Te "rekordy", które załączono do artykułu i pozwolono im w nim zagościć na tak długi czas, nie dość, że stanowią informację zbyt drobiazgową, aby zasłużyła sobie na zabranie równie wielkiej ilości przestrzeni w ciele artykułu, to jeszcze pochodzą z nieaktualnej wersji gry, a dodatkowo zostały zdyskredytowane przez społeczność jako "spowolnione". Moim zdaniem ten artykuł nie powinien zawierać zresztą *żadnych* informacji o rekordach. Rekordy same w sobie nie stanowią dla czytelnika artykułu żadnej wartości, gdyż są pozbawione kontekstu jego własnych wyników. Nie potrafi przecież wyobrazić sobie, ile pracy potrzeba na zdobycie 500. czy 2000. piętra. viny.tell // 09:39, 7 wrz 2009 (CEST)
=== Schodki 1000+ w 1.4 ===
10marek.n: moim zdaniem twoje podejście jest błędne. Tabela opisująca schodki w swojej obecnej formie nie przedstawia różnic w wyglądzie schodków, ale w ich naturze, rodzaju. O ile wiem każdy typ schodka uległ w 1.4 zmianom w wyglądzie, choćby kosmetycznym. Dlatego jeśli za kryterium wyróżniające "typy schodków, które uległy znaczącej zmianie w trakcie zmiany wersji z 1.3 na 1.4" mielibyśmy uznać wprowadzenie dowolnej zmiany w grafice (a to właśnie zdajesz się postulować poprzez odnotowywanie w artykule różnic pomiędzy "czerwonymi" a "różowymi" - zresztą te nazwy kolorów są kwestią subiektywną - schodkami metalowymi), każdy wiersz omawianej tabeli musiałby posiadać dwie osobne komórki, dla 1.3 i 1.4. A konsekwencją tego byłyby wyszczególnianie w niej nawet absurdalnie znikomych różnic pomiędzy typami, jak np. tych, które dotknęły schodki kamienne (tj. zmian w fakturze lub teksturze). Do tego nie powinniśmy dopuścić.
Możesz teraz zapytać, dlaczego więc w mojej edycji typ schodków powyżej 1000. piętra został jednak rozdzielony na dwie komórki. Jest tak dlatego, że jest to jedyny przypadek zmiany schodka, którego nie możemy zinterpretować jako ewolucję, ale jako zmianę radykalną, odgórną, tematyczną. Schodki "Mario" i schodki "rurowe" mają wspólny element tematyczny: (ujmując to pospolicie) hydraulikę. Możemy naocznie stwierdzić podobieństwo. Ale szklane tafle z 1.3 i (jak ja je rozumiem) wydzielone kawałki przestrzeni zawierające błyski symbolizujące gwiazdy, które widzimy w 1.4, nie mają ze sobą nic wspólnego. Dlatego je wyróżniam.
Oprócz tego tego typu drobiazgowość w opisywaniu różnic pomiędzy schodkami może zaszkodzić wizerunkowi artykułu. Opisywaniem bardzo szczegółowych różnic pomiędzy grafikami powinny się zajmować serwisy fanowskie. viny.tell // 20:34, 7 wrz 2009 (CEST)
thread_title:  O ważności 

message: 10marek.n: moim zdaniem twoje podejście jest błędne. Tabela opisująca schodki w swojej obecnej formie nie przedstawia różnic w wyglądzie schodków, ale w ich naturze, rodzaju. O ile wiem każdy typ schodka uległ w 1.4 zmianom w wyglądzie, choćby kosmetycznym. Dlatego jeśli za kryterium wyróżniające "typy schodków, które uległy znaczącej zmianie w trakcie zmiany wersji z 1.3 na 1.4" mielibyśmy uznać wprowadzenie dowolnej zmiany w grafice (a to właśnie zdajesz się postulować poprzez odnotowywanie w artykule różnic pomiędzy "czerwonymi" a "różowymi" - zresztą te nazwy kolorów są kwestią subiektywną - schodkami metalowymi), każdy wiersz omawianej tabeli musiałby posiadać dwie osobne komórki, dla 1.3 i 1.4. A konsekwencją tego byłyby wyszczególnianie w niej nawet absurdalnie znikomych różnic pomiędzy typami, jak np. tych, które dotknęły schodki kamienne (tj. zmian w fakturze lub teksturze). Do tego nie powinniśmy dopuścić.
Możesz teraz zapytać, dlaczego więc w mojej edycji typ schodków powyżej 1000. piętra został jednak rozdzielony na dwie komórki. Jest tak dlatego, że jest to jedyny przypadek zmiany schodka, którego nie możemy zinterpretować jako ewolucję, ale jako zmianę radykalną, odgórną, tematyczną. Schodki "Mario" i schodki "rurowe" mają wspólny element tematyczny: (ujmując to pospolicie) hydraulikę. Możemy naocznie stwierdzić podobieństwo. Ale szklane tafle z 1.3 i (jak ja je rozumiem) wydzielone kawałki przestrzeni zawierające błyski symbolizujące gwiazdy, które widzimy w 1.4, nie mają ze sobą nic wspólnego. Dlatego je wyróżniam.
Oprócz tego tego typu drobiazgowość w opisywaniu różnic pomiędzy schodkami może zaszkodzić wizerunkowi artykułu. Opisywaniem bardzo szczegółowych różnic pomiędzy grafikami powinny się zajmować serwisy fanowskie. viny.tell // 20:34, 7 wrz 2009 (CEST)
thread_title:  Schodki 1000+ w 1.4 

message: W kwestii użycia list w infoboksie (a raczej infoboksach). Jest ich w nich tak wiele, ponieważ Szablon:Gra komputerowa infobox jest skonstruowany w taki sposób, że zawartość niektórych jego wierszy jest wyświetlana z odstępem paru pikseli od górnej krawędzi komórki tabeli, w której się ona znajduje. Ściślej mówiąc, niektóre wartości infoboksa są wyświetlane w akapitach zawartych w komórkach (które to akapity posiadają prawdopodobnie górny margines), w przeciwieństwie do pozostałych, które są umieszczane bezpośrednio w komórkach. Ten pierwszy przypadek zachodzi, o ile dobrze rozumiem, dla wartości parametrów "data wydania", "kategorie wiekowe", "nośniki" i "wymagania". Jednak można go (i zarazem tego nieprzyjemnego efektu estetycznego) uniknąć, jeśli tylko wartość danego parametru infoboksa nie jest tekstem, ale listą. Postanowiłem to wykorzystać. W ten więc sposób, aby uniknąć dysharmonii, która byłaby spowodowana faktem, że niektóre komórki posiadają górny odstęp a niektóre nie, każdy z wymienionych czterech parametrów w niniejszym artykule jest albo nie wykorzystywany w ogóle, albo wyrażony poprzez listę. (Niestety nie podejmuję się na razie zadania zmiany szablonu tak, aby ten problem całkowicie wyeliminować).
Kiedy już zaś część parametrów, które zawierały wylistowania (np. informacja o nośnikach albo o wymaganiach) została wyrażona poprzez listy, oczywistym było, że powinna tym śladem pójść także reszta. W ten sposób wszystkie parametry mogące potencjalnie być wyrażone jako listy są nimi. Chodzi po prostu o bycie konsekwentnym pod kątem layoutu strony. Zresztą moim zdaniem efekt końcowy nie wygląda źle. W kwestii natomiast tego, dlaczego wszystkie listy wykorzystują znaczniki HTML zamiast wikiznaczników. O ile pamiętam, parser nie umiał przekonwertować składni opartej o gwiazdki na listę HTML w dokumencie wynikowym w każdym z parametrów, gdzieniegdzie generując błędy. Listy HTML są bardziej pewne i działają zawsze.
W kwestii sposobu osadzenia w artykule list przypisów i nie wykorzystywania w nim szablonów. Kiedy postanowiłem wykorzystać możliwość grupowania przypisów, na początku zdecydowałem się na Szablon:Przypisy rzeczowe. Jednak okazało się, że narzuca on stosowanie w artykule przypisów o nazwie grupy brzmiącej "przypis rzeczowy" właśnie. Niestety tak długa nazwa grupy powodowała, że przypisy użyte w wąskich tabelach wyświetlały się nieatrakcyjnie. Z tego powodu zmieniłem ją na krótszą (nb.). To rozwiązało problem ich wyglądu w tabelkach (są teraz o wiele węższe), ale podczas wyświetlania ich listy w końcowych sekcjach artykułu musiałem zrezygnować z użycia dedykowanego szablonu. Nie jest możliwe sparametryzowanie go tak, aby wymagana przez niego nazwa grupy mogła być różna w różnych artykułach, więc nie "wykryłby" on moich przypisów o zmienionej nazwie. Dlatego zagnieździłem ręcznie znacznik  oraz śródtytuł. A jeśli postąpiłem tak dla przypisów rzeczowych, to to samo musiałem wykonać z przypisami normalnymi. 
Wybaczie, że tak rozwlekle, ale pamiętam, że np. sprawa list bywała chyba kiedyś osią rewertów, więc warto jest wyłożyć swoje argumenty raz na zawsze. ;) viny.tell // 23:18, 16 wrz 2009 (CEST)
replies: text: To ja dla odmiany krótko: Pomogło?  « Saper // @dyskusja »  23:47, 11 kwi 2010 (CEST)
replies: text: : Nie. ( ;) ) Problem dotyczy nie list, ale właśnie akapitów, bo .infobox p { margin-top: 0px; } - o ile to jestem w stanie przetestować - działa. viny.tell // 14:16, 6 cze 2010 (CEST)
thread_title:  Znaczniki HTML 

message: Wiele niedoróbek, błędne linkowania, tabele zbyt szerokie. Wiele wyboldowań i list, braki w źródłach.--Basshuntersw (dyskusja) 12:27, 2 maj 2013 (CEST)
thread_title:  Do poprawy