Faire un jeu en C ++ en utilisant un traitement parallèle

Question

Je voulais & "émuler &"; un jeu flash populaire, Chrontron, en C ++ et avait besoin d’aide pour démarrer. (NOTE: pas pour la libération, juste pour pratiquer moi-même)

Basics:
Player has a time machine. On each iteration of using the time machine, a parallel state
is created, co-existing with a previous state. One of the states must complete all the
objectives of the level before ending the stage. In addition, all the stages must be able
to end the stage normally, without causing a state paradox (wherein they should have
been able to finish the stage normally but, due to the interactions of another state,
were not).

Cela explique en quelque sorte le fonctionnement du jeu. Vous devriez jouer un peu pour vraiment comprendre quel est mon problème.

Je pense qu'un bon moyen de résoudre ce problème serait d'utiliser des listes chaînées pour stocker chaque état, qui sera probablement soit une carte de hachage, basée sur le temps, ou une liste chaînée qui itère basé sur le temps. Je ne suis toujours pas sûr.

QUESTION RÉELLE:

Maintenant que j'ai quelques spécifications, j'ai besoin d'aide pour choisir les structures de données à utiliser pour cela et pourquoi. De plus, je veux savoir quelle API / couche graphique utiliser pour cela: SDL, OpenGL ou DirectX (mon choix actuel est SDL). Et comment ferais-je pour implémenter des états parallèles? Avec des fils parallèles?

