Meni se čini iz tvog opisa da je dovoljno da imaš jednu klasu.
Ona može da sadrži properties tipa sprajt ID, pointer na rutinu koja
će obradjivati AI, i slično. Pristupa ima nebrojeno mnogo, a sve zavisi
od konkretnih potreba.

Uvek možeš da napraviš neki jednostavan propery sistem i da karakteristike
neprijatelja učitavaš iz fajla/skripta/net-a...

tako sam i mislio,ali nisam bio siguran.
Vec sam snimio tinyXML za implementaciju takvog sistema.

Hvala

Ne bih ti preporuchio XML za tu svrhu (mada je tome namenjen). Pogledaj mali skript-jezik pod imenom LUA.

Hmm.. sada sam zbunjen, bio sam ubedjen da se lua koristi za programiranje AI-a i upravo sam za to planirao i da ga koristim.

Da li mozes malo da pojasnis?

Korisiti se, izmedju ostalog i za to. Evo vidi ovde recimo sta kazu: http://en.wikipedia.org/wiki/L...gramming_language#Applications
Najlepse od svega je sto je jednostavan i sto je free. :)

OK, znaci sugestija je na mestu, Lua umesto XML-a.

Hvala

"Lua za programiranje AI-a" i nije bash najsrecnija rechenica. Za shta mozhesh koristiti Lua-u je pre svega stvar organizacije tvog koda (tj. shta Lua mozhe da "vidi" od tvojih klasa i funkcija).
Kako god, Lua je i dalje najbolji embedable jezik za data-definition/description namene - Lua Tables je ono shto je XML mogao da bude u idealnom sluchaju :)

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.

hvala na opsirnom objasnjenju.
videcu u hodu sta mi je ciniti, ali sve savete uzimam u obzir.

situacija je sledece, a vi recite na sta to lici.
posto se radi o 2d shooteru (ipak je to pocetak), imam klasu Ship, klasu Player i klasu Enemy.
Da bi Player kontrolisao odredjeni brod treba dodeliti pokazivac na objekat igraca objektu broda npr:
theShip->getOwner(thePlayer), isto tako se brodu moze dodeliti i neprijatelj.
Na taj nacin sam razdvojio logiku od prikaza(nesto kao MVC, ipak sam ja PHP programer:O)) , posto samo klasa Ship ima metod render()
Sta mislite?

Sve je to ok sa tvojim klasama i verujem da ce dobro da radi. Imaces problem sa razlicitim vrstama neprijatelja.
Ne postoje pravila kako se pravi shooter. Zavrsi igricu pa cemo posle da razgledamo, i sigurno ce biti stvari koje su dobre i koje su lose. Svi mozemo da naucimo nesto iz tvog projekta.

Ona metoda ce biti pre SetOwner nego GetOwner :)

Ovo dole je samo jedno resenje, koje u tvom slucaju ne mora nista da znaci, jer nemam pojma kako si zamislio igru, sta ce biti od gameplay, feature-a itd, sta su u stvari nivoi... Opisi detaljno sta se u stvari dogadja u igri, pa mozemo dalje da razmisljamo.


class cSprite
{
public:
cSprite(textura *new_texture,float new_widht,float new_height);
virtual void Render(...);
};

class cShip : public cSprite
{
public:
cSprite(...,v3 & new_position);
bool operator+(cShip &); // kolizija sa drugim shipom
virtual void Render();
private:
v3 vec3Position;
}

class cEnemy : public cShip
{
public:
cEnemy(...,float strength);
virtual void Update(float dt);
private:
float fStrength;
int iState;
};

class cEnemyBullet : public cEnemy
{
public:
virtual void Update(float dt);
virtual void Render();
};



class cEnemyRocket : public cEnemy
{
public:
cEnemyRocket(...);
private:
cSmokeTrail SmokeTrail;
};

class cPlayerInput {
...
};

class cPlayer : public cEnemy
{
public:
virtual void Update(float dt);
virtual void Render(...);
private:
cPlayerInput PlayerInput;
};

class cNizNPC : public vector<cEnemy*>
{
public:
void Update(float dt);
};

class cGame {
public:
...
bool Update(void)
private:
cTimer t;
cNizNPC NPC;
cPlayer *Player;
};

sto se igre tice, radi se, ali polako, jos sigurno par meseci necu imati nista prezentabilno.

hvala na odgovoru.

btw, gde su mloh i mloh2 ?

:)