Ajouter des méthodes dynamiquement

[NicoMSEvent]

@Roworll :
eclaireur serait une classe dérivée de unité,

Code :

classe eclaireur extends unite{
  function SeCamoufle(){
  }
}

il ne te reste plus qu'a rajouter les action spéciales pour ce type d'unité (toutes les actions de base de l'unité sont accessibles via "$this->GetName()", ou a la limite via "parent::GetName()" si tu as surchargé la fonction -> http://www.manuelphp.com/php/keyword.parent.php );

Si maintenant, tu as un ninja qui pourrait attaquer en plus, il pourrait être lui même un "éclaireur étendu" avec comme action supplémentaire "attaque sournoise"

[Roworll]

Sauf que, comme je l'ai précisé dans mon premier message, ça devient ingérable très rapidement

Chaque unité peut avoir de 0 à n capacité spéciale.
Dans un environnement Objet, ces capacités sont des méthodes permettant de réaliser des actions spécifiques (support aérien, pose de mines, tir de couverture, camouflage, etc).

J'ai vite abandonné l'idée de faire des classes spécifiques héritées de la classe Unité en fonction des capacités spéciales tant la liste et les combinaisons sont grandes.

Prenons le cas du camouflage. A la louche, on peut actuellement le coller sur 5 type d'unités
- simple unité d'éclaireurs (camouflage)
- unité de Ninjas (Camouflage + Assassinat)
- une unité de sabotage (Camouflage + Démolition)
- Espion (Camouflage + Espionnage)
- Agent Spécial (Camouflage + Assassinat + Démolition + Espionnage)

Je nous vois mal faire une classe éclaireur, une ninja, une Sabotage, etc, se repiquant toutes les méthodes les unes aux autres. Les unités seront créées par l'admin en ajoutant des capacités spéciales au template "unité" de base.
Vu qu'on a pour le moment pas loin d'une 30aine de capacités différentes, on a bien trop de combinaisons pour faire des classes spécifiques, d'où l'idée de faire des méthodes dynamiques.

[NicoMSEvent]

donc, tu vas répliquer la fonction "se_camoufle" 5x
l'autre problème avec les actions spéciale sous forme de fonction nommée est qu'il faut connaitre le nom de la fonction pour l'appeler (a moins que tu aies un truc pour ça, alors partage le si tu veux bien, parce que j'ai des difficultés a concevoir comment tu y arriverais)

J'aurais pensé a un truc du genre :
Pourquoi pas avoir ces actions spéciales sous forme d'objet (lié dans un tableau contenu dans l'unité)
A ceci, il faudrait ajouter la possibilité de détecter si l'action a une cible qui détermine l'action (vers une troupe -> assassinat, vers un batiment -> démolition)

class Unité{

 private $action_speciale;

function __construct(){

$action_speciale=array();

switch($this->typeunité){

case 'eclaireur':

$this->action_speciale[]=new ActionCamoufle();

break;

case 'ninja':

$this->action_speciale[]=new ActionCamoufle();//placer les actions selon leurs priorités

$this->action_speciale[]=new ActionAssassinat();

break;

[...]

}

}

function ActionSpeciale($vers_objet){

//parcourir les actions spéciales avec un foreach par exemple

}

}

j'oubliais presque l'appel :

$mon_unité->ActionSpeciale($cible_click_droit);

[Anthor]

Mais qu'est-ce que vous avez tous avec vos switch de 15 bornes de long franchement ?

[Argorate]

tu préfères les if? ^^

[NicoMSEvent]

Mais qu'est-ce que vous avez tous avec vos switch de 15 bornes de long franchement ?

j'aime bien séparer chaque cas, je trouve que ça compartimente bien (surtout avec des commentaires //----------------------------- )

[Roworll]

l'autre problème avec les actions spéciale sous forme de fonction nommée est qu'il faut connaitre le nom de la fonction pour l'appeler (a moins que tu aies un truc pour ça, alors partage le si tu veux bien, parce que j'ai des difficultés a concevoir comment tu y arriverais)

Pour le moment, on a dans la classe Unité un tableau qui contient toutes les références des capacités spéciales disponibles pour l'unité en question. Ce tableau contient plusieurs colonnes : libellé de l'action, instance de la classe, type de cible (unité, terrain, etc)

Niveau interface, on passe par une couche JS pour stocker les actions possibles. On sait alors par exemple que l'unité d'archers montés peut 'Charger' ou effectuer un 'Tir de suppression'.

Pour la résolution de l'action, il suffit d'appeler (je schématise à fond en laissant de coté la sécurité, les pre-checks, etc))
$Unité->$_POST['action']($cible);
La méthode __call gère alors l'appel vers la classe concernée en instanciant l'objet si ce n'est déjà fait.

On peut ainsi construire le nom de la méthode à appeler.
Pour lancer l'action ce sera
charge() pour charger, hide() pour se camoufler
Pour la liste des cibles disponibles
charge_targets(), hide_targets()

Ça semble tenir la route pour le moment.

[NicoMSEvent]

ça parait super intéressant comme approche, je ne l'aurais pas imaginé comme ça (clair que sans vérification, c'est la mort ^^)

je trouve ça un peu dommage de passer par une couche JS, que fais-tu des visiteurs qui l'ont désactivé? je pense aux déficients visuels, etc...
(et hop, je lance le troll )

[Roworll]

La couche JS est là pour dynamiser l'interface.
En cliquant sur l'action 'charge' par exemple, il est prévu de faire un appel asynchrone à charge_targets(), de recevoir la liste des cibles possibles, puis de mettre mettre en surbrillance les cibles valides pour l'action.

Donc Dynamique + Ajax + Effets visuels (dans la mesure de nos pauvres compétences graphiques et moyennant le fait qu'on a tous les deux des goûts de chiottes), c'est sur que les gens n'ayant pas activé JS et/ou avec des problèmes de perception visuelle ne pourront pas profiter du jeu.

Un choix discutable certes mais en ce qui nous concerne, définitif.

[Anthor]

Mais qu'est-ce que vous avez tous avec vos switch de 15 bornes de long franchement ?

j'aime bien séparer chaque cas, je trouve que ça compartimente bien (surtout avec des commentaires //----------------------------- )

C'est pas ce qu'on appelle une méthode dynamique ^^ Je dis juste que dans un cadre objet où tu cherches à dynamiser les classes, tu ne met pas un switch où il faudra repasser derrière ton code dès que tu as une modification à faire.

D'autant que 2/3 posts plus haut, tu as une superbe réponse de QuentinC avec le __call.

tu préfères les if? 34

Pourquoi ça m'étonne plus de ta part ? ^^