Hello,

Mi-am propus sa fac un joc pe calculator si de data asta chiar sa il termin. Jocul ales va fi street fighter si anume in genul alpha 2 sau 3. Nu stiu cand il voi termina, pentru ca sunt ultimul an la master si am o gramada de proiecte, dar mi-ar placea sa obtin feedback de la voi nu doar pentru a imbunatati viitorul joc dar si pentru a identifica anumite bug-uri din joc. Fiind un singur om, e greu sa testezi jocul pentru fiecare scenariu posibil si plus ca, stiti cum e, iti cunosti proiectul atat de bine, incat nu il mai vezi per ansamblu si te concentrezi prea mult pe detalii.
Asadar, dupa aceasta mica introducere, mi-am ales cateva milestones pe care trebuie sa le realizez:

1. the moves validator: Se bazeaza pe o arhitectura interesanta, care imi va permite sa il folosesc in orice joc, sa decteze orice miscare si sa o valideze. Va suporta orice combouri. Evident va trebui sa fie usor de folosit in final si practic.

2. animation system: Aici nu ma refer doar la sistemul de animatii, ci si interpolari intre animatii si cum o actiune determina o anumita animatie. Trebuie sa fie total indepedent de joc, sa ruleze in paralel. Se va axa pe un design pattern bine cunoscut - game state pattern(+altele)

3. Data Base design: Vor fi multe personaje, animatii, sunete. Fiecare personaj cu magiile lui si trebuiesc stocate. Inca nu stiu daca voi folosi xml, plain txt sau binary files. Probabil voi merge in final pe binary, sa protejez datele

4. The scrolling mechanism: Orice joc care se respecta, are un fundal care se deruleaza. Voi incerca din nou sa ma axez pe un sistem cat mai indepedent de joc, sa il pot refolosi si mai mult sa implementez un sistem gen Parallax Scrolling(derularea mai multor fundaluri, fiecare cu viteza lui, ceea ce va da senzatia de adancime)

5. The collision detection: Asta se va baza pe interactiunea dintre personaje. Voi face un editor, in care se definesc zonele de contact pentru fiecare jucator, pentru a realiza un collision cat mai 'real' intre personaje.

Dupa cum vedeti, sunt interesat nu doar in joc, ci mai ales in aritectura sistemului. Cum zicea cineva "toti stim sa scriem programe..putini stim sa scriem programe bune". Dupa asta ma voi ghida. Tot ceea ce fac, sa poata fi reutilizat, flexibil, extensibil si usor de verificat. Voi posta ideile mele aici; va voi prezint abordarea mea, din 2 motive: Poate unii vor aprecia si ii va ajuta, iar altii, ceea ce imi doresc, e sa ma corecteze sau sa ma indrume spre un design mai bun

Sa nu uit, folosesc C++ in Visual Studio 2008 si HGE pentru grafica.

Weekendul asta voi incepe cu moves validator si de indata ca voi termina, voi pune un link ca sa il testati sa vedeti daca ati gasit ceva bug-uri, daca are delay-uri, daca merge pe calculatorul vostru, daca recunoaste fiecare miscare, etc.

Sa ne auzim cu bine

Spor.

Iti recomand VS 2010 in loc de 2008. HGE e ok. Pentru contacte ai putea folosi un engine fizic gen Box2D. Chiar daca nu il folosesti pentru collision response, e foarte bun la collision detection.

Si o intrebare: Move Validator-ul asta e un fel de masina de stari?

Helo,
Da, stiu ca VS2010 e mai bun, dar inca nu este integrat code rush si refactor pro pentru el si lucrez foarte mult cu ele. La fel si cu visual assistX. Deocamdata VS2008 e foarte bun pentru ce fac.

Cat despre contacte, m-am gandit la box2D, e foarte bun, da! L-am folosit de multe ori, doar ca in acest context nu prea isi are rost, fiind vorba de un simplu box collision. Oricum, bine ca mi-ai adus aminte de el! Imi poate rezolva o problema la care ma tot gandeam si anume ce sa fac la impactul dintre personaje si cum sa aplic fortele..asa ca multumesc

