[QST][COD] Liste des classes

aimak · 25-01-2010 22:41:31

A définir ici :

La liste des classes nécessaires à l'élaboration du moteur de simulation.

aimak · 26-01-2010 11:11:00

- Cycliste
- Equipe
- Groupe
- Secteur
- Course
- Texte

Dernière modification par aimak (26-01-2010 11:13:56)

Tonioketaman · 31-01-2010 18:05:18

Je viens de télécharger un logiciel de modélisation en UML, ce qui facilitera je pense toute la phase de codage et de développement.

Pour ceux qui ne sont pas spécialement au point sur la POO en PHP et qui ont un peu la flemme de chercher ^^, voici le lien vers un tuto du Site du Zér0 : http://www.siteduzero.com/tutoriel-3-14 … n-php.html

Dès que j'installe le logiciel, je ferai un premier essai de modélisation des classes proposées par aimak.

aimak · 31-01-2010 20:20:41

Je viens de télécharger un logiciel de modélisation en UML, ce qui facilitera je pense toute la phase de codage et de développement.

Des diagrammes de classes ne seront utiles que quand on aura une idée plus claire de ce qu'il y aura effectivement dans chaque classe. Pour le moment, ça donnera plutôt qqch qui ressemblerait à ceci, pour la classe Cycliste, par exemple :

L'UML pourquoi pas, c'est clair que ça peut aider pas mal à la conception d'un plus ou moins gros projet. Encore faut-il être certain que tous pourront le comprendre/exploiter. Et, de toute façon, tant qu'on n'a pas encore définit la grosse majorité des besoins, ça ne servira pas à grand chose.

Dernière modification par aimak (01-02-2010 10:58:36)

Tonioketaman · 31-01-2010 22:19:00

Je viens de télécharger un logiciel de modélisation en UML, ce qui facilitera je pense toute la phase de codage et de développement.
L'UML pourquoi pas, c'est clair que ça peut aider pas mal à la conception d'un plus ou moins gros projet. Encore faut-il être certain que tous pourront le comprendre/exploiter. Et, de toute façon, tant qu'on n'a pas encore définit la grosse majorité des besoins, ça ne servira pas à grand chose.

C'est justement pour voir si l'UML serait accessible à tous. Mais il est clair que pour le moment il est beaucoup trop tôt pour commencer à coder quoi que se soit.

Tonioketaman · 08-02-2010 20:55:17

Le débat s'étant un peu tari dernièrement, je pense qu'il est temps de faire un premier récapitulatif et de commencer à réfléchir sur les moyens qui seront mis en œuvre pour mener à bien ce projet de Live pour CyManager.

Principes généraux

- Prépondérance de l'équipe sur l'individualité
- Choix des statut et de la stratégie de l'équipe obligatoire pour chaque course (doit permettre d'obtenir de bons résultats)
- Choix des zones d'action et des consignes individuelles facultatif (le fait de choisir des consignes individuelles ne doit pas assurer de meilleurs résultats)
- ...

Statuts des coureurs

Les différents statuts des coureurs sont :
- Leader
- Electron Libre
- Equipier

Le comportement "par défaut" des coureurs dépend de leur statut et de la stratégie de l'équipe

Stratégie de l'équipe

Les différentes stratégies d'équipe disponibles sont :
- Par défaut
- Rouler dans les roues / Se préserver
- Assurer le train pour revenir sur les échappés ou pour durcir la course / Rouler sur les échappées
- Assurer le train dans le sprint final
- Rouler pour faire la sélection
- Prendre toutes les échappées / Attaquer
- Sprinter dans le final / Attendre le sprint final

