Autor Wątek: Jak wygląda gra jako całość??  (Przeczytany 3186 razy)

Offline michald

  • Użytkownik

# Grudzień 26, 2007, 17:05:14
Cześć

Mam takie pytanie: jak wygląda gra jako całość? Już tłumaczę co mam na myśli.

Otóż zainteresowałem się już tematem programowania gier i zacząłem szukać informacji na ten temat. Znalazłem mnóstwo źródeł na tematy: programowania, grafiki komputerowej, WinAPI32, itp. - wszystko jak najbardziej potrzebne jako elementy gry. Jednak nie znalazłem informacji o budowie całości programu jakim jest gra komputerowa.

Tłumacząc dalej powiem parę słów o sobie. Jestem programistą z wykształcenia i zawodu, znam C++ bardzo dobrze, znam zagadnienia związane z programowaniem, zacząłem uczyć się grafiki, ale nadal nie wiem jak wygląda gra (i nie mogę tego znaleźć) jako całość.

Gdyby ktoś mnie zapytał jak wygląda taki typowy program biznesowy to bym mu opowiedział, że mamy dane składowane w jakieś bazie danych, kod programu mamy zazwyczaj podzielony na warstwy dostępu do danych, logiki biznesowej i prezentacji. Czasem używa się też architektury klient - serwer, itd. itp. mógłbym tak pisać i pisać. A jeśli chodzi o gry to znalazłem dużo materiałów nt. grafiki, nt. programowania, itd, ale NIE ZNALAZŁEM jak wygląda przeciętna gra jako całość, np. (tak to sobie wyobrażam) mamy silnik graficzny, sercem programu jest silnik logiczny, który pamięta stan gry (gdzie stoi jaki player, czy ta beczka już wybuchła, itd.), itd. itd. Np. pojęcia nie mam gdzie w grach się używa języków skryptowych, pomimo, że wiem, że się używa...

Gdzie mogę znaleźć takie informacje?? Mile widziane linki jak i tytuły książek.

Z góry dzięki,
pozdrawiam,
Michał vel Dab3r





Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Netrix

  • Redaktor
    • Netrix’s devBlog

# Grudzień 26, 2007, 17:11:23
Najprościej jest zacząć pisać grę tzn. najpierw ją zaprojektować tak jak chciałbyś, aby wyglądała. Struktura gry "wyjdzie w praniu" :).

FREQUENT

  • Gość
# Grudzień 26, 2007, 18:03:19
Właśnie, zapoznaj się z pętlą przetwarzania komunikatów. Zaimplementuj jakieś okno graficzne np. za pomocą OpenGL czy czegokolwiek innego i stwórz przesuwający się kwadrat poruszany strzałkami klawiatury. Dodaj do okoła jakieś ograniczenie np. w postaci ścian i zaprogramuj to wszystko tak, aby kwadrat nie mógł osiągnąć wartości (współrzędnych) poza tymi ścianami. Wszystko niech będzie choćby z samych linii, ale to jest najlepszy sposób żeby zobaczyć na własne oczy czym tak na prawdę jest gra. Że jest to tylko zbiór odpowiednich zależności istniejących w każdym obiegu pętli. A nawet i poza nią. Wyświetl tekst na ekranie, np. wartość jakiejś zmiennej i inkrementuj ją za każdym razem kiedy kwadrat dotknie ściany. Początek punktów.

Offline michald

  • Użytkownik

# Grudzień 26, 2007, 19:13:12
Dziękuję za odpowiedzi.

Doprecyzuję trochę moje pytanie. Ja wiem rozumiem czym jest gra. Wiem co to jest pętla komunikatów okna w Win32 API. Co do ruszających się kwadratów i ograniczeń na rozmiar ekranu itp. to w zasadzie też to znam. Z 5 lat temu napisałem sobie arkanoida w text mode. Wiem, że operowanie na obiektach OpenGL czy Direct3D jest zapewne trudniejsze, ale ogólnie ja czuję o co chodzi.

