Discussion :

[hydrolyre]

Bonjour à tous !

Tout d'abord, les présentations :
Je m'appelle julien, j'ai 17 ans, je suis en terminale S. Je connais le C/C++, HTML et un peu PHP.

Après avoir fait quelques jeux assez basic, je me suis dit que ça serait sympa de faire des jeux un peu plus étoffés
En plus la réalisation d'un tel jeu apporterai beaucoup :
-Pour les programmeurs, l'expérience d'un RTS (architecture...), et aussi une maitrise accrue du langage, sans oublier que c'est ça fait toujours plaisir de pouvoirs montrer ce qu'on a fait !
-Pour les programmeurs français , des sources commentées en français d'un jeu et un exemple,
-Pour les gens qui pensent que la SFML est nulle, l'exemple d'un programme complet réalisé avec !


LE BUT PRINCIPAL EST L'APPRENTISSAGE.
Le but est de créer un jeu en 2D, un peu comme warcraft 2 (exemple pour situer a peu près) avec quelques personnalisations comme l'ajout d'un système de niveaux.


Le langage utilisé est le C++ (on s'en doutait),
pour les graphismes la SMFL ,
pour le son FMOD (un moteur audio basic est déjà implémenté),
et pour le réseau, on décidera plus tard.

Comme dit précédement, les sources seront publiées.


J'entends déjà les troller me dire que mon projet n'est pas très avancé (ce qui est vrai). C'est normal, ce que je veux c'est qu'une équipe puisse développer un jeu et non un programmeur seul qui recrute seulement quand il ne peut pas implémenter telle ou telle partie.


C'est pourquoi je cherche des gens motivés qui veulent créer un jeu en C++.
Les connaissances de la SFML, FMOD sont préférables, mais ce projet peut aussi être un bon moyen de les apprendre !

Ps : ceci est mon premier post pour le recrutement, donc ça serait sympa de me dire ce qui ne va pas pour que je m'améliore, merci

Pour les candidatures, envoyer moi un mp.
Et si vous avez des questions, j'y repondrai avec plaisir

[SkYsO]

Salut à toi,

Bonne chance pour ton projet, il est vrai qu'apprendre en réalisant un jeu c'est plus excitant que de coder une appli de gestion d'employés ;p

Au sujet de ton annonce, peut être faudrait il préciser un peu plus le projet ?
Si le genre est défini, le sujet est il à discuter avec ceux que tu vas recruter ?
As tu un game design bien défini avec déjà pas mal de choses bornées ? ou bien c'est avec ton équipe que tu vas tout décider ?

Voilà peut être des réponses qui pourront motiver les gens, ceux qui cherchent un projets bien pensé ou ceux qui cherchent un projet et qui veulent s'impliquer de A à Z dedans, ce qui pour le débutant peut être sympa je trouve ça permet de toucher à tout. Bon après faut pas tomber dans les habituels pièges ;p

[nouknouk]

salut,

Après avoir fait quelques jeux assez basic

N'hésite pas à montrer des choses, ça ne peut que donner plus de poids à ton post.

et pour le réseau, on décidera plus tard.

Attention: les problèmatiques réseau seront probablement celles qui seront les plus dures à résoudre pour ton projet. Mieux vaut y penser trèèèès sérieusement, de la façon la plus exhaustive possible dès le départ pour ne pas se retrouver coincé ensuite.

Ce que j'entends par là c'est qu'il est très dangereux de dire "je commence par faire une version mono-joueur, et j'ajouterai une fonctionnalité réseau ensuite" : c'est le risque d'aller droit dans l'impasse et de devoir modifier des pans entiers du jeu pour pouvoir intégrer le réseau.

Mieux vaut développer un embryon de module réseau, l'intégrer dès le départ dans le jeu et le développer en parallèle avec le reste: dès qu'une nouvelle fonctionnalité du jeu est développée, l'intégrer au module réseau.

Ps : ceci est mon premier post pour le recrutement, donc ça serait sympa de me dire ce qui ne va pas pour que je m'améliore, merci

Esprit ouvert, réalisme et modestie: (très) bon point.
Trop de smileys (ça fait un peu trop kikoolol à mon goût), mauvais point (mais c'est du détail).

Bon courage pour la suite en tout cas

[Mat.M]

Le but est de créer un jeu en 2D, un peu comme warcraft 2 (exemple pour situer a peu près) avec quelques personnalisations comme l'ajout d'un système de niveaux.


J'entends déjà les troller me dire que mon projet n'est pas très avancé (ce qui est vrai). C'est normal, ce que je veux c'est qu'une équipe puisse développer un jeu et non un programmeur seul qui recrute seulement quand il ne peut pas implémenter telle ou telle partie.

Si je peux me permettre un conseil pour ce type de jeu une bonne maitrise de l'Intelligence Artificielle (IA ) est incontournable....
si tes entités n'ont pas un bon pathfinding ça peut casser tout un jeu.
Dans la théorie il y a des tas de tutos là-dessus et des exemples mais une fois appliqué on n'obtient pas toujours les résultats voulus à l'écran.
Je te conseillerais d'architecturer ton jeu là-dessus car c'est ardu à mettre au point..
si tes persos se déplacent n'importe comment ça donne une image négative du jeu...

Attention: les problèmatiques réseau seront probablement celles qui seront les plus dures à résoudre pour ton projet. Mieux vaut y penser trèèèès sérieusement, de la façon la plus exhaustive possible dès le départ pour ne pas se retrouver coincé ensuite.

Ce que j'entends par là c'est qu'il est très dangereux de dire "je commence par faire une version mono-joueur, et j'ajouterai une fonctionnalité réseau ensuite" : c'est le risque d'aller droit dans l'impasse et de devoir modifier des pans entiers du jeu pour pouvoir intégrer le réseau.

je ne suis pas d'accord car j'ai le même raisonnement que lui.
Pour faire une version réseau rien ne l'empêche de reprendre le code et d'en faire une autre version ; ce qui est important c'est de bien structurer le code avec une architecture modulaire...
Il peut très bien faire une version joueur simple contre l'ordinateur pour commencer ainsi il aura une bonne base qu'il pourra améliorer par la suite..
mettre une couche réseau c'est d'emblée compliquer les choses...
comme dit le proverbe chi va piano, va sano e va lontano

[nouknouk]

je ne suis pas d'accord car j'ai le même raisonnement que lui.
Pour faire une version réseau rien ne l'empêche de reprendre le code et d'en faire une autre version ; ce qui est important c'est de bien structurer le code avec une architecture modulaire...

Oui mais non:

quand on développe une version uniquement pour le 'local', on va développer en fonction des besoins du jeu en local. Or beaucoup de contraintes peuvent s'ajouter lorsqu'on touche à la transposition vers un mode réseau, notamment (mais pas seulement) à cause de la latence réseau qui introduira la notion d'événements passés

Exemple concret: le joueur A fait une action à t=10s, l'envoie sur le réseau ; le joueur B qui en est en local à t=10.5s reçoit un événement qui se produit à t=10s. Il lui faut retourner en arrière pour gérer les conséquences de cet événement (sinon, c'est la perte de cohérence assurée).
Conséquence: il faut que le moteur de jeu soit capable d'historiser l'état du jeu sur une période tampon, chose totalement inutile en monojoueur.

Ce genre de problématique simple montre que ça change radicalement la façon d'appréhender la conception du moteur de jeu. Ce que je veux dire par là c'est que la fonctionnalité réseau n'est pas qu'une fonctionnalité supplémentaire (un module qu'on va ajouter à la base monojoueur) : c'est une fonctionnalité transversale qui a des conséquences dans le coeur même de plusieurs autres modules (moteur de jeu, ...).

Bien sûr, en théorie il suffirait d'y penser dès le début du développement pour prévoir ce dont on aura besoin.
Sauf qu'en pratique, le sujet est assez complexe pour que cette méthode ne marche qu'avec les dév. déjà (très) expérimentés dans le développement de ce genre de jeu en réseau. Sinon tu oublies forcément de tonnes de trucs en cours de route.
D'où l'idée de progresser en parallèle.

Il peut très bien faire une version joueur simple contre l'ordinateur pour commencer ainsi il aura une bonne base qu'il pourra améliorer par la suite..
mettre une couche réseau c'est d'emblée compliquer les choses...

Je pense exactement l'inverse: développer un module réseau me semble beaucoup moins complexe que mettre en place une IA à peu près convaincante pour jouer contre l'ordinateur.

PS @hydrolyre: on part peut-être un peu dans le hors sujet avec nos réflexions Mat.M et moi, là ; ton post se voulant être un post de recrutement. N'hésite pas à nous recadrer

[MoDDiB]

@nouknouk : Le système réseau que tu proposes est valable pour un jeu d'action (FPS ou autres) mais inutile pour un RTS : dans Wacraft 3 par exemple le serveur reçoit l'action de l'utilisateur à effectuer et envoi un paquet aux joueurs (dont le joueur qui a effectué l'action) pour signaler quelle action effectuer et quand sauf que ce "quand" est forcément dans le futur et supérieur à tous les pings. ( après si un des joueurs n'a pas exécuté l'action à temps il y a freeze, rattrapage des actions etc...)
Mais même ainsi il vaut mieux penser au réseau dès le début afin d'éviter de nombreuses surprises et devoir retransformer complètement son architecture.

@hydrolyre : Il y a de fortes chances que tu n'arrives pas au bout du projet pour X raisons (BAC , études supérieures, un autre projet en tête etc...)
donc je te conseille surtout de te faire plaisir et d'apprendre le maximum de choses sans réellement te prendre la tête : comment mettre en place une architecture cohérente à l'avance sur un type de projet que l'on a jamais réalisé ?
Bon courage et n'hésites surtout pas à demander de l'aide !

[hydrolyre]

Merci pour vos réponses.

Au sujet de ton annonce, peut être faudrait il préciser un peu plus le projet ?
Si le genre est défini, le sujet est il à discuter avec ceux que tu vas recruter ?
As tu un game design bien défini avec déjà pas mal de choses bornées ? ou bien c'est avec ton équipe que tu vas tout décider ?

Pour ce qui est du projet, je n'ai pas dit grand-chose parce que je veux que le principal soit le code. Par exemple, savoir que la faction #2 n'aura que des unités aériennes ne m'intéresse pas. Je préfère me concentrer sur les problèmes liés au code, comme le réseau par exemple.

Le game design n'est pas totalement définis, je préfère en discuter avec l'équipe. Mais ce sera assez basic car on ne veut pas vendre le jeu, donc pas de public ciblé en particulier (de 9 à 99 ans)... J'aimerais bien qu'on prenne du plaisir à y jouer même si c'est dur de faire des jeux sympas.

La plupart des décisions seront prises avec l'équipe.

@nouknouk : quand je dis qu'on décidera avec l'équipe pou le réseau, je parlais de la bibliothèque. Je ne connais pas vraiment les bibliothèques existantes donc je préfère attendre les avis de l'équipe. Mais il est évident que l'architecture réseau sera au centre du projet.
Pour ce qui est des sources, je mettrai un lien cette aprem.

Je pourrai vous recadrer, mais comme ce qui est dit peut me servir, je préfère en profiter.

@Mat.M : Je suis totalement d'accord que l'IA est essentiel. Mais il ne sera pas implémenter dans la première version jouable.
Pour une raison simple, un IA est dur à coder, donc une fois que le jeu fonctionnera bien, on pourra envisager un ajout.
C'est pour ça que le réseau sera développé en même temps que les autres moteurs.
Pour ce qui est du pathfinding, j'ai déjà un A* qui marche très bien... Sauf qu'il ne gère qu'une unité et ne marche pas avec un groupe.

@MoDDiB :
Mon projet IRA JUSQU'AU BOUT!!!!!!!!!!!!!!!
Je connais les contraintes. Mais c'est comme tout, si je me dis que ça ne va pas marcher avant de me lancer, je ne fais rien et je reste dans mon coin, non ?

comment mettre en place une architecture cohérente à l'avance sur un type de projet que l'on a jamais réalisé ?

Les solutions existe déjà, je suis pas la pour réinventer les architectures, juste pour les apprendre


Sur un autre forum on m'a posé quelques questions, j'en profite pour vous éclairer :

Quels sont tes objectifs techniques en terme de développement ? ok tu veux utiliser le C++ et SFML, mais pour un jeu, il y a pleins de choses à faire, par exemple pour la GUI, veux tu la coder toi même ou utiliser une bibliothèque externe ? pour le reséau, tu dis à voir plus tard mais c'est maintenant que ça se décide. Quel protocol tu vas utiliser ? le serveur va t il être codé en C++ ? comment vas tu gérer la communication entre les modules ? etc.

Quels sont tes objectifs artistique ? quel style tu veux ? comment comptes tu faire les graphismes (toi même ou un artiste) ? si un artiste, tu veux l'attirer comment ? pareil pour la musique, et j'en passe des questions.

Il n'y a pas d'objectif temporel, même si je pense qu'en 3/4 mois on peut arriver à quelque chose de pas trop mal.
Du côté des perfs, il faut que ça soit optimal !
Pour le GUI, comme il n'y en pas dans la SFML, je pense utiliser une bibliothèque qui existe. Là encore je ne les connais pas, donc on décidera avec l'équipe.
Le protocole utilisé sera TCP, plus sûr que UDP même s'il est moins rapide.
Tout est codé en C++.
Pour la communication entre les modules, elle se fait grâce à des pointeurs sur les différents modules, chaque module possède un pointeur sur les autres.
Il n'y a pas d'objectif artistique. Par contre, l'ajout de sprite "fait maison" est envisageable une fois que le jeu est jouable.

Si vous avez des questions, n'hésitez pas !

[nouknouk]

Je pourrai vous recadrer, mais comme ce qui est dit peut me servir, je préfère en profiter.

T'as bien raison

Il n'y a pas d'objectif temporel, même si je pense qu'en 3/4 mois on peut arriver à quelque chose de pas trop mal.

Ca me paraît personnellement trop court 3/4 mois pour avoir quelque avec la majorité des fonctionnalités.
Maintenant, comme tu le dis: tu n'as pas d'objectif temporel, donc ça te laisse toute latitude pour naviguer un peu plus "à vue", le but premier étant d'acquérir de l'expérience si j'ai bien compris.

Du côté des perfs, il faut que ça soit optimal !

Attention à ne pas tomber dans l'écueuil du "tout optimiser à priori"

Le protocole utilisé sera TCP, plus sûr que UDP même s'il est moins rapide.

Le protocole UDP n'est pas en soi "plus rapide" que le TCP :un paquet UDP met le même temps qu'un paquet TCP à être acheminé. Cela se joue plus sur la notion de garantie de transmission de tous les paquets dans l'ordre, qui elle peut effectivement avoir une incidence sur le délai de transmission en cas de perte de paquets (TCP retient et ne délivre pas les paquets x+a tant qu'il n'a pas reçu le paquet x, a étant un positif).

Ceci étant dit, je pense que tu as raison de partir sur du TCP qui t'évitera d'avoir à implémenter des mécanismes plus ou moins complexes te garantissant la livraison des paquets 'importants'.

[hs]Je développe moi-même une petite application 'test' pour valider un mini-moteur réseau pour jeu d'action (bomberman like), et qui a donc des besoins plus importants qu'un RTS en termes de "temps réel". Les premiers test montrent que le TCP reste tout à fait approprié.[/hs]

@nouknouk : Le système réseau que tu proposes est valable pour un jeu d'action (FPS ou autres) mais inutile pour un RTS

Effectivement: les RTS sont plutôt basés sur le principe que tu as décrit avec 'freeze temporaire' en cas de délai trop important (my mistake, j'ai un peu trop la tête dans le guidon avec mon dév. actuel ).

J'ai retrouvé un lien très intéressant à ce sujet: la méthode utilisée dans Age Of Empires (l'article sur GamaSutra et la non moins intéressante présentation powerpoint).

[hydrolyre]

Ca me paraît personnellement trop court 3/4 mois pour avoir quelque avec la majorité des fonctionnalités.
Maintenant, comme tu le dis: tu n'as pas d'objectif temporel, donc ça te laisse toute latitude pour naviguer un peu plus "à vue", le but premier étant d'acquérir de l'expérience si j'ai bien compris.

Je n'ai jamais implémenté un tel programme, donc je ne connais pas le temps que ça prend. Et oui, c'est l'expérience qui prime. Je vais rajouter une petite précision sur le rythme. Sachant que j'ai bientôt le bac, je ne serai pas très contraignant. Par contre, l'engagement à long terme est important.

Attention à ne pas tomber dans l'écueuil du "tout optimiser à priori" qui est plus une perte de temps qu'autre chose: en règle générale, on commence par coder une première version centrée sur l'implémentation des fonctionnalités, la propreté du code et la place faite pour pouvoir le faire évoluer par la suite.
On n'optimise ensuite que là où c'est réellement nécessaire, c'est à dire là où de vrais tests concrets ont montré qu'il y avait des conséquences néfastes sur l'expérience utilisateur finale en fonction des configs. hardware visées.

Merci du conseil et pour l'article, qui est... en anglais. Mais il donne de très bon conseil. Je vais enfin pouvoir me défouler sur les clics à répétition !

Tu utilises quelle bibliothèque pour le réseau ?
Et je recrute toujours.

[nouknouk]

pour l'article, qui est... en anglais.

A un moment ou à un autre, tu n'y échapperas pas de toute façon.
T'as qu'à voir ça comme des révisions pour le BAC

Tu utilises quelle bibliothèque pour le réseau ?

Je développe en Java ; j'utilise les sockets standard (grosso modo c'est l'équivalent des sockets en C) et j'ai implémenté ma propre petite librairie au dessus. Rien de bien extraordinaire ceci dit.

Tu trouveras quelques idées par ici.

Attention: l'exemple concerne plutôt une application client/serveur où le serveur est la station sur laquelle tous les clients vont se connecter (topologie en étoile) ; le serveur relayant les paquets de données reçus par un client aux autres clients si besoin est.
- c'est très pratique pour le jeu en réseau sur internet sans que les clients aient besoin de rediriger un port TCP sur leur NAT (box ADSL, point d'accès WiFi, ...).
- par contre, c'est moins performant en termes de latence (il est plus long de faire ClientX=>Serveur=>ClientY plutôt qu'une connexion directe ClientX=>ClientY) et ça nécessite d'avoir un serveur central dédié.

