Malheureusement, votre conception actuelle suce :)
Je ne vais pas dire ce que je vais proposer est en fait la meilleure solution disponible, parce que dans la conception de jeu, il est généralement « pas le meilleur » solution, mais je pense que cela vous ferait réfléchir.
Agrandir UML here.
alt text http://yuml.me/1924128b
Disons que vous avez votre classe de base Game. C'est une classe abstraite qui enveloppe toutes les logiques de jeu et fonctionne comme une sorte de couteau suisse. Vous devez créer deux autres classes - UI et State (qui, évidemment, encapsulent les opérations d'interface utilisateur du jeu et stockent l'état actuel du jeu). Laissez votre classe Game tenir UI et State instances.
Maintenant, votre classe Game devrait avoir des méthodes de base pour contrôler votre jeu. Ils pourraient être simples render(...) et update(...) méthodes et cette partie est en fait un peu difficile. Si votre jeu est en temps réel, vous devrez mettre à jour votre état toutes les millisecondes Y, donc votre update(...) devrait être appelée en boucle.
Si votre jeu n'est pas réellement en temps réel, vos mises à jour ne doivent se produire que lorsque l'utilisateur fait quelque chose ou que vous connaissez réellement que vous avez besoin de changer quelque chose. Vous pourriez mettre en place une file d'attente de messages ici et l'appel update(...) viderait simplement tous ces messages. Puis, la méthode render(...). Créez une classe et appelez-la Backend - laissez cette classe encapsuler toutes vos possibilités de dessin. Il ya une chose vraiment cool ici - vous pouvez laisser votre Backend être une super-classe abstraite et créer quelques béton backends, qui dérivent de Backend. Et cela vous donnerait l'occasion de changer votre Backends avec des manipulations de code simples.
Après cela, vous devez passer votre Backend par exemple à votre méthode render(...), qui ferait le dessin approprié et il est logique pourrait être écrit de la manière suivante:
foreach (const Object& object, game_state) {
object->render(backend); // Or something like that
}
La dernière chose à mentionner, votre état de jeu . Vous pourriez avoir une structure simple pour contenir tous vos objets courants, marquer, etc., etc. Laissez chaque objet accéder à cette structure GameState et tout ira bien.
En fait, il y a beaucoup de choses à penser, si vous le souhaitez, je pourrais écrire plus sur cette approche de conception de jeu et de partager quelques trucs :)
Vous devez concevoir d'abord, puis programmer un jeu. Aussi, est ce jeu dans une console, en 2D, 3D ..? – Alerty
Il semble que vous soyez plus à la recherche de jeux d'exemples existants. Le développement du jeu est généralement dicté par les exigences de performance, et non par la beauté du design. – Dummy00001
Hey comment avez-vous fait ce diagramme génial? –