Sterowanie bohaterem — feedback na temat przyciskologii

Pracuję obecnie nad rozkładem funkcji na kontrolerze oraz klawiaturze (i myszy). Funkcji w grze będzie trochę, ale one wszystkie muszą po pierwsze zmieścić się na standardowym kontrolerze (np. PS czy XBox) oraz ich użytkowanie musi być wygodne. Żeby zobrazować czym będzie się sterowało, można zobaczyć na The Legend of Zelda: ALttP — będzie podobna mechanika, tyle że znacznie bardziej zaawansowana.

Wstępny układ funkcji na kontrolerze wygląda w ten sposób:

Najważniejsze jest samo chodzenie — domyślnie lewy analog. Gra docelowo będzie posiadać trzy prędkości — zgodnie z prędkością będzie to skradanie się, chodzenie oraz bieganie. Domyślny ruch to chodzenie, natomiast skradanie się oraz bieganie będą funkcjami sytuacyjnymi, rzadziej używanymi (ew. bieganie do speedrunów). Domyślnie lewa gałka będzie działać tak, że lekkie wychylenie będzie oznaczało skradanie się, a mocniejsze (np. od 75% wychylenia) będzie oznaczało chodzenie. Aby biec, trzeba będzie wychylić mocniej gałę i trzymać przycisk run.

Oczywiście to jest schemat domyślny, ale pewne funkcje będzie można rozdzielić lub użyć inaczej. Np. skradanie się będzie można wydzielić na cały D-Pad, lewą gałką obsługiwać wyłącznie chodzenie, a bieganie mieć jako połączenie chodzenia + przycisk run. Alternatywą (z myślą o klawiaturze) będzie chodzenie WASD, skradanie się oraz bieg jako połączenie chodzenia + trzymanie przycisku. Inną alternatywą będzie bieganie dostępne pod D-Pad/WASD dzięki kilkukrotnemu wciśnięciu danego kierunku w krótkim odstępie czasu (pomysł zaczerpnięty z gry Kunio-Kun no Nekketsu Soccer League) — dla ograniczenia liczby przycisków.

Chodzenie/skaranie będzie powiązane z funkcją strafe, dostępną domyślnie pod dodatkowym przyciskiem. Trzymając przycisk strafe, będzie można poruszać się w dowolnym kierunku, jednocześnie nie zmieniając orientacji bohatera (przydatne podczas walki). W razie czego, funkncję strafe (tak jak i skradania) będzie można w całości umieścić na D-Padzie — dzięki temu gałka będzie mogła być używana do chodzenia/skarania, a D-Pad wyłącznie do ”strafeowania”.

Funkcja ruchu będzie posiadała jeszcze inne funkcje sytuacyjne. Mając jakiś długi przedmiot do atakowania (np. patyk, łom itp.), będzie można trzymać przycisk ataku (nazwany na schemacie use) i zataczać koła analogiem/D-Padem, aby wirując atakować wszystko dookoła. Natomiast ruch w połączeniu z przyciskiem dodge pozwoli wykonać unik, czyli szybki skok z przewrotem (à la ”dive”).

Grając na D-Padzie/WASD, dostępne będzie 8 podstawowych kierunków, a przy użyciu gałki, ruch będzie odpowiadał kątowi wychylenia gałki (sprajty będą nadal dla 8 kierunków).

Do ataku i skoku skorzystam z typowego układu, czyli przycisków Y i B, a obok przyciski do podnoszenia i odkładania obiektów. Funkcja grab będzie umożliwiać chwytanie większych obiektów w celu ich ciągnięcia, pchania lub przesuwania w dowolnym kierunku (w zależności od wielkości/wagi obiektu).

Co sądzicie o takim sterowaniu, biorąc pod uwagę docelowy gatunek gry oraz układ funkcji na kontrolerze?

