Discussion :

[Tigrounette]

Salut ici :p

J'aimerai mettre en pratique une petite idée qui me trotte dans la tête depuis un certain temps. Lorsque je décide de créer un nouveau jeu, j'ai tendance à faire ça un peu à l'arrache, sans poser de base et sans réfléchir en profondeur à certains aspects pourtant importants. Et surtout, je fait ça dans mon coin sans demander d'avis à personne.

Jusque là, j'était en train de travailler sur un autre projet : Extinction. Mais je tourne en rond pour le finir, il manque un petit quelque chose et j'ai décider de le mettre de côté pour l'instant, le temps que l'inspiration revienne.

J'ai donc envie de me lancer dans un autre jeu qui sera beaucoup moins ambitieux. Pour le moment, je table sur 2 mois au maximum pour avoir quelque chose de plus ou moins finalisé (J'ai commencé tout ça le 15 octobre, je vais mettre quelques messages à la suite pour l'avancement jusqu'ici). Et au passage, je pense qu'il serait intéressant de tenir à jour ce petit journal de bord pour expliquer et pour discuter de toutes les étapes de réalisation du jeu (game-design, graphisme et programmation).

J'espère que ça pourra vous être utile à vous autant qu'à moi et que vous pourrez m'apporter avis et critiques :p

____________________


Maintenant, commençons par le commencement ^^

Quel genre de jeu ?

Alors, quel sera le genre de ce jeu ? C'est pas compliqué, j'ai regardé ce que je savais faire et ce que j'aimais bien et j'ai mélangé tous ça ^^

Je sais faire des jeux multijoueurs
Je sais dessiner (avec plus ou moins de succès)

Je ne sais pas faire de 3D
Je ne sais pas faire de 3D isométrique

J'adore les zombies ^^
J'adore plus particulièrement le film Zombies et son remake L'armée des morts
J'adore le jeu Dead Rising

Je compte pas faire un jeu super original avec des concepts jamais vues. Je veux faire un truc simple, efficaces et pas trop long à faire Donc, à partir de ce constat, je pense faire le jeu suivant :

Gameplay :

Les joueurs incarneront des survivants qui tentent de survivre dans un centre commercial envahi par une foultitude de zombies.
Ca c'est la base, mais je compte orienter le jeu sur deux points importants :

• La survie, grâce à une gestion de la faim, le joueur devra explorer le centre commercial pour se nourrir, sous peine de mourir de faim. La plupart des interactions multijoueurs viendront de ce concept.
• L'utilisation d'objets, qui permettra aux joueurs de combattre les zombies avec un grand nombre d'objet différent. Mais ces objets seront fragile, ce qui obligera les joueurs à souvent combattre avec ce qui leurs tombent sous la main.

Graphisme :

C'est la partie qui m'inquiète le plus, je ne veux pas "voler" de sprites qui ne m'appartiennent pas, donc va falloir faire un truc jolie et fonctionnel avec des compétences limités :o

Donc là, j'ai pas trop le choix, comme je ne sais pas faire de 3D ou de 3D isométrique, je vais faire ça en 2D, mais en 2D un peu plus évolué qu'un Mario sur un seul plan. En gros, seul le décors sera en 3D isométrique, tout le reste (Personnage, zombie, objets) sera en 2D. Ce sera un peu le même principe que le jeu Castle Crasher, dont voici un petit screen :

Castle Crasher

Les zones seront surtout étirées en largeur mais les joueurs pourront se déplacer en haut et en bas (Mais même en marchant vers le haut, le joueur restera de profil). Par contre, je pense pas prendre en compte l'axe Z, donc les joueurs ne pourront pas sauter.

Technique :

C'est la partie que je maîtrise le mieux, et qui me posera le moins de problème.

Le client sera en flash, en 800x600 et utilisable via un navigateur ou un fichier exécutable. Le serveur sera en Java qui tournera sur un serveur dédié et la connexion se fera par socket (donc en temps réel). La base de donnée sera une base MySQL.

