Zapobiegaj nadsterownej katastrofie w grach wyścigowych

Podczas gry w GTA III na Androida zauważyłem coś, co denerwuje mnie w prawie każdej grze wyścigowej, w którą grałem (może oprócz Mario Kart): jazda na wprost jest łatwa, ale zakręty są naprawdę trudne. Kiedy zmieniam pas lub mijam kogoś, samochód zaczyna się kręcić w przód iw tył, a każda próba jego poprawienia tylko gorzej. Jedyne, co mogę zrobić, to nacisnąć hamulce. Myślę, że to jakaś nadsterowność.

To, co sprawia, że ​​jest tak irytujące, to fakt, że nigdy nie zdarza mi się to w prawdziwym życiu (dzięki Bogu :-)), więc 90% gier z pojazdami w środku wydaje mi się nierealne (pomimo prawdopodobnie bardzo dobrych silników fizyki). Rozmawiałem o tym z kilkoma osobami i wydaje się, że albo „dostajesz” gry wyścigowe, albo nie. Z dużą ilością praktyki udało mi się uzyskać pół-dobre wyniki w niektórych grach (np. Z serii Need for Speed), jeżdżąc bardzo ostrożnie, dużo hamując (i zwykle skurcz w palcach).

Co możesz zrobić jako twórca gier, aby zapobiec katastrofie nadsterownego rezonansu i sprawić, by jazda była przyjemna? (W zwykłej grze wyścigowej, która nie dąży do 100% realistycznej fizyki)

Zastanawiam się także, jakie gry, takie jak Super Mario Kart, robią inaczej, aby nie miały aż tak nadsterowności?

Wydaje mi się, że jednym problemem jest to, że jeśli grasz na klawiaturze lub ekranie dotykowym (ale nie na kołach i pedałach), masz tylko wejście cyfrowe: naciśnięty lub nie gaz, kierowanie w lewo / prawo lub nie, i znacznie trudniej jest odpowiednio sterować podana prędkość. Drugą rzeczą jest to, że prawdopodobnie nie masz dobrego wyczucia prędkości i jeździsz znacznie szybciej niż (bezpiecznie) w rzeczywistości. Z góry mojej głowy jednym z rozwiązań może być zmiana reakcji kierowania w zależności od prędkości.

Jednym z rozwiązań byłoby trochę oszukać i zgadnąć, co gracz chce zrobić. Gdy gracz znajduje się na prostej linii i naciska w lewo, możesz założyć, że chce zmienić pas. Kiedy jest już blisko zakrętu lub skrzyżowania, z pewnością chce się skręcić. Gracz nie jest w stanie kontrolować jego dokładnego kąta skrętu na zakręcie, więc możesz zdecydować, czy dać graczowi wątpliwości, i zawsze pozwalaj mu przejeżdżać przez zakręty pod idealnym kątem, kiedy naciska przycisk skrętu w odpowiednim momencie (tak długo jak to fizycznie możliwe - każdy gracz, który próbuje jechać zakrętem o prędkości 200 km / h, zasługuje na karę krótkiego lotu nad trawą).

To oczywiście może być trudne, gdy gracz naprawdę chce zawrócić na prostym odcinku lub faktycznie chce zmienić pas ruchu tuż przed skrzyżowaniem.

Innym rozwiązaniem byłaby różnica między stukaniem w klawisz a trzymaniem go. Im dłużej gracz trzyma klucz, tym większy kąt obrotu. Nie wydaje się to nawet nierealne, ponieważ mając kierownicę, potrzebujesz czasu, aby obrócić ją do końca.

Edycja: Na ekranie dotykowym można użyć suwaków zamiast przycisków do kontrolowania sterowania i prędkości w analogiczny sposób. Gdy ekran jest wrażliwy na nacisk, możesz również zinterpretować nacisk (ale dać wizualną informację zwrotną na temat maksymalnego nacisku lub nadgorliwi gracze mogą zepsuć swoje wyświetlacze). Gdy urządzenie ma czujniki orientacji, można użyć przechylania urządzenia do sterowania kierowaniem.

