spyked bricks in the wall

the first, the person and the shooter

[ sau cum să scrii un FPS în cel mult puțin patru zile ]

În mod cert, a scrie un FPS (acronim pentru First Person Shooter în acest caz) nu-i treabă ușoară. Necesită timp, răbdare și o echipă pusă pe treabă, chiar și atunci când se pune baza într-un motor grafic/fizic deja existent; sau mai ales atunci. Cu toate astea, m-am decis să fiu un smartass (în traducere liberă, un „fund deștept”, cât de deștept poate fi un dos de om) și – spre disperarea unora și amuzamentul altora – să neg tot ce am spus adineauri. Cu alte cuvinte, realizarea unui shooter schelet de shooter nu durează în realitate mai mult de patru zile, testat. Mai mult, orice student în anul al treilea de CS vă poate confirma asta.

Se dau următoarele ingrediente:

• Un set de modele 3D, cu sau fără texturi, animate sau neanimate, în funcție de tema jocului. Sigur, se pot concepe de la zero, dar munca în plus ar fi imensă. De exemplu, aici există o serie de modele (statice), cât și codul sursă al unui program care le parsează. Se poate recurge la câteva formate mai avansate, dar nu intru în detalii.
• Cunoștințe medii ale unui limbaj de programare cât de cât cunoscut (oricare din gama C++, Python, Java, C#, asta dacă nu vă dau prin minte ceva gânduri exotice). Nu e nevoie de cunoștințe avansate, dar aveți nevoie de cunoștințe minime de programare orientată pe obiecte în cazul limbajelor menționate anterior; asta dacă nu vreți cumva să lucrați în C, caz în care timpul de lucru crește semnificativ, pe cuvânt. De asemenea, trebuie avută în vedere descărcarea unui compilator sau interpretor pentru limbajul în cauză.
• O bibliotecă pentru grafică 3D; fie ea GLUT, SDL sau DirectX. Ultimele două sunt mai sofisticate, lucrând și cu sunet și având primitive mai serioase pentru alte controllere (joystick și altele). Important e să aveți documentația la îndemână și o experiență minimă în folosirea uneia din ele (unde prin experiență minimă se înțelege dezvoltarea unui schelet de aplicație folosind biblioteca respectivă).
• Patru zile libere. Asta înseamnă cam zece ore de lucru pe zi => se renunță la jocuri, filme, prietenă (prieten, în cazul programatoarelor), bere cu amicii, școală, muncă etc. Ne pare rău, dar asta e situația.

Ca fapt divers, subsemnatul a ales combinația C++ și GLUT, fiindcă așa s-a cerut la temă. Deși poate părea mai greoi la prima vedere, l-am preferat în detrimentul unor abominații cum e Java (și orice ați spune voi, eu am dreptate, da? Sper că ne-am înțeles). În plus, cartea lui Bjarne e sfântă.

Iar rețeta propriu-zisă sună cam în felul următor:

• Se face un scurt plan; preferabil o diagramă UML (asta dacă s-a ales paradigma orientată pe obiect; în cazul în care programați funcțional, eu spun că sunteți deja prea meseriași să citiți rețete de genul), dar se poate recurge într-un mod mai simplu la clasicele creion și foaie. Se schițează un plan de bătaie, având în vedere câteva lucruri de bun simț – toate astea durează maxim patru ore și scutesc programatorul de o groază de dureri de cap:
  • Simplitate: cu alte cuvinte, aveți grijă să nu vă duceți în bălării cu clasele și metodele. Aveți în vedere folosirea bibliotecilor standard din limbaj (STL în cazul C++), nu redefiniți structuri de date acolo unde nu este nevoie. C# e un plus, fiindcă are XNA.
  • Reutilizabilitate/modularitate: altfel ați putea programa lejer în Brainfuck și nu orientat pe obiecte. Se aplică la fel de bine și la paradigmele procedurală și funcțională, în ciuda aparențelor. De asemenea, e good practice ca logica jocului să fie pe cât posibil separată de partea de desenare.
  • Ierarhie: evitați moștenirea multiplă și orice alt aducător de posibile probleme. Mențineți o ierarhie simplă de genul Object3D => Enemy, Projectile, Player și așa mai departe. Nu faceți headere/module care să se includă reciproc, decât în cazul în care vreți ca preprocesorul/compilatorul să o ia razna.
• Se dă comandă la un stack de pizza, câteva sticle de cola și se pregătește din timp patul, pentru a avea o alternanță somn – cod cât mai lină. De asemenea, se închid telefonul, messenger și alte posibile time-wasters.
• Se trece la treabă.
• După treabă, se trece la ciclul de testare – debugging.
• Abia apoi se respiră.

În funcție de funcționalitatea dorită, realizarea aplicației va dura mai mult sau mai puțin: vreți modele animate – o zi în plus; vreți motor fizic – două săptămâni în plus; și așa mai departe. Sper că nu am uitat să amintesc faptul că e musai să aveți câteva cunoștințe despre cum se iluminează o scenă, cum se face o detectare a coliziunilor, așa, chestii mărunte fără care nu puteți face o clonă de Mario, să nu mai vorbesc de un shooter.

După depunerea unei munci titanice, din care rezultă în jur de două mii de linii de cod (plus – minus câteva sute), vă puteți mândri de munca voastră, care va arăta mai mult sau mai puțin în felul următor [*]:

Și uite așa vă puteți declara un dezvoltator de shootere, cam ca și Carmack în tinerețile lui. Ei, cum vi se pare?

[*] – Results may vary. You’ve been warned!