____________________


Voilà :p ça c'est la base de la base. Je vais pas encore détailler le gameplay, car pour l'instant, je travaille sur les personnages et leurs animations et voir ce dont je suis capable de faire (pas la peine de prévoir de nager dans le gameplay si je n'arrive pas à faire l'animation de nage ). Pour l'instant, j'ai un perso pas trop moche qui cours de façon pas trop ridicule, mais je détaillerai tout ça dans un prochain message, quand j'aurais un personnage qui peut attendre, courir et tenir un objet.

[Tigrounette]

Bon, je vais commencer par parler de la création des personnages et de leurs animations. Par personnages, j'entend les humanoïdes qui bouge, donc les joueurs et les zombies pour l'instant.

Avant de commencer, j'avais en tête un truc important : faire en sorte que les personnages soient personnalisables et évolutifs. Donc faire chaque image de chaque animation de chaque personnage était hors de question

C'est pourquoi, j'ai décider d'utiliser un truc tout bête : Les squelettes.

Ces squelettes sont des personnage en bâtonnet, que j'anime ensuite. Puis dynamiquement, je peut appliquer un modèle sur ce squelette. Un squelette comprend 14 partie :

• La tête (Qui est aussi un squelette, qui comprend les éléments du visages : Cheveux, yeux, nez, bouche)
• Le corps
• Les 2 bras découpés en 3 parties (Main, avant bras, et bras)
• Les 2 jambes découpés en 3 parties (Pied, Jambe, Cuisse)

Voici mon super squelette :



Et voici ce que j'obtient en appliquant mon premier petit modèle (je peux pas vous montrer les animations, mais pour l'instant j'ai une animation de course et une animation statique ou le personnage se contente de respirer) :



Avec ce système, je dispose des avantages suivants :

• Je peux créer de nouveaux vêtement ou zombies sans toucher aux animations.
• Les personnages sont "découpable", attendez vous à voir des têtes, mains, bras et pieds qui volent
• Les joueurs pourront vraiment personnaliser leur personnages, en changeant de coiffure, de visage, et de couleurs (chaque partie peut avoir sa propre couleur).

Bon, ya encore pas mal d'ajustement à faire, mais pour un premier jet c'est pas trop moche, je m'attendais à pire Donc voila, pour la prochaine étape : Création d'une version masculine et d'un premier zombie ^^

[Tigrounette]

Une petite explication sur la futur création et personnalisation des personnages ^^

A la base, les "modèles" de personnage sont en nuance de gris comme ceci :