Ja chciałbym bardziej jakieś best practices nt. projektowania gier (ale nie mam na myśli projektu jaklo stosu dokumentów, tylko jak całość kodu będzie grała ze sobą). Mam na myśli jakiś zarys kluczowych klas/obiektów i sposób ich komunikacji.

Wiadomo, że wszystko musi się dziać w pętli komunikatów okna. Jak się zastanawaiam to widzę takie coś:
- przelicz logikę (czyli zobacz o ile się przemieściły postaci, czy beczka już wybuchła itp.)
- wyrenderuj obraz

I chyba tyle. Widać, że pierwszy punkt jest ogromny, renderowanie grafiki wymaga mniej inwencji... Jak to się robi? Czy macie w swoich grach jakieś super-obiekt o nazwie "świat", który pamięta wszystko - przede wszystkim mapę, pamięta w jakim stanie jest jaki obiekt na mapie (w tym gracz), przelicza jakieś okresowe zadania (np. żeby zegar na rynku zrobił "tyk")? Jestem ciekawy jak wygląda u Was pętla komunikatów...

Wiecie, bardzo możliwe że powinienem rzeczywiście usiąść i coś napisać, ale jestem bardzo leniwy i zanim zacznę chcę mieć na prawdę maksimum informacji na ten temat.

Pozdrawiam,
Michał

Offline Netrix

  • Redaktor
    • Netrix’s devBlog

# Grudzień 26, 2007, 20:32:28
Moim zdaniem, przeczytanie tych wszystkich informacji na ten temat jest bezcelowe i co najważniejsze zajmie ci bardzo dużo czasu. Najlepiej samemu (ucząc się na własnych błędach) zaprojektować grę (już w Symfonii C++ masz opisane jak powinno się projektować, krótko ale na temat), więcej o projektowaniu gier tutaj (mógłbyś to sam znaleźć, są święta będę dobry). Dzięki temu zdobędziesz odpowiednie doświadczenie. Drugim, zdecydowanie trudniejszym i bardziej czasochłonnym sposobem, jest studiowanie kodów innych gier. Tak więc są 2 drogi do jednego celu to jest twoja sprawa, którą wybierzesz.

FREQUENT

  • Gość
# Grudzień 26, 2007, 22:26:20
Hej uspokójcie się chłopaki, to doświadczony koder, więc nie opowiadajcie tu bzdet o podstawach C++ i API Windows.

Gra komputerowa, która ma odnieść komercyjny sukces to naprawdę potężny system.
Pooglądaj sobie diagramy dostępnych opensource’sowych silników graficznych a będziesz miał przedsmak tego czym jest gra.
Kod jako-tako skomplikowanej gry to około pół miliona linii kodu (liczę z toolsami, które są niezbędne). Przemyśl ile to będziesz klepał.

Offline vashpan

  • Użytkownik
    • Strona

# Grudzień 26, 2007, 22:45:33
Podlacze sie do tego co mowili poprzednicy - najlepiej samemu zabrac sie do roboty :) Ogolnie rzecz biorac myslisz dobrze, zreszta nie ma optymalnego rozwiazania, raz lepsze jest to innym razem co innego ;p Wiem ze to ogolniki, ale najlepiej chyba bedzie jak rzeczywiscie spojrzysz na jakas ( niewielka, ale dojrzala i dobra ) gre opensource, np. supertux ( czemu nie :D - kiedys lektura tego kodu zrodlowego naprawde mi pomogla, w sensie ogolnym... ) Przejedz to jakims doxygenem z diagramami i ogolny obraz od razu bedziesz mial a szczegoly w kodzie :)

A jezyki skryptowe - coz w grach mozna sie bez nich obyc, tym bardziej jezeli z zalozenia gracz nie ma miec duzego wplywu na gre, no to wszystko zalezy od gry, ale uzywa sie ich czesto w kwestiach ktore nie maja duzego znaczenia obliczeniowego, np. zachowanie postaci, zachowanie gui etc... Ale jak dla mnie przy niewielkiej grze nie ma to duzego sensu. W kazdym razie silnika fizycznego i graficznego lepiej w pythonie nie pisac ;p

Jednym slowem - zacznij pisac :)

