Ta postać w Baldur's Gate 3 pokazuje się z zupełnie innej strony, po zastosowaniu konkretnej zmiany

Gracze zwrócili uwagę na ciekawą zależność.

W Baldur's Gate 3 Karlach to charakterystyczna postać grywalna, która po raz pierwszy pokazuje swój berserkerski szał podczas misji rekrutacyjnej. W akcie pierwszym, po zabiciu wszystkich mnichów w rogatkach, Tiefling nie potrafi kontrolować emocji, rycząc i szalejąc jak prawdziwy barbarzyńca. Okazuje się jednak, że jej reakcja wygląda zupełnie inaczej, jeśli wcześniej przemieni się ją w mniszkę.

Karlach niczym Bruce Lee w Baldur’s Gate 3

Zmiana podklas postaci w grze pozwala nie tylko wzmocnić drużynę, ale też odblokowuje nowe dialogi i interakcje. Jeśli Karlach zostanie mniszką – czy to za pomocą moda, czy specjalnych narzędzi w grze – jej reakcja w rogatkach odzwierciedla tę przemianę. Zamiast ognistej furii... rozwala meble siłą własnych pięści. To daje zupełnie inne wrażenia wizualne i dźwiękowe.

Użytkownik Reddita SkeletonChurch podkreśla, że zmiana klasy Karlach wprowadza unikalną dynamikę do sceny. Nie jest pewien, czy efekt wynika z jej nowej klasy, czy z braku broni, ale przypuszcza, że chodzi o samą klasę.

GramTV przedstawia:

Zamiast ryczeć wściekle, krzyczy HIIIIIIIIIIIIYA niczym Miss Piggy, niszcząc pobór opłat, i to jest wspaniałe.

Eksperymentowanie z klasami w Baldur's Gate 3 staje się coraz popularniejsze – gracze zmieniają np. Lae’zel w barda i cieszą się nietypowymi dialogami. Pojawiają się też pomysły na Astariona jako barbarzyńcę czy Mintharę jako bardkę. To pokazuje, że nawet dobrze znane sceny mogą wyglądać zupełnie inaczej, gdy postacie przyjmują nowe ścieżki i style walki.

Jakub Piwoński

Dziennikarz filmowy z otwartym podejściem do kina i popkultury. Science fiction w każdej postaci przeplata seansami klasyki. Gdy akurat nie gra w Diablo 4, nie pogardzi dobrym komiksem i książką.

Komentarze

koNraDM4

Gramowicz

30/12/2025 04:37

Yarod napisał:
bo z sensem, po developersku ;)
Ogólnie tez bym tak do tego podszedł kodując mechaniki - nigdy nie lubiłem sztywnego podejścia, typu "zakoduj coś i cześć", choć też nigdy, jeszcze jako dev nie robiłem w gamedevie, a i moje dni developerskie dobiegły już końca.
Mnie jednak zastanawia coś innego - jak projektując tego typu rozwiązanie podejść do granic? gracze podobnie jak kiedyś moi użytkownicy słyną z "fantazji" - sam wiesz jako dev :) zauważ że jednak kilka sytuacji zakodowali/ujęli - te zmiany zachowania vs klasy da się ogarnąć mechaniką klasy ale dialogi? no i sławne na yt sytuacje gdzie idzie dialog a tam z tyłu trwa rzeź - vide F4?
Ciekawy temat, który budzi mojego martwego już deva, ale tylko na chwilę ;)

Z dialogami to jest ciekawa sprawa bo sama Bethesda kiedyś nie miała tego problemu - jak zaczynałeś gadać to czas się zatrzymywał np. w takim Oblivionie, a kamera najeżdżała centralnie na postać. Jednak prawdopodobnie dla swego rodzaju filmowości zrezygnowano z takiego umieszczenia kamery oraz zatrzymywania czasu, dialogi w F4 mają więcej z cutscenek niż odrębnej mechaniki dlatego wszystko w tle dalej jest obliczane. Co więcej główny bohater ma w końcu głos oraz mimikę twarzy więc to może być kolejny powód. W Starfield nie grałem ale z tego co wiem Bethesda uznała, że F4 było błędem pod tym względem więc zgaduję że Starfield powrócił do tego co było wcześniej i znowu jest niemy bohater bez charakteru więc może i czas znowu się zatrzymuje ale tego nie wiem bo nawet nie sprawdzałem szczególnie materiałów z gry.

W GTA V też normalnie wszystko w tle się dzieje pomimo, że gra daje złudzenie iż to prerenderowana cutscenka:

https://www.youtube.com/watch?v=2eaG7MVaqD8

Jest tego dużo więcej ale wolałbym nie sypać tu za dużo linkami :D

Yarod

Gramowicz

30/12/2025 00:12