Dans ton cas, tu préféreras peut-être une architecture plus orientée P2P, où chaque client se connectera en direct à tous les autres clients.

A toi de voir.

[hydrolyre]

Je pense me tourner vers une architecture "P2P" car c'est plus cohérent avec la manière dont les modules peuvent communiquer.
Par contre j'ai peur que ça pose des problèmes de synchronisme, non ?
Mais cela va dépendre de la difficulté à implémenter l'architecture. Si une architecture serveur/client est plus simple, elle sera privilégiée.

[nouknouk]

Je pense me tourner vers une architecture "P2P" car c'est plus cohérent avec la manière dont les modules peuvent communiquer.

La topologie réseau choisie n'influencera en rien l'architecture interne de ton code et les dépendances entre les autres modules.
A la limite, les deux topologies pourraient même être implémentées pour par exemple avoir du P2P quand c'est possible et du client/serveur sinon.

Par contre j'ai peur que ça pose des problèmes de synchronisme, non ?

si tu appelles "synchronisme" la notion de multi-thread, tu n'y échapperas de tout façon pas: en général la socket a son propre thread, l'affichage le sien et le moteur de jeu peut également avoir le sien. Donc ça ne change rien.

Mais cela va dépendre de la difficulté à implémenter l'architecture.
Si une architecture serveur/client est plus simple, elle sera privilégiée.

