Discussion :

[Mat.M]

le quadrillage est très bien sa lui rajoute des zones de collision

Oui et non ; ça risque de compliquer les choses.
La méthode que j'utilise pour mon jeu c'est celle parfaitement décrite par Frifron.
A chaque rendu je copie chaque rectangle cadre d'image ou frame vers une pile d'objets temporaires puis ces objets sont triés selon la coordonnée Y de positionnement à l'écran et finalement affichés à l'écran et cela fonctionne de manière satisfaisante.
Avec un quadrillage je ne vois pas comment gérer cela ce serait plus compliqué.
Le quadrillage c'est essentiellement utilie pour des algos de pathfinding en A* le grand classique de la programmation de JV
En 3d il n'y a pas tous ces problèmes Direct X et la carte graphique me semble-t-il fait soi-même le tri dans le Z Buffer

[Tigrounette]

oui d'accord pour utiliser un quadrillage pour les zones de collisions eventuellement mais pour determiner l'ordre d'affichage c'est pas très utile. Actuellement ca sert uniquement a replacer le joueur a la bonne position quand c'est necessaire. Ca fonctionne car il n'y a qu'un objet mobile mais lorsqu'il y en aura plusieurs dizaines, ca n'a plus beaucoup d'utilité, un tri sur l'ensemble des objets a chaque frame sera beaucoup plus facile a implémenter et plus précis. C'est d'ailleurs le technique utilisé dans ce genre de jeu 2D en général : affichage des tiles (ou de l'image de background) puis affichage des objets triés en y

Oui c'est parfaitement vrai et c'est vrai qu'au delà d'un certain nombre de joueur, l'utilisation du cadrillage ne sera plus très utile pour l'ordre d'affichage.

Le problème, c'est qu'actuellement, le jeu se met à ramer bien avant d'atteindre ce nombre (qui doit être d'environ une centaine). Donc ça me fait gagner quelques ressources, pas énormément mais c'est toujours ça

____________________


Bon, en ce moment je met en place la couche réseau. C'est long pas super intéressant :p Mais je vais quand même parler un peu du système de déplacement et des outils externes qui me permettront de créer le centre commercial.

La synchronisation des déplacements

Dans un jeu multijoueur, ya énormément de façon de gérer les déplacements. La plus simple, c'est de simplement redistribuer les évènements claviers entres les joueurs.

Par exemple : Un joueur appuie sur la touche droite, le jeu envoie cette information au serveur qui la redistribue à tous les joueurs présents dans la zone, faisant avancer le personnage chez tout le monde. Lorsque le joueur relâche la touche droite, le jeu envoie cette deuxième information au serveur qui la redistribue encore à tous les joueurs, arrêtant le personnage.

Ensuite, il faut prendre en compte les collisions. De base, le jeu gère les collisions de tous les objets susceptibles de se déplacer (les zombies, et les joueurs). Donc lorsque qu'un joueur B se déplace et que sur l'écran d'un joueur A, le joueur B rencontre un obstacle, le joueur B s'arrête.

Le problème, c'est que gérer les collisions de tous les joueurs prend un peu trop de ressource et comme je cherche à afficher un maximum de zombie, il faut que j'optimise là ou je peux.

Donc, plutôt que de laisser le jeu gérer toutes les collisions, il va gérer uniquement les collisions du joueur qui à lancer le jeu. Ensuite, lorsque ce joueur rencontre un obstacle, il envoie cette information au serveur pour la redistribuer à tous les joueurs de la zone.

En fin de compte, je sacrifie un peu de bande passante pour alléger un peu le processeur, mission accomplie :p

L'éditeur de monde

Ici, j'ai pas mal galéré à trouver un système satisfaisant. La problématique était la suivante :

J'ai un serveur, plusieurs joueurs et un monde à afficher chez tous les joueurs. Ce monde doit avoir une représentation côté serveur et côté client. Malheureusement, ils utilisent des langages différents et l'outil me permettant de créer le monde (Flash CS3) me sort un format propriétaire (SWF) que je ne peux pas décortiquer au lancement du serveur pour reconstruire le monde sur celui-ci.

Avoir une représentation du monde côté serveur permet de synchroniser les évènement entre les joueurs. Par exemple, si un joueur prend une chaise, celle-ci disparaît, et lorsque qu'un joueur se connecte un peu plus tard, il faut que le serveur puisse lui dire que cette chaise n'est plus là.

Ya plusieurs façon de procéder :