... en cours de discussion (http://www.cymanager.net/index.php?showtopic=11930)

Zones d'action

Au nombre de 40 (environ) par course, elles permettent d'affiner la stratégie en indiquant les zones d'action des consignes individuelles des coureurs.

Trouver un algorithme capable d'automatiser la détection des zones d'actions sur n'importe quel profil (cf. méthode de fab).

Consignes individuelles

Au nombre de 5 maximum par coureur, il en existe deux "types" : les consignes applicables à tous les coureurs, et celles qui ne le sont qu'a un statut et une stratégie d'équipe.

Consignes individuelles applicables à tous les coureurs :
- Attaquer : le coureur attaque dans la zone indiquée
- Contre-attaquer : le coureur se porte en tête du peloton et contre-attaque si il y a une attaque
- Récupérer : le coureur se met dans les roues et récupère
- Prendre les relais : le coureur prend les relais pour maintenir un certain tempo
- Rouler à bloc : le coureur roule à bloc pour creuser l'écart ou revenir sur des échappés
(- Faire les sprints intermédiaires et GPM)

Consignes dépendant de la stratégie d'équipe et du statut du coureur :
(cf tableau en enlevant le statut Sprinter et en rajoutant les éléments de ce statut à Leader: http://www.cymanager.net/index.php?show … ge=368380)

Gestion de la forme

En attente de reformulation

... en cours de discussion (cf http://www.cymanager.net/index.php?showtopic=11945)

Tonioketaman · 16-02-2010 19:10:01

Pour revenir aux questions plus techniques, j'ai commencé à réfléchir sur les classes nécessaires pour le moteur de simulation, et voici mes premières conclusions :

- une classe Cycliste qui serait Abstraite
- des classes Leader, Electron_Libre et Equipier qui elles hériteraient de la classe Cycliste

Ceci permettra d'avoir dans la classe Cycliste les caractéristiques des cyclistes (endurance, montagne, plaine, ...) sous forme d'attributs et les actions de bases (attaquer, rouler, effort curseur) sous forme de méthodes. Ensuite, d'après nos diverses discussions, il est apparu qu'il y aurait des actions différentes selon les statuts. Ainsi, en héritant de la classe Cycliste, la classe Leader pourra intégrer des éléments spécifiques que seulement lui possèdera (de même pour les classes Electron_Libre et Equipier).

~~

Ensuite, une classe Equipe serait également nécessaire (ne serait-ce que pour tenir compte des stratégies d'équipes). En soit elle n'aurait que des pointeurs vers des objets de la classe Cycliste et des méthodes correspondant aux différentes stratégies d'équipe.

~~

Pour ce qui est des autres classes, je n'y ai pas énormément réfléchi pour le moment ^^

aimak · 16-02-2010 20:02:51

Pour revenir aux questions plus techniques, j'ai commencé à réfléchir sur les classes nécessaires pour le moteur de simulation, et voici mes premières conclusions :
- une classe Cycliste qui serait Abstraite
- des classes Leader, Electron_Libre et Equipier qui elles hériteraient de la classe Cycliste
Ceci permettra d'avoir dans la classe Cycliste les caractéristiques des cyclistes (endurance, montagne, plaine, ...) sous forme d'attributs et les actions de bases (attaquer, rouler, effort curseur) sous forme de méthodes. Ensuite, d'après nos diverses discussions, il est apparu qu'il y aurait des actions différentes selon les statuts. Ainsi, en héritant de la classe Cycliste, la classe Leader pourra intégrer des éléments spécifiques que seulement lui possèdera (de même pour les classes Electron_Libre et Equipier).

Je suis un peu sceptique quant à la réelle nécessité de devoir faire ceci. Sauf si tu me démontres que c'est absolument indispensable tongue

Pour ce qui est des autres classes, je n'y ai pas énormément réfléchi pour le moment ^^

J'y avais déjà pensé plus haut :

- Cycliste
- Equipe
- Groupe
- Secteur
- Course
- Texte

Dernière modification par aimak (16-02-2010 20:03:12)

Tonioketaman · 16-02-2010 20:19:15

Pour revenir aux questions plus techniques, j'ai commencé à réfléchir sur les classes nécessaires pour le moteur de simulation, et voici mes premières conclusions :
- une classe Cycliste qui serait Abstraite
- des classes Leader, Electron_Libre et Equipier qui elles hériteraient de la classe Cycliste
Ceci permettra d'avoir dans la classe Cycliste les caractéristiques des cyclistes (endurance, montagne, plaine, ...) sous forme d'attributs et les actions de bases (attaquer, rouler, effort curseur) sous forme de méthodes. Ensuite, d'après nos diverses discussions, il est apparu qu'il y aurait des actions différentes selon les statuts. Ainsi, en héritant de la classe Cycliste, la classe Leader pourra intégrer des éléments spécifiques que seulement lui possèdera (de même pour les classes Electron_Libre et Equipier).
Je suis un peu sceptique quant à la réelle nécessité de devoir faire ceci. Sauf si tu me démontres que c'est absolument indispensable

Ce n'est pas indispensable, mais ça facilite grandement la tache (et non je ne crée pas des classes abstraites et de l'héritage rien que pour le fun ^^).

L'autre moyen que je vois pour mettre en place le système de Leader et cie (en sachant que chaque statut a ses particularités) seraient de créer des attributs et des méthodes dans la classe Cycliste, ce qui nous fera beaucoup de test en plus (si il est leader, alors ...) alors que si on sépare bien les Leaders des Equipiers (avec comme base la classe Cycliste) on s'évite pas mal de test et pas mal de problèmes par la suite (en sachant que notre code sera plus lisible et plus évolutif).

Après il y a peut-être une autre solution que je ne vois pas.

Tonioketaman · 16-02-2010 20:35:57

Voilà un petit diagramme UML fait à la va-vite, mais en gros ça permettrait d'avoir une base commune pour tous les coureurs (la classe Cycliste) et à partir de celle-ci, de "spécialiser" les coureurs selon leur statut (en sachant que la méthode sePreserver() de la classe Leader est différente de celle de la classe Equipier par exemple).

Jtemange · 16-02-2010 21:05:55

Pourquoi tu mets les mêmes choix pour les leader, les électrons et les équipiers ?

aimak · 16-02-2010 23:37:50

Pour revenir aux questions plus techniques, j'ai commencé à réfléchir sur les classes nécessaires pour le moteur de simulation, et voici mes premières conclusions :
- une classe Cycliste qui serait Abstraite
- des classes Leader, Electron_Libre et Equipier qui elles hériteraient de la classe Cycliste
Ceci permettra d'avoir dans la classe Cycliste les caractéristiques des cyclistes (endurance, montagne, plaine, ...) sous forme d'attributs et les actions de bases (attaquer, rouler, effort curseur) sous forme de méthodes. Ensuite, d'après nos diverses discussions, il est apparu qu'il y aurait des actions différentes selon les statuts. Ainsi, en héritant de la classe Cycliste, la classe Leader pourra intégrer des éléments spécifiques que seulement lui possèdera (de même pour les classes Electron_Libre et Equipier).
Je suis un peu sceptique quant à la réelle nécessité de devoir faire ceci. Sauf si tu me démontres que c'est absolument indispensable
Ce n'est pas indispensable, mais ça facilite grandement la tache (et non je ne crée pas des classes abstraites et de l'héritage rien que pour le fun ^^).
L'autre moyen que je vois pour mettre en place le système de Leader et cie (en sachant que chaque statut a ses particularités) seraient de créer des attributs et des méthodes dans la classe Cycliste, ce qui nous fera beaucoup de test en plus (si il est leader, alors ...) alors que si on sépare bien les Leaders des Equipiers (avec comme base la classe Cycliste) on s'évite pas mal de test et pas mal de problèmes par la suite (en sachant que notre code sera plus lisible et plus évolutif).
Après il y a peut-être une autre solution que je ne vois pas.

En fait, que le type soit en ENUM dans une grande classe Cycliste ou qu'il y ai 3 classes qui héritent d'une classe Cycliste, quand on devra faire des conditions, entre faire moncycliste.type==LEADER ou bien instanceof, ça revient au même.

Par contre, c'est vrai qu'à long terme c'est peut être plus logique d'utiliser ce que tu suggères, puisque si on décide de rajouter des actions pour un seul ou deux types de coureurs, c'est plus facilement possible.

rolan · 17-02-2010 01:16:14

Est-ce que cette figure permettra au Leader de bénéficier de la force de son équipe à son avantage ?

Parce que au niveau des tactiques qui s'ouvent à nous avec le live, il serait souhaitable que la désignation du leader de la course puisse accorder une forme de bonus à ce coureur élu. Par exemple une équipe moyenne ayant besoin de points pour se maintenir pourrait choisir de désigner un lieutenant à la place du leader naturel* pour que ce lieutenant puisse obtenir un meilleur résultat et de prendre le plus de points possibles au détriment du vrai leader de l'équipe qui lui, normalement, devrait se classer assez haut de toutes façons.

En résumé, le leader (naturel ou non) devrait recevoir un bonus de départ. L'importance du bonus reste bien sûr liée au nombre d'équipiers de qualité qui l'entoure.

Dans le tableau indiqué, je ne vois pas l'avantage du leader.

---

* un leader naturel qui n'est pas super costaud et qui n'a apriori aucune chance de victoire, même en épuisant son équipe à son service.

aimak · 17-02-2010 02:24:46

Dans le tableau indiqué, je ne vois pas l'avantage du leader.

Il ne s'agit pas d'un tableau, mais d'un diagramme de classes. On n'y indique donc pas nécessairement ce genre de notions, qui concernent plus l'implémentation du diagramme que de la structure en elle-même.

rolan · 17-02-2010 07:13:10

Ah bon, d'accord merci.

Mais la phase d'implémentation qui vient plus tard dans la mécanique (de ce que j'en comprends :gene: ) est-il prévu de donner un avantage -physique- au coureur désigné comme leader ?

boreal · 17-02-2010 09:39:40

Je dirais non pour ma part.
C'est le fait qu'il soit protéger par des coéquipiers qui fera qu'il perdra moins de points d'énergie forme que normalement et qu'il pourra prétendre à de meilleurs résultats.

aimak · 17-02-2010 12:15:21

Je dirais non pour ma part.
C'est le fait qu'il soit protéger par des coéquipiers qui fera qu'il perdra moins de points d'énergie forme que normalement et qu'il pourra prétendre à de meilleurs résultats.

J'ai tendance à être plutôt d'accord avec ça, tout en étant un peu plus modéré : je pense qu'il est normal qu'un leader puisse être avantagé grâce au travail/à la présence de ses équipiers, sans pour autant qu'une équipe avec 1 leader + 6 très bons équipiers ai forcément course gagnée.
Pour moi, cet avantage doit être présent sans pour autant plomber la course dès le début. Il faut que le très bon coureur seul puisse avoir une chance contre toute une équipe organisée.

Tonioketaman · 17-02-2010 17:39:00

Je dirais non pour ma part.
C'est le fait qu'il soit protéger par des coéquipiers qui fera qu'il perdra moins de points d'énergie forme que normalement et qu'il pourra prétendre à de meilleurs résultats.
J'ai tendance à être plutôt d'accord avec ça, tout en étant un peu plus modéré : je pense qu'il est normal qu'un leader puisse être avantagé grâce au travail/à la présence de ses équipiers, sans pour autant qu'une équipe avec 1 leader + 6 très bons équipiers ai forcément course gagnée.
Pour moi, cet avantage doit être présent sans pour autant plomber la course dès le début. Il faut que le très bon coureur seul puisse avoir une chance contre toute une équipe organisée.

Je suis d'accord avec aimak, mais de toute façon aucun élément ne devra être prédominant par rapport aux autres (aucun élément ne doit permettre d'avoir course gagnée).