Offline counterClockWise

  • Użytkownik

# Grudzień 26, 2007, 23:08:58
Każda gra może wyglądać inaczej - zależnie od metod stosowanych w korporacji. I moim skromnym prywatnym zdaniem, projektowanie architektury gry jest znacznie ciekawsze niż najnudniejsza sprawa jaka dla mnie istnieje w postaci j2ee.
A spotykane warstwy to:

- UI; I/O
- Moduł Grafiki 3D
- GUI, grafika 2D, jakieś overlay'e, HUD, Menu itp
- Moduł dźwiękowy
- Moduł fizyki
- Moduł sieciowy (to może być ogromnie skomplikowane i ingerujące w inne moduły)
- Kernel obsługujący wymianę informacji, zarządzanie message'ami (jeśli MD), entry point itp
- Logika (jakiś GameStateManager), AI
- Dziennik Zdarzeń, Logger, Konsola, Profiler,
- Garbage Collector, Resource Manager (jak zwał tak zwał)
- Moduł numeryczny (na samym dole jeśli z niczego nie korzystamy)

To tylko suche przykłady.
Z zaprojektowaniem architektury gry jest masa problemów jak choćby gdzie co trzymać, jak rozwiązać sprawę komunikacji między modułami, ile danych i jak wysyłać przez sieć, jak sparametryzować, oskryptować, zautomatyzować wiele spraw bez nadmiernego wysiłku i przyrostu kodu, jakich gotowych narzędzi/silników użyć i jak je zintegrować itd itd...

Offline MDW

  • Użytkownik
    • www.encore-games.com

# Grudzień 26, 2007, 23:29:04
A jak ma wyglądać? Gra wygląda tak jak ją sobie zaprojektujesz. :) Skoro jesteś doświadczonym programistą to na pewno jesteś sobie w stanie wyobrazić program choćby był tak specyficzny jak gra. Tak samo jak każdy inny program ma jakieś swoje dane. Tak samo można grę zaprojektować po bałaganiarsku i się w tym wszystkim zgubić podczas piasania. Podstawową różnicą między jakimś typowym biznesowym programem, a grą jest to, że w grze bardzo liczy się prędkość. Dla użytkownika programu biznesowego nie ma znaczenia czy wynik jakiejś operacji dostanie za 0.01 sekundy czy za 0.1 sekundy. No a  w grze różnica między 50 a 5 FPS jest taka, że albo w grę da się grać albo się nie da. :) Poza tym gra często ociera się o sztukę (tak jak np. film) więc pracują nad nią nie tylko rzemieślnicy.

FREQUENT

  • Gość
# Grudzień 26, 2007, 23:56:54
Poza tym gra często ociera się o sztukę (tak jak np. film) więc pracują nad nią nie tylko rzemieślnicy.
Pozwolisz, że ozdobię sobie, tym treściwym aczkolwiek krótkim zdaniem, swój nieogarnięty i niezbyt określony profil ?!  8)

//edit:@down:
Cytuj
Ale to trochę nieładnie nabijać się ze starszych. Cheesy Wink
Normalnie staram się, ale nie rozumiem. :)
« Ostatnia zmiana: Grudzień 27, 2007, 02:22:17 wysłana przez digress »

Offline MDW

  • Użytkownik
    • www.encore-games.com

# Grudzień 27, 2007, 00:49:35
Pozwolisz, że ozdobię sobie, tym treściwym aczkolwiek krótkim zdaniem, swój nieogarnięty i niezbyt określony profil ?!  8)

A proszę bardzo. :) Ale to trochę nieładnie nabijać się ze starszych. :D ;)

Offline michald

  • Użytkownik

# Grudzień 27, 2007, 20:01:13
Dzięki za wszystkie wypowiedzi, rozjaśniliście mi sprawę.

Artykuły na głównej stronie czytałem już parę razy wcześniej, są bardzo fajne i w ogóle extra że jest tam tyle materiału do edukacji :)

Bardzo spodobał mi się pomysł przeglądania kodów open source'owych gier - niby oczywiste, ale jakoś nie szukałem... A w Wikipedii na przykład jest fajny spis (http://en.wikipedia.org/wiki/List_of_open_source_games)