W teorii wydaje się, że sterowanie będzie choletnie skomplikowane, jednak to tylko pozory — w mojej opinii, czyli kogoś z drewnianymi rękami do gier. Poza tym, niektóre funkcje będzie można zastąpić prostszym odpowiednikiem — np. bieganie za pomocą kilkukrotnego tappowania, czy skradanie się w formie rzadkich i krótkotrwałych wciśnięć przycisków ruchu, dzięki czemu wszystkie trzy prędkości poruszania się będzie można obsłużyć D-Padem/WASD (tak jak we wspomnianym Nekketsu Soccer League). Podczas walki będzie można nie używać strafe i dodge — jeśli ktoś nie będzie potrzebował, nie będzie ogarniał większej liczby przycisków lub nie będzie miał na tyle przycisków w kontrolerze. Natomiast funkcje pick i grab będzie można połączyć i umieścić w jednym przycisku, dzięki czemu dobór funkcji będzie sytuacyjny (jak w ww. Zeldzie).

W ten sposób zminimalizuje się liczbę potrzebnych przycisków o połowę, co nie dość że pozwoli grać na kontrolerze posiadającym mało przycisków (np. repliki kontrolerów od starych konsol), to również pozwoli użyć mniejszej liczby klawiszy, jeśli ktoś będzie wolał grać na klawiaturze.

use musisz zamienc z L2 miejscami bo wlasnie gralem w twoja gre w wyobrazni i wyczailem ze jak bede mial patyk i bede musial tzrymac ten guzik use (Y) to bede musial lewym analogiem krecic zeby ruszaxc tym patykiem , ale lewy analog mi bedzie krecil postacia, wiec prawym analogie nie pokrece bo kciuka mam na guziku. takze z d**y. dlatego musisz zrobic tak zeby trzymac L2 jako use, lewym analogiem ide postacia w kierunku celu a prawym obracam kamera.

Czy grab i pick nie można scalić?

furious programming napisał(a):

Chodzenie/skaranie będzie powiązane z funkcją strafe, dostępną domyślnie pod dodatkowym przyciskiem. Trzymając przycisk strafe, będzie można poruszać się w dowolnym kierunku, jednocześnie nie zmieniając orientacji bohatera (przydatne podczas walki). W razie czego, funkncję strafe (tak jak i skradania) będzie można w całości umieścić na D-Padzie — dzięki temu gałka będzie mogła być używana do chodzenia/skarania, a D-Pad wyłącznie do ”strafeowania”.

Zobacz sobie grę Rustler:

Nie wiem jak się gra kontrolerem, ale klawiaturą chodzisz sobie w dowolnym kierunku WASD, a myszką masz celownik wskazujący w którą stronę patrzy postać.

https://strategywiki.org/wiki/Resident_Evil_2/Controls
https://strategywiki.org/wiki/Resident_Evil_3:_Nemesis/Controls
Może jeśli chodzi o chodzenie, to niezbyt chlubny przykład (tank controls), ale reszta przycisków (kolumna PlayStation) może służyć za inspirację ;)

chomikowski napisał(a):

use musisz zamienc z L2 miejscami bo wlasnie gralem w twoja gre w wyobrazni i wyczailem ze jak bede mial patyk i bede musial tzrymac ten guzik use (Y) to bede musial lewym analogiem krecic zeby ruszaxc tym patykiem , ale lewy analog mi bedzie krecil postacia […]

O to właśnie chodzi — o kręcenie się postaci wokół własnej osi, z wyprostowanym ”patykiem”. Przycisk use musi być jako Y, dlatego że do niego będzie przypisana najważniejsza funkcja. Zwykle jest nią strzał lub najważniejszy atak. Podobna sytuacja ma miejsce w przypadku skoku — też standardem jest przycisk B, bo jest na przegubie kciuka.

Ja ją nazwałem use, bo będzie pozwalać na użycie aktywnego przedmiotu — niektóre będą bronią białą do uderzania, niektóre małymi przedmiotami do rzucania, niektóre pozwolą na strzelanie (np. proca), a niektóre nie będą służyć do ataku, a do ”zaaplikowania” bohaterowi (np. napój do wypicia, jedzonko do zjedzenia, kubeł do nakrycia się w celu schowania się itp.).

Ale od razu zaznaczam, że gracz będzie miał możliwość dowolnego zmapowania przycisków (z poziomu ustawień gry), więc jeśli ktoś będzie chciał mieć atak pod L2, to będzie mógł go sobie tam ustawić.

Spine napisał(a):

Czy grab i pick nie można scalić?

