Vilmar

Gramowicz(ka)
  • Zawartość

    2334
  • Dołączył

  • Ostatnio

Posty napisane przez Vilmar


  1. Dnia 01.07.2012 o 14:50, MKRaven napisał:

    Także, dodając także moje wcześniejsze doświadczenia, omijać HP szerokim łukiem.


    Zgadzam się. Mam w domu dwa różne Paviliony i w obu po nieco ponad dwóch latach (niezły zbieg okoliczności, swoją drogą) padła bateria - z dnia na dzień, z godziny na godzinę. Komputery potrafią się tak przegrzać (np. w trakcie grania), że układ nie wytrzymuje i sprzęt się wyłącza. Nigdy więcej tego producenta.


  2. Dnia 15.06.2012 o 18:10, Abi_Dalzim napisał:

    Pewnie nigdy. Nie sądzę żeby się chwalili, bo to będzie "tajemnica handlowa" jak bardzo
    rżną graczy.


    Myślę, że częściowo te dane mimo wszystko ujrzą światło dzienne - przecież Activision musi publikować raporty finansowe.


  3. Właśnie straciłem postać Hardkorową tylko dlatego, że mnie rozłączyło z serwerem w nieodpowiednim momencie. Ehhh... gra jest naprawdę fenomenalna, ale te problemy techniczne potrafią niesamowicie napsuć krwi :/ Moim zdaniem to spora porażka Blizzarda.


  4. Dzięki Isildurowi mam już jeden guest pass, ale niestety jako że kumpli do przekonania do zakupu Diablo 3 mam aż dwóch, to potrzebuję jeszcze jednego - ma ktoś może taki klucz na zbyciu i nie przeszkadza mu, że mam już jeden? :)

    PS. Nie byłoby problemu gdyby Blizzard nie poleciał w kulki z osobami, które zapisały się na Annual Pass :/


  5. Dnia 12.05.2012 o 20:16, Xantus napisał:

    $this->view->message = ''Page not found'';


    ''view'' To jest obiekt widoku (zakładam, że termin MVC nie jest Ci obcy) - pewną niekonsekwencją Zenda jest fakt, że do widoku odwołujemy się przez $this->view, a nie przez $this->getView() (jak w przypadku $this->getResponse()), ale to nawet lepiej, bo tak jest krócej ;)

    Wszystko co znajduje się po $this->view nie odnosi się już do obiektu $this, ale do obiektu $view (Zend_View).
    ->message = ''Page not found'' to nic innego jak przypisanie zmiennej widoku o nazwie ''message'' wartości ''Page not found''. Jak większość rzeczy w PHP i w Zendzie, można by było to napisać inaczej, np. tak:

    $this->view->set(''message'', ''Page not found'');

    Zend wykorzystuje tu dość ciekawą cechę PHP-a - tzw. magiczne metody, które powodują, że ten język jest tak elastyczny. Otóż wydawałoby się, że skoro piszemy $this->view->message = ''X'', to obiekt $view powinien zawierać właściwość/pole $message (analogicznie do tego w jaki sposób Zend_Controller_Action zawiera z góry zdefiniowaną właściwość $view - żeby daleko nie szukać ;)), ale w rzeczywistości ani tak nie jest, ani nie jest to wcale wymagane. Możemy napisać:

    $this->view->reksio = ''X'';
    $this->view->szarik = ''Y'';
    $this->view->bonifacy = ''Z'';

    i wszystko będzie w porządku - do widoku zostaną przekazane zmienne ''reksio'', ''szarik'' i ''bonifacy''. Wystarczy pamiętać, że można by było równie dobrze napisać:

    $this->view->set(''reksio'', ''X'')->set(''szarik'', ''Y'')->set(''bonifacy'', ''Z'');

    (po moim poprzednim wykładzie powinieneś przewidzieć, że taki zapis jest możliwy i całkiem często wykorzystywany w praktyce :)).

    No dobra, ale po co przekazywać jakiekolwiek zmienne do widoku? To dość oczywiste. Załóżmy, że mamy szablon HTML (załóżmy też, że w stylu Zenda):

    <html>
    <head>
    <title><?php echo $this->title; ?></title>
    </head>
    <body>
    <?php echo $this->message; ?>
    </body>
    </html>

    Oraz kontroler:

    class GramplController extends Zend_Controller_Action {
        public function indexAction() {
            $this->view->title = ''Gram.pl - strona główna'';
            $this->view->message = ''Witamy na stronie głównej gram.pl!'';
        }
        
        public function sklepAction() {
            $this->view->title = ''Gram.pl - sklep'';
            $this->view->message = ''Witamy w sklepie gram.pl!'';
        }
        
        public function forumAction() {
            $this->view->title = ''Forum gram.pl napisane w Zendzie!'';
            $this->view->message = ''Witamy na forum gram.pl!'';
        }
    }

    Co by było, gdybyśmy weszli na strony: /grampl (index to nazwa domyślnej akcji), /grampl/sklep i /grampl/forum?
    Pierwsza miałaby tytuł "Gram.pl - strona główna" i zawartość "Witamy na stronie głównej gram.pl!", druga: tytuł "Gram.pl - sklep" i zawartość "Witamy w sklepie gram.pl!", a trzecia: tytuł "Forum gram.pl napisane w Zendzie!" i zawartość "Witamy na forum gram.pl!"

    Dzięki temu możemy mieć tylko jeden szablon layoutu w HTML i wypełniać go różną zawartością zależnie od kontrolera i akcji, które wywołujemy.


  6. Dnia 10.05.2012 o 04:03, Xantus napisał:

    Trochę wstyd pytać, ale słaby jestem z obiektówki. Co oznacza taki zapis w PHP:
    $this->costam()->costam()->costam();

    np.
    $this->getResponse()->setHttpResponseCode(404);
    $this->view->message = ''Page not found'';


    To jest tzw. wywołanie łańcuchowe, możliwe do zastosowania wtedy, gdy kolejne metody w łańcuchu zwracają obiekty. Przykładem takiego wywołania w innym języku (JavaScript) jest np.:

    var str = ''Ala ma kota''.substr(0, 6).replace(''Ala'', ''Jola'').toUpperCase().concat('' PSA!'')

    który spowoduje krótkim wywołaniem zmianę tekstu ''Ala ma kota'' na ''JOLA MA PSA!'' - tradycyjnie wyglądałoby to tak (oba przykłady dają ten sam wynik):

    var str = ''Ala ma kota'';
    str = str.substr(0, 6);
    str = str.replace(''Ala'', ''Jola'');
    str = str.toUpperCase();
    str = str.concat('' PSA!'');

    Który z nich jest wygodniejszy? :)
    Oczywiście trzeba wyważyć pisanie tego typu one-linerów z czytelnością kodu, ale na ogół ten pierwszy sposób zapisu powinien być preferowany.

    Warunkiem do tworzenia klas, których metody można wywoływać łańcuchowo, jest zwracanie obiektu przez każdą kolejną metodę w łańcuchu oprócz ostatniej. W JavaScripcie wszystko jest obiektem, więc zawsze można dopisać kolejną kropkę i kolejną metodę (choć czasem nie ma to sensu), ale w PHP polega to na tym, że mając obiekt klasy:

    class Samochod {
      public function jazdaDoPrzodu() {
        // jakies instrukcje
        return $this;
      }

      public function zmienOpony() {
        // jakies instrukcje
        return $this;
      }

      public function zatankujPaliwo(Paliwo $paliwo) {
        // jakies instrukcje
        return $this;
      }
      
      public function podajPredkoscNaGodzine() {
        return $this->predkoscNaGodzine;
      }

    Można napisać:

    $samochod->zatankujPaliwo($pb95)->zmienOpony()->jedzDoPrzodu();
    $samochod->zmienOpony()->zatankujPaliwo($pb95)->jedzDoPrzodu();
    $samochod->jedzDoPrzodu();
    $predkosc = $samochod->jedzDoPrzodu()->podajPredkoscNaGodzine();

    Ale nie można napisać:

    $samochod->podajPredkoscNaGodzine()->jedzDoPrzodu();

    Bo "podajPredkoscNaGodzine" nie zwraca obiektu (a już na pewno nie typu Samochod), tylko typ prosty (int lub float). Dobrym stylem programowania w PHP-ie jest zapewnianie, że wszystkie metody obiektów mają na końcu instrukcję return z argumentem - nawet te, które na pierwszy rzut oka niczego sensownego nie zwracają (wtedy po prostu powinny mieć na końcu return $this, co pozwoli na tworzenie wywołań łańcuchowych).

    W Zendzie (a z niego, o ile się nie mylę, pochodzi Twój przykład) wszystkie obiekty są w ten sposób napisane. Pierwszą linijkę należałoby czytać tak:

    "Pobierz będący jednym z moich pól obiekt Zend_Http_Response i zmień kod odpowiedzi na tym obiekcie na 404". Bezpośredni ekwiwalent:
    $response = $this->getResponse();
    $response->setResponseCode(404);

    Druga linijka z Twojej wklejki jest trochę inaczej skonstruowana - wyjaśnić?


  7. Bardzo fajna sprawa :) Brawo!
    To dobrze, że gram.pl jest wciąż jednym z tych nielicznych seriwsów, które mają wśród swoich użytkowników ludzi zdolnych i gotowych ulepszać serwis "dla idei" :)
    Liczba danych, które można wyliczyć w takim serwisie jest w zasadzie nieograniczona - dla fanów liczb i statystyk to ogromna frajda - mam nadzieję, że planujesz co jakiś czas dorzucić jakiś nowy bajer, bo z Twoich słów wynika, że podstawę już masz - skuteczny i niezawodny indekser to 80% sukcesu w takim przedsięwzięciu.

    Czapki z głów :)

    PS. Nie znam innych programistów z obecnej ekipy gramu, ale o Kamilu nie mogę powiedzieć złego słowa - to bardzo dobry fachowiec. Niektórzy mogliby się czasem ugryźć w język i docenić wysiłek oraz umiejętności, jakich wymaga tworzenie poszczególnych elementów tak bogatego portalu od zera. A przecież można było forum postawić na phpBB3, a gramsajty na Wordpressie, prawda?


  8. Dnia 06.05.2012 o 21:34, Janek_Izdebski napisał:

    A co byśmy mieli gdyby wygrał Sarkozy:

    - kontynuację duetu Sarkozy - Merkel (polityka ciągłego zaciskania pasa w całej UE)
    - redukcję budżetu UE, w tym funduszy strukturalnych dla Polski


    To akurat pozytywy. Do czego prowadzi nadmierne rozpasanie chyba wystarczająco dobitnie pokazuje przykład Grecji?

    Dnia 06.05.2012 o 21:34, Janek_Izdebski napisał:

    - w większym stopniu kumanie się Francji ponad naszymi głowami z Rosją
    - konsekwentną politykę Fracji umniejszania roli Polski w Europie (w poufnych rozmowach
    z dziennikarzami francuscy dyplomaci do dziś narzakają, że Polska jest w UE, a jak jej
    nie było to decyzje w UE łatwiej i szybciej się podejmowało).


    A to Twoje opinie, niepodparte żadnymi argumentami a zwłaszcza powodami, dla których zmiana prezydenta na lewicowego miałaby zmienić tą sytuację.

    Hollande to może być "lepszy wybór dla Polski" tylko w jednym przypadku - jeśli jego polityka przyspieszy znacząco rozpad UE. Są na to pewne szanse.


  9. Dnia 04.05.2012 o 14:11, Tenebrael napisał:

    Wniosek: jeśli chcesz stworzyć WoW-killera, musisz zrobić grę co najmniej tak dobrą i
    pełną contentu, jak WoW w chwili OBECNEJ.

    Wniosek 2: tworzenie klona WoW''a nie ma żadnego sensu, gdyż, o ile nie masz astro0nomicznego
    bnudżetu i masy czasu, nie będziesz miał możliwości przebicia swojego rywala w czymkolwiek.


    Wnioski są błędne - w tej chwili mnóstwo contentu WoW leży odłogiem, nikt z niego nie korzysta, a duża część została całkowicie usunięta - słowem: porzucony content mógłby nie istnieć, a i tak WoW cieszyłby się obecną popularnością. Gracze WoW katują na okrągło to, co zostało dodane w ostatnim dodatku/patchu, a tego jest na tyle mało, że spokojnie można sobie pozwolić na przygotowanie takiej zawartości przed premierą gry MMO.

    W przypadku Rift-a i TOR-a (nie grałem w żaden z nich, więc opieram się tylko na opiniach innych), z tego co zdążyłem się zorientować, problemem jest nuda po wbiciu maksymalnego poziomu, kiedy osiągnęło się już wszystko i nie bardzo jest co robić dalej - czyli brak tzw. end-game contentu. A end-game contentu i w WoW-ie jest niewiele, więc grunt w tym, żeby był on na tyle różnorodny i satysfakcjonujący, a zarazem sprawiający wrażenie bogatego i ciągle po cichu lub z pompą rozwijany, by gracz się nie połapał, że jest go jak na lekarstwo.

    Moim zdaniem kluczem do sukcesu gry MMO, oprócz zapewnienia możliwości ciągłego, nieskończonego rozwoju postaciom graczy na wiele różnych sposobów, jest zmiana sytuacji przy wydawaniu gry i modelu płatności w przypadku abonamentu:

    Po pierwsze - wersja trial w dniu premiery jest absolutną koniecznością. Twórcy RIFT-a się pod tym względem nie popisali, TOR chyba też ma z tym problem.
    Po drugie - wersja BOX może kosztować jak pozostałe gry, ale za to abonament MUSI zmaleć co najmniej o połowę - do 10 EUR za 2 miesiące grania. Koszt utrzymania serwerów wcale nie usprawiedliwia obecnych cen abonamentu - ustalanie go na poziomie WoW-a to zwykła chciwość i zarzynanie kury, zanim zdąży złożyć pierwsze złote jajo.
    Po trzecie - regularne opłacanie abonamentu musi być odpowiednio wynagrodzone w świecie gry. Nie mówię tutaj o żadnych dodatkowych zdolnościach czy ułatwieniach w grze, ale o jakiejś specjalnej pelerynie, unikatowym mouncie (lub, jeszcze lepiej, możliwości zmiany wyglądu normalnego mounta), kolorze nicka itd. itp. Przy czym bonus tego typu mógłby (i powinien!) być stopniowany: pierwszy stopień po upłynięciu 6 miesięcy ciągłego opłacania, drugi po upłynięciu roku, a trzeci po upływie 2 lat. Przy czym zamrożenie konta na dłużej niż 3 dni powinno skutkować natychmiastowym odebraniem tego typu przywilejów i konieczności budowania "prestiżu" od nowa.

    Z tych wszystkich trzech rzeczy wydaje mi się, że najtrudniejszym do przełknięcia jest ten drugi, bo raz ustanowioną cenę abonamentu byłoby szalenie trudno podnieść bez bolesnych strat w liczbie aktywnych subskrypcji, a przecież po osiągnięciu pewnego pułapu (5 mln graczy?) chęć podniesienia zysków z abonamentu jest naturalna i słuszna. Ale to nie jest sytuacja bez wyjścia, bo można się ratować różnymi płatnymi usługami, a poza tym można w pewnym momencie wypuścić sequel z nieco wyższą ceną abonamentu.


  10. Wszystkie zmiany, które zachodzą w tej branży (brak wersji demo, instalowanie trojanów razem z grami, blokowanie używek itd. itp.) powinny prowadzić do jednej z dwóch opcji (lub obu):

    1. drastycznego spadku liczby gier kupowanych rocznie przez przeciętnego gracza,
    2. wzrostu piractwa.

    I już chciałoby się krzyknąć "choose your DESTINY", gdyby... rzeczywistość nie udowadniała, że rynek chłonie wszystkie te idiotyzmy jak gąbka. I rośnie. To zadziwiające, ale wychodzi na to, że trzeba przyklasnąć wydawcom i pogratulować skuteczności, bo w ostatecznym rozrachunku (gdy przychodzi pora płacenia) wychodzi, że wszystkie ich decyzje są słuszne. Czapki z głów :)

    Gdyby jeszcze tylko gry nie były tak drogie w produkcji...