Gucio and his frogs vs. programmers' persistence

25 maja 2023
Jakub Rojek Jakub Rojek
Source: based on photos from page https://www.sadanduseless.com/grumpy-avocado/
Kategorie: Zarządzanie, Programowanie

Internet naprawdę jest dziwnym miejscem. Wiadomo, że to skarbnica wiedzy, informacji oraz narzędzie do komunikacji. Jednocześnie - miejsce rozrywki i to czasem... niebanalnej lub takiej, której w życiu byśmy się nie spodziewali, że może kogoś interesować. A co zabawniejsze, czasem takie "wygłupianie się" może posłużyć jako inspiracja do przemyślenia pewnych "poważniejszych" spraw i podzielenia się swoimi refleksjami np. na temat tworzenia oprogramowania.

Świat gier wideo niesamowicie się rozrósł i to na wszystkich płaszczyznach - istnieje dużo narzędzi dla potencjalnych twórców (dzięki czemu nie tylko wielkie studia mogą tworzyć produkcje dla masowego odbiorcy), technologia pozwala tworzyć coraz bardziej zaawansowane tytuły, toczą się poważne rozgrywki w grach sieciowych, nierzadko interaktywna fabuła stoi na poziomie porównywalnym z filmową, w tle przerzucane są duże pieniądze, a to wszystko sprawia, że elektroniczna rozrywka weszła do tzw. mainstreamu i stała się elementem popkultury. Gry przeniknęły do naszego życia na tyle mocno, że niektórych fascynuje nie tylko granie, ale nawet oglądanie. A to objawia się w postaci streamowania swojej rozgrywki przez różne osoby i specyficznej kultury oraz wydarzeń z tym związanych. Czasami są one zrozumiałe tylko dla osób w danej "bańce", czasem dla szerszego, ale nadal wtajemniczonego grona, ale od czasu do czasu zdarzy się coś, o czym słychać nawet w "niegrowych" mediach. I tak było na początku maja 2023 r. ze streamerem o nicku Gucio.

Mniej więcej w tym okresie na rynku pojawiła się gra Star Wars Jedi: Survivor, która jest kontynuacją wcześniejszej produkcji Star Wars Jedi: Fallen Order. Oba tytuły należą do tzw. podgatunku Soulslike, a więc gier cRPG widzianych z perspektywy trzeciej osoby i nastawionych na akcję, wyróżniające się naturalnie wysokim poziomem trudności. Gracze doświadczają w nich wielu śmierci i powtarzania poszczególnych walk, ale za to są wynagradzani dużą satysfakcją po pokonaniu bossów, których często trzeba się po prostu "uczyć" i poznać ich zachowania na drodze wielu porażek. Nazwa nurtu wzięła się od najpopularniejszej serii tego typu, a więc Dark Souls, aczkolwiek warto wspomnieć również o Bloodborne, Elden Ringu czy Sekiro: Shadows Die Twice, gdyż to najpopularniejsi przedstawiciele tego gatunku. Czytając opis, łatwo domyślić się, że dla niektórych bardziej radosne niż sama gra będzie oglądanie zmagań innej osoby i jej czasami nieudolnych prób poradzenia sobie z wyzwaniem, ale także obserwowanie sukcesów. Nie mówiąc o tym, że niektórzy wyćwiczyli się w tego typu grach na tyle, że narzucają sobie dodatkowe wyzwania w stylu przejścia gry bez jednego draśnięcia lub nawet z użyciem elektroencefalografu. Jednak są to jednostki - czasem nawet zwykły sposób pokonania gry stanowi wyzwanie. I tutaj wracamy do Gucia.

Ten na swojej transmisji spróbował swoich sił właśnie z nową grą z uniwersum Gwiezdnych Wojen, wiedząc, że czeka go trudna batalia, zwłaszcza, że wybrał najwyższy poziom trudności. Tym niemniej, nie spodziewał się, że pokonanie jednego z opcjonalnych bossów, a więc dwóch ogromnych żab będzie aż tak skomplikowane. Ale co to za gracz Soulslike, który odpadnie po paru porażkach, prawda? Więc spróbował znowu. I znowu. I jeszcze raz. I kolejny... W ten sposób w pierwszej sesji zajęło mu to 22 godziny, po czym następnego dnia (albo raczej nocy) przystąpił do kolejnego szturmu i po dalszych 7 godzinach w końcu poradził sobie z Oggdo Bogdo oraz jego (jej?) pomiotem. Streamerowi zajęło to łącznie 29 godzin i ponad 1200 śmierci tylko w tym fragmencie rozgrywki. No cóż, wytrwały gracz, pomyślicie. Dlaczego zatem walka Gucia z przerośniętymi płazami stała się wręcz viralem i jakie to miało skutki?

