mloh3 Zoran Stupic
Član broj: 101240 Poruke: 13 *.beotel.net.
|
Da, bolje je da imas nasledjenu klasu za svakog neprijatelja, jer ce ti se AI razlikovati, tj. ponasanje - sto vuce sa sobom i posebne promenljive clanice.
Imaces nesto kao npr: virtual int Update(float dt); i tu ce ti se razlikovati update od neprijatelja do neprijatelja.
Sto se tice gomile klase, bolje tako nego gomila koda u jednoj klasi ( sta ce ti onda klase uopste???, radi strukturno :) ). "Gomilanje klasa" moze da bude problem ako budes imao vise stotina neprijatelja, sto sumnjam da je slucaj. Cak i tada ce biti preglednije i lakse raditi!
Imaces zaseban .h i .cpp fajl za svakog neprijatelja i bice veoma pregledno ono sto radis. Osim toga mozes sve neprijatelje da drzis u jednom nizu, pa kad krenes update za sve, samo protrcis kroz niz i svakom kazes update, a on ce vec znati sta da radi. Od svih njih formiras npr: enemy_lib, pa iskoristis za sledecu igricu, tako sto uzmes vec gotove enemije ili dodas nove.
Constructor tipa switch(enemy_type) = nocna mora. Update metoda ce ti tek biti smor, pogotovu sto ces imati FSM, za svaki od tipova neprijatelja, pa ce ti kod izgledati otprilike ovako:
switch(enemy_type)
case FIGHTER1 :
switch(fighter1_state)
case DIE:
itd...
Tako ce ti vremenom metoda update rasti i FSM-ovi ce se gnjezditi jedan u drugom dok ne budes dobio Update junglu ...
Reset metoda, isti problem. Destructor, isti problem.
Ovako napises mali konstruktor za svakog neprijatelja, koji radi samo ono sto treba. Ako dodajes nesto kao particle sistem, za nekog izvednog enemija, to onda lepo odradis u konstruktoru pa samo enemy koji treba da ima svoj partikce sistem, zaista ga i ima, a ne svaki.
Kad nesto budes menjao u bossenemy3, nema bojazni da se pokvari nesto u ostalim neprijateljima. Ako na primer naguras sve u jednu klasu, doci ces u iskusenje da koristis istu promenjlivu-clanicu za vise tipova neprijatelja sto unosi dodatnu nepreglednost. Ispravke su mnogo lakse kad su klase "razdvojene".
Sto se tice osnovne klase enemy, u njoj zadrzi samo ono sto je zajednicko za sve enemije, nemoj da je prepunis. Ako neki nasledjeni enemy nema koristi od nekog clanice-promenljive osnovne klase, onda mu nije mesto u osnovnoj klasi. Ako se tu dvoumis jednostavno izvedi npr:
enemy->bossenemy
enemy->groundenemy, pa onda iz njih izvedi konkretne klase.
Takodje za osnovnu klasu enemy, vidi sta ces da ugradis? Ako imas nesto kao cSprite ili slicno koji sa sobom vuce operatore za koliziju, distancu i slicno, onda i osnovnu klasu enemy nasledi iz cSprite.
cSprite bi mogao da ima i npr: virtual void Render(...), koji ce ti se lepo provuci kroz drvo nasledjivanja, pa ces moci da za svakog konkretnog enemija da napravis "custom" rendering metodu, a ako ti ne treba "custom" lepo prozoves Render(...) od osnovne klase.
Moze i virtual bool cSprite::Save(...) pa to isto prodje kroz drvo, i imas Save za ceo stejt igre. Za razliku od kurslusa "ako ima ovo onda snimi ako nema proveri da li ima ono pa snimi ako nije vece od 9" itd...
Tako na kraju mozes i cPlayer da nasledis iz bilo kog enemija, pa da na svakom nivo-u Player izgleda drugacije, dodas samo kontrolu i slicno...
Iz enemy-a moze da nasledis i button za GUI, koji ce da "doleti" na ekran.
Nacrtaj na papiru drvo nasledjivanja, i razmatraj sta koja klasa treba da sadrzi.
|