Grosso modo, c'est du kif kif. Peut-être un poil plus court avec la solution P2P car tu n'auras pas de serveur à développer.

[Mat.M]

Par contre j'ai peur que ça pose des problèmes de synchronisme, non ?
.

Comme le dit Nouknouk il faut que tu passes par une architecture de multithreading.
As-tu déjà fait des petits jeux ?
Je te déconseille encore une fois de faire multijoueur tu risques de trop complexifier la chose il vaut mieux faire un bon jeu bien finalisé monojoueur.

Je suis totalement d'accord que l'IA est essentiel. Mais il ne sera pas implémenter dans la première version jouable.
Pour une raison simple, un IA est dur à coder, donc une fois que le jeu fonctionnera bien, on pourra envisager un ajout.
C'est pour ça que le réseau sera développé en même temps que les autres moteurs.
Pour ce qui est du pathfinding, j'ai déjà un A* qui marche très bien... Sauf qu'il ne gère qu'une unité et ne marche pas avec un groupe.

euuh le pathfinding fait partie de l'IA dans un jeu , bon c'est jouer sur les mots.

Si tu n'as pas une bonne IA tu vas créer un jeu qui tombera à plat et dénué d'intérêt...
surtout pour un RTS ou l'IA est primordiale...
que pour un simulateur de vol tu n'aies pas de comportement intelligent des entités passe encore mais pour un jeu de stratégie cela semble difficile de se passer d'une bonne IA

