logoskutecznyprogramista.pl

Zacznij dowozićBlog

Buggerpunk 2077 i Problem Dreamlinera

Źródło: CD Projekt Red

Długość wpisu: 7 min

💡 Ważne: Celem tego posta nie jest krytykowanie CDP i Cyberpunka. Każdy, kto ma do czynienia z wytwarzaniem oprogramowania, wie, jakie to jest trudne. Mój umysł nie potrafi pojąć, jak można stworzyć coś tak wielkiego, jak CP2077. Kibicuję programistom CDP, żeby udało im się zachować motywację i zrobić z CP2077 jeszcze lepszą grę niż jest teraz 🤞.

Lata temu Boeing zapowiadał Dreamlinera jako samolot przyszłości, który miał wyznaczać nowe standardy. Okazało się, że głównym standardem, jaki wyznaczał, była ilość usterek spowodowana wprowadzeniem nieużywanych i nieprzetestowanych wcześniej rozwiązań.

Zamiast latać, samolot stał w hangarach i dostawał kolejne poprawki oraz aktualizacje, a Boeing tracił na każdej jednostce nawet kilkadziesiąt milionów dolarów.

Nie wiem, czy wyszli już na plus (chyba nie), ale Boeing ma z tymi samolotami problem nawet teraz.

Eksperci podają wiele czynników, które wpłynęły na taką sytuację, ale ja dzisiaj chciałem napisać tylko o jednym, który fajnie przekłada się na naszą branżę.

Poprzednie samoloty Boeinga były w większym lub mniejszym stopniu kolejnymi iteracjami sprawdzonych rozwiązań. Natomiast Dreamliner został zaprojektowany od początku i jego najważniejsze systemy były czymś zupełnie nowym. Czymś, z czym Boeing wcześniej nie miał doświadczenia.

Przeprojektowali i wymienili wszystkie najważniejsze systemy naraz i gdy potem zaczęli łączyć je ze sobą, to okazało się, że nie działa to tak, jak powinno.

Moi koledzy Bartek i Żółw nazywali to kiedyś Problemem Dreamlinera i pokazali mi, jak to się przekłada na tworzenie oprogramowania.

Buggerpunk 2077

Żeby nie szukać daleko, możemy spojrzeć na Cyberpunka, nasz nowy skarb narodowy, który zabił konsole poprzedniej generacji schodząc do zawrotnych 15 klatek na sekundę przy rozdzielczości 720p w stresowych sytuacjach. 3 klatki mniej i osiągnąłby poziom dwuwymiarowych animacji Disneya.

Niektórym to nie przeszkadza, ale ja wiem, że przy tylu klatkach na sekundę celować nie potrafię i pewnie rzucałbym padem o ścianę.

Jak pewnie większość graczy, wierzę, że CDP naprawi problemy związane z wydajnością i grafiką. Mocno nadszarpnęli swój kredyt zaufania, bo nie pokazali (zataili?) przed premierą, jak gra zachowuje się na konsolach, ale Wieśkiem udowodnili, że potrafią dbać o graczy, naprawić każdą usterkę, a potem przekroczyć nasze oczekiwania. Pewnie w ramach rekompensaty znajdą nawet sposób, żeby zrobić port na Switcha.

Nie jestem jednak przekonany, czy uda im się poprawić największy problem tej gry: słabe AI i bezduszność NPCów, a przy tym całego Night City.

Te problemy są w moich oczach typowym przykładem Problemu Dreamlinera. Mogłoby się wydawać, że to jest po prostu kolejny RPG, po udanym Wiedźminie 3. Jednak tak naprawdę przeprojektowali i wymienili wszystkie najważniejsze systemy naraz, przez co nie udało im się odpicować wszystkiego tak, jak byśmy się spodziewali.

Świat fantasy wymienili na świat SF, małą liczbę NPC zamienili na olbrzymią liczbę NPC, zamiast koni wrzucili ruch drogowy i samochody (których też jest znacznie więcej niż koni), miecze zastąpili strzelaniem, hakowaniem i walką wręcz, tryb trzecioosobowy zastąpili pierwszoosobowym, miasta można eksplorować wertykalnie… itd. Można by jeszcze trochę wymieniać.