Cat despre moves validator, voi posta maine probabil sistemul, chiar acum lucrez la el. Dar nu este vorba de o masina de stari. Ideea de baza, este ca se verifica fiecare key apasat, se pune intr-o stiva, care contine tasta apasata si cat timp a fost apasata, cand a fost apasata si cand a fost released. Dupa care stiva este analizata de un MovesValidator, care isi ia din stiva butoanele si verifca combinatia(trebuie sa treaca prin mai multe teste ca o combinatie sa fie valida - cum ar fi timingurile). Combinatia este verificata raportat la o baza de date, unde este specificata. Mai exista si ideea de prioritate - mai multe combinatii pot fi valide. Asa ca toate combinatiile valide, sunt preluate de un Manager, care in final va returna combinatia cu prioritatea cea mai mare.

Imi place ideea ta, zici ca esti un singur om, sunt curios cum vrei proceda cu sprite-urile pentru personaje, sau vei folosi sprite-uri gata facute de pe internet ? De asemenea ai in gand si o implementare de multiplayer ?
Ai jucat Street Fighter IV ? pe mine m-a fascinat nivelul de detaliu al fundalului...

Fiind singur, ma voi concentra mai mult pe jocul in since, vorba aia, vreau sa devin game programmer, nu designer)

Sprite-urile le voi lua gata facute, am gasit pentru toti jucatorii, in toate pozitile. Sunt foarte multe, va dura putin pana le voi aranja, dar macar sunt facute.

Cat despre SF4, am jucat da. E superb jocul! Detaliile, fiind un joc de ultima generatie sunt pe masura. Si eu vreau sa ma axez foarte mult pe detalii, sa nu am nivele statice. De aceea am zis ca trebuie sa implementez si un sistem de parallax scrolling care include si caractere animate in fundal(gen cei care aplauda cand te bati, scari rulante, etc)

Multiplayer-ul va mai trebui sa astepte pentru ca sunt doar la inceput si am foarte multe de invatat. Cand va fi gata, evident va fi pentru 2 player mode.. de acolo, implementarea de multiplayer sper ca nu va fi prea grea, presupunand, in foarte mare, ca tot ce trebuie sa fac e sa trimit datele despre jucatori la un server si sa le citesc, apoi sa le transpun in joc. Dar, dupa cum ziceam, inca nu stiu partea de multiplayer.

In sfarsit am reusit sa termin acest Moves Validator. Pentru inceput o mica descriere a aplicatiei.

Butoanele de baza sunt

left,right,up,down - from arrow keys
a - low punch(lp)
s - mid punch(mp)
d - high punch(hp)
q - low kick(lk)
w - mid kick(mk)
e - high kick(hk)
esc - terminate application

Combourile pe care le poti face sunt

LowHadouken down right lp
MediumHadouken down right mp
HighHadouken down right hp
LowShoryuken right down right lp
MediumShoryuken right down right mp
HighShoryuken right down right hp
LowHurricaneKick down left lk
MediumHurricaneKick down left mk
HighHurricaneKick down left hk
Catch lk+lp
LowSuper down right down right lp
MediumSuper down right down right mp
HighSuper down right down right hp
Ultimate down right down right lp+mp+hp

obs: lp+lk, inseamna ca se apasa in acelasi timp

O sa vedeti un fisier acolo, assets\moves\ryu.txt

Acolo puteti adauga si miscarile voastre daca vreti dupa formula NumeMiscare Prioritate 0/1 [lista de miscari dupa exemple]
Acel 0/1 inseamna CHARGE. Adica, magii cum are guyle de exemplu.

Deocamdata nu se pot modifica butoanele, decat din fisierul sursa, dar nu va fi greu de implementat un editor de controale.

Aici e linkul pentru aplicatie: http://www.box.net/shared/e7uruaghb8

Acuma, pentru cei interesati voi descrie pe scurt arhitectura sistemului. Asta e diagrama de clase, simplificata.



InputHandle
O clasa abstracta care verifica daca o anumita KEY a fost apasata si o adauga in InputStack. Ea verifica doar KEYs-urile care au fost definite in baza de date. Acest sistem imi permite sa definesc customizable controls in timpul jocului. Toate clasele care vor fi derivate din clasa asta, vor trebui sa contina practica 2 functii importante, bool keyPressed(Key*) si bool keyReleased(Key*).

