Come performances c'e' poco da dire, come eleganza del codice diciamo che e' un disastro.
Primo evidente problema e' la nomenclatura, uno strafalcione dopo l'altro. PlayerMovIment?
ma che e' ? Mezzo italiano mezzo inglese. Un bordello, un disastro, illegibile... passiamo al codice vero e proprio
I "numeri magici" vanno evitati come la morte. Magari oggi leggere "risorse->PlayerMoviment(0);" ti e' completamente chiaro, il codice lo hai scritto 10 minuti fa e l'associazione fra lo 0 e il tipo di movimento richiesto e' ancora "calda". Ti assicuro che fra 1 mese leggerai sta cosa e dirai: "che gatzo faceva sto zero qua?" .
Andiamo avanti, perche' per muovere il giocatore devo parlare con risorse? "Risorse" dovrebbe essere un manager no? Un manager gestisce i suoi subalterni, non lavora per loro.. quindi non ha senso dire a Risorse "playerMovement" . Se un giorno devi far sparare il player che fai? Crei una playerShoot dentro manager che chiama "shoot" del player? Sembra assurdo no?
Risorse dovrebbe avere una semplice:
Player& getPlayer();
Fine della sorella. Da li in poi parli con il player.
Una volta preso il player tocca spostarlo. La "Move" come e' adesso va bene, ma IMO ha il problema di delegare il calcolo della quantita' di movimento all'esterno di player. Ci sono molte possibili soluzioni... la prima e' ignorare il problema e fare:
Player& player=risorse->getPlayer();
if ( sf::Keyboard::IsKeyPressed(sf::Keyboard::W))
player.move( Vector2f( 0 , -player.getSpeed() * deltaT));
...
e via discorrendo. E qui hai risolto il problema dei numeri magici. Lo spostamento viene espresso esplicitamente dopo l'if quindi sai esattamente cosa sta facendo quella cosa e come.
Un'altra e' lasciare la logica di movimento a player, indicando a questo solo una direzione di movimento e un deltaT:
Player& player=risorse->getPlayer();
if ( sf::Keyboard::IsKeyPressed(sf::Keyboard::W))
player.moveToDirection( Vector2f( 0 , -1) , deltaT));
...
dove:
void Player::moveToDirection(const Vector2f& dir , float deltaT)
{
sprite->Move( dir.x * speed * deltaT , dir.y * speed * deltaT);
}
Cosi' hai il vantaggio che, se domani vuoi implementare un player che accelera e rallenta, tutta la sua interfaccia resta invariata, e devi cambiare solo moveToDirection.
E per finire, l'ultima soluzione, che e' quella che io uso, che astrae ancora di piu' le interfacce. Ed e' una cosa tipo:
struct PlayerControls
{
PlayerControls()
{
... // INIZIALIZZA TUTTO A ZERO
}
float xAxis; // E' float cosi' puoi supportare i pad analogici e i joystick
float yAxis; // Idem con patate
bool isFiring; // Premuto il pulsante per sparare?
... // TUTTO QUELLO CHE UN PLAYER PUO' ricevere dall'esterno
};
Poi quando gestisci l'input da tastiera:
PlayerControls controls;
if ( sf::Keyboard::IsKeyPressed(sf::Keyboard::W))
controls.yAxis=-1;
if ( sf::Keyboard::IsKeyPressed(sf::Keyboard::A))
controls.xAxis=-1;
... // E VIA COSI' FINO A:
risorse->getPlayer().setControls(controls);
dove setControls non fa altro che farsi una copia dei controls passati.. poi in:
void Player::update(float deltaT)
{
// QUI USO IL MIO STATO DI INPUT PER AGGIORNARE IL MIO STATO
sprite->Move( controls.xAxis * speed * deltaT , contorls.yAxis * speed * deltaT);
}
In questo modo hai sganciato completamente la logica di rilevazione dei controlli da quello che i controlli effettivamente fanno, e ora tutta la logica del funzionamento del player e', correttamente, dentro alla classe player.
e chest'e' zam zam
Lista utenti
Chat
Usermap
![[Immagine: acsign.jpg]](http://www.netkar-pro.com/public/acsign.jpg)