Wpływ na to miała absurdalność wyzwania - umówmy się, większość z nas już po 100-200 śmierciach zaczęłaby szukać innej drogi pokonania tego bossa lub jego ominięcia. Zwłaszcza, że żaby były przeciwnikiem opcjonalnym, a więc niewymaganym do ukończenia gry. Co więcej, większość graczy zaopatrzyłaby się w inny ekwipunek, zestaw umiejętności lub zwyczajnie ukończyłaby parę innych zadań, aby wzmocnić postać i dopiero wtedy wróciła do gigantycznych potworów. Tutaj nie będę ukrywał - nie wiem, czy podejście Gucia było optymalne, aczkolwiek sądząc po różnych komentarzach w Internecie, to na tym etapie rozgrywki i z tym "buildem" było to szaleństwo oraz bardziej sprawa honoru, mająca zmazać na nim plamę po tak wielu zgonach. Żeby było jasne - świetnie że się udało, należą się gratulacje, natomiast warto pamiętać o tym uporze, gdyż to właśnie nić łącząca ten viral z programistami. Ale o tym za chwilę.

Należy jeszcze wspomnieć, jakie liczby wygenerowała nierówna walka Gucia z żabami. Nie była to bowiem wielogodzinna bitwa oglądana przez dziesiątki kibiców - w szczytowym momencie obserwatorów było ok. 60 tysięcy. A mówimy o polskim streamerze i "zwykłym graniu w grę". Popularność tego wydarzenia wyszła daleko poza Twitcha i trafiła do firm niezwiązanych z gamingiem, które zaczęły umieszczać nawiązania do żab w swoich postach promocyjnych (tzw. RTM-y, Real-Time Marketing), a nawet przyjmować zakłady bukmacherskie. A to wszystko już podczas pierwszej, tej 22-godzinnej sesji. To wszystko sprawiło, że Gucio stał się bardzo popularny, a podejrzewam, że sam wydawca gry w Polsce również zacierał ręce widząc szał wokół tej sytuacji i nazwą produktu w tle.

Wróćmy jednak do innego aspektu - uporu, z jakim następowały kolejne podejścia do dwóch żabek (wielkości bardzo dużego człowieka). Trwało to wiele godzin, na pewno powodowało frustrację u gracza (aczkolwiek nieprzesłaniającą motywację) i - powiedzmy wprost - nie było to efektywne wykorzystanie czasu. Czy z tym samym nie mierzą się programiści, gdy próbują wykonać szczególnie uciążliwe zadanie? I nie chodzi mi o wymagania funkcjonalne obliczone na wiele godzin, gdyż te z natury rzeczy albo są dzielone na mniejsze partie lub realizowane etapowo. Bardziej mam na myśli pozornie nieskomplikowane funkcje, w których nie umiemy poradzić sobie z drobnym elementem i blokuje to dalsze prace. Lub nie blokuje, ale czujemy, że musimy to skończyć teraz. Może być to umiejscowienie fragmentów na stronie za pomocą CSS-a lub długotrwałe szukanie drobnego błędu w kodzie, który nie wiadomo kiedy się ujawnia. Jako programiści brniemy w to, gdyż wiemy, że nie powinno to zająć dużo czasu, ale zanim się obejrzymy, mija wiele godzin, a efektów brak. Narasta gniew, zniechęcenie i rzadko jest to motywujące, zwłaszcza, że nie ogląda nas 60 tysięcy kibiców, tylko zdenerwowany kierownik projektu oraz klient. Idąc tropem Gucia, mogłoby to przedłużyć się nawet na kolejne dni w biurze, aż w końcu szef by nie wytrzymał i przekazałby to innej osobie lub kazał odpuścić, a programista skończyłby z poczuciem porażki.

Tylko że najczęściej okazuje się, że jeśli dane zadanie odpuścimy, zajmiemy się czymś innym lub - co najlepsze - wyczyścimy głowę odpoczynkiem po pracy, to rozwiązanie znajduje się samo. Czasem jest to nagłe uświadomienie sobie pewnego aspektu języka, o którym zapomnieliśmy. Niekiedy jest to dojrzała zmiana podejścia, np. struktury elementów w HTML-u, przez co łatwiej je ostylować. Kiedy indziej po prostu nowy pomysł na kawałek kodu i generalnie spojrzenie na problem z dystansu. Nie bez powodu, gdy nie możemy sobie przypomnieć, co chcieliśmy powiedzieć, to najlepszą receptą jest zaprzestanie prób i pomyślenie o czymś innym - mózg pracuje "w tle" i jest szansa, że po jakimś czasie uda nam się wpaść na właściwy trop z innej strony.