Mais bon, là on dévie un peu du sujet ... :pinch:

aimak · 21-02-2010 14:48:46

Je suis un peu sceptique quant à la réelle nécessité de devoir faire ceci. Sauf si tu me démontres que c'est absolument indispensable
Ce n'est pas indispensable, mais ça facilite grandement la tache (et non je ne crée pas des classes abstraites et de l'héritage rien que pour le fun ^^).
L'autre moyen que je vois pour mettre en place le système de Leader et cie (en sachant que chaque statut a ses particularités) seraient de créer des attributs et des méthodes dans la classe Cycliste, ce qui nous fera beaucoup de test en plus (si il est leader, alors ...) alors que si on sépare bien les Leaders des Equipiers (avec comme base la classe Cycliste) on s'évite pas mal de test et pas mal de problèmes par la suite (en sachant que notre code sera plus lisible et plus évolutif).
Après il y a peut-être une autre solution que je ne vois pas.
En fait, que le type soit en ENUM dans une grande classe Cycliste ou qu'il y ai 3 classes qui héritent d'une classe Cycliste, quand on devra faire des conditions, entre faire moncycliste.type==LEADER ou bien instanceof, ça revient au même.
Par contre, c'est vrai qu'à long terme c'est peut être plus logique d'utiliser ce que tu suggères, puisque si on décide de rajouter des actions pour un seul ou deux types de coureurs, c'est plus facilement possible.