XXX_InputHandle
Reprezinta implementarea concreta a clasei abstracte de mai sus. Abstractizarea asta imi permite sa accept input de la orice sistem: keyboard, mouse, gamepad, xbox controller, stick arcade. nu are importanta atat timp cat respecta regulile de baza. Acum am implementat pentru keyboard si XBOX, folosind XInput.

Key
Practic e o clasa care contine toate informatiile despre key-ul care a fost apasat. Informatii cum ar fi nume, functionalitate, si un time stamp care imi zice cand a fost apasata/ridicata si timpul total.

Key_DataBase
Asta contine baza de data cu butoanele care sunt disponibile pentru utilizator. Si se creeaza foarte usor de forma



Key_DataBase_Factory
Practic, dupa cum spune numele, se foloseste de factory design pattern si faciliteaza procesul de crearea de mai sus. Aceasta faciliteaza procesul de selectie a unui input predefinit.

InputStack
Contine ultimele N keys apasate si pe masura ce se adauga mai multe, se sterg primele.

SpecialMoveValidator
Reprezinta Creierul operatiunii. Verifica inputul din Stack-ul de mai sus si contine metoda de baza bool is Valid() care este apelata de client. Acum, pentru a putea verifica daca o miscare este valid sau nu, ea trebuie compusa dupa forma:



Algoritmul de baza, care verifica daca e sau nu valida o combinatie introdusa, se bazeaza pe checks.



SpecialMoveValidator_Factory
Faciliteaza procesul de creatie de mai sus pentru un special move.

SpecialMovesValidator_Manager
Contine o lista de special moves, pentru un caracter, si returneaza doar una singura valida si anume cea cu prioritatea cea mai mare. Astfel ca, in final, totul se reduce la un cod usor de folosit. De asemnea se ocupa si de incarcarea fisierului cu miscarile definite pentru un caracter.



Pana acum, din cate l-am testat se comporta bine. Recunoaste miscarile, timpii de executie sunt decenti, si nu are bug-uri. Probabil pe viitor voi implementa o aplicatie in care utilizatorul isi defineste butoanele...ar fi chiar necesara o astfel de aplicatie, asa ca probabil va fi urmatoarea pe lista.

Vezi ca ai scris de 3 ori "design pattern" in 2 post-uri despre un joc cu bataie. Nu-i a buna.

Am citit articolul si nu sunt deacord cu el Si dupa cum vezi este o mare controversa la el pe blog, despre acel articol.

Toate sistemele complexe au la baza o arhitectura extensibila, flexibila si usor de intretinut. Da, se poate face si fara design patterns, dar un design pattern trebuie privit doar ca o organizare metodica a claselor pentru a rezolva probleme comune. Evident, nu trebuie abuzat de ele, dar stau la baza oricarui design bun.

Pentru mine este mult mai usor sa ma bazez pe ele, imi rezolva multe probleme si in final am un cod usor de citit si mai ales de folosit. Cand vreau sa il extind, simplu, mai adaug o clasa fara sa modific nimic altceva.

Evident ca iti poti prinde urechile in OOD si totul poate deveni foarte complicat. Studiez de un an design patterns, deci nu de foarte mult timp, mai am mult de invatat, dar pana acum, cat am aplicat si folosit, mi-au usurat munca foarte mult.

Ok, eu iti recomand doar sa nu te concentrezi pe termeni pomposi facuti pentru a vinde carti si bilete la conferinte. In lumea reala, "design patterns" astea nu rezolva nici o problema de arhitectura, extensibilitate si ce mai zici tu acolo pentru ca sint banalitati izvorite din capetele unora care cred ca-i mai important sa arati cool cind programezi decit sa programezi. Singurul lucru pe care l-ar putea inlesni ar fi comunicarea, ca sa poti sa zici "MVC" in loc sa povestesti de fiecare data modul banal in care freaca o pagina web niste date. Nici asta nu au reusit insa, deoarece ca sa vinzi bilete la conferinte trebuie sa adaugi o aura obscura si mistica unor concepte banale. N-o sa vina nimeni sa te auda vorbind despre variabile globale si instructiunea switch. Zi-i insa variabilei globale "singleton" si instructiunii switch "factory pattern" sau "reactor pattern" si sa vezi cum ti se umfla buzunarul.

