Programowanie Gier -> Pracownia Michalisa

Pracownia: piątek, 10:15-12:00, sala 110.

Pracownia 110 to Windowsy, jeżeli ktoś woli pokazywać pod Linuxem (do czego Michalis zachęca ), to Michalis ma Linuxa w swoim pokoju (z dość starą kartą graficzną NVidii) i na laptopie (ze stosunkowo dobrą ATI; będę go przynosił do ii kiedy będzie termin oddawania zadań).

Zasady

• Obecność na pracowni nie jest obowiązkowa. Jeżeli ktoś chce, może robić projekty sam w domu. Trzeba pojawiać się osobiście tylko na oddawanie projektów.
• Można używać dowolnego języka programowania, o ile
  1. jest implementacja open-source'owa jego kompilatora (ew. interpretera) albo
  2. jest zainstalowany na pracowniach w ii.
• Kod powinien być udokumentowany za pomocą narzędzia (open-souce'owego albo zainstalowanego na ii) Waszego wyboru. Np. doxygen, pydoc, ocamldoc, javadoc, pasdoc, fpdoc etc.

• Kod źródłowy powinien być trzymany w repozytorium SVN na serwerze michalis.ii.uni.wroc.pl. Wszyscy powinniście już dostać swoje hasło i wszystkie informacje o SVN mailem (o tytule "[ProgrGier] Twoje repozytorium SVN na michalis.ii.uni.wroc.pl"), w razie problemów zgłaszajcie się do Michalisa. Prośby o alternatywne (ale sensowne i open-source'owe) systemy kontroli wersji (np. git lub mercurial) będą akceptowane.

  Alternatywnie, jeżeli wiecie że Wasz projekt będzie na to zasługiwał :), można też założyć projekt na SourceForge.net, Google Code, Savannah albo innym serwerze hostingowym dla projektów FOSS. Wtedy naturalnie nie musicie korzystać z michalis.ii.

• Kiedy termin oddawania wszystkich zadań się zakończy, repozytoria zostaną otwarte na odczyt przez cały świat. Wybierzcie licencję zgodną z OSI na której chcecie żeby Wasz kod był dostępny (umieśćcie w repozytorium plik o nazwie COPYING albo LICENSE z tekstem wybranej licencji).

Punktacja

Punktacja:

Od 50% jest zaliczenie, przy czym za projekt końcowy trzeba uzyskać przynajmniej 30%.

Zadanie 1

W ramach "wprawki", zaimplementuj prostą grę z grafiką 2D. Podstawowe umiejętności które trzeba pokazać to posługiwanie się SDLem do grafiki 2D, ładowanie i wyświetlanie obrazków (można posłużyć się SDL_Image i rysować przez SDLa, ale można też użyć dowolnej innej biblioteki open-source do ładowania obrazków i rysować przez OpenGLa). Naturalnie trzeba też zaimplementować prostą logikę gry, to ma być coś grywalnego --- przynajmniej na kilka minut

Każdy sam wybiera jaką grę implementuje, myślę że to sprawi że rezultaty będą ciekawsze. Dobre pomysły to zaimplementowanie jakiejś bardzo, bardzo starej gry (DOSowej albo na automaty). Istnieje cała masa gier tego typu, zaimplementowanie ich przy użyciu nowoczesnych bibliotek jak SDL może być i łatwe i zabawne.

Konkretne pomysły można czerpać np. z "the crypt" na abandonii. Poza odmianami pacmana, tetrisa, SpaceInvaders etc. można tam znaleźć trochę mniej znanych "perełek", np. sopwith. Nie trzeba nawet grać w te gry, wystarczy popatrzeć na screenshoty aby nabrać inspiracji

Termin na wykonanie zadania: 27 marca.

Zadanie 2

Zadanie 3

Zadanie 3 to po prostu projekt końcowy. Elementarne założenia:

1. Ma to być grywalna gra, nie tylko engine.
2. Chcę ocenić Wasze zdolności programistyczne, więc gra musi mieć coś 3D i wykorzystywać sporo rzeczy omawianych na wykładzie. Jednocześnie, nie chcę oceniać Waszych umiejętności posługiwania się programami do tworzenia grafiki 2D lub 3D, więc nie wymagam żeby gra miała 30 leveli i 10 potworków. Dla niektórych gier, wystarczy nawet 1 level i 1 potworek, jeżeli będą wystarczająco skomplikowane i sprawią że gra będzie ciekawa. Oczywiście dla niektórych gier w ogóle nie będzie pojęcia level/potworek...

Rzeczy co do których daję Wam zupełnie wolną rękę:

1. Gatunek i klimat gry wybieracie sami (edukacyjny survival horror na bazie pasjansa?). Można zrobić strzelankę, można zrobić przygodówkę, strategię, cokolwiek Wam przyjdzie do głowy. W ramach inspiracji, można przejrzeć np. http://en.wikipedia.org/wiki/Video_game_genres. Tylko podkreślam: to nie jest zadanie z projektowania światów 3D, ani pisania dobrych scenariuszy do gier. Wymyślcie coś krótkiego, co zdołacie skończyć w te półtora miesiąca do końca wykładu. Jeżeli wymyślicie coś epickiego, to śmiało: ale zamiast robić "Moją Wielką Grę", zróbcie tylko pierwszy level / rozdział / etc. Waszej wymarzonej gry.

2. Sieciowość: ten element programowania gier nie został omówiony na wykładzie tak jak na to zasługuje, zwyczajnie nie ma to czasu, mamy na ii całe przedmioty temu poświęcone, a i tak każdy rodzaj gry ma swoją specyfikę. Odradzam porywanie się na grę sieciową czasu rzeczywistego. (Gra podzielona na tury, z ograniczoną ilością graczy, z założeniem szybkiej sieci lokalnej, gdzie gracze ufają sobie i nie stosują cheatów --- to może nie być takie straszne do zaimplementowania.) Jeżeli chcecie zrobić rozgrywkę "człowiek vs człowiek", pomyślcie np. nad prostszymi rozwiązaniami, jak "split-screen". Ostatecznie, decyzja czy (i jak) zrobić grę sieciową jest Wasza --- ale pamiętajcie że roboty i tak jest dużo, więc nie porywajcie się na to chyba że rzeczywiście bez tego Wasza gra nie ma sensu.

Wymagania:

1. Gra ma mieć elementy 3D zrobione w OpenGLu. Piszę "elementy", bo nie trzeba robić typowej kamery 3D w stylu FPS (z oczu gracza albo zza pleców postaci). Można kombinowac, ograniczyć kamerę np. do widoku z góry na świat, z perspektywą albo ortogonalną (ale, żeby nie było zbyt łatwo, nie można zupełnie oszukiwać i robić 99% gry w 2D...).
2. Naturalnie, elementy 3D muszą być ruchome. Swoboda ruchu gracza i innych elementów nie może być "tile-based", gdzie kolizje robimy przez proste testy ze stałą tablicą 2D albo 3D. Świat musi być możliwie dynamiczny. Wiem że to brzmi trochę mało precyzyjnie, ale trudno napisać coś precyzyjnego jednocześnie dając Wam dużą swobodę na wymyślenie własnej gry.
3. Trzeba mieć jakąś metodę badania kolizji. Z graczem, i/lub pomiędzy elemantami świata --- cokolwiek będzie odpowiednie. Nie narzucam konkretnej techniki, ale musi być szybka i odpowiednia do danej gry. Napisałem że "swiat musi być dynamiczny" w poprzednim punkcie właśnie po to aby zmusić Was do jakiejś mniej trywialnej metody sprawdzania kolizji.
4. Trzeba mieć jakś metodę obcinania dużej sceny dla OpenGLa. Może to być frustum culling zrobione w ramach zad2, może być coś innego (portale? hardware occlusion query?).
5. Gra musi mieć dźwięk. Nie narzucam używania OpenAL, ale trzeba użyć czegoś open-source. Dźwięk musi być co najmniej stereo, co najmniej uwzględniający odległość od źródła dźwięku. Najlepiej żeby po prostu był to dźwięk w przestrzzeni 3D. Musi być możliwość załadowania dłuższych dźwięków (ścieżka z muzyką, albo tekst mówiony).
6. Trzeba użyć przynajmniej dwóch z trzech nie-trywialnych technik renderowania:
   • bump mapping
   • lustra przez cube environment mapping, albo inne zastosowania render-to-texture (niekoniecznie do cube environment mapping, może być np. do renderowania portali (jak w Portal) / widoku z kamer (jak w Duke Nukem 3D))
   • cienie przez shadow maps albo shadow volumes albo volumetric lightmapping
7. Trzeba użyć shaderów GLSL albo Cg.
8. Trzeba wykorzystać albo zewnętrzny engine fizyki, albo zintegrować się z zewnętrznym językiem skryptowym.

Na razie to tyle.

Pierwszy etap: pomysł na grę, dźwięk

1. Wymyśl jaką grę chcesz robić. Ustal dokładnie jakich danych będziesz potrzebował (jakie/ile modeli 3D, jakie grafiki?). Ustal jak zrobisz podstawowe punkty z wymagań --- jak dynamiczny jest świat, jak zrobić na nim dobrze wykrywanie kolizji? Jak zrobić cienie? Czy bardziej przyda Ci się engine fizyki, czy porządny język skryptowy? Etc. Wreszcie: ile z kodu źródłowego zadania 2 wykorzystasz?
   • Zapisz to pokrótce w pliku tekstowym. Nie zależy mi na żadnym oficjalnym raporcie, nie starajcie się formatować żadnego pięknego dokumentu. Najzupełniej wystarczy zwykły plik tekstowy, krótki ale treściwy. Ma to być precyzyjny opis, odpowiadać na wszystkie pytania powyżej, wyjaśniać jak spełnicie wymagania projektu, opisywać gatunek/klimat gry, etc.

     Po czym koniecznie skonsultuj się z Michalisem czy jest Ok, czy coś dodać, czy za łatwe etc.

2. W ramach rozrywki, zaimplementuj dźwięk. Nie musi to jeszcze być zaimplementowane jako część Waszej gry. Nie musi to też być zaimplementowane jako dodatek do kodu z zadania 2. Po prostu --- pokażcie że umiecie wykorzystać jakąś bibliotekę open-source do robienia dźwięku.

Termin: 22 maja.

Drugi etap: shadery

Dopisz do swojego kodu ładującego i wyświetlającego modele 3D możliwość używania shaderów. Omawialiśmy GLSL na wykładzie, i myślę że zintegrowanie z GLSL będzie prostsze (skoro i tak jesteśmy nastawieni tylko na OpenGL), ale jeżeli ktoś chce --- można alternatywnie użyć Cg.

Nie chcę na tym etapie zmuszać Was do pisania większych shaderów, chodzi tylko o to żeby była możliwość załadowania shaderów i nałożenia ich na Wasze obiekty 3D, można testować z trywialnymi shaderami z wykładu.

Precyzyjnie wymagania/rekomendacje:

• Trzeba móc załadować fragment shader z 1 pliku (polecam: najlepiej pozwolić też na ładowanie fragment shadera z wielu plików, to jest przydatne kiedy mamy duże shadery).

• Analogicznie, trzeba móc załadować vertex shader z 1 pliku (i polecam żeby zezwolić na ładowanie ich z wielu plików).

• Musi być możliwość podmiany shaderów poprzez edycję danych gry (bez rekompilacji programu).

• I musi być możliwość nałożenia shaderów na coś mniejszego niż cały model z pliku 3D. Innymi słowy, jeżeli zrobię level 3D do Waszej gry, to musi być możliwość zapisania w pliku 3D że niektóre elementy używają jednego zestawu fragment i/lub vertex shader, inne elementy --- innego zestawu shaderów.

Na przykład dla Wavefront OBJ można dodać obsługę linijek zaczynających się od tokenów "vertshader", "fragshader":

o Obiekt1
vertshader nazwa_pliku_z_vertex_shader.vs
fragshader nazwa_pliku_z_fragment_shaderem.fs
....
o Obiekt2
vertshader nazwa_pliku_z_vertex_shader_2.vs
fragshader nazwa_pliku_z_fragment_shaderem_2.fs
....

(Nie, to nie jest żadne oficjalne rozszerzenie Wavefront OBJ, wymyśliłem to przed chwilą.) Można zrobić shadery dla każdego obiektu ("o") albo grupy ("g") Wavefronta, co Wam będzie wygodniej.

Kto obsługuje Colladę, może odczytywać shadery podążając za specyfikacją Collady, ale pozwalam też na chwilę zignorować standard i rozszerzyć XML Colladę tak jak Wam będzie wygodnie to zaimplementować.

Acha, i jeszcze jedno wymaganie:

• Przy próbie kompilacji i linkowania shaderów mogą występować błędy. Trzeba sprawdzać czy shader się odpowiednio skompilował/zlinkował i w razie błędów trzeba pobierać od OpenGLa informację o tym jakie to błędy, i trzeba to gdzieś wyświetlać (do loggera, na konsolę etc. --- byle było widoczne). Patrz funkcje glGetProgramiv(ProgramId, GL_INFO_LOG_LENGTH, ...);, glGetProgramInfoLog(ProgramId, ...);, glGetShaderiv(ShaderId, GL_INFO_LOG_LENGTH, ...);, glGetShaderInfoLog(ShaderId, ...);  (jeżeli używanie funkcji shaderów w OpenGL 2.0 core) albo analogiczne glGetObjectParameterivARB(ObjectId, GL_OBJECT_INFO_LOG_LENGTH_ARB, ....); i glGetInfoLogARB(ObjectId, ...)

Acha, można użyć funkcji OpenGLa 2.0 albo rozszerzeń ARB do shaderów (ARB_shader_objects, ARB_vertex_shader, ARB_fragment_shader, ARB_shading_language_100). Które będzie Wam wygodniej (albo: które Wasz OpenGL implementuje).

Czyli w skrócie, trzeba zaimplementować to co opisałem w sekcji API OpenGLa do shaderów na wykładzie.

Termin: za tydzień, czyli 29 maja.

Etap ostatni: końcowa gra !

(Poniżej skrót maila:)

Czas na skończenie projektu macie do 28 czerwca. Tak, to już w czasie sesji. Nie, nie ustaliliśmy jeszcze kiedy będzie egzamin, ale wiemy już na pewno że do oceny końcowej (z wykładu) 50% punktów będzie branych z egzaminu (łatwego!, jak obiecywaliśmy) a 50% z projektu końcowego (który jest na tym przedmiocie najważniejszy, tak jak ostrzegaliśmy od początku ).

Nie będę już narzucał Wam kolejnych tygodniowych zadań, ponieważ rozwój każdej gry powinien już biec swoim torem. Każdy z Was wie najlepiej w jakiej kolejności musi dodawać kolejne elementy gry żeby pracowało się Wam wygodnie, szybko, i żeby powstała gra i grywalna i stabilna.

Osoby które pracowały mają już gotowe techniczne podstawy (engine do wyświetlania 3D z shaderami, kolizjami i dźwiękiem). Z dużych rzeczy technicznych pozostało Wam zrobić ładne efekty graficzne (bump mapping i/lub cienie i/lub lustra etc.) i zintegrować się z fizyką albo językiem skryptowym. I, co najważniejsze, oczywiście zaimplementować całą grę którą zaplanowaliście. Sami decydujecie od teraz w jakiej kolejności to wszystko zrobicie.

Jedna moja rada (a na ile użyteczna, zdecyduje każdy sam patrząc na swój kod i cele gry): zanim zajmiecie się polerowaniem silnika, spróbujcie zrobić "szkicową" wersję "alpha" Waszej gry przy użyciu takiego silnika 3D jakie macie dzisiaj. Zasugeruję nawet więcej: spróbujcie zrobić to w tydzień, serio. Mówiąc wprost, po prostu spróbujcie sklecić Waszą grę na szybko, byle jak, używając silnika takiego jaki macie. Potem wszystko przerobicie --- ale w ciągu tygodnia robienia takiego "szkicu" gry zorientujecie się jak szybko to idzie, co konkretnie jest potrzebne do gry, gdzie Wasz silnik wymaga poprawy, etc. Pamiętajcie że wymagania techniczne (ta długa lista na początku zadania) to jedno, a drugim wymaganiem jest cały czas "chcemy zrobić grywalną grę".

Acha, i jeszcze jedno: chociaż nie ma konkretnego zadania na najbliższe piątki, zapraszam a nawet wymagam pojawiania się na pracowni w czerwcu. Przychodźcie i pokazujcie mi co tydzień Wasze postępy.

(Skrót informacji z maila 19 czerwca:)

Michalis ma miękkie serce i zgodził się żeby ostateczny (ale to naprawdę kompletnie-bezwzględnie-nieodwołalnie ostateczny) termin oddawania projektów był 10 lipca. Co nie zmienia faktu że 28 czerwca (oficjalny termin) trzeba pokazać przynajmniej szkielet gry (czytaj: coś co spełnia chociaż część założeń projektu, i ma coś więcej niż tylko wymagania na "etap drugi - shadery").