Model jazdy w wyścigach typu arcade


Warsztat - Programowanie gier komputerowych :: Model jazdy w wyścigach typu arcade







Strona główna Forum Szukaj Lista użytkowników
Grupy
Zarejestruj Zaloguj

Artykuły
Kliknij na kategorię żeby dodać artykuł Szukaj
Programowanie gier » Artykuły » Matematyka i Fizyka
[Wersja do drukowania]
Model jazdy w wyścigach typu arcade
Opis Model jazdy w wyścigach typu arcade
Autor Regedit Data Sro 15 Gru, 2004 1:32 pm Typ **
Słowa klucze
Kategoria Matematyka i Fizyka
Odsłony 986


Model jazdy w wyścigach typu arcade
Model jazdy w wyścigach typu arcade

Część I
Jeśli grałeś w Micromachnies, to wiesz o co mi chodzi:
poślizgi, dym spod kół, wchodzenie bokiem w zakręty.
Wiadomo - poruszanie się samochodu w wyścigach Arcade
nie ma dużo wspólnego z realnym modelem jazdy, ale jest
o tyle ciekawe, że uproszczone metody poruszania się
dają dużą grywalność mimo paskudnego widoku (np. z
góry).

A teraz konkrety: Pisząc model jazdy do "Radości
Szofera" postawiłem sobie cztery zasadnicze cele:
zgodność fizyki jazdy gracza i przeciwników
sterowanych przez komputer,
poślizgi lepsze niż w Micromachines,
hamulec ręczny,
dynamika jazdy.
Wyjaśnię pokrótce punkt pierwszy: w kilku grach tego
typu zauważyłem, że komputer "oszukuje". Samochody przez
niego sterowane są zwrotniejsze lub szybsze - tak aby
dorównać graczowi. Chcąc tego uniknąć stworzyłem dwie
odrębne tablice:
signed int ruch[maxgraczy][2];
DANE_POJ danepoj[maxgraczy];
Pierwszy wymiar tablicy ruch odpowiada za oś Y joysticka
lub kursory góra-dół, drugi za oś X lub kursory
lewo-prawo. W tablicę wpisujemy wartości -1 lub 1 lub ją
zerujemy w zależności od tego jaka jest decyzja gracza
komputerowego lub jaką akcję wykonał human player.

Jeśli chodzi o dane_poj jest to tablica rekordów
zawierających wszystkie dane potrzebne mi do generowania
nowego położenia pojazdu:


typedef struct
{
signed int x,y;
int xekr,yekr;
float rx,ry;
float srx,sry;
float pr;
int kat,katk;
int rozn;
char teren[4];
}DANE_POJ;
x,y to pozycja pojazdu na mapie
xekr,yekr to pozycja pojazdu na ekranie
rx,ry to wektor przesunięcia pojazdu (te dwie zmienne
są dodawane do swoich odpowiedników x,y po każdej
klatce)
srx,sry to wektor przesunięcia w poprzedniej klatce,
nie pamiętam już do czego był mi potrzebny (był
napewno, jak go wyrzuciłem to TOO MANY ERRORS)
pr typu float to oczywiście prędkość poruszania się
pojazdu (mała rada: polecam wartości od 0 do 10
maximum, przy większej ilości przeskoczonych na klatkę
pikseli gracz traci świadomość gdzie jest, a od tego
to już krok, szósty krok)
kat i katk to CLUE poślizgów, omówię je za chwilę
rozn to różnica pomiędzy kat i katk
teren[4] zawiera numery terenów pod każdym z kół
(trawa, asfalt, piasek)
licz_posl to czas do wyrównania kat i katk
W każdej klatce gra dodaje do wartości x,y wartości
rx,ry, które są współrzędnymi wektora przesunięcia,
UWAGA: kat. Katk zaś to wektor położenia kadłuba.

Jeśli samochód jedzie prosto, te zmienne są sobie równe.
Jeśli pojazd skręca, np. w lewo, zmienna katk zmniejsza
się o jeden, ale kat jeszcze nie. Powiedzmy, że kadłub
już się obrócił, ale samochód nadal jedzie w tą stronę,
w którą chciał. W następnej klatce zmienna katk
zmniejsza się już o dwa, ale kat dopiero o jeden. I tak
dalej. Jeśli rozn (różnica) będzie większa niż trzy,
spod kół leci dym. Jeśli gracz zdejmie żelazko z
kursora, to zmienna kat przestanie się zmniejszać, a
katk po kilku klatkach zrówna się z nią i znów samochód
jedzie prosto.