Można — będzie możliwość przypisania obu funkcji do jednego przycisku (pisałem o tym). Problem z tym jest jednak taki, że gra będzie musiała zgadywać co chce gracz zrobić, a więc te funkcje będą ograniczone (czyli mogą irytować). Bo co jeśli podejdę do stołu, na którym leży jakiś przedmiot i wykonam grab oraz pick jednocześnie? Czy bohater ma złapać za stół w celu jego przesunięcia, czy podnieść przedmiot? Jak silnik ma taką sytuację rozstrzygnąć?

Na razie jestem na etapie pisania kodu inputu, więc się nie pali — ale problem nie zniknie. Wstępnie pomysł jest taki, aby ustalić priorytety i wykonać najpierw najmniej ”szkodzącą” czynność. Do tego zapamiętać ostatnio wykonaną akcję dla danej pozycji gracza, tak aby ponowne jej wykonanie oznaczało wykonanie innej funkcji, zamiast drugi raz tej samej. Kolejne wciśnięcie to wykonanie tej pierwszej itd, itd. Ale to tylko w przypadku konfliktu tych dwóch funkcji.

Nie zauważyłem tekstu pod filmem.

Spine napisał(a):

Nie wiem jak się gra kontrolerem, ale klawiaturą chodzisz sobie w dowolnym kierunku WASD, a myszką masz celownik wskazujący w którą stronę patrzy postać.

Wszystko fajnie, tylko że to nie będzie point-and-click, kursor nie będzie widoczny podczas grania. Poza tym będą trzy prędkości ruchu, co też nieco skomplikuje sterowanie, jeśli chodzi o klawiaturę+mysz. Bo mogę zrobić tak, że ruchem myszy będzie się wybierało kierunek ruchu, a jednym z trzech klawiszy jego prędkość. I o ile nie problem ograniczyć ruch kursora do niewidzialnego koła (tak aby podczas gry nie wyjeżdżać kursorem poza okno) i to wszystko ładnie zaimplementować, o tyle nie będzie się dało chodzić do tyłu i strafe'ować, a więc to trochę bez sensu. Tzn. będzie się dało, ale nie będzie to intuicyjne (przynajmniej w teorii).

Tak więc mysz będzie stanowić coś na kształt gamepada, po prostu jako zestaw przycisków. Natomiast po pokazaniu menu gry lub zasobnika z przedmiotami, myszą będzie można je obsługiwać, co będzie wygodne. Ale to jeszcze się zobaczy, bo kursor nie może być widoczny — grając we dwoje na jednym ekranie (bez split-screena), machanie kursorem po ekranie będzie przeszkadzać drugiemu graczowi. Ta gra ma być przeznaczona głównie do gry kontrolerem, a klawiatura i mysz tylko dla tych, którzy nie mają kontrolera lub nie mają takiego z odpowiednią liczbą przycisków i osi.

Zrob ludzika i pokaz jak nim sterujesz to bedzie ci latwiej wtedy dodawac kontrolery jak tak zrobilem w swoim. najpierw sprajt z ludzikiem i potem sterowanie, zwlanianie czasu itd. bo tak na sucho to lipa. zrob takie cos daj builda i my ci przetestujemy

To nie takie proste — kolejność musi być sensowna, a na pisanie osobnego prototypu na razie nie ma czasu. Żeby zrobić takie demko, musiałbym mieć podstawy silnika, ale żeby mieć silnik, muszę mieć zaprogramowany input. No a pisząc kod mapowania urządzeń inputu do przycisków i graczy, muszę sobie najpierw jakieś menu napisać. No a żeby mieć menu, najpierw muszę system kontrolek zrobić (à la LCL).

Pytam o to z dwóch powodów. Po pierwsze, teraz piszę kod mapowania inputu (gracze, urządzenia i przyciski), a żeby mieć wysokopoziomowe funkcje do testowania inputu, muszę najpierw wiedzieć jak on ma działać i jakie możliwości ma dawać. Po drugie, nie jestem graczem, a wielu z was ma bogate doświadczenie związane z graniem w konkretne tytuły, więc dobrze jest o feedback poprosić.

To co obecnie ustaliłem to efekt własnych doświadczeń oraz tego co zaobserwowałem oglądająć materiały na temat różnych gier. Wydaje się to logiczne i zgodne ze sterowaniem obowiązującym w innych (w tym w dużych) grach, ale że funkcji ma być sporo, to zawsze fajnie dopytać. Jak się nie ma jeszcze prototypu, to pozostaje tylko wyobraźnia. ;)