[nouknouk]

euuh le pathfinding fait partie de l'IA dans un jeu , bon c'est jouer sur les mots [...] Si tu n'as pas une bonne IA tu vas créer un jeu qui tombera à plat et dénué d'intérêt...

Il y a IA et IA en effet:

1/ L'IA qui gère les comportements des personnages en fonction d'ordres de "plus haut niveau" qu'on leur a donné. Par exemple:

- "bouge unité vers x,y" implique l'utilisation d'un algorithme de pathfinding

- "coupe du bois" implique que le personnage aille couper du bois dans la case définie (ou aux alentours lorsqu'il n'y aura plus de bois en x,y) et fasse automatiquement l'aller retour entre la forêt et le village pour rapporter le bois coupé (cf. warcraft 2).

- "répondre à une attaque" : lorsqu'un personnage se fait attaquer, il ripostera automatiquement.

- etc...

Cette partie de l'IA (la n°1) est effectivement indispensable dans tous les cas (mono-joueur et multi-joueur). Elle fait partie du moteur de jeu. Donc de toute façon il faudra la développer.

2/ L'IA qui gère un des joueurs de la partie quand un joueur humain veut jouer contre un ordinateur. Cette IA suppose qu'il construise une stratégie, par exemple:
- mon but est d'éliminer l'adversaire. Il me faut des unités. Je vais construire un baraquement pour pouvoir créer ensuite des unités.
- je n'ai plus assez d'or pour faire ceci ou cela, il faut que j'affecte des paysans pour en chercher dans la mine.
- le concurrent m'attaque systématiquement cette zone: je vais renforcer la défense avec des tours et poster des unités ici.
- je me fais attaquer par des unités uniquement terrestres, je vais plutôt construire et envoyer des unités aériennes que l'ennemi ne pourra pas attaquer.
- etc...

