|
Alpha & Oméga
|
Les collisions et la profondeur
Oui, c'est la meilleurs solutions je pense. Les textures sur toute une surface ça encombre un peu trop je trouve. Enfin, c'est le genre de trucs que je risque de faire en dernier de toute façon
 Citation :
 Mais je compte faire plusieurs test avant, surtout pour bien tester les combats. Le premier test se fera d'ici 1 ou 2 semaines.____________________ Aujourd'hui, je vais parler de la mise en place du système de collision et du système de profondeur. La profondeur des joueurs et des objets Dans un jeu en 2D comme ça, il faut gérer la profondeur sur l'axe nord-sud. En gros, si un objet est plus bas qu'un autre, il doit se retrouver devant ce dernier. Pour mettre en place un tel système, j'ai découpé l'espace de jeu en petite case de 20 pixels sur 20 pixels. Comme ceci :  Quand le joueur se déplace sur l'axe Y et qu'il change de ligne, ça déclenche la mise à jours de la profondeur du dit joueur. C'est à dire qu'on regarde sa position en fonction des autres objets du monde et on ajuste sa profondeur. Par exemple, si le joueur est plus bas qu'une table ça donne ceci :  Alors que si le joueur est plus haut, il se retrouve derrière :  Le fait d'avoir découpé l'espace en petit carré de 20x20 permet de déclencher ce genre de mise à jours beaucoup moins souvent que si j'avais testé ça pixel par pixel, ce qui économise beaucoup de ressource. L'inconvénient, c'est que les objets doivent être attachés sur cette grille pour éviter d'avoir des chose comme un joueur légèrement plus bas qu'un objet mais de quand même rester derrière. Ce genre de problème se produira en revanche entre les joueurs, mais bon, comme ils seront souvent en mouvement, ça sera moins désagréable. Au pire, je peut toujours rétrécir le quadrillage. En revanche, un autre problème s'est posé à moi au bout d'un moment. Dans le dernier screen, on peut voir que je suis plus bas que la chaise posée sur la table mais que je suis quand même derrière celle-ci. En fait, j'ai du mettre en place un système de liaison entre les objets pour ce genre de cas, où un objet est en fait posé sur un autre objet. Ca me permet de prendre en compte la position d'un seul objet pour calculer la profondeur de tout un groupe d'objet. On le vois bien sur ce screen :  Les deux bouteilles d'eau sont à la même position sur l'axe Y mais celle de droite est liée à la table ce qui la place devant mon personnage. De cette façon, on voit bien qu'elle est en fait posée sur la table, alors que l'autre est posée par terre. Les collisions J'ai profité de ce quadrillage pour mettre en place mon système de collision. J'ai créé un truc tout bête qui prend en compte la taille de l'objet pour marquer certaines cases du quadrillage comme étant "non franchissable". Comme le montre ce petit screen (Les cases vertes ne peuvent plus être traversées) :  Si un objet est trop petit, il ne déclenche pas de collision avec les joueurs, comme le montre la petite bouteille en haut à gauche. Comme pour la profondeur, le fait d'utiliser un quadrillage permet d'économiser des ressources plutôt que de gérer les collisions pixels par pixels. D'autant que pour ce genre de vue, ya pas besoin d'avoir un truc ultra précis Tout ceci se fait dynamiquement. C'est à dire que sur flash, j'ai une scène qui représente un niveau où je place mes différents objets à l'arrache. Ensuite, c'est le jeu en se lançant qui reconstruit le monde en rendant les objets sélectionnable, en les attachant au quadrillage et en créant les zones de collision suivant la taille de l'objet. Ca va me permettre de créer du contenu rapidement sans trop d'effort à paramétrer chaque objet avec des valeurs numériques De plus, ce quadrillage me servira plus tard pour gérer le pathfinding des zombies. Ca permettra de rendre les objets infranchissable pour les zombies et ça me donne des idées de gameplay autour des barricades et autres joyeusetés du genre  Prochaine étape : le tapage de zombie 