Je crée un petit fichier texte avec la liste des zones et des objets présents dans ces zones, avec leur position, rotation, paramètre, etc. Ensuite, le serveur décortique ce fichier au lancement et lorsque qu'un joueur se connecte, le serveur lui envoie ce fichier pour que le client le décortique de la même façon.

Le problème de cette méthode, c'est que créer un monde depuis un fichier texte c'est pas tip top Donc en plus de ça, il aurait fallut que je crée un éditeur avec une interface graphique capable ensuite de convertir tout ça en fichier texte.

Bon, c'est super galère donc j'ai cherché une autre solution

J'ai déjà une interface graphique (Flash) me permettant de placer des objets à la volée tout en leurs appliquant des transformations facilement (grossissement, rotation, effets spéciaux, etc). Mais je ne peux pas communiquer avec le serveur directement. Donc j'ai décidé de faire comme ça :

Je crée mes différentes zones, je place mes objets, dans flash. Ensuite, lorsque je lance le serveur, si celui-ci ne dispose pas de représentation du monde en mémoire, se met en mode "attente". Il attend en fait qu'un admin se connecte, en faisant patienter les joueurs susceptible de se connecter avant lui. Lorsque l'admin se connecte, le serveur lui demande de lui faire parvenir toutes les informations du monde dont il dispose. Lorsque que le client de l'admin reçoit ce message, il passe en revue toutes les zones et les objets et enregistre ces informations dans un fichier XML qu'il fait ensuite parvenir au serveur. Le serveur crée ensuite sa représentation du monde, et connecte tous les joueurs qui était en attente.

Bon, concrètement ça prend pas plus d'une seconde, donc mission accomplie, pas besoin de créer un éditeur de monde qui aurait été de toute façon bien moins pratique et puissant que l'environnement graphique de flash :p

L'interface

J'ai aussi commencé à travailler sur l'interface, c'est pas trop mon truc malheureusement donc j'ai essayé de faire un truc simple et sobre. je pense la retravailler un peu plus tard si j'ai le temps.

L'interface de connexion :



L'interface en jeu : en bas c'est pour le chat, en bas à droite ça sera pour le menu (Inventaire, compétences, option, etc) et en haut les informations importantes. Bon, par contre ya de grande chance que ça change, c'est loin d'être définitif ^^

[divxdede]

J'ai un soucis avec ton mécanisme de déplacement.

Finalement ton principe s'appuie essentiellement sur le temps.
Je m'explique, je recois un evenement

"fleche haut appuyé pour joueur Z", mon poste client commence a faire avancer le joueur Z

le temps passe, le joueur Z relache.

"fleche haut relachée pour joueur Z", mon poste client arrette le joueur Z.

Admettons que sur le poste de Z, il ai avancé de 2 cases.
Si l'evenement "Début mouvement" arrive vite et que l'evenement "Fin mouvement" mette du temps à arriver, mon poste client fera peut être avancé de 3 cases (ou plus) alors que Z n'a avancé que de 2 cases.

Pour éviter ceci, tu as un mécanisme tout aussi simple:
- Envoyer les ordres de mouvement avec la position absolue du joueur au moment du changement de mouvement.

Ce qui donnerait:

1. Evenement "Avance" à partir du point 22,44
2. Evenement "Ne bouge plus" à partir du point 22,64

Lorsque tu recois le 1er évenement, on peut commencer a effectuer l'animation. Comme tu connais le sens du mouvement, meme si tu as une petite défaillance réseau, tu peu "extrapoler" son mouvement et le continuer.
Lorsqu'il te donnera un changement de mouvement (ou un arret) il te redonne avec exactitude sa position, ce qui te permet d'ajuster sa position local si elle n'est pas bonne.

Bon, j'ai écris un peu vite, mais j'espere avoir été assez clair.
Il s'agit ni plus ni moins qu'un "Dead Reckoning" simplifié a l'extreme.
Mais pour un tel système, il est souvent preferable que le poste local gére la physique (collisions dans ton cas) de toute les entitées sous "dead reckoning"

[th3r1ddl3r]

Cela reste malgré tout insuffisant, il suffit qu'un joueur A ait un tres mauvais taux de fps pour qu'il ne se déplace que d'une case alors que du coup il aurait du faire au moins 2 voire 3 cases...

Du coup au prochain changement de direction les joueurs verront le joueur A reculer.