Je te déconseille encore une fois de faire multijoueur tu risques de trop complexifier la chose il vaut mieux faire un bon jeu bien finalisé monojoueur.

Un jeu mono-joueur implique le développement de l'IA n°2 en plus de l'IA n°1 (contrairement au jeu uniquement multi-joueurs).

Cette seconde partie de l'IA me semble bien plus ardue à développer car elle implique la notion de stratégie sur du plus long terme (algo min-max etc).

C'est de cette IA dont je parlais quand je disais que "développer un module réseau me semble beaucoup moins complexe que mettre en place une IA à peu près convaincante pour jouer contre l'ordinateur.".

[nouknouk]

A noter qu'il existe un projet open source de moteur de jeu RTS et qui implémente énormément de fonctionnalités (dont le jeu en réseau).

Le projet s'appelle Stratagus et a été utilisé pour concevoir un clone (en mieux ) du Warcraft 2 original: wargus.

Ca devrait te donner un gisement inestimable d'informations pertinentes.

[hydrolyre]

Comme le dit Nouknouk il faut que tu passes par une architecture de multithreading.
As-tu déjà fait des petits jeux ?
Je te déconseille encore une fois de faire multijoueur tu risques de trop complexifier la chose il vaut mieux faire un bon jeu bien finalisé monojoueur.