|
29/10/2008, 22h17
|
[Journal de bord] Création d'un petit jeu de zombies
| Suivre |
|
|
Partager | Rechercher |
|
[Mael]
Alpha & Oméga
|
Citation :
Sinon, c'est vraiment sympa, ce petit compte-rendu ... on dirai presque que tu fais un projet d'école, et que tu rendra tes posts à la fin à des profs  Qui sait, ça pourra sûrement aider d'autres personnes qui voudront faire un jeu en flash (ou autre), dans le type de développement ... Faudrait que tu pense à l'archiver quelque part, pour le garder longtemps ^^ Hum , sinon ... Que dire ... Le système de collision à l'air bien, l'affichage aussi, tout à l'air de marcher, et ne pose pas de problèmes .... Maintenant ... Plus qu'à attendre un peu, pour commencer les béta tests Bonne continuation 
|
|
29/10/2008, 22h34
|
|
Alpha & Oméga
|
Oops, c'est corrigé
Oui, le but c'est de faire quelque chose de bien construit pour changer. Et je dois dire que ça m'aide énormément, pour l'instant j'ai quasiment pas recommencé de partie précédente à cause de choses non prévues, ce qui me permet de faire tout ça vite et bien. En plus, ça motive de tenir ce petit journal, qui est justement fait pour en garder une trace
|
|
29/10/2008, 22h51
|
|
[Mael]
Alpha & Oméga
|
Ben si ça t'aide, c'est tant mieux
Comme d'hab, tu pourra compter sur mes retours pour ta béta, je serai là, à tout essayer ce qui pourra se faire PS: c'est mignon l'avatar qui regarde ton titre d'Ange avec les mains qui semblent en position de prière 
|
|
29/10/2008, 23h50
|
|
Alpha & Oméga
|
Joli boulot Tigrounette, dommage pour ton card game, mais j'ai hâte de voir ce que va donner celui ci.
Une question, ton server en Java c'est assez complexe? Parce que je cherche actuellement une solution pour un serveur pour une appli flash, j'ai essaye PHP (facile a faire pour moi mais bien trop lent), C# (très facile a mettre en oeuvre, mais oblige a avoir un serveur Microsoft et je m'emmêle pas mal les pinceaux sur le multithreading x_x ), donc je me demandais si Java était facile a utiliser pour faire ce genre de chose (je ne suis pas un noob total en Java, j'en ai fais en BTS mais jamais utilise en dehors du cadre scolaire). Si tu as des ressources je suis preneur Citation :
(c'est pas contre toi )Pour faire cours, une appli développée correctement en AS3 est vraiment très tres loin d'être aussi consommatrice que si elle avait été faite en AS2, le changement de Virtual Machine pour flash a fait un bien fou a l'animation et aux effets graphiques (entre autre), encore plus depuis flash 10 et un meilleur support de l'accélération matériel. Si le codeur fait les choses proprement (Garbage Collection, typage correct, utilisation des BitmapArray pour les graphismes,...) un jeu en AS3 doit pas manger beaucoup... |
|
30/10/2008, 00h52
|
|
Alpha & Oméga
|
Vous avez des bonnes docs ou sources (bouquin anglais ou non) sur le "bien coder" en AS3 ?
Je suis épaté par le travail de Tigrounette. Niveau technique, tu assures. Mais en plus niveau graphique, c'est bon. Quand je vois comme je galère pour sortir du graphisme qui n'écorche pas les yeux... Bravo ! |
|
30/10/2008, 10h42
|
|
Alpha & Oméga
|
Citation :
Citation :
Puis, après des dizaines de version, j'en suis arrivé à un serveur java sur un seul thread utilisant java.nio. Serveur beaucoup plus performant mais pas facile à programmer, j'ai toujours pas de version vraiment stable, donc bon... Tu as pas mal d'exemple sur le net comme celui-ci. Le problème c'est que quasi totalité de ces exemples sont pour la plupart bugué et explose avant d'atteindre un certain nombre de connecté. |
|
30/10/2008, 21h51
|
|
Bagnard
|
Franchement , c'est un truc énorme que tu nous fait encore Tigrounette
 Je tes connu ya fort lgts , et je regrette pas ; ) Tu fait vraiment du beau travaill , et j'espère pouvoir joue à ton jeux