( Vous pouvez aussi voir la version masculine, j'ai pas encore fait de barbes ou de moustaches mais ça viendra :p )

Ce qui permet ensuite de "teindre" chaque partie du squelette avec une couleur différente de façon dynamique, c'est à dire qu'en cours de jeu, ces couleurs pourront éventuellement changer. Ce système permettra de bien différencier chaque joueur au premier coups d'oeil, en plus des éventuels vêtements, coiffures et visages propre à chaque joueur. Quelques exemples :

[Tigrounette]

Hop là, le dernier message qui date d'aujourd'hui : En ce moment je travaille sur les animations en rapport avec les objets. Ben c'est pas facile J'ai pas mal galéré sur certains trucs.

Déjà, ya un problème au niveau du fonctionnement de mon squelette. Quand je crée une animation de course par exemple, je dois animer toutes les parties du squelette. Le problème viens lorsque je veux effectuer une attaque en courant, comme les animations d'attaque et de course sont deux animations distinctes, je peux pas "fusionner" ces animations pour avoir un personnage qui attaque en courant.

J'ai donc du apporter quelques modification à mon squelette. Pour y arriver j'ai découper mon squelette en 3 parties:

• La tête
• Le haut du corps (Corps et bras)
• Le bas du corps (Jambes)

Chaqu'une de ces parties contiennent d'autres sous-parties (Cuisses, jambes et pieds pour le bas du corps par exemple), ce qui ne modifie pas le fonctionnement global du squelette.

Maintenant, pour créer une animation d'attaque par exemple, je dois juste créer une animation avec le haut du corps ce qui me permet de ne pas toucher aux jambes qui peuvent faire autre chose pendant ce temps :p

Ce système, je l'ai surtout fait pour une chose : Les différentes poses du personnage en fonctionnement de l'objet. J'ai pas envie que les personnages tiennent un canif de la même façon qu'un banc

Pour l'instant, j'ai ces 4 postures différentes :



Je compte en ajouter encore 2 ou 3, pour d'autres types d'objets. Après, il faudra que je fasse une animation d'attaque pour chaque pose. C'est en cours, mais c'est pas facile :p

Un petit exemple (bon, ça rend mieux quand c'est animé ^^):



D'ailleurs, ces objets vont servir à créer la première zone du jeu, une petite cafétéria. Quelques autres objets :



C'est la première fois que je fait ce genre d'animation, ben c'est un peu prise de tête Mais bon, une fois que j'aurai mon système bien en place, ça roulera tout seul :p

Voilà, je mettrai à jour ce sujet régulièrement, n'hésitez pas à critiquer ou à poser des questions

[nouknouk]

Salut,

tout d'abord:
- excellente idée, plutôt originale.
- tu as les pieds sur terre: tu sais estimer ta charge de travail et ne pas te lancer dans un projet pharaonique. C'est sans aucun doute ce qui fera que ton projet arrivera à terme.
- quand j'ai lu que tu ne savais pas dessiner, ça m'a fait sourire car je suis un peu dans le même cas. Et quelques screens après, je me suis rendu compte que tu étais bien modeste

Don félicitations pour le début et bon courage pour le reste

Maintenant, une ou deux remarques:

Je ne sais pas faire de 3D
Je ne sais pas faire de 3D isométrique

Concernant la 3D et la 3D isométrique, ne serait-ce pas justement une solution plus simple que la 2D ?
Je m'explique:
- il est relativement plus simple de trouver des modèles 3D en LGPL sur le net, quitte à les retravailler un poil.
- la 3D est bien plus pratique pour les animations sous forme de squelettes
- la 3D est bien plus pratique pour la personnalsation d'avatar (en gros, on redessine une texture et c'est fini).

... quitte à retourner à la 2D ensuite: faire un modèle en 2D iso à partir d'un modèle 3D est quasi immédiat: une fois la caméra de ton logiciel de rendu configurée 'aux petits oignons', c'est ton logiciel qui fait le reste.

En gros, seul le décors sera en 3D isométrique, tout le reste (Personnage, zombie, objets) sera en 2D. Ce sera un peu le même principe que le jeu Castle Crasher

J'ai vu le screen et je m'interroge: pour moi, pour que le joueur ait une plus grande liberté de mouvement, il faudrait qu'il puisse se déplacer dans les quatre directions (Nord / Sud / Est / Ouest), et pas seulement - comme le screen me le laisse penser - uniquement en Est+Ouest (avec un Nord/Sud très limité, de quoi éviter un obstacle pas plus).

Un vue du dessus (en 2D isométrique à la Dofus ... ou pas isométrique, à la zelda (old school)) permettrait 4 degrées de liberté, et donc amènerait à concevoir des niveaux moins 'linéaires', non ?

[Tigrounette]

- quand j'ai lu que tu ne savais pas dessiner, ça m'a fait sourire car je suis un peu dans le même cas. Et quelques screens après, je me suis rendu compte que tu étais bien modeste

Concernant la 3D et la 3D isométrique, ne serait-ce pas justement une solution plus simple que la 2D ?
Je m'explique:
- il est relativement plus simple de trouver des modèles 3D en LGPL sur le net, quitte à les retravailler un poil.
- la 3D est bien plus pratique pour les animations sous forme de squelettes
- la 3D est bien plus pratique pour la personnalsation d'avatar (en gros, on redessine une texture et c'est fini).