Pomysł z oglądaniem diagramów/wygenerowaniem_ich_doxygenem też jest w deche :)

BTW. Dziś za ostatnie pieniądze nabyłem nowe komponenty kompa wraz z grafą: GeForce 8800 GTS oraz CoD4. Zobaczymy :-)

Jeszcze raz dzięki i pozdrawiam,
Michal vel Dab3r

Offline wilk

  • Użytkownik

# Grudzień 27, 2007, 22:25:46
A wiec gra najczesciej wyglada tak

zmienne
wczytywanie obrazkow
wczytywanie duszkow

stan gry 

glowna petla
 sprawdz stan
 1:menu
 2:gra
 3:rekord
 4:info
 :5wyjscie
jesli wyjscie jest prawda to koniec petli

funkcja menu
 tworzy i wyswietla menu
koniec funkcji

funkcja gra
 sterownia
 sztuczna inteligencja
 rysowanie tla
 rysowanie duszkow
koniec funkcji

funkcja rekord
 wyswietla rekordy
koniec funkcji

funkcja info
 wyswietla informacje o grze
koniec funkcji

oczywiscie to jest uprostszony model gry,najlepiej samemu napisac albo zobaczyc kod jakies krotkiej gry.

Offline michald

  • Użytkownik

# Grudzień 28, 2007, 14:21:39
A wiec gra najczesciej wyglada tak (...)

Fajnie to rozpisałeś, ale czy zadanie "sprawdź stan" nie powinno być na początku funkcji "gra" ?

A jeszcze druga sprawa, czyli gdzie w grach się używa języków skryptowtych? Rozumiem, że nie chodzi o skrypty ułatwiające zbudowanei projektu, tylko skrypty zaszyte w samej grze. Słyszałem nei raz tekst, że jakaś gra jest mocno "poskryptowana", raczej nie pochlebna opinia, mówiąca, że dużo rzeczy w grze dzieje się na zasadzie "player wszedł w miejsce-wyzwalacz, to kładka się zawaliła".

Rozumiem, że do tego używa się w grach języków skryptowych. Tylko w jaki sposób?? Poczynając od pytania o osadzenie skryptu w aplikacji Win32 API. Wiem, że są biblioteki, które umożliwaiją wykonanie kodu skryptu z innego środowiska, np. biblioteka do C++, która wykonuje skrypty Perl'a. Czy to tak się osadza skrypty w grach? Bo mam przeczucie, że nie, ale nic innego mi do głowy nie przychodzi. I dlaczego akurat trzeba uzywać języków skryptowych a nie samego C++ ?

Pzdr.
Dab3r

Offline Kos

  • Użytkownik
    • kos.gd

# Grudzień 28, 2007, 14:30:22
Gdy się mówi, że gra jest, jak mówisz "poskryptowana", to chodzi raczej o to, że są w niej takie, jak mówisz, predefiniowane triggery, pozwalające na akcje typu "ha, stoję teraz na dwudziestej trzeciej desce tego mostu, i pamiętam że jeśli teraz zrobię krok w przód to się zawali". To pojęcie imo raczej nie ma dużo wspólnego z zastosowaniem języków skryptowych ;)
Te ostatnie są używane najczęściej do AI, choć nie tylko. Dlaczego nie samo C++? Żeby te np. zachowania botów nie były wkompilowane w program na stałe, a przypisane do pliku / zbioru plików danej postaci i interpretowane podczas wykonania. Sam język nie ma znaczenia, Quake 2 bodaj miał różne skrypciki obiektów (broń, pickupy, etc) napisane w języku QuakeC, o ile pamiętam; quake 3 chyba też. Gdy sobie wyripujesz paki, możesz się dobrać do tych skryptów, ludzie w ten sposób robili różne mody, jak chociażby shotgun strzelający pociskami z raila. Całe zachowanie broni było właśnie w pliku ze skryptem. Tak samo w grach można rozwiązywać zachowania NPC, by były złożone i nieprzewidywalne.