Tous les codeurs sont d'accord avec ceci ? :inn:

gegevert · 21-02-2010 15:10:32

Tous les codeurs sont d'accord avec ceci ? :inn:

Je ne suis pas un grand habitué de la programmation en classe. Pour la plupart des projets php je trouve que ça alourdit considérablement la programmation (et l'efficacité des code).
Mais pour ce projet, je vois bien l'intérêt des classes pour une programmation partagée avec une logique identique.

Du coup il me semble logique de prévoir ce qui pourrait plus facilement gérer des ajouts ensuite et donc de créer les 3 classes supplémentaires.

CyManager, forum officiel du jeu de cyclisme en ligne !

#1 25-01-2010 22:41:31

Re : [QST][COD] Liste des classes

#2 26-01-2010 11:11:00

Re : [QST][COD] Liste des classes

#3 31-01-2010 18:05:18

Re : [QST][COD] Liste des classes

#4 31-01-2010 20:20:41

Re : [QST][COD] Liste des classes

#5 31-01-2010 22:19:00

Re : [QST][COD] Liste des classes

#6 08-02-2010 20:55:17

Re : [QST][COD] Liste des classes

#7 16-02-2010 19:10:01

Re : [QST][COD] Liste des classes

#8 16-02-2010 20:02:51

Re : [QST][COD] Liste des classes

#9 16-02-2010 20:19:15

Re : [QST][COD] Liste des classes

#10 16-02-2010 20:35:57

Re : [QST][COD] Liste des classes

#11 16-02-2010 21:05:55

Re : [QST][COD] Liste des classes

#12 16-02-2010 23:37:50

Re : [QST][COD] Liste des classes

#13 17-02-2010 01:16:14

Re : [QST][COD] Liste des classes

#14 17-02-2010 02:24:46

Re : [QST][COD] Liste des classes

#15 17-02-2010 07:13:10

Re : [QST][COD] Liste des classes

#16 17-02-2010 09:39:40

Re : [QST][COD] Liste des classes

#17 17-02-2010 12:15:21

Re : [QST][COD] Liste des classes

#18 17-02-2010 17:39:00

Re : [QST][COD] Liste des classes

#19 21-02-2010 14:48:46

Re : [QST][COD] Liste des classes

#20 21-02-2010 15:10:32

[QST][COD] Liste des classes

Pied de page des forums