EDIT (pour clarifier davantage):
OS - Windows (puisqu'il s'agit d'un projet amateur, vous pourrez le faire ultérieurement sous Linux)

Graphiques - 2D Langage - C ++ (doit être C ++ - il s’agit d’un cours pour le semestre prochain)

Q-Unanswered: SDL: OpenGL: Direct X
Q-Answered: Éviter le traitement en parallèle
Q-Answered: Utilisez STL pour implémenter des actions pas à pas.

So far from what people have said, I should:
1. Use STL to store actions.
2. Iterate through actions based on time-step.
3. Forget parallel processing -- period. (But I'd still like some pointers as to how it
could be used and in what cases it should be used, since this is for practice).

Pour compléter la question, j’avais déjà utilisé principalement C #, PHP et Java afin de ne pas me décrire en tant que programmeur expérimenté. Quelles connaissances spécifiques à C ++ contribueraient à rendre ce projet plus facile pour moi? (c.-à-vecteurs?)

Answer 1

Ce que vous devez faire est d’abord de lire et de comprendre le " pas de temps fixe & "; boucle de jeu (voici une bonne explication: http://www.gaffer.org/ game-physics / fix-your-timestep ).

Ensuite, vous gardez une liste de paires de compteurs d’images et d’actions. Exemple STL:

std::list<std::list<std::pair<unsigned long, Action> > > state;

Ou peut-être un vecteur de listes de paires. Pour créer l'état, pour chaque action (interaction du joueur) que vous stockez le numéro d'image et quelle action est effectuée, vous obtiendrez probablement les meilleurs résultats si l'action était tout simplement & "; Clé & Lt; X gt; appuyé sur " ou " clé < X > publié ":

state.back().push_back(std::make_pair(currentFrame, VK_LEFT | KEY_PRESSED));

Pour lire les états précédents, vous devez réinitialiser le compteur d’images chaque fois que le lecteur active la machine à remonter le temps, puis parcourir la liste d’états pour chaque état précédent et voir s’il en existe un qui correspond à l’image actuelle. Si c'est le cas, effectuez l'action pour cet état. Pour optimiser, vous pouvez conserver une liste d'itérateurs à l'endroit où vous vous trouvez dans chaque liste d'états précédente. Voici quelques pseudo-codes pour cela:

typedef std::list<std::pair<unsigned long, Action> > StateList;
std::list<StateList::iterator> stateIteratorList;
//
foreach(it in stateIteratorList)
{
  if(it->first == currentFrame)
  {
    performAction(it->second);
    ++it;
  }
}

J'espère que vous avez une idée ...

Des threads séparés ne feraient que compliquer grandement les choses, ainsi vous obtiendrez le même résultat à chaque fois, ce que vous ne pouvez pas garantir en utilisant des threads séparés (vous ne pouvez pas vraiment voir comment cela serait implémenté) ou un pas de temps non fixé. boucle de jeu.

En ce qui concerne les API graphiques, je choisirais SDL, car c’est probablement la solution la plus simple. Vous pouvez toujours utiliser OpenGL à partir de SDL ultérieurement si vous souhaitez utiliser la 3D.

Answer 2

Cela ressemble beaucoup à Braid . Vous ne voulez vraiment pas de traitement parallèle pour cela - la programmation parallèle est difficile et, dans ce cas, les performances ne devraient pas être un problème.

Le vecteur d'état du jeu augmentant très rapidement (probablement de l'ordre de plusieurs kilo-octets par seconde, en fonction de la fréquence d'images et de la quantité de données que vous stockez), vous ne voulez pas d'une liste chaînée, qui contient beaucoup des frais généraux en termes d'espace (et peuvent entraîner de lourdes pénalités de performances dues aux échecs de cache si celui-ci est mal agencé). Pour chaque scénario parallèle, vous souhaitez une structure de données vectorielles. Vous pouvez stocker chaque scénario parallèle dans une liste liée. Chaque chronologie sait à quelle heure elle a commencé.

Pour lancer le jeu, vous parcourez tous les scénarios actifs et effectuez des actions d'une image à la fois. Pas besoin de traitement parallèle.

Answer 3

J'ai déjà joué à ce jeu. Je ne pense pas nécessairement que le traitement parallèle soit la voie à suivre. Vous avez partagé des objets dans le jeu (leviers, boîtes, ascenseurs, etc.) qui devront être partagés entre les processus, éventuellement avec chaque delta, ce qui réduirait l'efficacité du parallélisme.

Personnellement, je garderais simplement une liste d’actions, puis, pour chaque itération suivante, commencerions par les entrelacer. Par exemple, si la liste est au format & Lt; [iteration.action] & Gt; la troisième fois, alors, exécuterait les actions 1.1, 2.1, 3.1, 1.2, 2.2, 3.3, etc.

Answer 4

Après avoir brièvement survolé la description, je pense que vous avez la bonne idée. J'aurais un objet d'état contenant les données d'état et le placerais dans une liste chaînée ... Je ne pense pas que vous ayez besoin de threads parallèles. ..

en ce qui concerne l’API graphique, j’ai seulement utilisé opengl, et je peux dire qu’elle est assez puissante et possède une bonne API C / C ++. des ordinateurs.

Answer 5

Une idée de jeu très intéressante. Je pense que vous avez raison de dire que l'informatique parallèle serait bénéfique à cette conception, mais pas plus que tout autre programme à ressources élevées.

La question est un peu ambiguë. Je vois que vous allez écrire cela en C ++, mais pour quel système d'exploitation le codez-vous? Souhaitez-vous que ce soit multi-plateforme et quel type de graphisme voudriez-vous, par exemple 3D, 2D, haut de gamme, basé sur le Web?

Donc, fondamentalement, nous avons besoin de beaucoup plus d'informations.

Answer 6

Le traitement en parallèle n'est pas la solution. Vous devriez simplement & Quot; enregistrer & Quot; les actions des joueurs puis les rejouer pour les " actions précédentes "

Vous créez donc un vecteur (une liste chaînée) de vecteurs contenant les actions. Enregistrez simplement le numéro de l’image qui a été effectuée (ou le delta) et terminez-la sur le & "Factice bot &"; qui représente le joueur au cours de cette instance particulière. Il vous suffit de parcourir les états et de les déclencher les uns après les autres.

Vous obtenez un effet secondaire de facilement & "; casser &"; le jeu quand un paradoxe d'état se produit simplement parce que la prochaine action échoue.

Answer 7

Sauf si vous êtes désespéré d'utiliser le C ++ pour votre propre éducation, vous devez absolument consulter XNA pour votre jeu & amp; cadre graphique (il utilise C #). C'est totalement gratuit, cela fait beaucoup de choses pour vous et vous pourrez bientôt vendre votre jeu sur Xbox Live.

Pour répondre à votre question principale, rien de ce que vous pouvez déjà faire dans Flash n’aurait besoin d’utiliser plus d’un thread. Stockez simplement une liste de positions dans un tableau et effectuez une boucle avec un décalage différent pour chaque robot.