Cała zasada jest banalnie prosta. Dodać jeszcze należy
ze dwa IFy do hamulca ręcznego: jeśli walnąłem
przypadkiem spację, a różnica jest różna od zera
(czytaj: akurat gdzieś skręcałem) to kat zmniejsza się
lub zwiększa (zależy w którą stronę skręcałem) dwa razy
szybciej.

Efekt wygląda bosko:



Na screenie widać trasę, po jakiej mniej więcej poruszał
się samochód. Zacząłem skręcać w punkcie 2, zaś w
punkcie trzecim wcisnąłem hamulec ręczny.



Powyżej zbliżenie akcji. Różowa oś to katk czyli kąt
kadłuba jak ją nazwałem, żółta to kat, czyli kąt
poruszania się samochodu. Na niebiesko zaznaczyłem
różnicę, widać że jest ona duża, około 90 stopni, więc
samochód wpadł w poślizg co jest zrozumiałe. Po
wciśnięciu hamulca ręcznego musi występowac jeszcze
jeden efekt: samochód musi zwalniać. Kiedy już się
całkowicie zatrzyma, zmiennej kat należy nadać wartość
katk. Jeśli o tym zapomnimy, przy ruszaniu samochód
rzuci się w bok jakby jeszcze był w trakcie poślizgu.
Część II
animacja i wyświetlanie pojazdów,
dym spod kół,
Animacja to jedna z najważniejszych cech gry, przyciąga
ludzi płynnością, oryginalnością, odwzorowaniem
rzeczywistości. Najlepsza grafika traci niesamowicie
dużo jeśli nie jest płynna, najgorsza może zachwycić
animacją. Dlatego w Radości Szofera każdy samochód
został wyrenderowany w 72 klatkach obrotu. Zmienne kat i
katk, o których pisałem w części pierwszej arta,
przyjmują właśnie wartości od 0 do 71. Nie jest to
najdoskonalsze rozwiązanie, dla potrzeb symulacji
należałoby zmienne te zadeklarować typu float, a ich
zmiany na klatkę liczyć do 4 miejsca po przecinku, ale
do arcade wystarczyło.

Zmienna typu float o nazwie pr, to prędkość jazdy
pojazdu. W każdej klatce gry wykonywane są następujące
instrukcje:


dane_poj[nrgracza].x +=
dane_poj[nrgracza].rx*dane_poj[nrgracza].pr;
dane_poj[nrgracza].y +=
dane_poj[nrgracza].ry*dane_poj[nrgracza].pr;

Dlatego pr nie powinno przyjmować dużych wartości. Ja
uznałem, zresztą w trakcie prac zmieniałem te wartości
nie raz, że prędkość samochodów nie będzie większa niż
10. Trzeba jeszcze zaznaczyć, że przy prędkościach
niższych niż 1, łatwo można stracić precyzję przesuwania
pojazdu. Zmienne rx[cc] i [c]ry są typu float, pr też,
zaś x i y to integery.

W Radości Szofera mapa nie była duża: miała 2000 na 2000
pikseli. Pozycja x,y typu i to właśnie pozycja samochodu
na mapie. Xekr i Yekr zaś to pozycja pojazdu na ekranie.


W programie w każdej klatce uruchamiałem procedurę
wyświetlania pojazdów, wyglądało to mniej więcej tak:


void wyswietl_pojazdy()
{
for (nr=0;nr if (gracze[nr].typ!=T_CZLOWIEK)
{
dane_poj[nr].xekr=dane_poj[nr].x-mapax;
dane_poj[nr].yekr=dane_poj[nr].y-mapay;
}
}

Tablica gracze to tablica rekordów, zawierająca m.in.
takie dane jak typ gracza (komputer, człowiek), ilość
zaliczonych okrążeń, numer ostatniego zaliczonego
checkpointu, czas okrążenia, rekordy itp.

MapaX i MapaY to dwie zmienne określające położenie
górnego, lewego rogu ekranu na mapie.

Następną fajną sprawą są efekty dymu spod kół. Aby je
wygenerować należy znać pozycję każdego koła pojazdu.
Sprawa jest pracochłonna. Renderując samochody w 3D
Studio, wykasowałem wszystkie obiekty poza kołami i
wyrenderowałem ich wszystkie 72 klatki obrotu, ambient
light ustawiając na maksimum. Dzięki temu i jeszcze
drobnej korekcie w programie 2d, otrzymałem zbiór
obrazów kół. Za pomocą prostej funkcji badającej kolor
punku pobrałem pozycje kół do tablicy o takim kształcie:



char poz_kol[72][4][2];

Pierwszy wymiar to oczywiście ilość klatek, drugi to
ilość kół, trzeci to x i y. X i y są wymiarami
względnymi t.j. są liczone od początku danej klatki
pojazdu.

Po zapisaniu tej tablicy można już przystąpić do
zdefiniowania tablic tworzących dym:


#define maxdym 1000
#define czasdym 10

int dym[maxdym][5];
int nrdym;

Stała maxdym to oczywiście ilość dymków istniejących
naraz w grze. Nie lubię definiować tablic dynamicznych i
tylko dlatego tak to wygląda. Stała czasdym to
maksymalna ilość klatek, przez jaką dym się utrzymuje.
Najpierw (w pierwszej klatce po stworzeniu ma on 10
części, w każdej następnej o 1 mniej, aż zniknie
całkowicie.

Dymek ma kształt okrągły i wielkość 5x5 pikseli.
Procedura wyświetlająca go zamienia każdy pikselpod
dymkiem na odpowiedni odcień szarości, a jesli jest już
on szary, zwieksza jego jasność. W ten sposób nakładając
na siebie wiele dymków, lekko wokół siebie rozrzuconych
(polecam random) osiągamy efekt chaotycznego, gęstego
dymu.

Ostatnim krokiem jest napisanie dwóch procedur: jednej
wstawiającej cztery dymki o czasie (czasdym) równym 10 i
w pozycjach kół (poz_kol), drugą, która w każdej klatce
zmniejszy czasdym i wyświetli dymki.

Efekt wszystkich tych manipulacji widać poniżej:


Autor: Kłamacz
E-mail: klamacz@_USUN_@poczta.onet.pl
WWW: http://www.klamacz.republika.pl/
Data: 15 Kwietnia 2001


Skocz do: Wybierz forumWarsztat - Programowanie
gier komputerowych|--Szkółka| |--Szkółka -
języki| |--Szkółka - grafika| |--Szkółka -
inne|--Programowanie gier| |--Ogólnie|
|--Dźwięk| |--Sztuczna Inteligencja|
|--Inne|--Programowanie grafiki|
|--Programowanie grafiki| |--OpenGL|
|--DirectX|--Produkcja| |--Pomysły|
|--Projektowanie| |--Projekty| |--Grafika|
|--Ogłoszenia|--O czym innym| |--Konferencje,
spotkania| |--Warsztat| |--Aktualności|
|--Artykuły| |--Wykłady| |--Compo|
|--Lepperlandia|--Śmietnik| |--Z odrzutu



Powered by Knowledge Base, wGEric (C) 2002 PHPBB.com MOD
This script (Knowledge Base - MX Addon v. 1.03e) is modified
by Haplo





W1.5b (C) 2004
[admin: ayufan, g[R]eK, Goliatus, mikael_, Regedit]
Wszystkie czasy w strefie CET (Europa)

Powered by phpBB2 Plus 1.52 based on phpBB 2.0.10 © 2001, 2002 phpBB
Group :: FI Theme :: Mody i Podziękowania












Wyszukiwarka

Podobne podstrony:
Hislop J Teoria i praktyka jazdy w wyścigach płaskich
Numeryczny model wymiennika ciepła typu rekuperator
Rzutparteru Model (1)
model ekonometryczny zatrudnienie (13 stron)
,Modelowanie i symulacja systemów, Model dynamiczny
Jęazykoznawsto ogólne model sens tekst
son rise?v model 3 PL poziomo
droga Model (4)
2008 marzec OKE Poznań model odp pr
Model oswietlenia

więcej podobnych podstron