dariuszp napisał:
Dzięki za pamięć! Ta moja gadatliwość czasem na coś się przydaje :-)
Dodam że to podejście też mocno eliminuje błędy z gier. Zamiast programować szereg etapów które musisz spełnić by wykonać zadanie, programujesz jeden. Musisz mieć w swoim posiadaniu przedmiot. I tyle. Jeżeli NPC posiada ten przedmiot albo wchodzi z nim w interakcje musisz mieć reakcję kiedy przedmiot jest lub go nie ma. Jeżeli w grze można przedmioty niszczyć to też potrzebna jest reakcja na to że przedmiot jest zniszczony. Tyle.
I każdy quest po prostu działa. Kładziesz przedmiot. Robisz zadanie w którym trzeba go zdobyć. I tyle. Potem możesz budować na około tego przedmiotu cały zamek ze strażnikami, dialogami i co tylko chcesz.
Ale dla questu nie ma znaczenia czy przechytrzyłeś strażnika i Cię wpuścił. Czy się przekradłeś. Czy może zebrałeś wszystkie skrzynki by zbudować wieżę po której przekradłeś się na mur zamku. Bo na koniec dnia wszystko po drodze nie ma znaczenia.
Wiele gier popełnia ten błąd że programują po drodze wszystkie etapy. Np. interakcja z przedmiotem aktywuje się dopiero jak przejdziesz przez drzwi zamku. Więc jak ktoś się dostanie inną nieprzewidzianą metodą to quest się psuje.
Jedyny problem do rozwiązania to nagrody. Projektowanie gry w ten sposób jest fajne ale nie chcesz żeby gracz sobie strzelił w stopę. Bo mogłeś zaplanować progress na to że jednak przejdzie przez wszystkie przeszkody po drodze tak by mieć w dalszym etapie gry odpowiedni XP i fundusze. I gracz może autentycznie to pominąć.
Dlatego warto by to wykonanie questa dawało wystarczająco XP i funduszy na kolejne etapy gry a cała reszta powinna być "ekstra". Plus gra zawsze powinna mieć mechaniki które pozwalają dorobić się funduszy czy XP jeżeli trzeba. Nawet jeżeli zaparty gracz może to wykorzystać by grindować ponad sensowny poziom.
Ewentualnie można na różnych etapach gry ograniczać ten grind. Tzn odblokować te akcje ale tylko do momentu uzyskania jakiegoś konkretnego poziomu.
Yarod napisał:
To tylko pokazuje skale tej produkcji ale też systemowość podejścia do mechanik o których wspominal kiedys w innym wątku @dariuszp

bo z sensem, po developersku ;)

Ogólnie tez bym tak do tego podszedł kodując mechaniki - nigdy nie lubiłem sztywnego podejścia, typu "zakoduj coś i cześć", choć też nigdy, jeszcze jako dev nie robiłem w gamedevie, a i moje dni developerskie dobiegły już końca.

Mnie jednak zastanawia coś innego - jak projektując tego typu rozwiązanie podejść do granic? gracze podobnie jak kiedyś moi użytkownicy słyną z "fantazji" - sam wiesz jako dev :) zauważ że jednak kilka sytuacji zakodowali/ujęli - te zmiany zachowania vs klasy da się ogarnąć mechaniką klasy ale dialogi? no i sławne na yt sytuacje gdzie idzie dialog a tam z tyłu trwa rzeź - vide F4?

Ciekawy temat, który budzi mojego martwego już deva, ale tylko na chwilę ;)

dariuszp

Gramowicz

29/12/2025 23:04

Yarod napisał:
To tylko pokazuje skale tej produkcji ale też systemowość podejścia do mechanik o których wspominal kiedys w innym wątku @dariuszp

Dzięki za pamięć! Ta moja gadatliwość czasem na coś się przydaje :-)

Dodam że to podejście też mocno eliminuje błędy z gier. Zamiast programować szereg etapów które musisz spełnić by wykonać zadanie, programujesz jeden. Musisz mieć w swoim posiadaniu przedmiot. I tyle. Jeżeli NPC posiada ten przedmiot albo wchodzi z nim w interakcje musisz mieć reakcję kiedy przedmiot jest lub go nie ma. Jeżeli w grze można przedmioty niszczyć to też potrzebna jest reakcja na to że przedmiot jest zniszczony. Tyle.

I każdy quest po prostu działa. Kładziesz przedmiot. Robisz zadanie w którym trzeba go zdobyć. I tyle. Potem możesz budować na około tego przedmiotu cały zamek ze strażnikami, dialogami i co tylko chcesz.

Ale dla questu nie ma znaczenia czy przechytrzyłeś strażnika i Cię wpuścił. Czy się przekradłeś. Czy może zebrałeś wszystkie skrzynki by zbudować wieżę po której przekradłeś się na mur zamku. Bo na koniec dnia wszystko po drodze nie ma znaczenia.

Wiele gier popełnia ten błąd że programują po drodze wszystkie etapy. Np. interakcja z przedmiotem aktywuje się dopiero jak przejdziesz przez drzwi zamku. Więc jak ktoś się dostanie inną nieprzewidzianą metodą to quest się psuje.

Jedyny problem do rozwiązania to nagrody. Projektowanie gry w ten sposób jest fajne ale nie chcesz żeby gracz sobie strzelił w stopę. Bo mogłeś zaplanować progress na to że jednak przejdzie przez wszystkie przeszkody po drodze tak by mieć w dalszym etapie gry odpowiedni XP i fundusze. I gracz może autentycznie to pominąć.

Dlatego warto by to wykonanie questa dawało wystarczająco XP i funduszy na kolejne etapy gry a cała reszta powinna być "ekstra". Plus gra zawsze powinna mieć mechaniki które pozwalają dorobić się funduszy czy XP jeżeli trzeba. Nawet jeżeli zaparty gracz może to wykorzystać by grindować ponad sensowny poziom.

Ewentualnie można na różnych etapach gry ograniczać ten grind. Tzn odblokować te akcje ale tylko do momentu uzyskania jakiegoś konkretnego poziomu.

Trwa Wczytywanie