Natknąłem się na to (stare) pytanie, badając, co zaimplementowały inne gry niż Grand Theft Auto IV i V, ale mam przyzwoitą odpowiedź, aby osiągnąć kontrolowaną nadsterowność. Mam tylko pewne doświadczenie w manipulowaniu modelem jazdy w Grand Theft Auto V, ale te informacje powinny dotyczyć większości nieco bardziej realistycznych modeli jazdy.

Wydaje się, że w większości gier samochodowych zdarzenie sterujące samochodu jest bezpośrednio powiązane z danymi wejściowymi gracza - nawet jeśli zastosowano jakieś (tymczasowe) wygładzenie. Powoduje to uczucie powolności lub szarpnięcia - a samochód nie koryguje się po zwolnieniu elementów sterujących. Jest to przeciwieństwo prawdziwego samochodu, w którym samochód ma tendencję do centrowania się po zwolnieniu siły na kole. Niektóre gry próbują to naprawić, zmieniając model obsługi lub posiadając modele obsługi zręcznościowej.

W Grand Theft Auto V można zaobserwować, że dane sterujące użytkownika nie są bezpośrednio powiązane z danymi wyjściowymi sterującymi. Pojazd kieruje się sam, w kierunku obecnego wektora prędkości. Jest to widoczne podczas wymuszania lekkiej nadsterowności i obserwowania kierowanych kół - bez żadnego wkładu same kontrują. Wszelkie dane wprowadzone przez użytkownika są następnie dodawane do tych „naturalnych” poprawek.

Minusem tego podejścia jest jednak to, że samochód jest zbyt lepki i nieco uparty, aby dostać się do lawiny lub driftu - więc tę wartość przeciwsterowania można ograniczyć do pewnego kąta.

Teorię tę można zweryfikować, ponownie wdrażając układ kierowniczy i porównując go z pierwotnym zachowaniem.

• Po bezpośrednim powiązaniu sygnału wejściowego z wyjściowym pojazd jest naprawdę niezwykle trudny do kontrolowania, nawet po zastosowaniu ogranicznika wejściowego układu kierowniczego opartego na prędkości.
• Po dodaniu naturalnego kontrpartnerstwa zachowanie jest prawie identyczne z implementacją gier, ale samochody są „zbyt” stabilne.
• Po dodaniu limitu 15 stopni do kontratera zachowanie jest prawie identyczne.

Należy pamiętać, że Grand Theft Auto V został tutaj uznany za „idealny” - chociaż nie znalazłem jeszcze żadnej gry, która implementuje ten system.

Jeśli jesteś ciekawy kodu, oto fragment mojej implementacji.

// Returns in radians
float Racer_calculateDesiredHeading(float steeringMax, float desiredHeading,
    float reduction) {
    desiredHeading *= reduction;
    float correction = desiredHeading;

    // Get the relative velocity vector
    Vector3 speedVector = ENTITY::GET_ENTITY_SPEED_VECTOR(vehicle, true);
    if (abs(speedVector.y) > 3.0f) {
        // Simplify it to an angle
        Vector3 target = Normalize(speedVector);
        float travelDir = atan2(target.y, target.x) - static_cast<float>(M_PI) / 2.0f;
        if (travelDir > static_cast<float>(M_PI) / 2.0f) {
            travelDir -= static_cast<float>(M_PI);
        }
        if (travelDir < -static_cast<float>(M_PI) / 2.0f) {
            travelDir += static_cast<float>(M_PI);
        }
        // Correct for reverse
        travelDir *= sgn(speedVector.y);

        // Limit to some degree, R* uses 15 degrees
        travelDir = std::clamp(travelDir, deg2rad(-15.0f), deg2rad(15.0f));

        // User input deviation
        correction = travelDir + desiredHeading;
    }

    return std::clamp(correction, -steeringMax, steeringMax);
}