Mais comme la dit Nounouk, c'est plus simple d'implémenter un moteur réseau qu'une intelligence artificielle complète. Et puis c'est plus sympa de jouer avec des gens sur le réseau que seul sur son pc !

Pour ce qui est de la partie IA qui gère les comportements, sur le papier elle est "simple" a implémenter.
Je pense à un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
//class pour gérer toutes les unités.
class Perso
{
smart_ptr< Action > My_Action;//Pointeur intelligent.
...
 
void Run_Action()//Permet de faire l'action, doit être appellée à chaque tour.
{
My_Action->Run();
}
...
 
};

[hydrolyre]

Hey, voilà un (tout) petit exemple de Snake. Si vous ne comprenez pas un truc dite le moi !
http://cjoint.com/?fkhSRBn0g3

Je tiens à présiser que ce jeux est (très) basic.
Si vous voulez l'exécuter, n'oubliez pas de mettre dans le répertoire:
SDl.dll et la police "Arial.ttf" !

[Mat.M]

Mais comme la dit Nounouk, c'est plus simple d'implémenter un moteur réseau qu'une intelligence artificielle complète. Et puis c'est plus sympa de jouer avec des gens sur le réseau que seul sur son pc !

C'est certain que pour un jeu en réseau tu n'as pas besoin d'IA c'est clair
tu as juste besoin du pathfinding des persos.
C'est pour cela qu'il y a des jeux exclusivement multijoueurs