... quitte à retourner à la 2D ensuite: faire un modèle en 2D iso à partir d'un modèle 3D est quasi immédiat: une fois la caméra de ton logiciel de rendu configurée 'aux petits oignons', c'est ton logiciel qui fait le reste.

Attention, tu as du mal me lire, j'ai pas dit que je ne savais pas dessiner, mais j'ai dit que je savais dessiner avec plus ou moins de succés. En gros, j'ai quand même une certaine expérience du dessin, infiniment plus qu'en modélisation 3D. Et je sais que j'arriverai à un résultat plutôt migon en continuant comme ça, alors qu'en 3D, ça sera juste infame

De plus, comme j'ai une bonne maîtrise de flash et que flash et la 3D c'est pas trop ça... :p

Bref, si je savais faire de la 3D j'aurais pas dit, mais faire le tout en 2D me prendra 10 fois moins de temps pour un résultat 100 fois plus agréable à l'oeil

J'ai vu le screen et je m'interroge: pour moi, pour que le joueur ait une plus grande liberté de mouvement, il faudrait qu'il puisse se déplacer dans les quatre directions (Nord / Sud / Est / Ouest), et pas seulement - comme le screen me le laisse penser - uniquement en Est+Ouest (avec un Nord/Sud très limité, de quoi éviter un obstacle pas plus).

Un vue du dessus (en 2D isométrique à la Dofus ... ou pas isométrique, à la zelda (old school)) permettrait 4 degrées de liberté, et donc amènerait à concevoir des niveaux moins 'linéaires', non ?

Oui ça aurait été possible, c'est vrai. Mais en choisissant ce principe j'avais en tête une chose : "Faut pas que ça prenne trop de temps, mais faut pas que ça soit moche".

L'avantage de cette méthode, c'est de pouvoir diviser la charge de travaille par 5, en fait, quand je crée un objet ou un personnage, je n'ai besoin de le faire qu'une seule fois. Ensuite, j'applique un effet de mirroir dynamique en jeu pour avoir les deux directions. Comme sur l'image si dessous :



Alors que dans un jeu en 3D isométrique, il faut faire au moins 2 dessins/animations pour chaque objet, mais ça, c'est seulement si on veut 4 directions. 4 c'est bien pour les jeux au tour par tour avec des cases, mais pour un jeu en temps réel il en faut bien plus pour avoir quelque chose de correct. Starcraft en compte 9 pour chaque unité par exemple, avec l'effet de mirroir ça donne 18 direction. Mais comme tu l'as dit, pour ce genre de chose les graphistes on tendance à d'abord créer un modèle en 3D puis à le prendre en photo sous toutes les coutures, mais je sais pas faire donc...

Pour la vue du genre Zelda, ça aurait pu être un bon compromis, mais ça m'oblige tout de même à faire 3 dessins pour chaque objets et refaire les animations en 3 exemplaires à chaque fois.

C'est vrai que la vue que j'ai choisie peut paraître un peu limité, mais ça ne va pas donner la même chose que le screen de Castle Crasher que j'ai montré. En effet, rien ne m'empêche de donner plus d'espace à l'axe Nord-Sud, avec un effet de scrolling.

Enfin, je suis globalement d'accord, ça risque de limiter un peu le gameplay, mais bon, avec des compétences limités il faut savoir faire des sacrifices. Si j'avais pu le faire en DX10, je l'aurais fait

[nouknouk]

Merci pour ces précisions.

Effectivement, je n'avais pas pensé à l'aspect "moins de graphismes à dessiner" lorsqu'on opte pour ta solution en 2D "vue de côté".

Bon courage pour la suite

[Mat.M]