Nu judeca parerea aluia doar pentru ca s-au gasit niste mintosi sa-l contrazica. Ala e director tehnic la Sony Santa Monica, a scris o carte de referinta despre collision detection si - surprinzator - a fost profesor universitar inainte sa coboare printre muritori. Aia din tabara cealalta sint bagatori de seama care au cumparat o carte de solutii si se cred invingatori.

Design patterns, impreuna cu rudele lor new-age legate de programare si project management gen Agile si XP, sint incercarile unor oameni simpli de a rezolva problemele foarte simple de care se lovesc - sau, cum zicea unul foarte bine, sint facute pentru a scrie "huge piles of straightforward code". In particular, sint facute, folosite si propovaduite de catre programatorii web. Cind ajungi la lucruri mai interesante observi ca nu te mai pasioneaza trivialitati gen ce clasa deriveaza din ce clasa, sau cum faci tu new in functie de valoarea unui enum, pentru ca astea nu comunica nimic despre problema si solutia ta. De asemenea, chestia aia cu software-ul modular si extensibil e un mit cu care nu e bine sa iesi din scoala, ca o sa te doara cind cazi pe un proiect real (mai ales daca te tii de game development).

Din ce-a zis Ericsson ala acolo, conteaza sa tii minte doar 2 fraze: "Thinking in patterns is exactly the wrong thing to do! It makes you think in terms of the solution instead of in terms of the problem!". Ti-am scris toata povestea asta pentru ca am mai vazut cazuri de oameni care au cazut victima sindromului "avem solutii, cautam probleme". Nu vreau sa fac polemici pe tema asta, ci doar sa mentionez ca in afara site-urilor de dating si a aplicatiilor de contabilitate, valoarea design pattern-urilor este destul de incerta.

PS: vezi ca am impresia ca returnezi un deque by value, ceea ce e o crima mult mai mare decit sa nu stii ca aristocratii programarii numesc variabila globala "singleton".

Merci mult si da ai perfecta dreptate! Deocamdata nu am lucrat la un proiect 'real' si de aceea poate inca cred ca 'tot ce zboara se mananca' si mi se pare ca design patterns reprezinta o solutie 'pompoasa' pentru niste probleme simple.


Aici ai dreptate, da...Si uneori e bine sa stii cuvinte mari pentru ca situatia materiala e importanta.


unde?aici bool SpecialMoveValidator::isValid()? aici doar bool returnez.
sau aici? deque keysFromStack = inputStack->getLastKeys(keyCombination.size());?


Merci de sfaturi si voi incerca, pe cat posibil sa le urmez. Desi stiu ca cel mai bine e sa inveti din greselile tale, prefer sa fac greseli pe proiecte personale, ca sa ma invat pe cand voi lucra pe un proiect real

ps- foarte reusit site-ul tau! am stat azi si am citit cateva ore

Cred ca aici returnezi deque prin valoare :
deque keysFromStack = inputStack->getLastKeys(keyCombination.size());


Despre design patterns. Nu am citit decat cateva, dar imi amintesc ca la majoritatea am ramas cu impresia "Chiar trebuie si o denumire pentru chestia asta ?".
Cu toate astea decorator pattern mi s-a parut destul de destept(nu cred ca ma gandeam singur la solutia aia), dar destul de urat de folosit. Ca sa nu schimb topicul, daca e alta metoda de a obtine acelasi efect vreau si eu o denumire, un link, ceva scurt.

Bafta la street fighter

Da, dar ca in orice religie sau alta forma de inselatorie, e bine pina incepi sa crezi si tu. Daca vrei sa-i exploatezi pe altii folosind cuvintele magice, e ok (desi exista lucruri mai putin injositoare din care poti cistiga bani ca programator), dar e bine sa nu devii tu ala exploatat.



Da, acolo. Presupun ca inputStack ala are un membru de tip deque si tu il tot copiezi acolo, in loc sa returnezi o referinta const la el. Alocarile de memorie si copierile inutile sint cea mai mare problema de performanta in jocuri, mai ales ca se ascund in spatele unor chestii care par inofensive, gen returnat sau pasat o variabila.