Hey, voilà un (tout) petit exemple de Snake. Si vous ne comprenez pas un truc dite le moi !
Je tiens à présiser que ce jeux est (très) basic.

Effectivement au premier coup d'oeil c'est assez simple
mais pas dit que je fasse mieux

[hydrolyre]

Mais sous ses aspects de simplicité, ce programme est le fruit de beaucoup de travail !
Sinon, il n'y a personne de motivé pour mon projet ?

[Matthieu Brucher]

@Mat.M : Je suis totalement d'accord que l'IA est essentiel. Mais il ne sera pas implémenter dans la première version jouable.
Pour une raison simple, un IA est dur à coder, donc une fois que le jeu fonctionnera bien, on pourra envisager un ajout.
C'est pour ça que le réseau sera développé en même temps que les autres moteurs.
Pour ce qui est du pathfinding, j'ai déjà un A* qui marche très bien... Sauf qu'il ne gère qu'une unité et ne marche pas avec un groupe.

L'IA dans un RTS, c'est indispensable. Sincèrement, une des raisons du succès des RTS, c'est le fait de jouer seul. Autrement, il te faut mettre en place un serveur, ... Et si tu regardes les stats de ventes des RTS, tu te rends compte que les joueurs sur Internet sont moins nombreux que ceux qui achètent le jeu.

@MoDDiB :
Mon projet IRA JUSQU'AU BOUT!!!!!!!!!!!!!!!
Je connais les contraintes. Mais c'est comme tout, si je me dis que ça ne va pas marcher avant de me lancer, je ne fais rien et je reste dans mon coin, non ?

Tu connais les contraintes, mais tu ne connais pas ton avenir. J'ai plusieurs projets que je m'étais juré de finir, certains sont abandonnés, d'autres avancent, mais trop lentement. Tu ne peux pas promettre d'être encore dispo dans un an, tu n'as aucune stabilité à moyen terme (ie 2-3 ans).

Le protocole utilisé sera TCP, plus sûr que UDP même s'il est moins rapide.

Pourquoi pas, mais l'UDP sera souvent plus intéressant.

Tout est codé en C++.

Erreur, à mon avis. Une IA en Python te fera gagner énormément de temps.

Comme le dit Nouknouk il faut que tu passes par une architecture de multithreading.
As-tu déjà fait des petits jeux ?
Je te déconseille encore une fois de faire multijoueur tu risques de trop complexifier la chose il vaut mieux faire un bon jeu bien finalisé monojoueur.