Poza tym wszystkim postanowili jeszcze, że zrobią turbo zaawansowaną graficznie grę, która będzie działać na 7 różnych konsolach i niezliczonej konfiguracji pecetów.

Wprowadzili zbyt dużo nowych rzeczy naraz i przy łączeniu wszystkiego ze sobą, gra ich po prostu przerosła. Przy tak wielkiej skali zmian, ponad miliard złotych budżetu i nadgodziny programistów tym razem nie wystarczyły, żeby dopracować wszystkie mechaniki w grze.

I teraz, podobnie jak Dreamliner, który zamiast latać, był uziemiony i ciągle naprawiany, tak Buggerpunk jest dla wielu graczy uziemiony i będzie długo naprawiany. Wiele problemów, ze względu na skalę i rozmiar zmian w porównaniu do Wiedźmina 3, nie będzie rozwiązanych nigdy, albo będziemy bardzo długo czekać na poprawki.

Jak to robią inni?

Dla niektórych będzie to może porównanie trochę z czapy, ale skonfrontujmy Cyberpunka z grami Rockstara.

Każda kolejna odsłona GTA, to kolejna iteracja dokładnie tego samego - gry o gangsterach w mieście. Nawet Red Dead Redemption, mimo zmiany samochodów i miast na konie i pola, są tak naprawdę grami o gangsterach, tylko tym razem na dzikim zachodzie. Widać, że w każdej z tych gier zastosowali pod spodem te same mechaniki.

Rockstar nie wymienia wszystkiego naraz, Rockstar poprawia, szlifuje oraz iteruje.

Cykl wydawniczy też jest zupełnie inny: w 2013 GTA 5 wydali na PS3 i x360, w 2014 na PS4 i Xbox One, w 2015 na PC i w przyszłym roku będzie wersja na PS5 i Series X/S.

Rockstar dał sobie rok (!) na wypuszczenie gry na kolejną generację konsol i jeszcze trochę więcej na wypuszczenie wersji na PC. To samo było z RDR2.

Efekt? GTA 5 miało problemy i bugi, jak każda gra, ale z tego, co pamiętam, obyło się bez dramatów obecnych przy Cyberpunku. Gra została okrzykniętą jedną z najlepszych gier na każdej generacji konsol i jest to najlepiej sprzedająca się gra wszechczasów (poza Minecraftem).

Co mi to wszystko daje?

Po pierwsze: gdy widzę, że firma pakuje się w Problem Dreamlinera to wiem, żeby nie kupować preorderów :).

Poza tym wprowadziłem w życie jedną z moich najważniejszych zasad: nie rób i nie wymieniaj wszystkiego naraz.

Stosuję tę zasadę do wszystkiego:

  • nie wprowadzam zbyt wielu zmian w kodzie naraz
  • nie refactoruję wszystkiego naraz
  • nie komituje wszystkiego naraz
  • nie releasuje wszystkiego naraz
  • nie próbuję nauczyć się wszystkiego naraz
  • nie próbuję robić w pracy wszystkiego naraz
  • nie wprowadzam wielu nawyków naraz
  • nie czytam zbyt wielu książek naraz

Zamiast tego stosuję zasadę skauta, inkrementalny refactoring, robię kiebłaskę, buduję chodzące szkielety, rozbijam zadania na mniejsze, robię mniejsze releasy i mniejsze iteracje.

Staram się zidentyfikować jedną najważniejszą rzecz, która sprawi, że wszystkie inne będą prostsze lub niepotrzebne zgodnie z tym, co opisał Gary Keller w książce The One Thing.

What’s the ONE Thing you can do, such that by doing it, everything else will be easier or unnecessary?

Przez ostatnie 7 lat pracy, większość klientów, z którymi współpracowałem, próbowała działać w ten sam sposób: żeby szybciej dowieźć aplikację na produkcję, dorzucali do zespołu kolejne osoby. W najbardziej klasyczny sposób twierdzili, że 9 kobiet urodzi dziecko w miesiąc.

