Discussion :

[grego91000]

Bonjour (ou bonsoir ?) je voudrais vous poser une question à laquelle je n'arrive toujours pas à trouver de réponse. Voyez-vous, je suis actuellement en train de créer un jeu de combat mais le seul point qui me manque est l'intelligence artificielle de l'ennemis et j'avouerai que je ne sais ni comment l'implanter au jeu, ni la faire en générale (mis à part les (très) grandes lignes).
Merci de votre aide en avance

[Matt_Houston]

Peux-tu préciser le genre de jeu de combat ? One on one en deux dimensions du style Street Fighter ?

Quelle que soit la réponse tu auras probablement besoin d'un automate à états fini. Tu peux déjà commencer à te renseigner là-dessus.


Accessoirement comme ta question n'a - je l'imagine - que peu de rapport avec le langage C++, elle aurait plus sa place dans le forum jeux vidéo. Un modo décidera peut-être de la déplacer.

[grego91000]

Salut, déjà merci de ta réponse je vais me renseigner dessus et c'est un jeu en 2D à la street fighter oui ^^

[grego91000]

Avant toutes choses, désolé pour le double-post
C'est maintenant que le sujet est placé au bon endroit grâce à cette question :
Comment implanter cette IA dans mon code, est-ce que je dois l'implanter dans le constructeur de ma classe ennemis ou je devrai la mettre dans mon main même voir, une autre classe ?

Merci d'avance pour vos réponses ^^

[Matt_Houston]

Ok. Ce dont tu auras besoin en premier lieu et que tu as peut-être déjà fait sans forcément t'en rendre compte pour les joueurs humains, c'est d'un automate qui en décrit le comportement. Tous les acteurs du jeu (qu'ils soient contrôlés par un humain ou une IA) peuvent être considérés comme des automates. Un automate est un ensemble d'états et de transitions.

Un état est une unité de comportement ou d'action :

• je suis statique (état de base) ;
• j'avance ;
• je recule / je bloque ;
• je donne un petit coup de point / un gros coup de pied ;
• je balance un hadoken ;
• je saute...

Une transition est un pont d'un état à un autre, elle décrit les conditions d'évolution d'état de l'automate grâce à trois propriétés :

• l'état de départ : j'avance ;
• l'état d'arrivée : je bloque / parry ;
• un prédicat (fonction qui renvoie vrai ou faux) qui détermine si le changement d'état est autorisé en fonction de paramètres extérieurs : si un hadouken m'arrive dessus, alors VRAI.

À chaque tick, le prédicat de toutes les transitions qui ont pour origine l'état courant est évalué. Les changements d'état possibles sont donnés par les transitions dont le prédicat donne VRAI. On dit d'un automate dont au plus une seule transition est vérifiée à tout moment qu'il est déterministe : on n'a jamais à choisir entre deux transitions, le comportement est déterminé. Dans un jeu vidéo en règle générale, on ne veut que du déterminisme. Surtout lorsque le jeu se joue potentiellement en compétition, comme un jeu de combat.