A l'inverse, il suffit d'accélerer la vitesse de gestion des évènements clavier pour que ton perso se déplace plus vite que les autres

[Tigrounette]

@divxdede : Tu as parfaitement raison, j'ai oublié de mentionner ce principe. A chaque mouvement, le client envoie le type de mouvement ainsi que la position du joueur, lorsque les autres joueurs reçoivent ce message, le joueur qui se déplace est déplacé la ou il est sencé être et le mouvement débute.

Pour les collisions, c'est la même chose, au lieu de tout gérer en local, chaque joueur envoie aux autres joueurs lorsqu'il percute un obstable, en signifiant qu'il s'arrête et à quel endroit. Du coup, on ne verra pas de joueurs "dans" un décors.

Le problème d'un tel système, c'est lorsque les connexions sont mauvaises, on à tendance à voir certaines personnes faisant de mini téléportation, mais rien de très génant. Car s'il y a un décalage lorsqu'un joueur commence à se déplacer, il y a de forte chance qu'il y ai ce même décalage lorsqu'il s'arrête. Dans ce cas (lorsque le ping est haut mais stable) il n'y a pas de téléportation.

@th3r1ddl3r : En fait, les déplacements ne se font pas image par image. Les personnages n'ont pas de vitesse comme 10 pixel par images, par exemple. En fait, le calcul des distances parcouru se fait sur la position de départ, le temps de départ, et une vitesse en pixel par secondes. Ducoup, quelque soit tes FPS, tu avancera à la même vitesse que les autres.

Pour avancer plus vite que les autres, le seul moyen est de télécharger un petit logiciel modifiant la vitesse à l'aquelle windows s'exécute ou alors de décompiler le client pour le modifier. C'est le risque, car je compte pas ajouter de vérification des déplacements côté serveur qui risque d'être trop gourmant. On verra bien

[nouknouk]

Heureux de voir que le projet avance bien

N'oublie pas de tester ton application dans des conditions réseaux 'réelles' : en effet, on a tendance à tout le temps tester nos applis dans des conditions idéales pendant le développement (typiquement avec les clients & serveurs en réseau local, voir avec tout le monde exécuté sur la même machine).

Le principal souci c'est qu'en ne testant pas l'appli avec un réseau 'moins idéal', eh bien tu vas passer à côté de 90% des bugs réseau.

Une solution tout simple pour simuler une connexion sur le net: avoir une machine sous linux et utiliser 'tc' pour ajouter des règles de gestion du traffic pour 'dégrader' ses caractéristiques, genre:

Code :

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

/> tc qdisc add dev eth0 root handle 1:0 netem delay 60msec 12msec 25%

... t'ajoutera 60ms de délai à l'interface eth0, et 25% de chances que le délai dévie de 12ms.

Dans le même esprit, tu peux simuler de la perte de paquets et plein d'autres choses.

[raptor70]

Ma contribution inutile du jour :est ce normal qu'une bouteille flotte ?

Sinon et de faire partager ton expérience sur ce projet

[nouknouk]

est ce normal qu'une bouteille flotte ?

Il me semble que ladite bouteille est posée sur le sol: sauf erreur de ma part, une bouteille posée à même le sol a été évoquée plus tôt dans le thread quand il était question de détection de collisions et/ou de 'z ordering'.

C'est surtout le fait qu'elle soit affichée à la même 'hauteur' que l'autre bouteille sur la table qui est un peu "confusing".

[Tigrounette]

N'oublie pas de tester ton application dans des conditions réseaux 'réelles' : en effet, on a tendance à tout le temps tester nos applis dans des conditions idéales pendant le développement (typiquement avec les clients & serveurs en réseau local, voir avec tout le monde exécuté sur la même machine).

