Discussion :

[killwin]

Bonjour,

J'ai une question au sujet de la mise en forme de mon projet qui a beaucoup avancé.
Est ce que c'est normal de me retrouver avec une très grosse structure comportant plus de 100 déclarations ? Ca me semble beaucoup et c'est surement pas normal.

Cette structure regroupe tous les objets, vecteurs, variables principaux.

En fait j'ai structuré le projet en petits fichiers cpp. Mais du coup sans cette structure je me retrouverais à passer dans les fonctions ou les méthodes une bonne vingtaine de paramètres.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
 
 
struct s_game {
#if KINECT_COMP==1
   CThread *th;
#endif
   int checkpoint;
   int window;
   s_keys keys;
   int nbr_enemies_1_seq, nbr_enemies_2_seq, nbr_coins_seq,   nbr_platforms_seq, nbr_powers_seq;
   std::vector<TVector2d<int> > Vcoord_explosion;
   int step_sky, step_ground;
   CJoystick *OJoystick;
   unsigned cursor_coin;
   unsigned cursor_checkpoint;
   unsigned cursor_enemy_1, cursor_enemy_2;
   unsigned cursor_platform;
   unsigned cursor_power;
   std::vector<int> VIdlife_coins;
   std::vector<int> VIdlife_enemies_1, VIdlife_enemies_2;
   std::vector<int> VIdlife_platforms;
   std::vector<int> VIdlife_powers;
   std::vector<TVector2d<unsigned> > VSeq_enemies_1, VSeq_enemies_2;
   std::vector<TVector2d<unsigned> > VSeq_coins;
   std::vector<TVector2d<unsigned> > VSeq_platforms;
   std::vector<TVector2d<unsigned> > VSeq_powers;
   std::vector<TVector2d<unsigned> > VSeq_checkpoints;
   int clock, clock_ticks;
   float coef_resol;
   bool fullscreen, kinect;
   TTF_Font *font; //fonts
   SDL_Surface *screen;
   SDL_Surface *text_surface_score;
   SDL_Surface *text_surface_clock;
   SDL_Rect rect_text_score, rect_score;
   SDL_Rect rect_text_clock, rect_clock;
   SDL_Rect rect_sky;
   SDL_Rect rect_earth;
   SDL_Rect coord_hearts;
   SDL_Rect coord_power;
   SDL_Color color_text;
   CDraw_World *ODrawW_sky;
   std::vector< std::shared_ptr<CDraw_World> > VDrawW_ground;
   //CDraw *ODraw_screen;
   CDraw *ODraw_text_score;
   CDraw *ODraw_text_clock;
   CDraw_Digits *ODraw_digits_score;
   CDraw_Digits *ODraw_digits_clock;
   CDraw_Digits *ODraw_digits_clock_baby;
   std::vector<float> resultants_y_earth; //y resultants vectors for the earth
   std::vector<float> ry_earth; // y position points for the earth
   // tux, fire, coins and game.OEnemy objects
   CDynamic_Tux *OTux;
   CDynamic_Boss *OBoss;
   std::vector< std::shared_ptr<CDynamic_Fire> > VFire;
   std::vector< std::shared_ptr<CDynamic_Fire> > VNutts;
   std::vector< std::shared_ptr<CDynamic_Enemy_1> > VEnemy_1;
   std::vector< std::shared_ptr<CDynamic_Enemy_2> > VEnemy_2;
   std::vector< std::shared_ptr<CDynamic_Coin> > VCoin;
   std::vector< std::shared_ptr<CDynamic_Platform> > VPlatform;
   std::vector< std::shared_ptr<CDynamic_Coin> > VPower;
   std::vector< std::shared_ptr<CDynamic_Coin> > VCheckpoint;
   // We create dynamic objects to calculate new positions of tux, fire, ennemy and coins
   CDynamic *OCalculator_tux;
   std::vector< std::shared_ptr<CDynamic> > VCalc_Fire;
   std::vector< std::shared_ptr<CDynamic> > VCalc_Nutts;
   std::vector< std::shared_ptr<CDynamic> > VCalc_Enemy_1, VCalc_Enemy_2;
   std::vector< std::shared_ptr<CDynamic> > VCalc_Coin;
   std::vector< std::shared_ptr<CDynamic> > VCalc_Platform;
   std::vector< std::shared_ptr<CDynamic> > VCalc_Power;
   std::vector< std::shared_ptr<CDynamic> > VCalc_Checkpoint;
   CDynamic *OCalculator_boss;
   CDynamic **OCalculator_coin;
 
   // Animations objects
   CAnimation *anim_screen_wait;
   CAnimation *anim_heart;
   CAnimation *anim_power;
   CAnimation *anim_fire;
   CAnimation *anim_nutts;
   CAnimation *anim_coin;
   CAnimation *anim_platform;
   CAnimation *anim_checkpoint;
   std::vector< std::shared_ptr<CAnimation> > VAnim_explosion;
   CAnimation *anim_level;
   CAnimation *anim_tux_right;
   CAnimation *anim_supertux_right;
   CAnimation *anim_baby_tux_right;
   CAnimation *anim_enemy_1, *anim_enemy_2;
   CAnimation *anim_boss_static, *anim_boss_static_injured;
   CAnimation *anim_boss_jump, *anim_boss_jump_injured;
   CAnimation *anim_boss_run, *anim_boss_run_injured;
   CAnimation *anim_boss_shut, *anim_boss_shut_injured;
   CAnimation *anim_tux_death_right;
   CAnimation *anim_tux_death_baby_right;
   CAnimation *anim_next;
 
   CSounds *sounds;
};

[metagoto]

Effectivement ça fait beaucoup

Rapidos, généralement pour un jeu on trouve des "modules" distincts pour justement éviter d'avoir 100 membres par classes.
Par exemple, un loader de resources distinct d'un renderer lui même distinct du manager d’entités de jeu encore distinct du controller d'inputs...

Donc à première vue je dirai que non ce n'est pas normal d'avoir autant de membres disparates dans une même structure.

[Bysbobo]

Bonjour,

La question que je me pose surtout c'est: Tu arrives à t'y retrouver?

[Médinoc]

Je plussoie metagoto ici, tu devrais regrouper certains membres dans des sous-structures. Notamment, séparer les données de jeu (nombre de pièces, etc.) des données graphiques (SDL_*).

[killwin]

Merci, je vais redéfinir ma strucutre en sous-structures et séparer les données.