Oczywiście, trudno porównywać pracę analityczną, jaką stają się szczególnie trudne okresy w programowaniu do działań fizycznych, wymagających zręczności gracza. Tym niemniej, mechanizm pozostaje taki sam - czasem ślepy upór w niczym nie pomaga, a tylko przeszkadza. Warto "oddalić się", spojrzeć na problem z pewnej perspektywy i zastanowić się, czy są inne drogi do osiągnięcia danego celu. Warto zwrócić uwagę, że w przypadku Gucia dochodziła do tego jeszcze kwestia honoru i przede wszystkim "hajpu", jaki wytworzył się w społeczności, a który prawdopodobnie zniknąłby, gdyby gracz zająłby się innymi zadaniami i do żab wrócił po czasie silniejszy. Obserwatorzy byliby zawiedzeni i opuścili transmisję. Programiści taki dylemat mają rzadko i należy to wykorzystać.

Istnieje jeszcze druga, powiązana sprawa - czasem wszystko idzie jak należy, ale programista ciągle nie jest zadowolony ze swojej pracy. W związku z czym szlifuje część systemu, nad którą właśnie pracuje. Jest to tak zwane polerowanie, które w skrajnym przypadku zmienia się w perfekcjonizm. Nie ma w tym niczego złego, gdyż dbanie o jakość należy pochwalać... o ile nie dzieje się to kosztem harmonogramu i innych zadań. Wielokrotnie widziałem bowiem sytuację, w której zadanie przewidziane na np. 10 godzin trwało 30, ale nie dlatego, że był problem z zaimplementowaniem pewnej funkcji, tylko programista "zapomniał się" i testował różne możliwości, aby uzyskać idealny efekt i zapewnić lepszy rozwój w przyszłości. Normalnie byłyby to cechy godne podziwu, ale zawsze trzeba brać pod uwagę kontekst, a więc np.:

  • obłożenie zadań w projekcie,
  • harmonogram oraz terminy,
  • priorytet oraz znaczenie zadania - jeśli to drobna funkcja, która nie ma wielkiego wpływu na środowisko biznesowe lub nie stanowi bazy dla innych funkcji, to warto odpuścić polerowanie.

Dążę do tego, że trzeba znać dwa powiedzenia - "lepsze jest wrogiem dobrego" oraz "trzeba wiedzieć kiedy ze sceny zejść niepokonanym". Może być tak, że w trosce o zadbanie o najmniejszy szczegół zapędzimy się tak, że zmarnujemy 8 godzin na dobranie odpowiedniej ikony lub obsłużenie przypadku, który nigdy nie wystąpi. Oczywiście, jest to bardzo względne - jeśli zadanie jest ważne i rozwojowe, a sam system skomplikowany, to wiadomo, że lepiej wszystko przetestować oraz poprawić różne przypadki lub przeprowadzić autorefaktoryzację. To już kwestia indywidualna i wymagająca zdrowego rozsądku zarówno programisty, jak i kierownika projektu, a być może także po prostu sygnał, że wycena powinna byc wyższa. Tak samo nie mówimy tutaj o sytuacji, kiedy rdzeń zadania jest dużo bardziej pracochłonny niż początkowo zakładano - w takim przypadku albo oszacowanie było błędne, albo część prac można zostawić na później (i np. zapisać sobie w Feedybackym, aby się nie zgubiło). Natomiast warto przyswoić sobie, że przed przystąpieniem do "polerowania" należy zastanowić się, w jakim stopniu jest ono rzeczywiście potrzebne i wykonalne.

Jak widać, można połączyć kulturę streamerską z programowaniem i nawet czegoś się nauczyć. A może nie i ten cały artykuł (setny na tym blogu) jest jedynie bajdurzeniem? Dajcie znać w komentarzach.

Pozdrawiam i dziękuję - Jakub Rojek.

Potrafimy całkiem sporo i co więcej, nasze umiejętności i zasoby są do Twojej dyspozycji. Zerknij na to, co możemy Ci zaoferować.

Komentarze

Wczytywanie komentarzy...

O autorze

Jakub Rojek

Główny programista i współwłaściciel Wilda Software, z wieloletnim doświadczeniem w tworzeniu i rozwoju oprogramowania, ale także w pisaniu tekstów na różnorakich blogach. Zaprawiony w boju analityk i architekt systemów IT. Jednocześnie absolwent Politechniki Poznańskiej i okazjonalny prowadzący zajęcia na tej uczelni. W wolnych chwilach oddaje się graniu w gry wideo (głównie w karcianki), czytaniu książek, oglądaniu futbolu amerykańskiego i e-sportu, odkrywaniu cięższej muzyki oraz wytykaniu innym błędów językowych.

Jakub Rojek