Eh bien c'est du beau travail Tigrounette j'apprécie l'aspect graphique des personnages.
Oui je pense que Flash est une bonne solution ; ne t'embarque pas encore dans la 3d temps réelle ,encore une fois je conseille de faire un bon jeu 2d bien abouti.
Parce qu'en 3d il faut gérer toutes les transformations

Bref, si je savais faire de la 3D j'aurais pas dit, mais faire le tout en 2D me prendra 10 fois moins de temps pour un résultat 100 fois plus agréable à l'oeil



Oui ça aurait été possible, c'est vrai. Mais en choisissant ce principe j'avais en tête une chose : "Faut pas que ça prenne trop de temps, mais faut pas que ça soit moche".

L'avantage de cette méthode, c'est de pouvoir diviser la charge de travaille par 5, en fait, quand je crée un objet ou un personnage, je n'ai besoin de le faire qu'une seule fois. Ensuite, j'applique un effet de mirroir dynamique en jeu pour avoir les deux directions. Comme sur l'image si dessous :

Tu as parfaitement raison ; en 3d temps réel les graphismes risquent d'être moches parce que tu seras limité(e) par le nombre de polygones et le Level Of Detail .
Faut penser aux petites machines qui ne sont pas forcément puissantes.
Et puis dessiner en 2d c'est relativement rapide il suffit d'utiliser des astuces comme tu dis le mirroir.

C'est une belle initiative en tout cas que je salue

[Tigrounette]

Hop là, la suite :p

J'ai pas mal travaillé sur l'optimisation du jeu, le but étant d'afficher le plus de zombie possible. Bon, c'est du flash, donc c'est difficile d'avoir quelque chose de fluide avec beaucoup de mouvement. Pour le moment, la limite se situe environ vers 20 joueurs affichés et 40 zombies sur le même écran. C'est honorable, le problème c'est qu'avec l'ajout de fonctionnalité au fur et à mesure, cette limite risque de descendre un peu. On verra :p

J'ai réalisé aussi les animations d'attaques des différents objets. Vu que ces attaques sont différentes en fonction du type d'objet, ça a pas été facile ^^

Quelques screens (même si pour montrer des animations c'est pas top :p) :

Pour les objets pointus (Couteau, fourchette, tourne vis...)



Pour les petits objets tranchants ou contondants (Bouteille, marteau, couteau...)



Pour les grands objets tranchants ou contondants (Chaise, Barre de bois, barre de fer, épée...)



Pour les gros objets ou les grosses piques (Banc, table, lance...)



Pour les objets massifs (Les gros blocs comme les poubelles, les pots de fleurs...) qui n'ont pas de prise on ne pourra pas attaquer avec, mais seulement les lancer. Mais bon, ces objets seront en fin de compte assez peu nombreux.

J'ai aussi réalisé une première zone, c'est un petit restaurant un peu moche, qui me servira principalement pour toute la mise en place du système de collision, de l'utilisation des objets et tu tapage de zombies :p (La zone vide sur la droite, c'est pour taper les futurs zombies)

[BrItneY]

J'ai lu ton début de journal avec intérêt, ton projet est fort intéressant, et tu as l'air motivé... j'y jouerais pour sûr quand il sera prêt

Je trouve cette idée de squelette très intéressante !
Débutant dans la création de jeux sous flash, je me pose une petite question : Comment fais tu tes animations ?! Directement avec flash ?! Tu fais l'animation du squelette puis attaches une texture dessus, c'est bien cela ?!

Bon courage pour ton projet !

BrItneY

PS : je trouve ton décord plutôt convainquant, et joli !

[Tigrounette]

Débutant dans la création de jeux sous flash, je me pose une petite question : Comment fais tu tes animations ?! Directement avec flash ?! Tu fais l'animation du squelette puis attaches une texture dessus, c'est bien cela ?!

Oui, c'est exactement ça. J'anime mon petit personnage baton en timeline et ensuite, une fois en jeu, je remplace dynamique les batons par des textures (des MovieClip en fait). De cette facon, les textures suivent les déformations de l'animation (translation, rotation, etc).

