Je fais un moteur de jeu avec C ++ et OpenGL. Je fais un petit jeu pour tester mon moteur incomplet. Mais après avoir ajouté des cours comme la caméra, le rendu de rendu, le niveau, le joueur, le zombie et l'homme, les paramètres de fonction de mes joueurs se situent longtemps sur 8 arguments, car le joueur doit interagir avec de nombreuses classes comme la caméra, le rendu, le zombie, l'homme, etc.
S'il vous plaît donner des suggestions à résoudre ce problème Ou c'est la bonne façon de faire des jeux.
3 Réponses :
difficile à dire sans plus de contexte. Cependant, un extrême est de regrouper tout ce qui est nécessaire comme paramètre dans une structure unique: puis transmettez-le comme paramètre unique: p> void foo(const GameContext& context);
Premièrement, des objets simples à l'intérieur d'une scène peuvent être mis en œuvre via Singleton Motif, puis vous pourrez y accéder de n'importe quelle classe simplement en ajoutant un en-tête requis.
Deuxièmement, certains des objets peuvent être représentés comme parents pour d'autres - comme les jambes ou les mains pour l'homme, utilisent la composition.
Troisième, comme la plupart des interactions entre les objets (comme des collisions et des trucs) sont communes entre tous les objets, vous pouvez laisser la majeure partie de la mise en œuvre dans la classe de base, qui libérerait zombies d'accéder à la caméra du tout. , parce que objet le fait déjà. Utiliser l'héritage!
quatrième, si rien n'a fonctionné, vous pouvez les regrouper tous dans une structure de pointeurs à ces objets et transmettez une seule structure au lieu de n paramètres.
À peu près ça.
Les singletons utilisés comme celui-ci ont certains des problèmes qui font du mal aux variables mondiales. Comme l'ordre d'initialisation. Maintenant, je ne les dirige pas complètement, mais je dirais que l'un devrait penser assez difficile si on veut utiliser une dans une situation donnée. (Je suis d'accord avec vos autres points.)
L'initialisation peut être reportée via des méthodes init (...) ou quelque chose comme ça. Bien sûr, utiliser le droit singletons nécessite une discipline.
C'est difficile à répondre sans voir une partie du code, mais voici quelques réflexions:
Je n'appellerais pas ça trop. Des choses compliquées sont compliquées. Avec cela dit, il n'y a qu'un seul caméra, j'imagine. Un joueur a-t-il besoin d'un zombie intégré? Il n'y a pas de véritable informations pour partir.
Tous ces objets pourraient-ils être dans un
struct que vous pouvez passer par référence?Vous question est à large. Généralement, c'est là que l'ingénierie logicielle et l'architecture entrent en jeu: pourquoi votre joueur classe est-il l'Intgrateur de tout? Votre moteur ne devrait-il pas regarder la façon dont les classes interagissent? En outre, oui, ce moteur devrait intégrer beaucoup de choses, mais pour de nombreuses choses qui se comportent de la même manière, comme des zombies et des humains, l'abstraction sous la forme d'interfaces et de polymorphes d'objet ou même de modèles / programmation générique me vient à l'esprit. Et oui, vous pouvez aussi simplement faire ensemble des trucs ensemble dans une structure. Mais cela n'aidera probablement pas le problème initial.
Pourquoi le constructeur a-t-il besoin de la partie zombie? En tout état de cause, envisagez de fractiver de grandes classes. Avoir une classe d'apparence et une pour la logique de jeu, par exemple. Dépend fortement du contexte.
Une fonction qui a besoin de caméra, de rendu et zombies et humains ressemble à une fonction pouvant être divisée. Par exemple, vous pouvez le diviser dans une fonction de rendu qui nécessite uniquement une caméra et un rendu et une fonction de mise à jour qui nécessite des zombies et des humains (peut-être, ne connaissez pas votre conception). J'aurais juste une classe de moteur qui est passée par référence et contient toutes les données dont vous avez besoin.