|
|
31/10/2008, 12h22
|
|
Alpha & Oméga
|
Citation :
http://www.bytearray.org/?p=128 Qui devait sortir chez O'Reilly France, mais qui a ferme ses portes entre temps, du coup l'auteur l'a sorti en open source. Apres l'aide de flash est superbe aussi comme le dit tigrounette. Cote web www.kirupa.com est un très bon site, les tips of the day sur le forum sont une vraie mine de bonne ressources et astuces. En français la communauté mediabox est de loin la plus active et propose un large panel de tuto et sur le forum ya de très bon expert qui répondent aux questions. -> http://flash.mediabox.fr/ Et cote optimisation : http://www.rozengain.com/blog/2007/0...optimizations/ ya plein de link en bas aussi
|
|
31/10/2008, 14h23
|
|
Alpha & Oméga
|
Merci pour toutes ces références.
Pour Tigrounette, concernant le serveur, NEL ne pourrais pas te rendre service ? |
|
31/10/2008, 15h54
|
|
Empereur
|
Citation :
Mais dans ce cas, je me pose la question: comment, avec une seule thread, gérer l'IA pendant que cette thread attend les requêtes des joueurs ? dstar |
|
01/11/2008, 11h07
|
|
Empereur / Impératrice
|
Il te suffit d'écouter tes sockets de manière non bloquante.
En gros dans la boucle de ton serveur, tu auras: - écoute de tous les sockets - mise a jour de l'ia - ... Cela te permet de tout faire de manière séquentielle et d'éviter l'overhead que tu aurais eu en ayant 1 thread par connexion, tout en t'évitant les problèmes d'accès concurrentiels aux données. |
|
04/11/2008, 16h51
|
|
Empereur / Impératrice
|
new post wouaaa!!
C'est trop bien ce journal de bord bravo!!
Je pense que c'est une idée géniale !! Si ce site n'était pas uniquement dédié au jeux j'y écrirai mon livre de la même façon que tu expose ton projets et son évolution !! Tu est vraiment douée et j'aimerai beaucoup apprendre à crée des jeux moi aussi comme ça mon livre prendrai d'autre dimension. j'attend la suite avec plaisir. |
|
07/11/2008, 19h56
|
|
Alpha & Oméga
|
Citation :
____________________ Bon, en ce moment je met en place la couche réseau. C'est long pas super intéressant 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 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 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 ^^ 
|
|
09/11/2008, 13h01
|
|
[Mael]
Alpha & Oméga
|
Ha ha, enfin de retour ^^
Ça a l'air de bien avancer ... Pas mal le coup de la synchronisation ... L'interface est sympa, la même qu'avant on dirait ... C'est bête, d'ailleurs, vu qu'elle va pas trop avec un thème "zombie" .... :-° 'Fin bon, c'est pas prioritaire, de toute façon ^^ @+ ! |
|
09/11/2008, 16h30
|
|
Alpha & Oméga
|
Citation :
|
|
09/11/2008, 18h41
|
|
[Mael]
Alpha & Oméga
|
Pour son graphisme, faudrait qu'il soit coordonné avec le design futur des survivants en général, et des zombies ...
Avec de petite "incrustations" comme une main (grossie) de mort vivant qui dépasse du cadre, une ou deux armes posés contre les boutons ou contre le bord, ça pourrai sans problème coller au thème ... Reste à trouver une couleur de fond, ou une texture simple .... et c'est ça le plus dur ... :s |
|
09/11/2008, 19h52
|
|
CEO 3DDuo, Empereur
|
Félicitations Tigrounette.
Je te lis attentivement depuis un moment et tout ce que tu expliques est super intéressant. J'espère que tu arriveras à ce que tu souhaites et que l'on pourra voir prochainement un petit truc testable Les zombies c'est à la mode en ce moment ^^ profites-en |
|
11/11/2008, 12h37
|
|
Alpha & Oméga
|
Les bases du combat
Citation :
____________________ 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 :
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, il 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
|
|
11/11/2008, 18h11
|
|
[Mael]
Alpha & Oméga
|
Ton zombie est zoliiiiiiiiiiiiiiiiiiiiiiiiiiiiii .............
'Fin bref, il fait sympa, faudrait que tu pense à mettre plusieurs types de zombies différents, avec des boss, celui là, avec un veste noire et une guitare (cassée) dans le dos (ou dans les mains) pourrai faire zombie de métaleux, en concert dans le Mall, ou dans une boutique thémée dessus ... Sinon, ton système de combat à l'air sympa, bien fait, tout ça ... Et bien expliqué, en plus .. @+ ^^ PS: ai pas répondu deux minutes après toi, comme d'hab, j'etais encore ban ... :'( désolé :-° |
|
11/11/2008, 22h51
|
|
Invité
|
Message supprimé par son auteur.
|
|
15/11/2008, 17h14
|
|
Alpha & Oméga
|
Les déplacements des zombies
Hop, la suite
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 
|
|
18/11/2008, 14h24
|
|
[Mael]
Alpha & Oméga
|
joli joli
Bonne idée, celle des déplacements ... ça rendra clairement les déplacements des zombies plus "réalistes" dans le sens où des zombies classiques savent juste avancer tout droit ... ^^ PS: j'adore ce model de zombie, même si tu ne l'a pas prévu comme final
|
|
18/11/2008, 14h31
|
|
Alpha & Oméga
|
Citation :
Le jeu proposera-t'il un mode 'Jeu par équipe' ? Envisages-tu, après la 1.0 qui tourne bien, de faire évoluer le jeu pour par exemple inclure des capacités funky et/ou des classes de perso (avec bonus et malus dans certains aspects du jeu) ? Bon courage et bon jeu! |
|
18/11/2008, 23h41
|
|
Héros
|
J'ai bien aimé ta réflexion sur le déplacement des zombis
 Je vois aussi que tu es passé à un système de tiling pour gérer les collisions (carrés bleus) Tu peux nous en dire plus sur ta gestion des cartes, edition y compris? |
|
19/11/2008, 00h49
|
| Suivre |
Connectés sur ce fil1 connecté (0 membre et 1 invité)
Afficher la liste détaillée des connectés
|