2013-03-06 2 views
0

Je suis curieux de savoir s'il existe une bonne stratégie pour gérer différents types de jeux dans un jeu qui se déroule sur la même boucle de jeu principale? En d'autres termes, j'ai un jeu avec trois types de jeu différents. Il existe seulement quelques différences mineures entre chaque type, de sorte qu'ils s'exécutent actuellement en utilisant la même boucle/classes. L'un est «combien de X pouvez-vous obtenir avant que le temps ne s'écoule», l'autre «combien de temps cela vous prend pour capturer 10 X», et le dernier est un type de jeu «pratique/temps infini». À l'heure actuelle, ma stratégie est d'exécuter un contrôle if, then, else sur toutes les parties du jeu et d'effectuer la logique appropriée pour chaque type de jeu.Game Design: gérer différents types de jeux?

if (gameType == INFINITE) 
{...} 
else if (gameType == TIMED) 
{...} 
else 
{...} 

Cela me semble terriblement mauvais, et aussi inefficace. Je ne veux pas embourber le CPU avec toutes ces vérifications inutiles quand il me semble que je pourrais faire cette vérification une fois et aller de l'avant. Je ne veux pas non plus copier-coller toutes mes classes pour ne faire que des changements mineurs dans chacune d'entre elles. Y at-il un bon moyen de le faire?

Répondre

3

Une façon de gérer cela est de créer un système de gestionnaire d'écran. Cela signifie essentiellement que vous avez une classe abstraite avec des opérations de mise à jour et de dessin. Chaque jeu (écran) dont vous avez hérité, permet à chacun d'avoir son propre comportement de mise à jour/dessin. En fin de compte, vous devez avoir une instruction if-else ou switch pour décider de dessiner/mettre à jour. Une façon de minimiser cela est de garder une trace de l'écran actuel en utilisant une variable de votre type abstrait, vous pouvez ensuite assigner polymorphiquement l'écran qui doit être mis à jour/dessiné à cette variable. Ensuite, lorsque vous appelez update ou dessinez sur l'écran en cours, vous n'avez pas besoin de connaître son type concret.

Il y a beaucoup d'exemples là-bas, un XNA décent peut être trouvé à l'adresse: http://xbox.create.msdn.com/en-US/education/catalog/sample/game_state_management

L'idée est complètement transférable. La plupart utilisent ce système pour ajouter des écrans de menu et des choses, mais il n'y a aucune raison que cela ne puisse pas être utilisé pour votre objectif.

+0

Oh garçon. Cela nécessiterait un refactoring majeur et majeur de mon code. – Clev3r

+0

@Clever oui peut être un problème lol –

+0

ah ... comment je manque vraiment une classe «vraiment» abstraite dans l'objectif-C. Cependant, je suis d'accord que ce serait la voie à suivre: un contrôleur abstrait qui a 3 (ou N) implémentations, et une usine pour instancier le approprié. Les protocoles le feraient aussi :) – YvesLeBorg

Questions connexes