As mai avea o sugestie de stil: scapa de this-> ala. Compilatorul stie sa cheme metodele alea si fara this->, iar pe tine nu te ajuta la nimic, ca presupun ca nu obisnuiesti sa ai jdemii de functii globale pe care sa le poti confunda cu metodele clasei.



Mersi, dar nu e al meu. Eu contribui ocazional.



Mie gunoiul ala mi se pare un exemplu foarte elocvent de cit de idioate si random sint pattern-urile astea. As vrea sa vad si eu un caz practic si non-trivial in care poti extinde un obiect in doua feluri, iar acele doua feluri pot fi combinate fara sa stie unul de altul. De fapt o sa ajungi sa ai prin toti decoratorii aia diverse verificari sa vezi daca nu cumva e aplicat si un alt decorator, ca sa vorbesti cu ala sa faci altceva daca e si el prin preajma. Mi se pare ilar cum cineva s-a putut gindi ca acest artificiu sintactic te scapa de explozia combinatorica ce apare cind un obiect de baza poate avea nu stiu cite feature-uri optionale.

Decoratoru' asta face exact ce zicea Ericsson sa nu faci: te pune sa incerci sa-ti adaptezi problema unei solutii, in loc sa cauti o solutie pentru problema. Ai fi mult mai cistigat daca te-ai gindi in fiecare caz ce fel de design se preteaza la problema in sine, in loc sa incerci sa adaptezi o mizerie d-asta cu decoratori si sa ajungi la chestii imbecile gen "nu pot sa implementez asta pentru ca nu-mi permite arhitectura".

De asemenea, decoratorul ala e legat de limbaj. In Python nu s-ar face asa. Programarea si design-ul aplicatiilor nu-s legate de limbaj. Limbajul e doar o modalitate de a exprima o solutie, nu e o unealta pentru gasirea solutiei aleia. Intii te gindesti cum faci un sistem extensibil si dupa aia vezi cum exprimi asta in limbajul in care trebuie sa-l implementezi. Mai toate pattern-urile astea sint de fapt moduri de a exprima chestii in Java. Exemplul meu preferat e singleton-ul, care e pur si simplu un mod de a face o variabila globala in Java, care n-are variabile globale in sintaxa. Cumva, aceasta banalitate (un if si eventual un mutex, daca te simti next-gen) necesara intr-un limbaj oarecare a devenit peste noapte un lucru relevant pentru intreaga lume a programarii.

Eu nu vad cum te ajuta pattern-ul ala, sau cu ce ar trebui sa ramii din el. Cumva, se bazeaza pe ideea de a face o interfata pentru modificatori si de a pasa niste date de la un modificator la altul, intr-un lant. Ideea asta merita mentionata, desi nu-i rocket science si orice programator ar trebui sa se prinda singur cum se face si cind se aplica un astfel de design. Totusi, e greu de extras ideea din descrierea standard a acestui "pattern", pentru ca pattern-ul e mai preocupat de cum sa implementezi o versiune limitata a acestui design in Java si cum s-o desenezi in UML. E ca si cum ai incerca sa faci pe cineva sa priceapa o demonstratie matematica explicindu-i cum se deseneaza literele grecesti si semnul ∈, in loc sa-i explici ideea si logica demonstratiei in sine.

Merci mult pentru sfatul cu deque! Chiar acum am corectat si stiu cat de mult conteaza viteza in jocuri precum si optimizarile.

Acum, sa revenim putin pe taramurile noastre, am implementat Parallax Scroller. Dupa multe modificari, am reusit sa reduc folosirea claselor, la ceva foarte simplu si straightforward.




Aici este linkul spre aplicatie ca sa o puteti incerca si sa vedeti daca ruleaza cum trebuie
http://www.box.net/shared/cfkm1rr3i2


Cu up,down,left,right controlati personajul. Nu are boundaries Check, sau collision detection. Aplicatia se refera strict la parallax scrolling. Partea buna e ca o pot folosi in orice joc si e dependenta doar de acel getPlacementComponent() care practic imi zice unde este personajul tot timpul ca sa poata fi urmarit.

Parallax Scrolling-ul merge si se vede frumos.

Merci de feedback
Acum incerc sa fac mici optimizari la el. Nu stiam exact daca merge pe alt pc, pentru ca deobicei uit sa adaug toate dll-urile necesare.