Od kuchni - kolizje, wypadki, zderzenia

30.12.09, 21:56
Kolizje, wypadki, zderzenia...

Tytuł wątku nawiązuje do starego artykułu traktującego o kolizjach w grach w
magazynie C&A. Nie bez powodu, bo tym razem postaram się omówić w jaki sposób
gry radzą sobie z kolizjami oraz odpowiem na kilka pytań dręczących graczy np.
skąd się biorą niewidzialne ściany.

Kolizje należą do jednych z bardziej zdradliwych elementów gier. Teoretycznie
proste, w praktyce to tam najczęściej gra potrafi pokazać "różki" w postaci
wypadnięcia bohatera za geometrię, zacięcia się między elementami itd.
Odszukanie wadliwych elementów ( które często nie wychodzą nawet na jaw w
momencie testów wewnętrznych ) nie należy do najprostszych.


1. Trochę historii.

Zacznijmy jednak od początku. Dawne platformy jak NES, C64, Amiga dysponowały
możliwością sprawdzania kolizji między elementami 2D po stronie hardware'u.
Odpowiedni układ był odpowiedzialny za sprawdzenie, czy dwa ruchome obiekty (
sprites ) na siebie nachodziły choćby jednym pikselem i raportował kolizję, po
czym gra obsługiwała to. Zwykle były dwa rodzaje takich kolizji - między
obiektami oraz obiekt-tło. Szybko jednak się okazało, że o ile zwalnia to
programistę od implementowania systemu kolizji ręcznie, ale również
ograniczało to bardzo sposób ich użycia. Nie można było zaraportować kolizji
"na życzenie" np. gdy obiekty już nachodzą na siebie, ale programista chciał
zachować pewien margines, gdy jeszcze nie następuje reakcja. Czasami również
chodziło o zwiększenie obszaru kolizji, gdzie obiekt nie posiadał żadnych
pikseli, a już mordęgą było sprawdzanie kolizji z "labiryntem" ( tak wówczas
określało się wszelkie levele w zręcznościówkach, bo i taką formę miały ),
gdzie kolizja z tłem ograniczała wygląd ścieżek ( po prostu nie mogło być tam
żadnej grafiki ). Rozwiązano to więc w prosty sposób, który jest prekursorem
obecnych kolizji - włożono wirtualnie każdy obiekt w tzw. "bounding box",
czyli prostokąt, który zawierał wewnątrz sprite'a. Poziomy natomiast zaczęto
sprawdzać nie za pomocą testów pixel-pixel, ale za pomocą wirtualnych map,
gdzie każdy "klocek" ( używamy do dziś terminu "tile" na określenie
pojedynczego "klocka" ) był również takim prostokątem. Kolizje więc dotyczyły
tylko prostokątów, które można było modyfikować dowolnie pod względem
wielkości, natomiast test był banalny, bo wystarczyło porównać odległości
między najbardziej oddalonymi od siebie punktami w pionie i w poziomie.
Warunkiem więc było, że odległość wierzchołków najbardziej wysuniętych w
pionie musiała być mniejsza niż suma wysokości obu sprite'ów oraz odległość
wierzchołków najbardziej wysuniętych w poziomie musiała być mniejsza niż suma
szerokości obu sprite'ów. Oba warunki musiały być spełnione by zaszła kolizja.
Hardware nie był już do niczego potrzebny, a matematyka zastosowana do testu
była prosta i nie odczuwało się problemów z wydajnością. Tak bardzo długo ( bo
aż do dziś ) system kolizji zachował się w grach 2D.

2. BBox i AABox ( również nazywany AABBox )

Gry 2D ewoluowały i pojawiły się tytuły, które mimo, że były jedynie
dwuwymiarowe, to była możliwość obracania świata gry o 360 stopni, prosta
matematyka już nie wystarczyła, bo sprawdzenie kolizji między obróconymi
"bounding box" (BBox) było nieco bardziej skomplikowane. Wtedy to programiści
pomyśleli, że skoro możemy obrócić BBox, to znamy położenie wszystkich jego
wierzchołków, więc może z nich zbudować kolejny BBox, tyle że zorientowany
zgodnie z osiami układu współrzędnych. Tak narodziły się AABox ( axis aligned
box ). Znaczne to upraszczało sprawę, bo nadal można było wykorzystać te same
algorytmy niezależnie od tego czy świat się obracał czy nie. Dyskusyjna była
dokładność tego rozwiązania, ale ponieważ większość spriteów i tak mieściła
się w prostokącie dumnie zwanym... "kwadratem", to niedokładność rozwiązania w
czasie gry nie dawała się we znaki. Przykład AABox stworzonego na bazie
obróconego BBox:

https://i46.tinypic.com/11ta7fp.png

Oczywiście to nie koniec pomysłów. Jak widać na rysunku powyżej, AABox
pozwalało łatwo ustalić czy zachodzi kolizja, ale często powodowało to
zniekształcanie obszaru kolizji. Próby stworzenia AABox na podstawie pikseli
nie były również zbyt sensowne, stąd pomyślano o dwóch możliwościach. Albo
można było sprawdzić przecięcie między dowolnymi BBox'ami sprawdzając czy
krawędzie przecinają się, albo można było wykorzystać inne kształty, bardziej
odpowiadające naturze i wyglądowi sprite'a. W ten sposób zaczęto także
korzystać z okręgów, elips, trójkątów itp. Każda z figur dostała własne proste
algorytmy sprawdzania przecięć oraz wypracowano algorytmy sprawdzania
przecięć między różnymi typami figur, w jakie można było wpisać sprite'y.
Przykłądowo, sprawdzenie kolizji między okręgami oznaczało sprawdzenie
odległości od środków i porównaniu z sumą ich promieni, a właściwie z
kwadratem tej sumy, by uniknąć pierwiastkowania ( pierwiastek kwadratowy to w
programowaniu bardzo smutny pan, bo nikt po prostu go nie lubi smile ). Te
mechanizmy pozwoliły na lepsze opisanie obiektów i mimo, że nadal siedzieliśmy
w 2D, to techniki te stanowią podstawę tego co jest teraz. Małpę z obrazka
wyżej o wiele lepiej byłoby wpisać w okrąg, przy obrocie okrąg cały czas
pozostaje na swoim miejscu, a jego orientacja zawsze jest zgodna z osiami
układu świata ( właściwie to zgodna z każdymi osiami ).

3. Era 3D.