Pour un joueur humain, les prédicats de changement d'état sont simples : ce sont en grande majorité les actions effectuées sur souris, clavier, pad, joystick, etc... Exemple : j'avance (état courant), soudain le prédicat pression sur le bouton A est vérifié : je saute (changement d'état).

Pour une IA en revanche tu t'en doutes, c'est un peu plus complexe. Les conditions de changement d'état sont déterminées par l'environnement extérieur :

• que suis-je en train de faire ?
• à quelle distance se trouve mon adversaire ? Que fait-il ?
• oh, il s'apprête à balancer un hadoken ! Il lui reste donc n frames avant de récupérer le contrôle et pouvoir bloquer, je peux donc tenter cette attaque qui dure k frames, go !
• etc... Les possibilités sont infinies.

Lorsque plusieurs stratégies d'attaque sont possibles, on peut utiliser un algorithme décisionnel comme minimax pour les départager. On peut également attribuer un paramètre de tempérament à l'IA (agressif, équilibré, prudent..) potentiellement dynamique (« combien me reste-t-il de vie ? » -> « 25% ! Mmm.. ok, je vais la jouer cool et assurer le coup. »).


Voilà quelques pistes, bon courage.

[grego91000]

Merci beaucoup pour ta réponse qui m'a avancé énormément dans mon projet mais une toute petite dernière question de rien du tout, l'IA doit être programmée dans le constructeur ou autre classe à part ? (A vrai dire, je suis sûr que cette question est stupide mais bon ^^)

[Matt_Houston]

Cette phrase est d'une banalité affligeante mais n'en reste pas moins vraie :

Les seules questions stupides sont celles que l'on ne pose pas.

l'IA doit être programmée dans le constructeur ou autre classe à part ?

Si tu choisis d'utiliser un automate (et je te le conseille car c'est très efficace pour représenter et surtout maintenir un comportement complexe comme celui d'un combattant à la Street Fighter), il y a mille manières de procéder à son implémentation. La plus simple est de représenter les états par un enum et de modeler le comportement par des switch (si on est dans l'état X alors x(), si on est dans l'état Y alors y()...).

En C++ on pourrait par exemple imaginer quelque chose de la sorte (ça ne compile pas, c'est une illustration) :

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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
class IState;
 
typedef bool (*Predicate)(const IState&);
 
class Transition {
public:
    bool test(const IState& sourceState) { return condition(sourceState); }
 
private:
    IState *destinationState;
    Predicate condition;
};
 
 
class IState {
public:
    ~IState() = default;
 
    void enter(); // called upon activating the state
    void exit(); // called upon quitting the state
    void update(); // called once per tick while the state is active
 
protected:
    std::vector<std::unique_ptr<Transition>> transitions;
};
 
 
class IStateMachine {
public:
    ~IStateMachine() = default;
 
    void start(); // runs the state machine: enters the initial state
    void stop(); // stops the state machine
    void update(); // called once per tick
 
private:
    void setState(IState *); // called by update() if a transition is validated
 
    std::vector<std::unique_ptr<IState>> states;
    std::size_t initialState, // index of initial state
                currentState; // index of current state
};
 
// ...
 
class Jump : public IState {
 
    // ...
 
};
 
class Fighter : public IActor, public IStateMachine {
 
    // ...
 
};

[grego91000]

Merci ^^ tu as répondus à toutes mes questions, du coups je met la discussion en résolu, au plaisir de ce reparler un jour !

[ternel]

généralement, dans les jeux, tu as une classe joueur, qui sert d'interface générale au coeur du jeu.
L'interface graphique est un joueur particulier, tout comme les joueurs au travers du réseau, et les joueurs controlés par l'ordinateur (les IA).

[Seabirds]

Dans un jeu vidéo en règle générale, on ne veut que du déterminisme. Surtout lorsque le jeu se joue potentiellement en compétition, comme un jeu de combat.

Il n'y a aucun comportement stochastique dans les IA du genre starcraft ?
Si on détermine exactement le comportement du joueur A via une simulation, l'IA aura exactement la même réponse à chaque simulation ?
Ma question n'a peut être aucun sens, mais je pensais que les IA faisaient de l'apprentissage et tiraient leurs décisions aléatoirement dans des distributions de proba qui s'actualisaient via les éléments de contexte (plus de chance de tirer la décision "fuit" dans le contexte de "méga grosse armée iz coming et tu n'as que trois péons" ).

Désolé, j'y connais rien, mais je trouve ça rigolo/intéressant

[ternel]

Dans les jeux de stratégies, les IA n'apprennent d'une partie à l'autre.
Par contre, elles modifient leurs stratégies au cours de la partie (comme le font les joueurs), en fonction de ce qu'elles constatent chez les autres joueurs.
Par exemple, pour attaquer depuis le ciel quand elle voit qu'un joueur qui ne prévoit pas de défense anti-aérienne.

[Matt_Houston]

Il y a bien du hasard dans un RTS (ou d'autres genres) mais, en général (chaque jeu est différent), on le sauvegarde.

La séquence de nombres produite par un générateur de nombres pseudo-aléatoires dépend totalement et uniquement de la graine avec laquelle il a été initialisé. C'est d'ailleurs pour cette raison que les nombres qui en sont issus sont pseudo-aléatoires. En cryptographie, c'est une faille énorme. Pour d'autres applications telles qu'un jeu vidéo, c'est très utile. La plupart du temps dans un jeu, les graines sont sauvegardées par round ou partie.

On s'assure ainsi que le coup porté par l'ennemi #1517 à la frame #89523 inflige toujours 796 points de dégâts, ni plus ni moins. Ou que l'ennemi #2513 décide toujours de tourner à gauche plutôt qu'à droite à la frame #92561. C'est aussi ce qui permet de faire des replays sans avoir à sauvegarder l'intégralité de l'état de jeu à chaque frame de simulation (Dawn of War en est un exemple).

Sauvegarde une partie de Heroes Of Might & Magic III, par exemple (je pense que c'est pareil pour le reste de la série mais c'est celui auquel j'ai le plus joué). Recharge plusieurs fois la sauvegarde et réalise les mêmes actions. Il y aura toujours la même chose dans les coffres, tes héros tomberont toujours sur les mêmes compétences et l'IA fera exactement les mêmes choix : inutile d'espérer ainsi échapper à une attaque imminente en jetant les dés tant que l'issue ne nous est pas favorable.

[Seabirds]

Recharge plusieurs fois la sauvegarde et réalise les mêmes actions. Il y aura toujours la même chose dans les coffres, tes héros tomberont toujours sur les mêmes compétences et l'IA fera exactement les mêmes choix : inutile d'espérer ainsi échapper à une attaque imminente en jetant les dés tant que l'issue ne nous est pas favorable.

Effectivement, maintenant que tu le dis je ne suis jamais parvenu à faire changer l'IA d'avis quant à me tomber dessus avec toutes ses wirms, goules et autres nécromanciens pour ravager ma base défendue par trois péons et un poulet

[Bousk]

C'est même grâce à ça qu'on fait du RTS multi, sinon il faudrait des bandes-passantes énormes http://www.gamasutra.com/view/featur...8_network_.php

[LittleWhite]

inutile d'espérer ainsi échapper à une attaque imminente en jetant les dés tant que l'issue ne nous est pas favorable.

Sauf sur les consoles (voir du côté des speedrunner et de la manipulation du hasard à la frame, qui leur est si chère), ou encore, il y a quelques éléments qui peut ne pas être soumis à la graine et générée sur le tas. Par exemple, le coup infligé par telle unité peut avoir une probabilité de fail, genre 5%. Et à chaque fois, lors du besoin cette probabilité peut être aléatoire, sans graine, à chaque tirage.
Toutefois, cela doit être absolument éliminé si on veut faire un replay, évidemment.
Autrechose, les particules et fioritures graphiques, peuvent ne pas utiliser la graine utilisé pour l'IA. Notamment car on n'a pas besoin du déterminisme.

[Matt_Houston]

Oui, je n'ai pas développé afin de ne pas alourdir le coeur de mon propos mais il est certain qu'il est presque toujours désirable d'avoir en parallèle plusieurs instances de génération pseudo-aléatoire, indépendantes et que l'on rend déterministes, ou pas.

Il est aussi à noter que lorsque l'on cherche du déterminisme pur, les calculs en virgule flottante sont à proscrire (il y a un article / post-mortem là-dessus qui traîne sur le net, dans la veine de celui mentionné par Bousk) sauf implémentation custom ou limitation à une architecture de copro donnée (je ne sais pas ce qu'il en est des GPU actuels, mais je ne me hasarderais pas à faire aveuglément confiance aux constructeurs).

[Bousk]

On a également un article traduit qui traite des problèmes de flottants http://jeux.developpez.com/tutoriels...ule-flottante/

[Matt_Houston]

Oui, bien vu !

Je crois maintenant me souvenir effectivement que l'auteur de l'article en question avait bossé sur le premier Supreme Commander, cité ici.

[koala01]

Salut,

Il est aussi à noter que lorsque l'on cherche du déterminisme pur, les calculs en virgule flottante sont à proscrire (il y a un article / post-mortem là-dessus qui traîne sur le net, dans la veine de celui mentionné par Bousk) sauf implémentation custom ou limitation à une architecture de copro donnée (je ne sais pas ce qu'il en est des GPU actuels, mais je ne me hasarderais pas à faire aveuglément confiance aux constructeurs).

Bah, de manière générale, tant que les valeurs (de manière générale) seront représentées sous la forme de bits en informatique, on ne pourra pas ignorer le fait que la représentation d'une valeur à virgule flottante -- quel que soit le nombre de bits que l'on y allouera) sera forcément imprécise par nature

Et même si on pouvait représenter ces valeurs sous une forme différente, un ordinateur est toujours un système fini, tout comme l'espace disponible sur une feuille de papier est limité à... sa superficie...

Or, si l'on a besoin de la virgule flottante, c'est bien parce que... certaines opérations ne sont justement pas finies... Et représenter une valeur est est par nature infinie dans un système qui est par nature fini, cela implique forcément d'avoir une "certaine imprécision" à un moment ou à un autre

On peut, certes, la réduire de plus en plus en augmentant les ressources utilisées pour la représenter, mais, le problème de l'infini devant rentrer dans un système fini reste malgré tout entier

[Matt_Houston]

Certes, mais plus qu'à l'exprimer avec une précision donnée, on recherche ici la constance du résultat. Erreur ou pas, tout le monde doit obtenir la même chose, bit à bit.