Jednym z najczęstszych argumentów było “ale przecież to jest w innej, odrębnej części systemu, więc można to robić równolegle”. Na początku kupowałem ten argument, bo brzmi sensownie.

Jednak koniec końców zawsze trzeba te odrębne części połączyć ze sobą. I niestety dzieje się to najczęściej na ostatnią chwilę, przed samym releasem i w momencie, gdy każdy programista jest zajęty problemami z własnymi zadaniami.

Wtedy każde oderwanie się od swojego taska, żeby zintegrować swój kod z kodem, który człowiek widzi pierwszy raz na oczy, to olbrzymi wysiłek mentalny, który bardzo często prowadzi do kolejnych bugów, opóźnień i olbrzymich niedopatrzeń. Brzmi znajomo. #buggerpunk

Najbardziej bezproblemowe projekty, w których biorę udział to te, w których klienci nie próbowali zarzucać problemu kolejnymi programistami, tylko ustalali priorytety i mieli jasno zdefiniowany zakres MVP, który potem stopniowo ulepszaliśmy.

Niestety programiści stosują podobne zagrywki.

Przykladowo: zamiast inkrementalnie wprowadzać małe zmiany, robić mniejsze pull requesty, które da się przeczytać w 10 minut, a nie 2 godziny i mergować zmiany w małych porcjach, robią jeden wielki PR, którego code review zajmuje kilka godzin, poprawki trwają nawet kilka dni, a zmergowanie do głównego brancha w efekcie rozciąga się czasem nawet na kilka tygodni, stopniowo zabijając zapał nawet najbardziej zapalonych programistów.

W takich sytuacjach najsmutniejszy jest widok autora tych wielkich zmian. Dostaje kilkadziesiąt komentarzy na CR, które potem naprawia długie godziny, czasem, gdy ma szczęście, to okazuje się, że musi większość kodu przepisać, bo nie o to chodziło i w efekcie pozbawia sam siebie przyjemności płynącej z dowożenia zadania. A to jest jeden z najważniejszych elementów produktywności, który pozwala utrzymać motywację i oszczędzać sanity pointy i WTFy, tak bardzo potrzebne w naszej pracy.

Zdaję sobie sprawę, że w niektórych projektach, zwłaszcza legacy, wprowadzanie małych zmian jest tricky as hell, ale zawsze warto próbować i widzę, że zbyt rzadko to robimy.

Podsumowując

Problem Dreamlinera występuje wtedy, gdy próbujemy wprowadzić zbyt wiele zmian w tym samym czasie. Prowadzi to do opóźnień, nieprzewidzianych bugów oraz utraty znacznej ilości naszych sanity pointów, bo musimy ogarnąć bardzo szeroki kontekst zmian.

Żeby obejść ten problem, staram się nie wprowadzać zbyt wielu zmian naraz, zmniejszyć ilość rzeczy, które w tym samym czasie biorę sobie na głowę. Dotyczy to programowania, pracy, nauki nowych rzeczy i ogólnie życia.

Dobrze działa rozbijanie zadań na mniejsze części, ustalenie kolejnego priorytetu i wprowadzanie zmian stopniowo, bo dowożenie zadań to chyba najlepszy sposób na podbicie motywacji i produktywności.

Brzmi to, jak coś oczywistego, jednak nawet takim mistrzom jak CD Projekt Red zdarza się o tym zapomnieć.

No i na koniec: nie wiem jak z Cyberpunkiem było na prawdę, ale widzę pewne analogie i swoje sposoby zapobiegania takim problemom, które bardzo dobrze działają. Dlatego polecam 👍.

🖖

Podziel się:

Zapisz się do newslettera, aby otrzymywać powiadomienia o nowych wpisach.

Wyślę Ci również dokument, dzięki któremu zaczniesz szybciej dowozić taski 💪.

Zapisz mnie

Cześć! Jestem Krzysztof. Dokumentuję swoją drogę w IT i pokazuję, jak wdrażam nawyki, narzędzia i taktyki skutecznych programistów.


Instagram, Twitter, YouTube, Facebook, LinkedIn