euuh le pathfinding fait partie de l'IA dans un jeu , bon c'est jouer sur les mots.

Idem, il est indispensable que tu aies une bonne expérience de jeu passé, surtout si tu veux être chef d'un tel projet. Avant de faire du multi-joueurs, il faut savoir comment faire un jeu mono-joueur.

Si tu n'as pas une bonne IA tu vas créer un jeu qui tombera à plat et dénué d'intérêt...
surtout pour un RTS ou l'IA est primordiale...
que pour un simulateur de vol tu n'aies pas de comportement intelligent des entités passe encore mais pour un jeu de stratégie cela semble difficile de se passer d'une bonne IA

+1

Il y a IA et IA en effet:

1/ L'IA qui gère les comportements des personnages en fonction d'ordres de "plus haut niveau" qu'on leur a donné. Par exemple:

- "bouge unité vers x,y" implique l'utilisation d'un algorithme de pathfinding

- "coupe du bois" implique que le personnage aille couper du bois dans la case définie (ou aux alentours lorsqu'il n'y aura plus de bois en x,y) et fasse automatiquement l'aller retour entre la forêt et le village pour rapporter le bois coupé (cf. warcraft 2).

- "répondre à une attaque" : lorsqu'un personnage se fait attaquer, il ripostera automatiquement.

- etc...

Cette partie de l'IA (la n°1) est effectivement indispensable dans tous les cas (mono-joueur et multi-joueur). Elle fait partie du moteur de jeu. Donc de toute façon il faudra la développer.

2/ L'IA qui gère un des joueurs de la partie quand un joueur humain veut jouer contre un ordinateur. Cette IA suppose qu'il construise une stratégie, par exemple:
- mon but est d'éliminer l'adversaire. Il me faut des unités. Je vais construire un baraquement pour pouvoir créer ensuite des unités.
- je n'ai plus assez d'or pour faire ceci ou cela, il faut que j'affecte des paysans pour en chercher dans la mine.
- le concurrent m'attaque systématiquement cette zone: je vais renforcer la défense avec des tours et poster des unités ici.
- je me fais attaquer par des unités uniquement terrestres, je vais plutôt construire et envoyer des unités aériennes que l'ennemi ne pourra pas attaquer.
- etc...


Un jeu mono-joueur implique le développement de l'IA n°2 en plus de l'IA n°1 (contrairement au jeu uniquement multi-joueurs).

Cette seconde partie de l'IA me semble bien plus ardue à développer car elle implique la notion de stratégie sur du plus long terme (algo min-max etc).

C'est de cette IA dont je parlais quand je disais que "développer un module réseau me semble beaucoup moins complexe que mettre en place une IA à peu près convaincante pour jouer contre l'ordinateur.".

min-max, c'est pour un jeu à connaissance complète, ici on ne peut pas utiliser ce genre d'outils. On va plus aller sur des prises de décisions avec apprentissage des solutions pertinentes et non pertinentes, analyse, statistiques, ...

Mais comme la dit Nounouk, c'est plus simple d'implémenter un moteur réseau qu'une intelligence artificielle complète. Et puis c'est plus sympa de jouer avec des gens sur le réseau que seul sur son pc !

Pas d'accord. Sur une seule machine, tu vas pouvoir commencer par régler des problèmes de synchronisation qui vont déjà être épineux. Lorsque tu vas avoir un message indiquant la destruction d'une unité (là aussi, qui prend la décision des dégâts d'une attaque ?) qui arrive 50 ans après que cette unité ait détruite un peu plus tard une autre unité, tu fait comment pour revenir en arrière ?
Avec une IA locale, tu vas déjà avoir moins de problèmes si tu considères que tout est décidé par un seul thread.

Mais sous ses aspects de simplicité, ce programme est le fruit de beaucoup de travail !
Sinon, il n'y a personne de motivé pour mon projet ?

Un projet comme celui-ci intéresse toujours, mais il faut voir les implications d'un tel projet (ça fait plusieurs années que je veux en faire un aussi, mais jamais eu le temps et l'énergie de commencer).