Discussion :

[Invité]

Salut,

Je suis un étudiant en informatique et avec un groupe de 2 étudiants nous devons faire un jeu comme Wolfeinstein3D avec notre propre code de raycasting, en C et avec le thème que nous voulons, bien sûr nous avons choisi le meilleur jeu de tous les temps AKA Minecraft pour theme, et nous devons le faire avec une libs graphique horrible (c'est une chose comme openGL mais 100 fois moins bien). Et comme nous sommes jeunes et stupides, nous voulons faire beaucoup plus que le résultat attendu par le sujet, notamment des Items, GUI, Blocks, Action bar, crafting.. Nous travaillons sur le projet depuis 2 mois, mais nous avons terminé la partie 'normale' et attendu par sujet en 2 semaines, mais on s'amuse trop (oui on sacrifie l'été pour ca)

Contexte :

Notre projet est construit comme ceci : Une structure de base qui contient toutes les choses

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
typedef struct s_core
{
    mlx_t           *mlx; //core of the graph libs
    t_player        player; //all the player infos (move speed, position, health..)
    t_imgs          imgs; //all our images
    t_sounds        sounds; //all our sounds
    t_item          items[7]; //all our items
    t_animation     animations[7]; //all our anims
    t_block         blocks[2]; //all our blocks
    t_map           *maps; //all informations about maps (the char **maps, height, weidth..)
    int             screen_size[2];
}   t_core;

Et nous essayons autant que possible de respecter le principe d'encapsulation, donner uniquement le strict nécessaire a chaque fonction.

problème:

Qu'est-ce qu'un bloc ? Un bloc est une chose avec un nom, avec une image à dessiner dans un monde, mais c'est aussi un item car vous pouvez l'avoir dans la main, construire avec lui, craft.. Et un bloc a une musique spécifique, et peut-être une animation, car le bloc peut être animé (par exemple un portail du nether..)

Donc, pour créer un bloc, je dois définir un item, donc je dois accéder à core->items[X] (sachant que les items sont créés avant les blocs), je dois définir le son, donc je dois accéder à core->sounds[X], mais j'ai aussi besoin d'une image, etc etc etc on ce retrouve a faire des genre de cascade d'informations et de paramètres..

C'est le même problème pour beaucoup de choses, les sons, les items, les blocs, les maps, le joueur, les animations, les imgs.. ils sont tous interdépendants et je ne sais pas comment faire autrement.

Finalement, un peu partout dans le code on se retrouve donc à envoyer soit le core entier en paramètre, soit plus de 4 éléments du core à une fonction pour faire le nécessaire. Donc au final, l'encapsulation pour les choses spécifiées plus haut, est brise.. J'veux dire, on a pas de 'bug' ou de problemes, on cherche juste comment faire un projet vraiment propre en terme de code

Débat :

Je pense que nous devons supprimer la structure core et rendre global toutes les structs la composant, mon teammate pense que nous devons créer un pointeur dans chacune d'elles qui envoie vers le core
exemple:

Code :

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

1
2
3
4
5
typedef struct s_item
{
    {...variables}
    t_core *core;
}   t_item;

Questions:

- Qu'est-ce que l'encapsulation en C, le concept d'encapsulation existe-t-il et est-il pertinent en C car il n'y a pas de POO ?
- En théorie, comment gérer un projet en C de manière général ?
- Dans notre cas, comment devons nous faire ?
- A-t-on atteint une certaine limite de la possibilité du C ? On a vraiment l'impression que juste le langage n'est simplement pas fait pour cela..
- Tout autre conseil pour nous, nous voulons être des codeurs élégants.

[Bousk]

Surtout, à aucun moment tu définis un bloc dans ton code, tu as juste foutu toutes tes données dans un truc nommé core, parce que.
Si tu vas chez Ikea acheter 3 meubles, est-ce que tu t'attends à avoir 2 cartons avec toutes les vis dans l'un, toutes les planches dans un autre et toutes les instructions dans le dernier ? Et si finalement tu veux en retourner 1, comment tu t'y prends ?
Ou bien tu auras 3 cartons, chaque carton ayant le nécessaire pour 1 meuble ?
La POO c'est pareil, c'est pas juste écrire struct.

Un bloc c'est tout ce que tu dis mais pas partout.
Dans le renderer, on se soucie d'avoir le model 3d ou texture à afficher, sa position, ...
Dans le gameplay et l'inventaire, on se soucie de la quantité qu'on possède, sa position dans l'inventaire, ...
Dans le code UI on va avoir son nom, son icône, ...
Le code audio va juste jouer ce qu'on lui demande avec possibilité de mettre en pause, arrêter, ...
Et la seule chose qui relie le tout c'est juste un identifiant.
Quand tu joues un bloc, tu dis à l'inventaire de consommer 1 élément dont l'id est X.
Et tu ajoutes au world un bloc id X à la position souhaitée.

Donc tu crées une "base de données" de tes éléments.
Dans la db tu mets tout ce qui définit le bloc pour le jeu : id, icône, model, son, ...
Et chaque partie a sa propre structure de données spécifique.

Par exemple

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
 
struct BlocDefinition {
  char id[20];
  char inventory_icon_path[20];
  char world_texture_path[20];
  char sound_path[20];
  ....
};
 
struct BlocRenderer {
  BlocDefinition* definition;
  int x;
  int y;
};
 
struct BlocGameplay {
  BlocDefinition* definition;
  int quantity;
  int ivnentory_x;
  int inventory_y;
};
 
struct BlocUI {
  BlocDefinition* definition;
  int x;
  int y;  
};
 
struct BlocAudio {
  BlocDefinition* definition;
};

Bien sûr si tu veux animer et pas avoir une image fixe, tu auras une donnée plus complexe qu'un simple path vers les icônes et models.

[foetus]

en gros @Bousk te dit d'aller lire des livres/ documentations sur les moteurs à l'ancienne avec des objets World, Renderer, différents Renderers/ Managers (son, entrée, réseau, …)
Ai-je besoin de te dire qu'il faut également des notions en mathématiques (projections, espaces affines, ...)

Mais le problème de ce moteur, c'est qu'il est supplanté 2 fois: 1 fois par le modèle ECS (Entity Component System) puis par l'Unreal Engine/ Unity.