Nastała era 3D. To czego już się nauczyliśmy nie dało się wykorzystać tak po
prostu, bo trzeci wymiar miał swoje wymagania. Podstawową figurą geometryczną
opisującą płaszczyznę stał się trójkąt, bo tylko on gwarantował, że mieliśmy
do czynienia tylko i wyłącznie z jedną płaszczyzną ( z matematyki - 3 punkty
zawsze leżą w jednej i tylko jednej płaszczyźnie ). W grach 3D posunięto się
dosyć daleko i często sprawdzanie kolizji - postacie-świat oznaczało
dosyć dokładny test z każdym trójkątem w obszarze kolizji. AABox wszedł w erę
3D, postaci w grach zostały w niego "owinięte", to samo część elementów świata
gry. Jednak początkowy koncept świata 3D w grach FPP nie był zbyt lekki dla
testów kolizji. Testy kolizji ze ścianami często wymagały przewędrowania przez
drzewo zawierające rozbitą geometrię ( gry nie zawierały takich detali jak
teraz i można było pokusić się o dosłownie pocięcię sceny na trójkąty i
zbudowanie drzewa BSP ( później Quadtree i Octree ). Tak robiono, toteż główne
sprawdzanie kolizji polegało na przetestowaniu przecięć między trójkątami w
polu widzenia lub dobieranych na innej zasadzie ( zależnie od użytej metody
partycjonowania oraz testów widoczności ). Generalnie miało to zaletę.
Pamiętacie wszelkie pierwsze gry w prawdziwym 3D? Można było wejsć praktycznie
wszędzie, nie było nigdy niewidzialnych ścian w tamtych czasach, bo każdy
trójkąt z jakiego zbudowana była scena podlegał testowi kolizji. Miało to
swoje negatywne odbicie w wymaganiach, aczkolwiek testy przecięć trójkątów (
jeśli jesteśmy w stanie w miarę dobrze określić, które trójkąty biorą udział w
teście ) nie należą do skomplikowanych i można je wykonać bez żadnej
zaawansowanej matematyki. Oczywiście starsze techniki wykorzystujące bounding
boxy, sfery i cylindry również były w grze, ale dotyczyły one tylko niektórych
elementów. Liczyła się dokładność i im dokładniejszy system kolizji istniał w
grze, tym dla tej gry było lepiej.

(no i limit 8000 znaków osiągnięty cool CDN za chwilę ).
    • j_uk_dev Re: Od kuchni - kolizje, wypadki, zderzenia 30.12.09, 22:02
      4. Collider Mesh.

      Ewolucja gier poszła do przodu, głównie pod względem rozwoju grafiki. Setki
      trójkątów zamieniły się w tysiące, tysiące przeszły w setki tysięcy, a te setki
      tysięcy - w miliony. Układy graficzne są w stanie przetworzyć olbrzymie sceny w
      krótkim czasie. Sprawdzanie kolizji jednak pozostało po stronie procesora. Gdyby
      podążać drogą wytyczoną przez pierwsze FPP, to same kolizje by drastycznie
      zwiększyły wymagania gier. Trzeba było poszukać alternatywy. Tak właśnie
      narodził się "collider mesh". Collider jest uproszczonym obiektem, którego nie
      widzimy, a który pokrywa elementy do których mamy dostęp, lub zależnie od testu
      - dostępu do nich nie mamy. Collider generowany często jest automatycznie przez
      edytory poziomów, aczkolwiek wielu designerów leveli woli robić takie rzeczy
      ręcznie upewniając się, że kolizje przebiegają tak jak powinny. Ilość trójkątów
      collidera jest wiele razy mniejsza niż całej sceny. Gra jest w stanie
      przetworzyć taką geometrię bardzo szybko, a dzięki "linkom" między trójkątami
      łatwo zdeterminować, które trójkąty należy sprawdząć najpierw. Collider jednak
      to nie tylko kolizje. To także ogromna pomoc dla AI, którego częścią jest
      wyszukiwanie ścieżek ( tzw. "pathfinding" ). Collider zbudowany jest z wielu
      trójkątów, które są ze sobą połączone, jeśli współdzielą te same wierzchołki. W
      ten sposób zawsze wiadomo, z którego trójkąta na który można przejść i to
      właśnie wykorzystuje się przy znajdywaniu ścieżek. Poza tym używając collidera
      wiemy, że ( teoretycznie, bo jak to działa w praktyce, to w grach czasami widać
      ) NPC będą poruszały się tylko po elementach poziomu, które dopuszczają ruch w
      ogóle. Nietrudno się domyślić, że collider odpowiedzialny jest za te nieszczęsne
      niewidzialne ściany oraz schody, które wydają się zupełnie płaskie, gdy po nich
      wchodzimy:

      https://i46.tinypic.com/s6lqv7.png

      Na ilustracji powyżej widać, że schody pokryte są tylko dwoma trójkątami
      collider mesha i generalnie postać wejdzie po tym ruchem "ślizgowym". Również
      celowo collider nie pokrywa do końca wnęki w ścianie, co stworzy własnie taką
      niewidzialną barierę. Akurat ten collider jest dosyć detaliczny, co widać po
      ilości trójkątów. Mozna zauważyć, że pokrywa jedynie podłogę. Gry, w których
      generalnie nie poruszamy się w powietrzu ( a i to nie jest warunek wink )
      korzystają głównie z takiej formy kolizji, bo tak naprawdę nie potrzebujemy
      wiedzieć nic więcej poza tym, gdzie jest podłoga. Oczywiście są elementy, które,
      mimo że są objęte colliderem, to mają specyficzne działanie i one na ogół mają
      wyższy priorytet niż sam collider. Stosuje się również właściwości "face'ów"
      collidera. Przykładowo, gdy postać może skakać, to trójkąt, z którego można
      wykonać taki skok będzie posiadał taką flagę. Dlatego np. czasami podchodzimy do
      krawędzi i nie wyskoczymy nigdzie, postać zacznie dreptać w miejscu, ale
      podchodząc do dziury w podłodze, którą trzeba przeskoczyć nie zostaniemy
      powstrzymani przed taką akcją ( choć tutaj sporo jest związku z triggerami i też
      wyłączaniem collidera ). Od razu widać, że nieważne jaka będzie geometria sceny,
      jak wiele detali poziom będzie posiadał, to collider w wielu przypadkach się nie
      zmieni. Przykładowo, dodając dekoracje na ściany, jakieś inne elementy, to
      sprawdzanie kolizji pozostanie dokładnie takie same. I o to chodzi. Dzięki
      takiemu uproszczeniu jesteśmy w stanie opisać ogromny świat, niezwykle
      detaliczny w taki sposób, by procesor się nie zakrztusił i gra działała
      wydajnie. Owszem, każde uproszczenie niesie za sobą wady. Jest tak i w przypadku
      collidera, ale jak to się mówi, nie ma róży bez kolców.

      Z collider mesh jest związanych jeszcze wiele zagadnień, ale chyba podstawowe
      omówiłem i części graczy powinno to pomóc zrozumieć jak działa system kolizji w
      nowoczesnym tytule.

      5. Headshot.

      No właśnie, mówimy o uproszczaniu sprawdzania kolizji, a co w przypadku, gdy
      kolizja musi być jednak detaliczna? Opisane uproszczenia nadal są stosowane do
      wyznaczenia momentu, w którym musimy zacząć bawić się w detale. System kolizji w
      grach na ogół sprawdza kolizje w kilku etapach, najpierw zbiera obiekty, które w
      kolizji wezmą udział, następnie dokonuje testów na bazie AABox. AABox zawsze
      obejmuje większy obszar niż sam obiekt, więc trafienie w niego z pewnością jest
      jednym z warunków dalszego testu. Wiele obiektów ma na sobie inne boxy, sfery
      czy cylindy. Nazywamy to "volumes", po polsku to chyba będzie "wolumin". W
      każdym razie jeśli mamy postać człowieka, to każda jego ważniejsza kość ( ręce,
      nogi, korpus i głowa ) jest w środku takiego woluminu ( bone volume ). Jeśli
      kości korzystają z AABox wtedy znów prosty test powie nam, czy i w co
      potencjalnie trafiliśmy, "volume" może być też już przetransformowany ( na ogół
      będzie ), więc test będzie nieco bardziej skomplikowany ( zależnie od użytej
      geometrii woluminu ). Jesli trafiliśmy kość, to możemy sprawdzać dalej i znaleźć
      dokładne miejsce trafienia ( np. do pokrycia miejsca krwią ) lub po prostu
      odnotować trafienie i zakończyć test. Tutaj akurat pojawia się często
      "wypominana" programistom kwestia, że jeśli nacelujemy niedokładnie, to i tak
      trafimy. Często zarzuca się, że to przez konsolowy system celowania - bzdura.
      Odpowiedzialne za to są właśnie kolizje promień-kość. Wolumin kości na ogół nie
      odzwierciedla dokładnego kształtu kończyny. W większości przypadków używa się
      cylindrów, bo kończyny mają podobny kształt, a znalezienie odległości promienia
      od cylindra jest dosyć łatwe ( po transformacji promienia do przestrzeni
      cylindra ). W wielu grach po prostu przestaje się dalej testować - trafiliśmy
      kość, postać oberwała. Ze wspomaganiem celowania nie ma to wiele wspólnego,
      natomiast może mieć nieco wspólnego z testami samej geometrii modelu postaci,
      której dalszy test często okazuje się zbyt kosztowny. Również to jest cena za
      detaliczność grafiki. Oczywiście rozwiązania nie kończą się na takim teście i
      programiści mają sporo asów w rękawie. Np. Mniej detaliczny collider w kształcie
      danej kończyny, ze znacznie mniejszą geometrią, czasami też po prostu testuje
      się każdy trójkąt danego fragmentu ciała i już. To już zależy od silnika, od
      samej gry i od samego celu programistów.

      W temacie kolizji można napisać jeszcze wiele, to po prostu temat rzeka. Obecnie
      coraz częściej kolizje są przejmowane przez silniki fizyczne, które działają na
      bardzo podobnej zasadzie u podstaw, ale włączają w grę prawa fizyki. Niestety
      jednak ciągle kolizje nie nadążają za stroną wizualną gier i będzie to jeszcze
      przez jakiś czas element, który zawsze ucierpi na dokładności. Przedstawiłem
      jedynie czubek góry lodowej i próbowałem oddzielić temat od pokrewnych mu
      kwestii, by nie wprowadzać zbyt dużo komplikacji.
      • wypisany Re: Od kuchni - kolizje, wypadki, zderzenia 30.12.09, 22:23
        Jak zwykle świetne. Z niecierpliwością czekamy na ciąg dalszysmile
      • Gość: ank Re: Od kuchni - kolizje, wypadki, zderzenia IP: 193.138.241.* 02.01.10, 21:16
        Jesteś informatykiem ?
      • Gość: gościu Re: Od kuchni - kolizje, wypadki, zderzenia IP: *.chello.pl 02.01.10, 23:56
        Czyli wezmy takie MW2 - grajac mam wrazenie, ze tworcy polecieli po najmniejszej linii oporu i dali "prostokatne" aka kwadratowe smile AAboxy, nawet nie starajac sie o wspomniane przez ciebie cylindry. Tylko czym to jest spowodowane? Nie wierze, ze konsole nie dalyby rady udzwignac wiekszej ilosci obliczen - nie w tej grze, bo tutaj w multi konsola sie nad fizyka wysilac nie musi. Lenistwo? Ulatwienie dla konsolowcow? A moze jednak sa jakies ograniczenia?

        BTW Artykul swietny, odcialem sie od swiata i czytalem w wielkim skupieniu, zeby wchlonac kazda informacje. Wielki szacunek.
        • cwicz Re: Od kuchni - kolizje, wypadki, zderzenia 03.01.10, 00:14
          Czy chodziło ci o: linia najmniejszego oporu?
          • Gość: asga Re: Od kuchni - kolizje, wypadki, zderzenia IP: *.adsl.inetia.pl 06.01.10, 11:06
            > Czy chodziło ci o: linia najmniejszego oporu?

            Obie wersje maja sens
      • Gość: gość portalu [...] IP: *.neoplus.adsl.tpnet.pl 03.01.10, 00:30
        Wiadomość została usunięta ze względu na złamanie prawa lub regulaminu.
        • Gość: Mikunda Re: Od kuchni - kolizje, wypadki, zderzenia IP: *.neoplus.adsl.tpnet.pl 03.01.10, 05:24
          Hmm ja np. jadąc samochodem lubię wiedzieć jak to działa. Oglądając film czasami
          zastanawiam się dlaczego to wygląda tak a nie inaczej, lecąc samolotem
          zastanawiam się czemu nie gruchnie na ziemię. Weź pod uwagę, że w Polsce są
          ludzie których po prostu ciekawi fakt działania otaczającego ich świata. Na
          świecie nie istnieje tylko konsumpcjonizm, jeśli ktoś interesuje się grami może
          kiedyś zacząć się zastanawiać jak to działa?
        • Gość: xeno Re: Od kuchni - kolizje, wypadki, zderzenia IP: *.sgyl.cable.virginmedia.com 03.01.10, 05:29
          Ręce opadają. Człowiek napisał parę kilo wartościowego tekstu, to zaraz znajdzie sie jakis burak-malkontent co będzie się w tym podłości doszukiwać.
        • Gość: hgkug Re: Od kuchni - kolizje, wypadki, zderzenia IP: *.neoplus.adsl.tpnet.pl 03.01.10, 10:30
          Zazdrościsz mu, że potrafi coś ciekawego i sensownego napisać?
          • Gość: gość [...] IP: *.neoplus.adsl.tpnet.pl 03.01.10, 11:04
            Wiadomość została usunięta ze względu na złamanie prawa lub regulaminu.
            • Gość: gość portalu [...] IP: *.neoplus.adsl.tpnet.pl 03.01.10, 11:09
              Wiadomość została usunięta ze względu na złamanie prawa lub regulaminu.
            • Gość: gościu Re: Od kuchni - kolizje, wypadki, zderzenia IP: *.chello.pl 03.01.10, 11:52

              "Jeżeli ktoś jest tylko ciekaw to nic nie zrozumie, a jak ktoś się chce tego nauczyć to czytanie"

              masz nas za idiotow? Ja np. nie mam pojecia o programowaniu, a ten artykul zalapalem w 90%. Wielu z nas na co dzien zajmuje sie innymi sprawami i nawet nie wpadnie im do glowy sprawdzic jak dziala system kolizji itd. A tak, przy okazji przegladajac neta natrafia sie na taki artykul, z ciekawosci zaglada i jak widac - mozna czegos sie ciekawego dowiedziec i zrozumiec. Poza tym, jesli ktos jest ciekawy, a nie jest totalnym zerem programistycznym, to ciezko bedzie znalezc odpowiedni artykul - ten taki jest w 100%. Mam gdzies jakie gosc mial intencje - dla nas, userow, ma to same plusy. A jak chcesz napisac o geometrii obliczeniowej, to rowniez z checia przeczytam - o ile nie wyskoczysz dla popisu z multum pojec programistycznych.

              BTW autor nie komentuje wpisow, ale jesli juz jakis informatyk tu jest, to z checia poslucham co ma do powiedzenia odnosnie sprawy z MW2, o ktorej wspomnialem kilka postow wyzej
              • Gość: gościu Re: Od kuchni - kolizje, wypadki, zderzenia IP: *.chello.pl 03.01.10, 11:54
                oczywiscie mialo byc:
                "Poza tym, jesli ktos jest ciekawy, a JEST totalnym zerem programistycznym"
        • Gość: fdf [...] IP: *.chello.pl 03.01.10, 15:06
          Wiadomość została usunięta ze względu na złamanie prawa lub regulaminu.
      • Gość: m_pl_dev ;) Re: Od kuchni - kolizje, wypadki, zderzenia IP: *.chello.pl 06.01.10, 00:54
        Ciekawa historia z trafieniem "dokładnym" i koścmi, ale ta technika wymaga podpinania
        conajmniej jednej kości do każdego props'a na mapie tudzież patrz Source Engine i
        ich "Physique" w 3DSMax podczas eksportu. Można ten problem rozwiązać
        wprowadzając atrybuty face'ów, które definiują cokolwiek zechcesz od rodzaju FX'a jaki
        poleci po kolizji aż po stopień penetracji, deformacji i odbicia. Technika jest
        bardzo "tania", puszczając trace (lub jak kto woli "strzelając" wink) łatwo określić dokładne
        miejsce trafienia, ale problem pojawia się gdy mamy laga na multi. Wtedy pojawia się
        znany tekst "ej, przecież trafiłem, a mi nie zaliczyło" smile

        Sięgając wstecz Quake 1, który dzielnie jechał na BSP kolizje miał liczone "per-face" i w
        wielu przypadkach nadal się to stosuje, ale upraszcza np. stertę kamieni pakuje się w
        jeden CollisionBox. Można też zaklejać dziury, aby gracz nie wszedł za pomocą
        płaszczyzn (ale bez przesady wink) tudzież są to CollisionBarriers lub ClipingPlanes itp. Dla
        porównania levele w Uncharted 1 jak i 2 były robione w Mayi i tam faktycznie Level
        Designer musiał dłubać CollisionBox'y, ale dla mnie ta technika to zło. Lepiej zrobić np.
        trzy modele skał z gotowym CollisionHull'em i te modele powielać. W tych przypadkach
        wystarczy dodać tylko kilka niewidocznych CollisionBox'ów tam gdzie trzeba/wypada.

        Z innych fajnych bajerów. Idealną bryłą służącą jako Collision Hull, CollisionBox, Collider
        Mesh (lub jak kto woli) jest kula. Wystarczy tylko sprawdzać radius smile


        pozdrawiam smile
    • martrzyk Re: Od kuchni - kolizje, wypadki, zderzenia 02.01.10, 14:01
      super test, juz drugi.. ja bym chetnie poczytał teraz o sposobach
      wykorzystywania wielordzenio/procesorowosci i rozdzielania działan(watkow?)
      miedzy procesory i karte/ty graficzne. O ramie wkoncu juz bylo smile. No i jak to
      teraz jest z tym pisaniem wielo procesorowym wsumie.. bo jak wiadomo nadal jest
      to jak polska.. 100 lat za murzynami (czt. hardwarem). smile
      • Gość: bzykacz Re: Od kuchni - kolizje, wypadki, zderzenia IP: *.master.pl 02.01.10, 16:12
        Myślę że grafika obecnie dostępna w grach takich jak np. Crysis jest
        wystarczająca, teraz programiści powinni się skupić na fizyce, efektach
        cząsteczkowych i wydajności samych silników graficznych. Przykre jest że grafika
        pędzi jak sku...syn, a fizyka w grach stoi mniej więcej na tym samym miejscu jak
        parę lat temu. Uważam że jeżeli dążymy do realności w grach to fizyka i
        zniszczalność obiektów jest teraz naszym priorytetem. Podziwiam twórców gier
        takich jak: Battlefield: Bad Company 1 i 2, Red Fraction: Guierilla, Crysis
        którzy poza grafiką skupiają się mocno na odwzorowaniu fizyki i zniszczalności
        obiektów, robią pierwsze małe kroczki, być może dojdzie do rywalizacji między
        jakimiś tytułami na tym tle i reszta branży również skupi się na tym punkcie.
        • Gość: czytelnik Re: Od kuchni - kolizje, wypadki, zderzenia IP: *.neoplus.adsl.tpnet.pl 02.01.10, 23:55
          @bzykacz W Uncharted 2: Among Thieves masz i świetną grafikę i wspaniałą fizykę
          ;] gra roku!
    • Gość: M Re: Od kuchni - kolizje, wypadki, zderzenia IP: *.pool.mediaWays.net 02.01.10, 16:57
      Fascynujące rzeczy piszesz. Nie myślałeś o jakimś blogu? (byłbym jednym ze
      stałych czytelników)
      • Gość: shambler Re: Od kuchni - kolizje, wypadki, zderzenia IP: *.12.rev.vline.pl 02.01.10, 21:35
        popieram smile
    • kamael80 Re: Od kuchni - kolizje, wypadki, zderzenia 02.01.10, 20:39
      Kolejny bardzo fajny artykuł.

      Naprawdę uważam, że Twoje teksty powinny ukazywać się jako regularne artykuły na GC, a nie "tylko" na forum smile
    • Gość: Cieć Re: Od kuchni - kolizje, wypadki, zderzenia IP: *.neoplus.adsl.tpnet.pl 02.01.10, 21:04
      I wszystko jasne... sciana. Na takich artykułach powinny być 18+. Mój mały
      mózg się przegrzał.
      • Gość: Gość Re: Od kuchni - kolizje, wypadki, zderzenia IP: *.euro-net.pl 02.01.10, 21:20
        Raczej <18. Z wiekiem człowiek głupieje. wink
        • wypisany Re: Od kuchni - kolizje, wypadki, zderzenia 03.01.10, 12:40
          @gość portalu
          To ja mam dla Ciebie radę. Skoro tekst j_uk_deva rani Twoje poczucie
          elitarności, to zgłoś to jakiemuś tajnemu zrzeszeniu game developerów, żeby
          wypuścili na niego list gończy. Oczyścisz wtedy szeregi Waszego tajnego bractwa
          i laicy znów będą żyć w błogiej nieświadomości.

          Albo po prostu nie czytaj tych tekstów, skoro i tak wszystko to wiesz. Jeśli nie
          rozumiesz, czemu j_uk_dev to napisał i w dodatku podobny tekst w Twoim wykonaniu
          byłby dla nas niezrozumiały (przynajmniej Ty tak twierdzisz. Może nas
          sprawdzisz?), to znaczy że zwyczajnie nie nadajesz się do pisania o takich
          rzeczach. j_uk_dev znalazł złoty środek i idealnie dopasował stopień
          skomplikowania tak, że rozwiał część naszych wątpliwości i jednocześnie nie
          zasypał nas pierdylionem zbędnych terminów specjalistycznych. Nikt tu nie jest
          na tyle naiwny, żeby uznać, że te teksty opisują cały problem. Doskonale zdajemy
          sobie sprawę, że j_uk_dev opisał problem na bardzo wysokim poziomie i potem jest
          mnóstwo coraz bardziej skomplikowanych poziomów do zaprogramowania.

          Nikt nie uważa j_uk_deva za boga programowania, ale wszyscy go szanują. Wiesz
          czemu? Nie dlatego, że pracuje w gamedevie, bo każdy gdzieś pracuje i każdy jest
          w czymś dobry. Szanujemy go za wysoki poziom wypowiedzi głównie. Też tak chcesz?
          To spróbuj, a nuż Ci się w końcu uda.
Pełna wersja