____________________


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 voit 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 :p

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 :p

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 zombies

[bafman]

juste une question : pourquoi tu n'utilise pas un bête algorithme du peintre pour dessiner, ça simplifierai grandement tes problèmes d'ordre d'affichage...

[Mat.M]

Tigrounette pour ce que tu veux faire le plus simple et plus basique c'est de gérer des "calques" ou layers affichés selon un ordre d'importance

juste une question : pourquoi tu n'utilise pas un bête algorithme du peintre pour dessiner, ça simplifierai grandement tes problèmes d'ordre d'affichage...

Euhh c'est quoi l'algorithme du peintre ? Des précisions seraient bienvenues

[nouknouk]

Euhh c'est quoi l'algorithme du peintre ? Des précisions seraient bienvenues

Google est ton ami sur ce coup là.

[Frifron]

l'algorithme du peintre c'est juste afficher les objet du plus lointain au plus pret (tant qu'il n'y a pas d'objet en biais ca fonctionne tres bien) et c'est déjà ce qu'il fait d'apres ce que j'ai compris en retriant uniquement les objets lorsque le joueur se déplace dans un nouveau carré. Lorsqu'il y aura plein d'objets mobiles dans la zone, cette opti n'aura plus énormément de sens (un tri par passe d'affichage c'est pas la mort (surtout en partant d'un tableau trié a la frame précédente) et le quadrillage n'est pas forcément utile)

Sinon très sympa comme petit projet. Et le journal de bord est une bonne idée !

[Tigrounette]

l'algorithme du peintre c'est juste afficher les objet du plus lointain au plus pret (tant qu'il n'y a pas d'objet en biais ca fonctionne tres bien) et c'est déjà ce qu'il fait d'apres ce que j'ai compris en retriant uniquement les objets lorsque le joueur se déplace dans un nouveau carré. Lorsqu'il y aura plein d'objets mobiles dans la zone, cette opti n'aura plus énormément de sens (un tri par passe d'affichage c'est pas la mort (surtout en partant d'un tableau trié a la frame précédente) et le quadrillage n'est pas forcément utile)

Sinon très sympa comme petit projet. Et le journal de bord est une bonne idée !

Oui c'est ça

Flash fonctionne avec une liste d'affichage qui affiche les objets les plus bas de la liste en premier, ils se retrouvent donc dernière.

L'intérêt de ce quadrillage, c'est de mettre à jour cette liste uniquement quand le joueur se déplace de 20 pixels vers le haut ou vers le bas. Plutôt que de le faire à chaque pixels de déplacement.

De plus, la liste d'affichage n'est pas entièrement mise à jours, je déplace juste le joueur en mouvement dans sa nouvelle position en testant le niveau de profondeur de 2 ou 3 objets par mise à jours au lieu de tester l'intégralité des objets et joueurs présents.

Je fait ces optimisations car je risque d'être un peu juste au niveau des ressources, donc je grapille la ou je peux

[Mat.M]

Flash fonctionne avec une liste d'affichage qui affiche les objets les plus bas de la liste en premier, ils se retrouvent donc dernière.

Il faut effectuer un tri alors.
Trier les entités selon leur position y ( c.a.d. en profondeur ) ceux dont la position y est la plus petite s'affiche en premier etc..
c'est comme cela que je procéde pour mon jeu et c'est satisfaisant.
Est-ce que c'est possible avec Flash ?
Sinon il faudrait éventuellement changer de techno car avec Flash on peut être limité

[Frifron]

oui et bien retrier le tableau trié a la frame précédente et pas recommencer a chaque fois. Un tri sur des éléments déjà plus ou moins trié sera beaucoup plus rapide.

Dans ton cas, pas besoin de se galérer avec un quadrillage, un tri en y a chaque frame sera rapide, précis et facilement implémentable.

[griffon0206]

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

[Frifron]

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

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