Ah bonne idée, malheureusement je suis pas sur linux, je vais essayer de bidouiller un peu mon serveur pour avoir ça Par contre, pour la perte de paquet, je crois qu'avec une connexion TCP ça n'arrive jamais, non ? (j'ai un doute)

Ma contribution inutile du jour :est ce normal qu'une bouteille flotte ?

Sinon et de faire partager ton expérience sur ce projet

Comme la dit nouknouk, c'était pour mettre en évidence la gestion de l'ordre d'affichage des objets posés sur d'autres objets. Comme le montre ce screen :



Même si les deux bouteilles sont au même niveau, on voit bien qu'ici, yen à une posée par terre et l'autre sur la table.

Mais c'est vrai que ça peut porter à confusion. Typiquement, dans ce genre de vue, on ajoute une ombre à la base d'un objet pour situer sa hauteur. Mais comme je ne vais pas gérer la hauteur des objets (à par quand il sont posés les uns sur les autres) je vais aléger le moteur graphique en zappant les ombres

[divxdede]

Ah bonne idée, malheureusement je suis pas sur linux, je vais essayer de bidouiller un peu mon serveur pour avoir ça Par contre, pour la perte de paquet, je crois qu'avec une connexion TCP ça n'arrive jamais, non ? (j'ai un doute)

Si, la perte de paquet au niveau de la transmission arrive tout le temps.
TCP/IP est un protocole qui gére cette perte en redemandant au serveur les paquets perdus, en retenant les paquets reçus qui doivent attendre. Bref, il s'occupe que tout arrive et dans le bon ordre.

Ceci dit, si ton réseau est mauvais, la couche TCP va devoir redemander régulierement des paquets, bloquants d'autres paquets et provoquant ce qu'on peut appeler des "lags". C'est à dire des trous pendant lesquels aucune information arrive, puis pleins de données vont arriver en burst.

Ton application doit être le moins sensible a ces grosses latences et a ces burst. Souvent ca peut se traduire par un bonhomme qui ne bouge plus puis qui finit par parcourir l'écran à la vitesse de la lumière.

[nouknouk]

Ah bonne idée, malheureusement je suis pas sur linux, je vais essayer de bidouiller un peu mon serveur pour avoir ça Par contre, pour la perte de paquet, je crois qu'avec une connexion TCP ça n'arrive jamais, non ? (j'ai un doute)

Que TCP t'assure que tu recevras tous les paquets n'empêche pas que la perte de paquet peut arriver au niveau du réseau. Donc du point de vue développeur ça veut dire:

- effectivement, que tous les paquets envoyés, tu les recevras car l'implémentation du protocole TCP se rendra compte de la perte et re-demandera à l'émetteur le paquet oublié.

- par contre, comme le paquet perdu au niveau du réseau va devoir être redemandé (par l'implémentation 'bas niveau' du protocole TCP ; tout cela est fait en interne et tu n'as pas à t'en soucier) ça aura deux conséquences sur le 'timing de réception' desdits paquets:

* un 'pic soudain' de la latence pour le paquet perdu

* tous les paquets suivants (et déjà reçus) vont être retardés le temps que le paquet perdu ait été à nouveau transmis. D'où la délivrance de plusieurs paquets (celui perdu et les suivants) d'un seul coup à ton application.

EDIT: grilled par divxdede

Ceci dit:

Si, la perte de paquet au niveau de la transmission arrive tout le temps.

Faut pas exagérer non plus: ça arrive de temps en temps, mais pas 'tout le temps'. Un paquet ré-émis a deux raison principales:

1- congestion du réseau => des paquets sont éliminés parce que le lien de transmission est saturé

2- contenu du paquet altéré.

Pour le (1), ça arrive relativement peu souvent étant donné que les connexions internet actuelles n'ont plus rien à voir avec nos anciens modems analogiques, et qu'en règle générale (et hormis si le joueur donwnloade 15 fichiers en même temps) la bande passante est rarement saturée.

Pour le (2), autant les paquets erronnés étaient monnaie courante avec des connexions RTC (ie. le bon vieux modem 56k), autant depuis l'ADSL, les altérations de paquets sont bien plus rares.

re-edit: A propos de linux, tu n'as pas besoin non plus d'installer un linux sur ta machine: un simple 'live cd' genre ubuntu peut suffire pour faire ce genre de tests.

Je t'assure qu'il faut vraiment que tu prévoies une campagne de chasse aux bugs réseaux, c'est limite indispensable. La robustesse et l'efficacité de la partie réseau vont être au coeur de la "smart user experience" de tes joueurs. Si cet aspect n'est pas peaufiné, tu risques d'avoir un jeu avec un superbe potentiel, mais les lags et autres joyeusetés dûes au réseau rendront le gameplay injouable/énervant pour le joueur qui se détournera rapidement de ton jeu.

[divxdede]

Oui j'ai eu une vision pessimiste pour faire un peu peur et pour le sensibiliser.

Ceci dit, dans ton exemple de congestion, le download des 15 fichiers en est rarement la cause.

Lors d'une congestion, le responsable est le plus souvent un maillon du réseau (a savoir un routeur quelqu'onque).
En effet s'il sature, sa pile de trames (ou une de ces piles) se remplit et finie par être pleine. A ce moment la des paquets commencent à être perdus et le destinataire n'en est pas responsable.

Mais je suis d'accord, la perte de paquets est beaucoup moins fréquente qu'il y a quelques années.

[Tigrounette]

Ok, merci pour ces précisions

____________________


En ce moment, je commence à travailler sur les combats. C'est une partie importante du jeu qui risque de beaucoup évoluer. Donc pour le moment, je vais tenter de poser de bonnes bases, quitte à ne pas tout utiliser à la fin.

Donc, 90% des combats se feront aux corps à corps avec des objets divers. Ces objets ont plusieurs caractéristiques qui serviront pour les combats :

• Les dégâts.
• La résistance (à chaque utilisation, l'objet s'abime et fini par être détruit).
• L'allonge (Je vais en parler un peu plus bas, elle permet de définir à quelle distance un joueur peut atteindre un zombie).
• Le nombre de zombie touché simultanément (Les gros objets pourront toucher plusieurs zombies en une seule attaque).

Une étape importante pour le bon déroulement des combats va être la mise en place du système de "collision" entre les armes et les zombies, pour savoir si un joueur est assez proche d'un zombie pour le toucher.

En fait, c'est assez simple. A chaque fois que le joueur porte une attaque, une petite zone se forme juste devant lui. Ensuite, on parcourt la liste des zombies présent dans la zone et on regarde quels sont les zombies présent dans cette petite zone.

Un petit screen pour illustrer tout ça (admirez au passage mon zombie, mais il vont changer, celui là est trop destroy ) :



Le petit rectangle correspond à la zone dans laquelle le joueur peut toucher quelque chose. La position du zombie est représenté par le petit carré bleu-vert, juste sur son pied. Lorsque le petit carré est dans la zone rouge, le joueur est bien placé pour toucher le zombie. S'il est à l'extérieur, ça veut dire que le joueur est trop loin. (Le rectangle et le carré, c'est juste pour vous montrez, ils n'apparaîtront pas en jeu )

La hauteur du rectangle est fixe mais pas sa largeur, qui dépend de l'allonge de l'arme que le joueur utilise. par exemple, avec ses poings, le joueur est obligé d'être plus prêt d'un zombie pour le toucher. Alors qu'avec un objet avec une meilleur allonge, il pourra toucher le zombie de plus loin, comme le montre ce screen avec le tabouret :



La hauteur de la zone est assez haute pour permettre aux joueurs d'attaquer un zombie par le bas et par le haut et de pas être obligé de se mettre exactement au même niveau. 2 petit screen montrant la limite de cette zone :



Comme vous pouvez le voir, sur ces deux screen, le joueur ne touche pas le zombie car le petit carré n'est pas dans la zone rouge. Il est juste en dehors, donc si le joueur descend un peu sur le premier screen ou monte un peu sur le deuxième, il pourra le toucher.

Maintenant que se passe t'il s'il y a plusieurs zombie dans la zone d'attaque d'un joueur ?

Chaque objet peut toucher un certain nombre de zombie simultanément, mais la plupart ne pourront en toucher qu'un seul à la fois. Pour porter une attaque, le joueur doit cliquer sur un zombie, si le zombie est à porté, il est touché et si l'arme peut toucher plusieurs zombie à la fois, le jeu regarde s'il y a d'autre zombie dans la zone d'attaque. En gros, l'arme touche d'abord le zombie sur le quel le joueur à cliqué. Si le zombie cliqué n'est pas à porté, le jeu regarde s'il peut en touché un à porté pour éviter de "gaspiller" des attaques.

Les attaques des zombies

Les zombies utiliseront le même système (sauf que eux, ils attaqueront uniquement quand ils seront à porté). Par contre, lorsqu'un zombie se fera attaquer il subira un instant d'étourdissement, où il ne pourra ni bouger ni attaquer (alors qu'un joueur touché gardera le contrôle de sont personnage). Le joueur pourra donc enchaîner un zombie sans qu'il puisse réagir, mais ou est la difficulté alors ? C'est simple, un zombie isolé ne représentera aucune menace pour un joueur alors qu'un petit groupe de zombie posera déjà beaucoup plus de problème.

La particularité des zombies c'est qu'il seront très résistant et relativement long à tuer (enfin... retuer ). Donc pendant qu'un joueur enchaînera un zombie pour l'empêcher de nuire, il faudra qu'il fasse attention aux autres zombies qui risqueront de l'attaquer. L'étourdissement d'un zombie après un coup, durera le même temps qu'une attaque d'un joueur, donc le joueur ne pourra pas alterner ses attaques pour en étourdir deux à la fois. C'est la que la coopération entre les joueurs entrera en jeu :p

[Tigrounette]

Hop, la suite :p La semaine dernière, j'ai migré le jeu sur la nouvelle version de flash (flash CS4) et j'ai regardé un peu les nouveautés et les choses qui pourront m'être utile, donc ça a pris un peu de temps.

____________________


Maintenant, je vais parler du système de déplacement des zombies. Au départ, je pensais utiliser un algorithme A*, mais bon, je trouvais un peu dommage que les zombies ne se coincent pas dans le décors, ben oui c'est des zombies et il sont bêtes

Donc plutôt que de leurs permettre d'éviter les zones de collision, j'ai décider de les faire avancer en ligne droite et de s'arrêter lorsqu'ils rencontrent un obstacle. Ca me permet d'économiser pas mal de ressources et d'effectuer ces calculs directement sur le serveur. Et les joueurs pourront se servir du décors pour éviter les zombies, et pourquoi pas faire des barricades. Un petit exemple en screen :



Sur ce screen, le zombie ne cherchera pas à contourner la table.

De plus, j'ai ajouté une autre petite variable : l'intelligence des zombies. Cette variable (qui change d'un zombie à l'autre) définie la durée entre chaque décision d'un zombie. Par exemple, si elle est définie sur 1, le zombie pourra changer de direction toute les 1 secondes. Ca va rendre certain zombie très bête (genre le zombie qui va là ou un joueur se trouvait ya 10 secondes) et d'autres plus "nerveux" qui pourront suivre les déplacements d'un joueur assez rapidement. Aussi, chaque zombie à une vitesse de déplacement différente, accentuant cet aspect.

Une autre screen pour la route

[Idrakis]

Je suis ton projet depuis qu'il a été crée, et je trouve que tu fais vraiment un superbe travail.

C'est réellement passionnant de voir le projet avancer rapidement et régulièrement, au jour le jour, avec des commentaires aussi détaillés et vivants de ta part.

Je trouve que tes dernières idées sur l'Intelligence Artificiel des zombies ( ou plutôt justement la "non-intelligence artificiel" ) ajoute vraiment une touche originale, innovante, et fun à ton jeu.

J'ai hate de pouvoir y jouer

[Tigrounette]

Justement j'aimerai mettre en place une petite phase de test. A ce stade du développement, elle ne me sera pas vraiment utile, mais peut être que certains d'entre vous aimerai en voir un peu plus.

Bon, y'aura pas grand chose à voir pour l'instant, mais si ça intéresse du monde, je referai des petits tests de ce genre régulièrement.

Au programme :
- Création des personnages.
- Manipulation du décors (Sélection des objets).
- Tapage de zombie.

Je ne peux pas laisser le serveur allumé sans surveillance, donc la phase de test ne durera pas très longtemps. Je vais donc poser un petit horaire.

Disons le mardi 25 novembre à 21h00. Je donnerai le lien du jeu à télécharger à ce moment.

Un petit screen de la création de personnage, au passage :

[BrItneY]

Bonne idée ! Qui sait, on pourra peut être t'aider à l'améliorer... avec left 4 dead qui est sorti, on est en plein tapage de zombies en ce moment

Prêt à casser du zombie (seulement pour que t'aider hein )

[Tigrounette]

Voilà, vous pouvez télécharger le jeu ici (4 mo).

C'est un exécutable qui intègre la bonne version de flash player, donc pas besoin de le mettre à jour (Il n'installera rien du tout, c'est juste un exécutable tout en un).

Je lance le serveur d'ici 10 minutes, ya encore quelques petits réglages à faire ^^

[raptor70]

Voilà, vous pouvez télécharger le jeu ici (4 mo).

C'est un exécutable qui intègre la bonne version de flash player, donc pas besoin de le mettre à jour (Il n'installera rien du tout, c'est juste un exécutable tout en un).

Je lance le serveur d'ici 10 minutes, ya encore quelques petits réglages à faire ^^

C'est vraiment nickel ..encore bravo

A part les petits bug que je t'ai signalé, rien à dire .. parfait

[nouknouk]

Ca a effectivement très bien fonctionné durant le test.

Ca promet pour la suite