57 réponses à ce sujet

[Monsieur Spi]

Salut la compagnie,

Je me suis enfin décidé à me monter des outils pour gagner du temps.

Je suis parti de çà : http://spi4.free.fr/....php?article191

Les éditeurs de cartes c’est pas ce qui manque sur Internet, mais je n’ai pas réussi à en trouver un qui me convient, alors je me suis fait le mien. Et je me suis demandé comment pousser le principe pour paramétrer un maximum de choses à l’aide d’une interface simple. Comme j’étais parti sur un jeu de rôle, j’ai tout orienté dans ce sens.


Editeur de maps


Feuilles de compétences


C’est loin d’être parfait, je suis intimement convaincu que c’eût été plus rapide, plus propre, plus adaptable, plus… en AS3 avec des classes, au lieu de l’AS2 procédural que j’ai utilisé, mais j’ai voulu monter un bidule pour mon usage personnel, et tant que çà répond à mes besoins…

En réalité j’aurais pu laisser mon programme brut, sans habillage et avec deux fois moins d’options, çà aurait allégé les calculs. Mais j’ai voulu essayer de créer rapidement une interface à destination de ceux qui auraient besoin de ce genre de choses.

Il y a encore à faire; gérer le chargement des tiles dans le format qu’on veut, améliorer la sauvegarde, éradiquer les devs sauvages et les petites rustines collées par-ci par-là pour « cacher la misère », comme on dit. Le programme est fait pour fonctionner en local uniquement, çà pose pas mal de problèmes, mais c’est un outil et si vous devez dépendre des caprices d’un serveur ou de votre connexion pour construire vos jeux, il va perdre beaucoup de son aspect pratique.

Je souhaite l’adapter pour d’autres types de jeu.et me faire un éventail d’outils complet.
Cà tombe bien j’ai commencé par du jeu de rôle, c’est celui qui demande le plus de paramètres.

Vous me voyez venir ?
Je ne suis pas développeur et je n’ai pas (encore) la vocation de créer des logiciels
Si certains d’entre vous se sentent de se pencher sur les problèmes évoqués çà pourrait aider et si vous souhaitez vraiment pousser un peu plus la chose pourquoi pas, je suis prêt à m’investir encore un peu dessus si besoin, mais pas trop. Là le soft répond à mes besoin, j'ai fait un effort pour l'interface mais je vais pas continuer à peaufiner tout seul si çà ne m'est pas utile.

N’hésitez pas à le tester et à me signaler les bugs, les incohérences, ce qui vous plait ou pas, etc …

Utilisez le pour vos jeux si vous sentez que çà peut vous aider, mais attention, créez vos propres planches de tiles. Ceux fournis en exemple ne sont pas tous libres de droits.

A propos des planches de tiles justement, si quelques graphistes avaient envie de se fendre de quelques petites planches, qu’ils ne se gênent pas, çà compléterait pas mal la chose

Pensez à lire la notice fournie avec, c’est important.
J’ai également besoin de savoir si cette notice est compréhensible et claire.

Sinon, il y a un grand absent au moment où je poste ces quelques lignes, le moteur.
C’est un complément logique à l’éditeur même si il reste simpliste.

• Charger et recomposer les tableaux
  
• Importer les tiles
  
• Créer la map
  
• Gérer les changements de cartes
  
• Poser les objets et les acteurs sur le plateau de jeu
  
• Leurs affecter leurs feuilles de compétences
  
• Gérer les déplacements simples et les collisions
  
• Gérer le choix d’un gameplay avec scrolling (ou pas) automatiquement

…

Autant de choses qu’il est possible de paramétrer dans l’éditeur et dont on peut simplifier le traitement dans le moteur du jeu en proposant une petite librairie.

Je m’y colle en AS2 puisque ma prochaine étape est de replonger sur mon jeu, mais cette fois à l’aide de l’éditeur. Parallèlement au développement du moteur de ce jeu, je ferai une version avec classes (çà sera l’occasion de m’y coller) qui servira de librairie de base, çà devrait pas être trop dur à faire évoluer petit à petit.

Par ailleurs rien ne vous empêche de créer vos propres librairies (AS2 ou AS3 peu importe) et de venir les partager.
L’éditeur suffit comme base et en repartant des tableaux de sauvegarde et de la biblio de tiles associée vous pouvez construire vos moteurs dans le format qui vous plait, vous n'êtes pas dépendant du code que j'ai adopté pour monter l'éditeur.

Bref, amusez-vous si le cœur vous en dit, je posterai des mises à jours dès que j’apporterai des modifications au projet

Ha j’oubliais, programme libre, distribution libre, ne pas utiliser les tiles fournis comme base pour un jeu commercial, laisser le copyright si vous distribuez, merci


Instructions :

Téléchargez le fichier joint.
Dézippez-le dans un répertoire de votre choix.

Vous y trouverez :

Toutes les instructions pour l'utilisation de l'interface dans le fichier "notice.pdf"
Le FLA et le SWF de le biblio partagée (voir notice)
Le SWF de l'éditeur
Un fichier "test.txt" qui n'est autre qu'une première carte de test que j'ai monté pour tester le chargement des maps, vous pouvez le charger depuis l'éditeur. Pour info vous pouvez rassembler vos maps à l'intérieur d'un sous dossier, il suffit de donner le chemin lorsqu'il sera demandé pour aller chercher la bonne carte dans le bon dossier.

Have fun.


EDIT : Pour un souci d'utilisation pour ceux qui ne disposent pas de Flash CS3 je rajoute la biblio en version Flash 8, je n'y avais pas pensé au départ désolé.

Miniature(s) jointe(s)

• 
• 

Fichier(s) joint(s)

•  Tiles_Studio_Editor_par_Monsieur_Spi.rar   4.3 Mo   111 téléchargement(s)
•  biblio.fla   2.34 Mo   108 téléchargement(s)

[Monsieur Spi]

Bonjour,

Premier problème détecté à propos du chargement du fichier TXT.
A première vue un problème de codage UTF pour les accents, je vais voir comment corriger çà rapidement.

[Tekkila]

Salut Mr Spi,

Ca a l'air très intéressant tout ça ...

Je jette un coup d'oeil ce soir et je te remonte les bugs si j'en trouve.

A+

Joni

[Monsieur Spi]

Hello Joni,

Merci pour le test n'hésites pas si tu vois des trucs qui vont pas ou des trucs a modifier (attention voir notice pour les devs en cours ou les devs déjà réfléchis).

Je cherches surtout des solutions pour la sauvegarde des maps (éviter le fichier TXT mais laisser de la souplesse pour l'utilisation hors contexte) et la gestion des biblios de tiles, je sais ce qu'il faudrait faire mais j'ai soit la flemme de chercher plus avant soit pas le temps de vraiment m'y pencher, si tu as des solutions je suis preneur.

Sinon autre bug détecté, le zoom ne réagit pas super bien, d'une part il ne se cale pas directement sur le bon tile lorsqu'on inverse le mouvement du zoom, d'autre part il faut que je rajoute des limites car là quand on cherches à trop zoomer çà fini par faire ramer grave le soft, voire le planter. C'est normal j'ai trop de calques et de grilles affichées pour les capacités de ma machine (çà passera sans doute mieux sur des machines récentes, je travailles avec une vieille bouse). Je vais voir ce que je peux faire pour améliorer tout çà rapidement.


Ha sinon, je l'ai indiqué dans les remerciements dans le soft mais pas sur le forum, merci à Jano qui m'a ôté une ou deux épines du pieds en ce qui concerne l'écriture dans les grilles. Je vais également implémenter son astuce pour faire de la sauvegarde auto dans un sharedObject (précisions à ce propos données par Frangois sur une question que j'avais deja posé à propos des sauvegardes des parties en cours, merci également à lui je vais me servir de ce qu'il m'avait indiqué), ce qui permettra de sécuriser la construction des maps au cas ou le soft plante. Je réfléchis aussi à une option genre CTRL+Z pour revenir un pas en arrière, après avoir testé le soft je me dit que çà serait parfois bien pratique. Mais pour ce dernier point je sais pas trop comment partir, enregistrer uniquement la dernière action menée (pose problème dans l'écriture de multiples tiles dans les grilles) ou faire une sauvegarde auto de la map dans son état avant modif dans un sharedObject qu'on rappelle au moment du CTRL+Z (risque d'alourdir le process si à chaque nouvelle action il faut sauver toute la map) .... je réfléchis.

[ghost]

Salut spi

Super beau boulot, l'interface est chouette et tout

deux suggestions:

-remplacer la lib de tiles par un dossier d'images pour que ça soit compatible avec ceux qui travaillent sur flex builder ou flashdevelop

-simplifier l'application pour la rendre générique, laisser l'utilisateur faire autant de calques qu'il veut et leur donner le nom qu'il veut (et la taille qu'il veut, s'il veut faire un scroll multi différentiel par exemple)

[ghost]

A propos de la sauvegarde des maps perso je trouve le système très bien comme ça, ça renvoie un truc facile à exploiter en as et les mecs s'ils le souhaitent peuvent recompresser ça dans un format adapté à leur moteur ou l'utiliser brut.

[Tekkila]

Salut MrSpi,

J'ai donc testé ton appli rapidement hier soir (j'ai pas eu bcp de temps) et mes premières impressions sont vraiment bonnes.
Je trouve l'interface simple à utiliser et vraiment sympa.

J'ai pas vu de bugs ... pas dans ce que j'ai essayé en tout cas.

Et comme Verpan, je trouve le système de sauvegarde très bien comme cela.

Je t'en dirait plus quand j'aurais eu le temps de tester ça plus en profondeur.

A+

Joni

[Monsieur Spi]

Hello,

Verpan > Merci du test et des retours

Pour le chargement des tiles c'est aussi ce que j'avais en tête, j'imaginais même directement le chargement en format planches de PNG (le format classique). Je vais essayer de me pencher dessus pour voir la faisabilité avec la construction que j'ai adopté mais effectivement çà semble la bonne solution.
Par contre çà pose quand même une contrainte de taille, avec le système actuel tu peux gérer une animation, qu'elle soit vectorielle ou pas, directement dans le tile chargé en biblio, c'est une liberté supplémentaire pour pré-animer ses sprites. En passant par un chargement par image et non une lib partagée tu perds cette possiblité ce qui est domage. Il faudrait donc pouvoir proposer les deux systèmes en fonction des choix techniques de l'utilisateur, c'est là que çà se complique un peu mais çà devrait le faire en réfléchissant deux minutes.

Pour l'ajout de calque à la volée c'est une bonne idée aussi, mais par contre çà va demander de revoir pas mal de choses, comme j'ai monté le truc au jour le jour sans vraiment analyser avant j'ai une construction assez rigide, pour bien faire faudrait tout repasser en classes et en dynamique. J'avoue que là par contre çà risque de me prendre trop de temps.

Par contre pour avoir commencé la première carte de mon jeu avec l'éditeur hier soir je ne peux que te confirmer que çà serait utile de pouvoir rajouter des calques à la volée, tout simplement parce que dans certains cas il peut manquer un calque qui avait pas été pensé au départ. Par exemple hier je suis tombé sur un problème, j'avais besoin d'une couche de décor supplémentaire qui ne soit ni un objet ni réellement un sol ou un mur. J'ai réussi à me débrouiller avec les calques dispo mais j'ai du jongler un peu et faire de ce décor un objet non actif.

En ce qui concerne la sauvegarde, toujours avec mon test de hier je m'aperçoit que çà serait quand même utile d'avoir une sauvegarde simplifiée. La raison est simple, quand on bosse sur une carte on a pas forcément créé tous les tiles avant de dessiner la map, dès qu'on a une modif à faire sur un ou deux tiles il faut sauver avec un copier/coller, fermer l'éditeur et le rouvrir pour recharger la map en cours, c'est un peu chiant à force. Mais je pense que passer par un sharedObject comme me l'avait préconisé Jano serait bien utile pour faire une sauvegarde auto de la map en cours au moment où on ferme l'éditeur, il le recharge tout seul quand on va le rouvrir.

Joni > Merci aussi pour le test et les appréciations

Mêmes réponses que pour Verpan


Petite question à tous ceux qui testent, pouvez-vous me dire si sur votre machine çà reste fluide ou si çà se met à ramer par moment et si oui à quels moments ?

Par exemple chez moi dès que j'affiche tous les calques et tous les numéros de références j'ai beaucoup de mal à déplacer la carte ou à écrire dedans, çà rame pas mal. Je pense pas pouvoir trop optimiser à ce niveau mais çà me serait utile de savoir à quel moment çà devient génant pour coller des limitations automatiques.

Enfin petit astuce que j'ai du utiliser hier, lorsqu'on veut travailler avec de grandes maps (plus de 40*40) il se peut qu'à la création du terrain le player vous affiche un joli "un script de cette animation semble ralentir le tout...blablabla" le classique quand on a une boucle infinie ou un truc trop lourd à générer. L'astuce c'est de répondre "non" lorsqu'il demande si on veut arrêter l'exécution des scripts pour cette anim. L'éditeur ne plantera pas et il construira correctement la carte, çà semble juste affoler un peu le player mais çà passe. Je n'ai pas essayé plus haut que 54*54, si çà vous tente ne vous gênez pas


EDIT : Nouveau petit bug détecté, à propos du bouton pour afficher/masquer les numéros des tiles dans les planches, il faut cliquer deux fois dessus pour qu'il fasse ce qu'on lui demande. De plus quand on passe d'une page à une autre les numéros reviennent même si ils ont été masqués à la première page. Je vais corriger çà rapidement car çà gène la lisibilité des tiles qui sont assez petits.

Je rassemble les différents bugs au fur et à mesure et je ferais une grosse mise à jour ce weekend.

[Monsieur Spi]

Hello Frangois,

Citation

Tu devrais passer en AIR. T'auras la classe File et toutes tes problèmes de sauvegarde/sauvegarde automatique/chargement sont résolus.

J'y ai bien pensé mais je connais pas du tout AIR, le temps que je m'y colle j'ai peur de plus avoir de temps pour faire mon jeu, mais tu as raison çà serait carrément la solution.

Citation

Pas normal qu'on puisse pas dépasser 54x54, c'est vraiment trop limité. Je downloade pas l'archive avant que tu annonces le 256x256

lol

(J'avais un doute sur la capacité de Flash à générer du 256*256 ne serait-ce que pour une grille alors j'ai quand même testé... )

Par contre c'est vrai que pousser un peu la taille çà serait pas du luxe, çà reste petit des maps de 32*32 de moyenne. Faudrait faire un scrolling pour bien faire et n'afficher que 20*20 mais on verrais de toute façon jamais la map en entier.

EDIT : je pense qu'on peut arriver à se débrouiller en créant des petites maps reliées entre elles par les "sorties" proposées dans le paramétrage du moteur. Suffit de recoller les maps à la volé dans le jeu...

[ghost]

fais surtout pas de planche png tu vas tout bloquer

il faut que les mecs dans leur moteur puissent mettre ce qu'ils veulent à la place d'une tuile, s'ils veulent animer les tiles par exemple, faire des tuiles destructubles, faire les persos et objets avec un bête calque tuiles, etc

c'est parfois difficile de faire simple, il faut se forcer à pas aller trop loin dans le développement

[Monsieur Spi]

Citation

il faut que les mecs dans leur moteur puissent mettre ce qu'ils veulent à la place d'une tuile, s'ils veulent animer les tiles par exemple, faire des tuiles destructubles, faire les persos et objets avec un bête calque tuiles, etc

Ben en fait c'est déjà le cas si on regarde bien, rien n'empêche de mettre ce qu'on veut à la place des tiles dans la biblio histoire d'avoir un repère visuel, on ne sauve que les références des grilles, ensuite dans le moteur tu exploite ce que tu veux graphiquement parlant du moment que tu as les tableaux.

Çà serait donc plutôt du côté du moteur qu'il faudra prendre çà en compte.

Par exemple j'ai rien prévu pour les portes (les portes des pièces). Plutôt que de modifier l'éditeur pour rajouter un calque la différencier je vais la mettre dans le calque dédié aux objets. Dans me moteur je regarde son ID, si c'est une porte (à chacun de fixer la ou les refs dans le moteur) reste plus qu'a lui dire quoi faire.

Je pense qu'une bonne partie peut être prise en charge par le moteur et que l'éditeur doit rester simple même si cela impose parfois certaines contorsions, au final on a juste besoin des tableaux de référence. Permettre d'ajouter des calques à la volée est une bonne idée car on peut toujours avoir besoin d'une grille de plus, mais après je pense qu'il faut s'appuyer sur le moteur.

Par contre dans l'éditeur il faudrait permettre de charger les planches de tiles dans les formats courants et donner le choix, et même un choix multiple avec par exemple les ennemis animé en biblio partagée, les décors fixes sur une planche PNG ou en séries d'images, ect... Je ne vois que la biblio partagée, les planches PNG et les séries d'images dans des dossiers. Cà demande pas de tout refaire et çà devrait pouvoir se faire rapidement.

Reste le problème du chargement à la volée qui n'est pas possible avec la biblio partagée, et le fait de ne pas disposer d'un explorateur simple pour aller chercher les images à importer ou sauver la map.


EDIT : A propos de l'explorateur justement, question à 100 balles mais FileReference çà ferait pas l'affaire ?

[Monsieur Spi]

Hello,

Voici les tous premiers pas du moteur, et un bout de map créé avec l'éditeur.

http://spi4.free.fr/tests

SHIFT pour courrir
Fléches pour se déplacer



EDIT : je viens d'ajouter la recomposition auto des grandes maps.

Pour faire une grande map de 80*80 je crée autant de petites maps de 20*20 qu'il faut.
La fonction les recompose en une seule grande.

J'ai testé avec 3 bouts de la map pour le moment.



EDIT 2 : suspension du compte Free pour 72 heures....

[Monsieur Spi]

Réouverture de mon compte Free, youpi.

Demain matin je poste les avancées du moteur.

[Monsieur Spi]

Hello,

Je parles un peu tout seul mais c'est pas grave, j'ai une question

Je viens de commencer à réfléchir pour afficher un plan de la carte à l'intérieur du jeu.
Pour bien faire le plan doit être masqué et ne découvrir que les cases visitées.

Problème, la carte fait 80*80 (colonnes*lignes).

J'ai commencé par essayer de créer un plan à l'identique de la map (génération de tous les tiles de la map à taille réduite), Flash a planté (normal).

Puis je suis parti sur l'idée de faire un plan complet JPEG que j'aurais recouvert d'une grille simple (un simple clip noir de 3*3 px), Flash arrive plus ou moins à me créer la grille mais rame de folie à la génération.

Je pense donc atteindre les limites pour la méthode que j'emploie à savoir :

function creePlan() {

        this.attachMovie("vide","plan",10);

        for (var y = 0; y<=80; ++y) {
                for (var x = 0; x<=80; ++x) {
                        var nom = "t_"+y+"_"+x;
                        plan.attachMovie("tile",nom,1+y*1000+x*2, {_x:x*3,_y:y*3});
                }
        }
}

creePlan();

Avant de m'engager sur les solutions comme copyPixels ou autre j'aurais voulu savoir si par expérience certains d'entre vous ont eu à générer des grilles comprenant de nombreuses lignes et colonnes et auraient des solutions simples pour contourner le problème (AS2).

Comme solution alternative j'ai imaginé de passer par de la copie de pixels, c'est à dire changer la couleur de mon JPEG en noir au départ puis aller lui redonner les couleurs d'origine pour la case découverte au moment voulu, ce qui éviterai la création d'une grille lourde mais je suis pas sur du résultat.

Autre solution possible, créer une forme vectorielle de la taille du plan, et aller supprimer dans cette forme des zones (carrées) correspondant aux pièces découvertes.

Merci.




EDIT : je viens de mettre à jour la page de démo du moteur (pensez à vider le cache si vous avez déjà été voir la page ce matin), la map est entièrement générée (80*80), j'ai quelques soucis avec l'affichage des objets qui apparaissent mal dans certaines conditions (sera vite réparé).

J'ai rajouté une option de saut (touche CONTROL) sommaire pour le moment.

[Monsieur Spi]

Yop,

Y a t'il un graphiste/animateur utilisant POSER et/ou 3DS dans la salle ?

Je travailles sur un jeu "Top Down View", je construit moi même mes sprites et mes anims avec POSER, j'ai beaucoup de mal à créer des modèles de base à animer et çà me prend un temps fou pour arriver à un résultat correct.

Donc, histoire de varier un peu je cherche une personne que çà amuserait de faire quelques monstres vus du dessus avec quelques mouvements simples (marcher, tirer ou taper, mourir).

J'ai pas besoin de grand chose, 1 ou 2 monstres c'est tout.
J'ai déjà des squelettes, des animaux, des humains variés, quelques petites bêtes ou robots faciles à faire, et toute une panoplie de pièges variés (flèches, pierres, tourelles, trous ...).

Au passage je viens de mettre à jour le test du moteur en cours de dev : http://spi4.free.fr/tests/

- courir = SHIFT
- sauter = CONTROL
- tirer = ESPACE pour mettre en joue, flèches droite et gauche pour orienter et haut ou bas pour tirer.
- essoufflement = si vous courrez trop longtemps vous perdez du souffle jusqu'à épuisement (servira aussi pour la nage et la noyade)
- récupération = si on continue à marcher on récupère moins vite son souffle que si on s'arrête complétement

Pour me permettre de faire mes tests il y a également un "trou" dans le mur juste sous la porte du bas quand vous démarrez le jeu. C'est simplement pour permettre de passer rapidement à la map du dessous sans avoir a faire le grand tour.

Il me reste deux maps à créer pour finir le plan rapide au sol du donjon.

[Monsieur Spi]

Hello,

Je continues mon monologue avec une petite question toute simple.

Est-ce que Flash (AS2) est plus rapide à déplacer un clip qu'à le créer ?

Pour le moment dans le moteur j'utilise un attachmovie pour aller poser mes objets sur ma scène quand j'en ai besoin. Et d'un autre côté j'utilise le système de Tonypa comme base de travail pour le scrolling du décor.
Le décor ne pose pas de problème car le moteur replace juste les clips déjà créés au bon endroit et y affiche la bonne image.Mais il se peut que parfois certains objets n'apparaissent pas en temps voulu.

Les deux systèmes étant différents j'aimerai savoir si le problème est lié à la création d'un nouveau clip (lenteur), si c'est le cas j'ai une autre solution à mettre en place mais avant de me lancer j'aimerai une confirmation.

Merci.

[Monsieur Spi]

Salut,

Petite mise à jour du moteur.

- Ajout de trois types de liquides : eau claire, eau polluée, lave
- Le perso nage lorsqu'il est dans un liquide (hors lave)
- Modification du décor, le jeu se passera dans une base futuriste
- Les arbres sont destructibles (lorsque l'on en détruit un on peu passer sous ce qu'il reste de branches)

A force d'utilisation de l'éditeur j'ai vu ce qui clochait je vais donc le réécrire sous peu en essayant d'optimiser certaines parties un peu chiantes lorsqu'on doit revenir souvent sur une map pour faire des corrections.

Au niveau du moteur, je vais d'abord créer tout mon jeu, puis ensuite j'en extrairait les fondamentaux pour le moteur que je mettrais à dispo. Comme j'avance sans analyse et sans plan directeur je ne sais pas encore tout ce qui va être utile pour créer des fonctions génériques (utiles pour la base de création des jeux de ce type). Je préfères donc commencer par monter mon jeu et l'optimiser puis ensuite réfléchir à un moteur générique (toute aide est la bienvenue bien sur).

vous pouvez tester le rendu toujours au même endroit : http://spi4.free.fr/tests

[remidebra]

Alors j'ai repéré quelques trucs qui n'allaient pas:

-Le perso ne nage pas dans la lave.
-Lorsqu'il nage il y a trop de sillons dans l'eau et ils sont posés au-dessus du personnage, ce qui fait bizzare.
-Et tu devrait "timer" ta cadence de tir au lieu de permettre au joueur de retirer quand son tir précédent est entré en collision avec le décor. Parceque par exemple met toi face à un mur et laisse appuyer sur tirer...Le tir s'actionne constamment.

[Monsieur Spi]

Hello,

Merci pour les remarques cependant ce jeu est en cours de dev donc certaines choses sont juste "posées" pour avoir un plan et seront affinées par la suite.

Par exemple le tir à été corrigé hier, il permet à présent de tirer de manière cohérente et également de faire varier (bonus) la rapidité du tir et son facteur de surchauffe. (pas encore mis en ligne)

Le perso ne nagera pas dans la lave, ce n'est pas Superman , si il plonge dans la lave il meurt... et comme je me suis pas encore occupé du tout de la vie et de la mort du perso c'est quelque chose qui arrivera après.

Pour la nage je vais voir, je ne suis pas encore totalement satisfait du résultat.

Merci de ces retours, cependant il faut prendre en compte que beaucoup de choses ne sont pas encore "propres", pour le moment j'en suis a poser le décor et à créer les animations du personnages sur un soft 3D ce qui me prend beaucoup de temps, je ne mets en place que des bases (par exemple le tir ou la nage) pour vérifier que l'animation fonctionne, j'affinerai après.

Ce qui est important pour le moment ce sont les fonctions principales comme le scrolling, la recomposition des tableaux, l'affichage des tiles, la différenciation des sols etc... tout ce qui sera utile au moteur que je souhaite fournir avec l'éditeur. Le reste (animations des persos, gestion du tir etc...) dépendent du jeu qu'on souhaite mettre en place, çà sera donc à chacun de créer ses fonctions pour que çà fonctionne avec ses propres sprites et sa propre technique. Mon but est juste de fournir une librairie de base permettant d'automatiser certaines choses créées avec l'éditeur, comme recomposer les tableaux à partir de fichiers externes formatés par l'éditeur, ou automatiser la recomposition de petites cartes en une grande

Ce qui peut être considéré comme un bug par contre c'est le fait que parfois certains objet n'apparaissent pas, problème de rapidité d'exécution à première vue que je vais devoir compenser par la suite en changeant de méthode.



EDIT : Tiens je viens d'y penser alors j'ai mis a jour la version online du test du jeu, maintenant le tir est "normal".

[papwal]

Pour scroller tes tuiles tu galèreras moins en utilisant les bitmapData et tu auras un résultat plus rapide car flash n'aime pas afficher beaucoup de clips.

la routine est très simple c'est quelque chose comme ça:
( screenRect est le rectangle de scrolling relatif au world , l'interdiction de sortir des limites a été préalablement résolue , il faut que toutes les tuiles aient la même taille à l'affichage )

(le code n'est pas testé donc vérifie avant)

// routine à répéter pour chaque calque

leftCol = int( screenRect.left / tileSize );
topRow = int( screenRect.top / tileSize );
xOffset = currentLayerRect_x % tileSize
yOffset = currentLayerRect_y % tileSize
point = new Point(0,0);
coins=[new Point(0,0),new Point(1,0),new Point(0,1),new Point(1,1)]
tileRect = new Rectangle(0,0,tileSize,tileSize);

for ( row=topRow ; row<topRow+numRow ; row++ ) {
 point.y = (row-topRow)*tileSize + yOffset;
 for ( col=leftCol ; col<leftCol+numCol ; col++ ) {
   point.x = (col-leftCol)*tileSize + xOffset;

   // on regarde si la tuile n'est pas masquée par les calques supérieurs
 
   masked=false;

   for ( iLayer=iCurrentLayer ; iLayer < numLayers && masked==false ; iLayer++ ) { // on stop le test lorsque la tuile est masquée
     layerGrid = layers[ iLayer ];
     layerRect = layerScrollRects[ iLayer ]; // les scroll rect des autres calques
     relLeftCol = int((point.y+currentLayerRect_y-layerRect.x)/tileSize);
     relTopRow = int((point.x+currentLayerRect_x-layerRect.y)/tileSize);
     p_masked=true;
     for ( sideBitMask = 0 ; sideBitMask < 4 && p_masked ; sideBitmask ++ ) {
       p_masked=(layerGrid[ relTopRow+((sideBitMask>>1)&1) ][ relLeftCol+(sideBitMask&1) ] == 0);
     }
     masked = p_masked;
   }

   if ( ! masked )  { screen.copyPixels( tiles[  currentLayerGrid[row][col]  ] , tileRect , point ); }
 }
}
 

après tu peux accélérer les calculs avec des operations bitwise pour virer les multiplications et les divisions
par exemple si ta tuile a pour taille 16, au lieu de faire int(x/16) et x*16, tu fais (x>>4) ou (x<<4)

et accélérer les lectures en tableau en rangeant tout dans un seul tableau et en plus deux petits tableaux qui stockent le premier index et la largeur pour chaque calque, et tu consultes la cellule en un seul coup comme ceci:
cell = map[ layerFirstCell + layerNumColon * row + col ];

si chaque calque fait la taille double du calque qui est derrière tu n'as même pas besoin de stocker le premier index et la largeur de chaque calque, tu peux les déduire



s'il y'a des points que tu ne comprends pas tu peux demander des explications

[Monsieur Spi]

Hello,

Merci des conseils déjà

Ensuite :

Citation

Pour scroller tes tuiles tu galèreras moins en utilisant les bitmapData et tu auras un résultat plus rapide car flash n'aime pas afficher beaucoup de clips.

Tu parles du moteur ou de l'éditeur ?
L'éditeur ne scrolle pas, il affiche les maps plein pot.
Le moteur en revanche scrolle, çà marche parfaitement avec le système de rondins de Tonypa (n'affiche qu'un nombre de clips limités, lorsqu'ils sortent d'un côté on les replace de l'autre côté et on change leur contenu -frame-), ce qui me pose problème c'est le clipping des objets sur la grille, et là je pense que je vais devoir réfléchir autrement pour que çà marche à coup sur.

bitmapData est à mon avis la bonne méthode, je vais sans doute m'y pencher plus sérieusement, merci pour ton exemple je vais étudier çà. Par contre avec du copyPixel et bitmapData je me demande si il y a vraiment besoin de tuiles. Il suffirait de retracer la zone utile depuis une map complète (a tester), on garde les tableaux pour les interactions.

Citation

après tu peux accélérer les calculs avec des operations bitwise pour virer les multiplications et les divisions
par exemple si ta tuile a pour taille 16, au lieu de faire int(x/16) et x*16, tu fais (x>>4) ou (x<<4)

Ha tient je connaissait pas çà, merci, çà va me servir.

Citation

et accélérer les lectures en tableau en rangeant tout dans un seul tableau et en plus deux petits tableaux qui stockent le premier index et la largeur pour chaque calque, et tu consultes la cellule en un seul coup comme ceci:
cell = map[ layerFirstCell + layerNumColon * row + col ];

Heu là j'ai pas suivit, dans le moteur j'ai deux tableaux géants, un pour le sol et un pour les objets, mais je stocke pas les tailles des cadres. Je consulte simplement les deux index des tableaux au moment où j'en ai besoin (donc sans les parcourir). A moins que tu parle de l'éditeur ?

En gros dans l'éditeur je décompose des petites maps en plein de petits tableaux.
Puis dans le moteur au chargement du jeu je recompose tout en 2 ou trois tableaux géants (1 par calque, pour l'instant sol et objets). Puis pour les interactions j'utilise le plus souvent la position du perso sur le sol et le type de tile où il se trouve pour lancer une action.


Je jettes un œil à ton code pour voir si je peux adapter et si j'y gagne en ressources utiles et je viens poster le résultat, merci.

[papwal]

Monsieur_Spi, le 04 November 2009 - 20:52 PM, dit :

Tu parles du moteur ou de l'éditeur ?

Le moteur, mais tant qu'à faire ça peut aussi servir pour l'éditeur, comme ça tu gères les deux appli avec la même classe

Citation

Ha tient je connaissait pas çà, merci, çà va me servir.

c'est pour ça que les calculs avec des integer utilisent presque tout le temps des puissance 2,
par exemple les cartes vidéo se servent des nombre puissance 2 pour optimiser le rendu des textures ou des voxel

les maps tile-based en théorie ne doivent utiliser que des dimensions comme 4 8 16 32 64 128 etc... par exemple des tuiles de 32*32, des maps de 128*128 tuiles pour l'arrière plan, 256*256 pour le plan du dessus et ainsi de suite


plein d'optimisations avec les opérations sur les bits expliquées ici:

http://lab.polygonal...t-integer-math/

Citation

Heu là j'ai pas suivit, dans le moteur j'ai deux tableaux géants, un pour le sol et un pour les objets, mais je stocke pas les tailles des cadres. Je consulte simplement les deux index des tableaux au moment où j'en ai besoin (donc sans les parcourir). A moins que tu parle de l'éditeur ?

En gros dans l'éditeur je décompose des petites maps en plein de petits tableaux.
Puis dans le moteur au chargement du jeu je recompose tout en 2 ou trois tableaux géants (1 par calque, pour l'instant sol et objets). Puis pour les interactions j'utilise le plus souvent la position du perso sur le sol et le type de tile où il se trouve pour lancer une action.

en fait ce qu'il faut c'est rendre les données les plus rapide d'accès possible là où le code passe souvent (c'est le cas de ma grosse boucle de tracé des tuiles). lire une cellule de tableau consomme pas mal de process en flash donc on utilise des astuces pour avoir le minimum de cellules à lire

[papwal]

sinon j'ai relevé une erreur dans mon code là

p_masked=(layerGrid[ relTopRow+((sideBitMask>>1)&1) ][ relLeftCol+(sideBitMask&1) ] == 0


j'ai raisonné comme s'il n'y avait que des tuiles sans alpha
en tenant compte qu'il y'a des tuiles avec et sans alpha ça serait plutôt

p_masked=(layerGrid[ relTopRow+((sideBitMask>>1)&1) ][ relLeftCol+(sideBitMask&1) ] >= firstIndexAlphaTiles

les tuiles alpha doivent rester peu nombreuses car leur copie consomme plus de cpu

[papwal]

des précisions pour l'encodage des tableaux:

-côté éditeur le format doit être le plus lisible possible, là tel que tu l'as fait il est très bien, mais côté moteur il doit être réoptimisé pour être lu plus vite


-concernant l'optimisation de lecture des grilles (côté moteur)

tu peux déjà commencer par linéariser les tableaux à deux dimensions comme cela:

au lieu de grid[rangée][colonne], faire grid[rangée*nombreDeColonnes+colonne]

tu sautes ainsi une lecture en tableau et gagne en vitesse

et tu peux encore accélérer la lecture avec des bitshit

exemple si ma grille a une largeur de 256 (=2 puissance 8)

lire grid[(rangée<<8)+colonne]

c'est la façon la plus rapide de lire dans une grille unique


pour lire dans plusieurs grilles, c'est simple aussi si tes maps ont des dimensions puissance 2 et un rapport 2 entre chaque calque

mettons que la taille de la première grille soit de 128*128 tuiles au total, puis 256*256 pour le plan du dessus, et enfin 512*512

// précalculé au début

min = 128*128
max = 512*512

// au runtime

layerFirstCell=0;
for (layerSize=min; layerSize<=max; layerSize=(layerSize<<2) ) {

cell=grid[ layerFirstCell + (rangée<<8)+colonne ];
layerfirstCell += layerSize

}

tu n'as donc plus qu'une seule cellule de tableau à lire pour chaque consultation de tuile, sur toute la routine de scroll, et pas d'autres calculs que des additions et bitshift, bref que du rapide

[Monsieur Spi]

Hello,


Merci çà fait du grain à moudre tout çà.
C'est vrai que je suis un peu resté sur des acquis mais qu'il y a d'autres méthodes plus rapides.

Après comme je l'ai dit plus haut, au départ je suis juste parti pour faire des outils pour me simplifier la vie.
Ce que tu propose là va m'obliger à tout reprendre (ou presque) côté moteur mais à la fois c'est l'occasion pour sauter le pas et évoluer un peu dans mes process.

Citation

les maps tile-based en théorie ne doivent utiliser que des dimensions comme 4 8 16 32 64 128 etc... par exemple des tuiles de 32*32, des maps de 128*128 tuiles pour l'arrière plan, 256*256 pour le plan du dessus et ainsi de suite

Yep çà je savais déjà, cependant imaginons qu'on veuille sortir du système et qu'on souhaite faire une map de 512*64 (par exemple pour un shoot'em up), ou même ne pas du tout respecter le format (523*42) ?

Je vais jeter un œil à ton lien çà a l'air super intéressant.

Citation

en fait ce qu'il faut c'est rendre les données les plus rapide d'accès possible là où le code passe souvent (c'est le cas de ma grosse boucle de tracé des tuiles). lire une cellule de tableau consomme pas mal de process en flash donc on utilise des astuces pour avoir le minimum de cellules à lire

Je suis d'accord avec çà, cependant je me pose une question, en formatant les tableaux de façon linéaire on perds énormément en lisibilité, ce qui va imposer d'utiliser l'éditeur si on veut faire une modif (par exemple une correction simple pour l'index d'un objet). La question c'est donc, où doit se trouver le compromis entre l'optimisation du code et sa facilité de lecture ?

Citation

-côté éditeur le format doit être le plus lisible possible, là tel que tu l'as fait il est très bien, mais côté moteur il doit être réoptimisé pour être lu plus vite

Donc si on veut éviter de repasser par l'éditeur cela impose de créer un petit module de recomposition des tableaux à la volée au moment du chargement de la map (tableau à deux dimensions). Çà permet de travailler directement avec des tableaux à deux dimensions facilement modifiable à la main qu'on recompose uniquement pour l'utilisation pure du moteur (tableau recomposé jamais visible).

Citation

-concernant l'optimisation de lecture des grilles (côté moteur)

tu peux déjà commencer par linéariser les tableaux à deux dimensions comme cela:

au lieu de grid[rangée][colonne], faire grid[rangée*nombreDeColonnes+colonne]

tu sautes ainsi une lecture en tableau et gagne en vitesse

Ok je vois le principe, on obtiens un tableau linéaire (une simple liste), plus rapide à parcourir effectivement, mais réellement efficace que sur les grosses boucles qui demandent de parcourir tout le tableau.

Citation

et tu peux encore accélérer la lecture avec des bitshit

exemple si ma grille a une largeur de 256 (=2 puissance 8)

lire grid[(rangée<<8)+colonne]

c'est la façon la plus rapide de lire dans une grille unique

Yep mais si j'ai bien compris çà ne peut marcher que si on impose de travailler avec des tableaux respectant un format précis, pas dans le cas où on souhaiterai utiliser des maps hétéroclites.


Bon donc si j'ai bien compris j'ai pas mal de boulot ce weekend pour modifier la gestion de mes maps et du scrolling

Merci pour les infos, je vais regarder tout çà de plus près, j'avoue que pour le moment mon problème se situe surtout au niveau de l'affichage des objets et pas tellement au niveau du scrolling, mais si c'est la solution pour alléger le système alors il faut le tenter. Surtout que pour le moment je n'ai que deux couches (sol et objets) et que je risque d'en rajouter (ennemis, masques, plans, etc...) alors autant optimiser de suite.

J'en profite pour glisser une question subsidiaire.
Dans ma construction un tile représentant une dalle du sol (ou objet, ou ennemis) peut être un movieClip qui va contenir plusieurs états (et/ou des animations si on prend l'exemple de la lave et de l'eau), cela permet de modifier directement l'état du sol lors d'une action (imaginons par exemple un pont en bois qui peut être détruit au simple passage du héros). Avec copyPixel plus question d'utiliser un clip avec des états pour faire çà, obligé donc de multiplier le nombre de tiles par le nombre d'états possibles du type et d'établir une correspondance entre les tiles pour gérer la modification d'un état (enfin à moins qu'il y ait une solution que je n'entrevois pas là comme çà au réveil). De plus comment gérer l'animation du tile dans ce cas (voir chaque dalle du pont s'effondrer sur quelques frames) ? Il y aurait bien la solution de venir poser un clip en replacement du tile mais pour le coup çà serait de la bidouille pas vraiment fiable.

Çà ne remet pas en question de formatage des tableaux pour leur lecture, mais par contre çà risque de poser problème pour les animations du terrain, du coup çà obligera à complexifier cette partie.

[papwal]

Citation

Yep çà je savais déjà, cependant imaginons qu'on veuille sortir du système et qu'on souhaite faire une map de 512*64 (par exemple pour un shoot'em up), ou même ne pas du tout respecter le format (523*42) ?

512*64 c'est bon, 523*42 ça va pas car on perd la possibilité de tout optimiser avec les operations sur les bits
ces opérations sont non seulement très rapides mais en plus elles servent à remplacer des calculs lents: multiplication, division, modulo, puissance

les puissance de 2 ont la particularité de n'avoir qu'un seul bit à true ce qui permet de faire des choses comme:

-remplacer modulo par un bitmask:
si l'on retranche un tous les bits précédents se mettent à true et permettent de masquer la partie inférieure du nombre
x & 7 à la place de x % 8

très pratique pour parcourir une map en boucle infinie (comme dans magic carpet)

-remplacer multiplication, division et puissance par bitshift ( << décale bits à gauche ou >> à droite)
si tu décales un bit à gauche (on ajoute un zéro à droite) tu multiplies le nombre par 2
si tu décales deux bits tu multiplies par 4, et ainsi de suite
si tu décale à droite tu duvises

Citation

Je suis d'accord avec çà, cependant je me pose une question, en formatant les tableaux de façon linéaire on perds énormément en lisibilité, ce qui va imposer d'utiliser l'éditeur si on veut faire une modif (par exemple une correction simple pour l'index d'un objet). La question c'est donc, où doit se trouver le compromis entre l'optimisation du code et sa facilité de lecture ?

En fait à partir du moment ou on fait un editeur prévu pour n'importe quels jeux il faut bosser avec deux formats et deux programmes.
D'un côté le format éditeur (qui est déjà fait), dont la priorité est la lisibilité, et qui est lu par l'éditeur
D'un autre côté un format optimisé pour le moteur, retravaillé par un autre programme (appleons ça un pseudo compileur)

Les editeurs de level multi-jeux utilisent ce système, le format lisible est le même pour tous, le format compilé dépend du jeu choisi, chacun ayant son compilateur.

Citation

Ok je vois le principe, on obtiens un tableau linéaire (une simple liste), plus rapide à parcourir effectivement, mais réellement efficace que sur les grosses boucles qui demandent de parcourir tout le tableau.

En effet tout dépend du besoin. un bête mouvement interpolé par exemple ne demande pas d'optimisation particulière, par contre pour faire du pathfinder, du scroll ou des collisions ça demande des grosses boucles, la façon dont tu vas retravailler le code dépend entièrement des besoins du moteur

Citation

Yep mais si j'ai bien compris çà ne peut marcher que si on impose de travailler avec des tableaux respectant un format précis, pas dans le cas où on souhaiterai utiliser des maps hétéroclites.

Ca dépend des choix qu'on fait dans le moteur encore une fois

Citation

j'avoue que pour le moment mon problème se situe surtout au niveau de l'affichage des objets et pas tellement au niveau du scrolling, mais si c'est la solution pour alléger le système alors il faut le tenter.

Il est préférable d'attaquer tout de suite la partie de l'appli qui va le plus contraindre le codage de la map... c'est à dire l'affichage de la map. ça réduit le nombre de modifications à faire ensuite

Citation

Surtout que pour le moment je n'ai que deux couches (sol et objets) et que je risque d'en rajouter (ennemis, masques, plans, etc...) alors autant optimiser de suite.

faut pas rajouter trop de surcouches non plus, attention à la ram
un tableau par plan de tuiles et un autre pour les objets et les infos de cellule ça devrait pouvoir tout faire

Citation

J'en profite pour glisser une question subsidiaire.
Dans ma construction un tile représentant une dalle du sol (ou objet, ou ennemis) peut être un movieClip qui va contenir plusieurs états (et/ou des animations si on prend l'exemple de la lave et de l'eau), cela permet de modifier directement l'état du sol lors d'une action (imaginons par exemple un pont en bois qui peut être détruit au simple passage du héros). Avec copyPixel plus question d'utiliser un clip avec des états pour faire çà, obligé donc de multiplier le nombre de tiles par le nombre d'états possibles du type et d'établir une correspondance entre les tiles pour gérer la modification d'un état (enfin à moins qu'il y ait une solution que je n'entrevois pas là comme çà au réveil). De plus comment gérer l'animation du tile dans ce cas (voir chaque dalle du pont s'effondrer sur quelques frames) ? Il y aurait bien la solution de venir poser un clip en replacement du tile mais pour le coup çà serait de la bidouille pas vraiment fiable

Çà ne remet pas en question de formatage des tableaux pour leur lecture, mais par contre çà risque de poser problème pour les animations du terrain, du coup çà obligera à complexifier cette partie.

au contraire ça va simplifier tout ça

pour la mise à jour des tuiles (démolition, bonus ramassé, etc), avec ma routine bête qui retrace tout l'écran à chaque fois il suffit de changer l'index de tuile dans le tableau

pour l'animation ça se passe directement dans la routine de rendu, en fonction de l'index de tuile on dit si elle est animée ou pas, par exemple si le bit 0 de l'image est à true... tu utilises les bits suivants pour coder d'autres infos: la tuile est-elle transparente, est elle réactive, etc, ce sont ces bits qui vont former le nombre entier qui est l'index de tes textures. (sur la planche tout est rangé en ordre logique donc)

pour les animer le plus simple est de jouer avec les paletteMapping comme dans les vieux jeux, tu t'en sors avec une seule image et tu peux traiter la tuile animée exactement comme les autres
sinon il faut un système de stockage qui différencie les tuiles animées et fixes


pour les objets statiques genre bonus il faut utiliser des tuiles aussi, seuls les objets qui bougent doivent utiliser les clips (c'est bien de ne pas dépasser une douzaine de clips à l'écran)

Modifié par cooz uz tencil, 05 November 2009 - 13:23 PM.

[Monsieur Spi]

Hello,

Bon j'ai commencé des essais avec ce que tu préconise, mais j'avoue avoir un peu de mal n'étant pas développeur j'ai des lacunes et j'éprouve des difficultés à travailler de manière abstraite (sans référence visuelle de ce que je fais).

Je pense qu'au final je vais modifier le moteur (du moins en ce qui concerne l'affichage) pour faire du CopyPixel, c'est ce qui me semble le plus réactif.

Sinon j'ai une autre question, comment géreriez-vous les ombrages dynamiques ?
Je m'expliques, j'aimerai pouvoir ajouter des effets d'ombres un peu partout mais je ne peux pas passer par les tiles pour çà, j'ai besoin de gérer les ombres sur l'ensemble d'une pièce en fonction des sources de lumières disponibles et de la configuration de la pièce, mais également que le perso passe sous ces ombres (çà me semble logique), voire de m'en servir pour que le perso soit caché à la vue des ennemis dans certains cas.

J'ai donc imaginé passer par un PNG global qui permettrait de tracer mes ombres sur la totalité du plan au sol et ensuite de le gérer par un CopyPixel simple qui conserverait la transparence. En gros je rajouterai une couche au dessus du perso qui servirait uniquement à afficher les ombres, retracées directement sans tuiles.

D'après vous, avant que je me lance sur du dev inutile, la méthode vous semble bonne ?

Je vois pas trop comment gérer çà autrement tout en restant simple, on pourrais imaginer coder entièrement les ombres dynamiquement en fonction des sources de lumières mais je pense que çà sera hors de mes compétences et je ne suis pas sur que çà fasse pas ramer l'ensemble.

[thot]

Le plus simple c'est encore de gérer l'ombre sur le tile de l'objet à qui appartient cette ombre.
Pour la bonne et simple raison que si tu vises la performance, un vrai calcul d'ombre c'est de la physique.
La physique ça consomme de la ressource quoique tu fasses.

Pour ma part j'ai un petit moteur 3D iso que j'utilises à loisir pour faire des map.
Les ombres peuvent être gérées au niveau des personnages et honnêtement le rendu est pas dégueu.

Ensuite si tu tiens réellement à passer par une couche mathématiques, il va falloir sérieusement repenser l'architecture du moteur ou sacrément bidouiller.

A ne pas oublier que si l'on a codé des jeux en 3D isométrique, c'est avant tout parceque certaines plateformes ne supportaient pas la charge requise pour de la vraie 3D.

Ben oui la géométrie de l'espace, les matrices et tout ça c'est pas une invention du 20ème siècle...

[papwal]

spi>

il y'a un choix à faire

soit tu continues à faire des jeux en amateur pour t'amuser avec des bricolages faciles d'amateur

soit tu attaques les techniques des pros et là ça devient un vrai métier dur et compliqué et tu vas devoir bouffer des tonnes de docs et de maths et tu as interêt à avoir un max de temps disponible... et il faut faire ça dans l'idée de passer pro, de pouvoir vendre tes jeux à des sites web ou d'en tirer des sous à ton compte, sinon aucun interêt d'en chier "juste pour le fun".

si tu préfères faire le premier choix alors laisse tomber le tile-based, c'est pas possible d'attaquer décemment les techniques de pro dans un cadre hobby

si tu préfères le second (bon courage), pour faire des ombres il faut calculer des intersections de droite. (j'irai pas dans les détails je t'ai déjà bien embrouillé avec mes explications sur le tilebase) ça n'est pas lent si c'est bien fait.

[Monsieur Spi]

Citation

il y'a un choix à faire

Ha ?

Citation

soit tu continues à faire des jeux en amateur pour t'amuser avec des bricolages faciles d'amateur
soit tu attaques les techniques des pros et là ça devient un vrai métier dur et compliqué et tu vas devoir bouffer des tonnes de docs et de maths et tu as interêt à avoir un max de temps disponible... et il faut faire ça dans l'idée de passer pro, de pouvoir vendre tes jeux à des sites web ou d'en tirer des sous à ton compte, sinon aucun interêt d'en chier "juste pour le fun".

Ha ? Sans vouloir débattre autour de la chose je ne suis pas tout à fait d'accord avec toi.
L'idée de faire des jeux (en hobby) et d'avancer petit à petit n'implique pas forcément de ne pas évoluer dans ses méthodes. C'est amusant cette propension qu'il y a à tracer une frontière entre ce qu'on peut ou ne peux pas faire si on ne porte pas l'étiquette de professionnel de la profession. Bien sur qu'il y a du chemin à faire surtout si on ne cherches pas forcément à en faire son métier, mais çà n'implique pas de ne pas se renseigner et d'essayer d'avancer.

Quand à en chier juste pour le fun je dirais simplement que je ne suis pas sportif et que je ne comprend pas non plus pourquoi certains adorent se lever aux aurores pour aller courir dans un sous-bois glacé.

Eux ils disent que çà entretient la forme...

Citation

si tu préfères faire le premier choix alors laisse tomber le tile-based, c'est pas possible d'attaquer décemment les techniques de pro dans un cadre hobby

Ben là non plus je suis pas d'accord, je ferais certainement pas un truc hyper pro c'est certain, mais çà m'empêche pas d'essayer de le faire déjà, puis d'essayer d'améliorer le résultat. Faut bien partir de quelque part. En tant que hobby justement j'ai le temps, je cherches pas à franchir absolument un cap.

Citation

si tu préfères le second (bon courage), pour faire des ombres il faut calculer des intersections de droite. (j'irai pas dans les détails je t'ai déjà bien embrouillé avec mes explications sur le tilebase) ça n'est pas lent si c'est bien fait.

Merci, c'est pas que je préfères non, mais bon si c'est le chemin à suivre pour arriver à faire ce que je veux pourquoi pas y jeter un œil, je suis pas allergique au fait d'ouvrir un bouquin.

Sinon je me sent pas embrouillé par tes explications, je les ai trouvé plutôt constructives au contraire et suffisamment claire pour que je puisse commencer à m'y plonger un peu. Après j'ai aussi un métier et pas mal de choses en cours, donc j'ai juste fait des essais rapides et j'ai pas réussi du premier coup mais c'est pas perdu pour autant

[Monsieur Spi]

Thoutmosis, le 12 November 2009 - 16:45 PM, dit :

Le plus simple c'est encore de gérer l'ombre sur le tile de l'objet à qui appartient cette ombre.
Pour la bonne et simple raison que si tu vises la performance, un vrai calcul d'ombre c'est de la physique.
La physique ça consomme de la ressource quoique tu fasses.

Pour ma part j'ai un petit moteur 3D iso que j'utilises à loisir pour faire des map.
Les ombres peuvent être gérées au niveau des personnages et honnêtement le rendu est pas dégueu.

Ensuite si tu tiens réellement à passer par une couche mathématiques, il va falloir sérieusement repenser l'architecture du moteur ou sacrément bidouiller.

A ne pas oublier que si l'on a codé des jeux en 3D isométrique, c'est avant tout parceque certaines plateformes ne supportaient pas la charge requise pour de la vraie 3D.

Ben oui la géométrie de l'espace, les matrices et tout ça c'est pas une invention du 20ème siècle...

Salut,

Que le calcul qui est derrière passe par de la physique j'en convient par contre je n'ai jamais parlé de 3D ni d'iso. Je suis sur de la bête 2D vue du dessus, çà simplifie quand même pas mal les choses.

De plus mes ombres sont fixes, je cherches pas à les rendre dynamiques dans le sens "bougent en fonction de l'éclairage" mais simplement rajouter une couche par dessus mes sprites qui vient afficher les ombres de mes pièces. C'est simplement la gestion d'un calque en plus c'est tout ce que je veux faire.

Pour l'instant je cherches pas plus loin que çà.

D'où l'idée de faire un PNG avec transparence et du copyPixel pour pas alourdir.

[Angelstreet]

Bonsoir,
Moi je ne suis pas du tout intéressé par l'Editeur car 2D et je travail en Isométrie par contre, je suis très intéressé par la partie de ton code concernant les tirs collisions et effets. Ton code étant propriétaire je ne veut pas m'en inspirer sans ton accord. Bien sur le code final que je créerais sera inspiré du tient mais largement adapté à mon moteur Isométrique IsoEnginev1.2.
J'attends donc ton approbation ou des liens vers des tutoriaux pour que je puisse me former.
Merci d'avance.

[Monsieur Spi]

Citation

Bonsoir,
Moi je ne suis pas du tout intéressé par l'Editeur car 2D et je travail en Isométrie par contre, je suis très intéressé par la partie de ton code concernant les tirs collisions et effets. Ton code étant propriétaire je ne veut pas m'en inspirer sans ton accord. Bien sur le code final que je créerais sera inspiré du tient mais largement adapté à mon moteur Isométrique IsoEnginev1.2.
J'attends donc ton approbation ou des liens vers des tutoriaux pour que je puisse me former.
Merci d'avance.

Hello,

Si çà peux t'être utile pas de problème, voici mon code pour le tir.
C'est certainement pas la méthode pro pour le faire mais pour le moment çà fonctionne pour mes besoins.
Si tu as besoin d'explications n'hésite pas.

Pour info, j'utilise deux tableaux pour les objets, un qui m'indique la position de l'objet dans la grille et son type, l'autre qui me renvoie son état (normal, cassé, pris, ect...). Quand je touche un objet je modifie son état, et j'enregistre çà dans le tableau ce qui me permet de conserver son état si je doit le réafficher.
Les effets lorsque le tir touche un mur ou un objet sont pour l'instant géré par un simple clip que je viens poser à l'endroit où le tir à touché et/ou sur l'objet concerné si celui-ci à besoin d'un effet particulier.
Attention, cette méthode fonctionne chez moi car pour tirer mon perso ne doit pas être en mouvement, du coup attacher un clip et le poser sur la grille (qui ne bouge pas) n'est pas gênant et ne consomme pas grand chose.
En mouvement çà changerais sans doute pas mal la donne.

// comteur qui permet de rythmer les tirs
var compteur:Number = 0;
function compter(){
        if(compteur>0){
                compteur--;
        }
}


function tirer() {
               
        var nbrTirs:Number = 2;// compter les tirs
       
        for (var i:Number = 0; i<nbrTirs; i++) {

                // si le tir n'existe pas
                if (!grille["tir"+i] && compteur == 0) {
                       
                        var vit:Number = 4; // vitesse de déplacement du tir
                        compteur = 20; // lance le compteur
                       
                        // positionne le tir au bout du canon
                        var X:Number = perso._x+Math.cos((perso._rotation-90)*Math.PI/180)*10*vit;
                        var Y:Number = perso._y+Math.sin((perso._rotation-90)*Math.PI/180)*10*vit;

                        grille.attachMovie("tir","tir"+i,grille.getNextHighestDepth(),{_x:X, _y:Y, angle:perso._rotation-90, vit:vit, _rotation:perso._rotation});
                        perso.anim.gotoAndPlay(2);
                }
               
                // si le tir existe    
                grille["tir"+i].onEnterFrame = function() {
                       
                        // deplace le tir
                        this._x += Math.cos(this.angle*Math.PI/180)*3*this.vit;
                        this._y += Math.sin(this.angle*Math.PI/180)*3*this.vit;

                        // conditions efface le tir
                        var l:Number = Math.floor((this._y)/tH);
                        var c:Number = Math.floor((this._x)/tH);
                        var d:Boolean = (this._x+grille._x)>440;
                        var g:Boolean = (this._x+grille._x)<0;
                        var h:Boolean = (this._y+grille._y)<0;
                        var b:Boolean = (this._y+grille._y)>280;
                        var m:Boolean = tabMurs[l][c] == 2;// touche un murs
                        var o:Boolean = tabObjets[l][c] != 1 && tabEtatObjets[l][c] == 1;// touche un objet

                        // attache un clip "effet" sur l'objet ou le mur touché
                        if (m || o) {
                                grille.attachMovie("exploTir","exploTir",999999999,{_x:this._x, _y:this._y});
                        }

                        // efface le tir
                        if (d || g || h || b || m || o) {
                                // touche un arbre
                                if (tabObjets[l][c] == 15) {
                                        grille["to_"+c+"_"+l].anim.gotoAndStop(2);// changement de frame de l'objet
                                        tabEtatObjets[l][c] = 2;// enregistre le nouvel état de l'objet
                                }
                                this.removeMovieClip();
                        }
                };
        }
}

[ghost]

en effet ça peut se faire mieux

utiliser des attachMovie / removeMovieClip pendant l'exécution du jeu n'est pas une approche adroite car en créant/détruisant des objets tout le temps, d'une part tu multiplies les risques de memory leak, d'autre part tu stimules le garbage collector qui peut consommer pas mal de cpu

la bonne technique est de créer les objets une bonne fois pour toutes au chargement du moteur et/ou des maps, puis les recycler en cours de jeu

par exemple pour chaque personnage qui tire je crée 8 balles dès le chargement de la map
ou bien je crée une bonne fois pour toutes 8 balles pour le joueur et 8 pour les méchants dès l'initialisation du moteur

ensuite pendant la partie tu gères les balles libres/occupées soit avec une série de push/splice dans un tableau, soit à l'aide d'un tableau de bits (un integer pour 32 balles) s'il n'y a plus de balles libres alors le tir est annulé.


les clips de flash c'est pratique pour l'animation mais pour les jeux ça n'est pas forcément le mieux, on peut tout à fait faire un jeu sans utiliser un seul clip, en utilisant seulement un bitmap dans lequel on copie les tuiles et les sprites à chaque frame

c'est cette approche que je te recommande pour revoir ton moteur, ça va te débarasser des clips et tu vas pouvoir te concentrer sur la logique du jeu et coder librement, si tu es plus à l'aise en procédural qu'en objet tu peux ainsi tout coder en procédural (comme dans les vieux jeux)... de toutes façons c'est la seule approche que j'ai trouvé pour faire du scroll multidifférentiel de tuiles classique sans exploser le cpu

en fait, flash a deux manières de faire la composition de ce qu'il va renvoyer à l'écran

- soit il utilise son moteur vectoriel, qui lui permet d'afficher les tracé vecto mais aussi les clips et les objets bitmap. il le fait vite et bien à condition d'afficher quelque chose de simple. étant donné que flash doit faire un clipping entre tous les polygones qu'il affiche (il les redécoupe là où ça se chevauche), si tu en as peu tout va bien mais si tu en as beaucoup ça commence à consommer du processeur

- soit il superpose des bitmaps avec copyPixels. c'est plus lent que tracer un simple poly ou un simple clip car il faut mettre à jour un tableau de pixels, par contre quand il y'a beaucoup d'images à assembler ça devient l'approche la plus rapide du fait qu'il n'y a pas de clipping à calculer

l'approche la plus optimisée c'est de trouver un équilibre entre la quantité de polygones tracés et de pixels mis à jour à chaque frame, et il faut un peu tester et chercher car ça va entièrement dépendre de l'aspect de ton jeu: les tuiles sont elles animées, multi-différentiel ou pas, quantité de sprites, taille des tuiles, etc

l'approche la plus simple c'est de ne pas se casser avec des recherches d'affichage optimisé pour flash et d'utiliser la technique classique, utiliser un bitmap unique qui va faire office d'écran et de tout copier dedans à chaque frame, tuiles et sprites
il va commencer le développement avec cette technique-là et puis chercher plus tard des techniques plus optimisées

[ghost]

mes excuses pour cette faute de frappe

Citation

il vaut mieux commencer le développement avec cette technique-là et puis chercher plus tard des techniques plus optimisées

autre chose, je n'aurais peut-être pas du écrire "ma" méthode
cette façon de faire n'est pas une technique perso, c'est la technique classique, trouvée dans des tutos java, basic, haxe, etc
comme ça on ne se prend plus la tête à optimiser l'affichage pour flash, on part sur un truc standard et on avance

[ghost]

Voilà quelques précisions et corrections après avoir joué un peu avec ton éditeur:

J'ai mal compris ce que tu voulais dire en parlant de calques, je pensais que tu parlais de scroll multi-différentiel... donc oublie ce que j'ai dit sur les calques de tuiles

Si ton scroll est sur un seul calque c'est beaucoup plus simple, le code ressemble à ça:

je me base sur le rectangle de l'écran relatif au repère world:

col1 = int(screenRec.left/tileSize);
row1 = int(screenRec.top/tileSize);
col2 = int((screenRec.right-1)/tileSize);
row2 = int((screenRec.down-1)/tileSize);
pt=new Point(-(screenRec.left%tileSize),-(screenRec.top%tileSize));

for ( row=row1 ; row<=row2 ; row++ ) {
 for ( col=col1 ; col<=col2 ; col++ ) {
  bgBmp.copyPixels( tiles[ tilesGrid[row][col] ] , pt , tileRect );
  pt.x+=tileSize;
 }
pt.y+=tileSize;
}

et c'est tout, c'est la méthode la plus simple pour scroller un fond

après il y'a plein de techniques pour l'optimiser en faisant des mises à jour d'image partielles

[Monsieur Spi]

Hello Verpan,

Merci pour ces précisions.

Pour le moment j'ai mis un peu de côté le dev du moteur car je me forme sur l'AS3 et que je pense tout revoir en AS3 en ce qui concerne le moteur du jeu.

Pour l'éditeur, comme je l'avais dit lors de mon tout premier message, c'est un outil perso qui répondait à un besoin immédiat, lui aussi je vais le reprendre un peu plus tard.

Les attachMovie et compagnie je pense que je vais complétement oublier et passer par du copyPixel c'est clairement beaucoup plus optimisé. De plus mon approche de départ n'était pas la bonne, je n'avais pas réfléchi en amont et je me suis lancé là dedans en "brute force", c'est à dire tête baissée en partant d'un truc simple et petit et en le poussant vers un truc plus complet, ce fut une erreur car les bases n'étaient pas saines, du moins pour être viables dans la version finale.

Il faut absolument que j'oublie mes mauvaises habitudes, je dois absolument séparer calculs et rendus, l'affichage en lui même ne doit représenter que la partie finale, c'est là mon erreur de départ. Quand frangois m'a lancé qu'il ne récupérerai pas la source avant que je propose du 256*256 sur l'éditeur j'ai pensé à une blague mais en fait pas du tout, c'était même la piste qui me manquait pour m'apercevoir que j'étais mal parti et que si je bloquais c'était justement parce qu'il faut réfléchir à la chose autrement. En réfléchissant un peu çà devient évident qu'on peut repousser la limite.

En reprenant vos divers conseils je pense arriver à repartir dans le bon sens, le seul problème est celui du temps, je ne peux pas tout faire d'un coup. Désolé donc si çà n'avance pas vite, je n'avais pas prévu de me lancer dans la conception d'un éditeur performant ni d'un moteur généraliste, j'avais juste eu envie de partager ce petit truc au cas ou çà servirait à d'autres. Mais bon de toute façon je m'aperçoit que si je veux faire évoluer un peu mes jeux je ne vais pas avoir le choix et que je vais devoir partir sur des techniques plus conventionnelles, alors autant repartir là dessus pour essayer d'obtenir un résultat propre.

Laissez-moi quelques semaines pour me plonger un peu dans les docs et me mettre à niveau en AS3 et j'essayerai de proposer quelque chose d'un peu plus propre et optimisé. Comme ce n'est pas mon métier je suis un peu plus lent qu'il ne faudrait mais bon j'ai tout mon temps je n'ai pas de deadline là dessus

Merci en tout cas à tout le monde pour les conseils, je pense que j'ai du grain à moudre à présent, n'hésitez pas si vous voyez d'autres choses que je puisse optimiser (sans rentrer non plus tout de suite dans des techniques ultra pointues pour le moment, çà viendra petit à petit). Mon but n'est pas de monter des choses pro mais juste d'évoluer un peu dans mes techniques histoire de pouvoir me monter des jeux un peu plus évolués, le temps donc de me mettre un peu à niveau et je vais surement revenir poser quelques questions

[ghost]

tu n'es pas forcément obligé de passer à l'as3 pour faire un moteur de jeu qui tienne la route

l'as3 permet d'accélérer les calculs et de profiter de la classe bytearray mais il n'accélère pas l'affichage et les copies de pixels

d'autre part l'as3 a un petit inconvénient pour les jeux: on perd la stabilité mémoire car à chaque event enterframe la mv2 crée un petit objet event (ça n'est pas significatif mais c'est le genre de petit détail qui montre que l'as3 n'est pas le meilleur choix dans 100% des cas)

en plus l'as3 est plus compliqué à rédiger et ça rallonge le temps de travail


l'as3 est pertinent quand on commence à devoir optimiser des calculs lourds, genre de la 3d ou de la physique

et il est utile aussi pour pouvoir faire une vraie gestion de fichiers avec le bytearray

Modifié par verpan, 28 November 2009 - 15:59 PM.

[Monsieur Spi]

Citation

tu n'es pas forcément obligé de passer à l'as3 pour faire un moteur de jeu qui tienne la route

Yep tout à fait, mais comme je passe progressivement à l'AS3 autant partir directement avec cette version du langage en fait. Quitte à de toute façon tout démonter pour tout reconstruire autant que je partes de suite avec AS3 çà m'évitera de devoir une fois de plus tout réécrire par la suite, et puis çà sera justement un bon exercice

Citation

d'autre part l'as3 a un petit inconvénient pour les jeux: on perd la stabilité mémoire car à chaque event enterframe la mv2 crée un petit objet event (ça n'est pas significatif mais c'est le genre de petit détail qui montre que l'as3 n'est pas le meilleur choix dans 100% des cas)

Tient çà je savais pas par contre merci de l'info.

Citation

l'as3 est pertinent quand on commence à devoir optimiser des calculs lourds, genre de la 3d ou de la physique

A terme j'aimerai bien partir sur du Raycasting, j'ai un projet de jeu qui traine depuis quelques années (faire mon propre épisode de Migth and Magic dérivé d'un manque dans l'histoire de MM7 : http://spi4.free.fr/....php?article408 mais j'en suis encore très loin), j'ai déjà fais des tests et monté des petits moteurs de RayCast, mais j'arrive pas a un résultat probant en AS2 alors qu'en AS3 çà me semble plus réaliste déjà.

Pour l'instant je monte des petits jeux qui m'apportent des solutions aux divers problèmes que je rencontre et parallèlement j'écris mon scénar, tous les jeux que je construit n'ont pour but que de comprendre certains principes dans l'idée générale de monter ce grand jeu un jour. Je suis parti de mon premier jeu : http://spi4.free.fr/...ip.php?article3 , là je construit le deuxième épisode avec des grandes maps pour les extérieurs et plusieurs donjons (d'où mon éditeur, le moteur que j'ai commencé à monter concerne 1 seul donjon pour le moment) mais toujours avec la même vue 2D du dessus, le but de cet épisode est de me permettre de gérer de grandes maps et d'augmenter considérablement les interactions, de comprendre comment simplifier la gestion des PNJ et la construction de l'univers, et surtout de travailler le scénario. Parallèlement j'étudie la possibilité de passer à un moteur de RayCast (ou autre, je teste par exemple Sandy comme lib externe), mais comme je manque de temps et de technique çà n'avance que doucement.

Le passage en AS3 va m'ouvrir plus de portes pour la construction de mon jeu, mais je ne pense pas commencer réellement la 3D avant l'épisode 4 ou 5, donc j'ai encore du temps devant moi , par contre autant passer de suite en AS3 car dans quelques années (mois ?) on aura oublié AS2.

[Leonerep]

Citation

http://alecmce.com/a...ing-enter_frame

arg fear la cradingitude pour rien (en plus utiliser un MC pour ce genre de connerie prend plus de ressource x___x)... sinon, un truc que je commence à utiliser de plus en plus notament pour la 3D, c'est de baisser le framerate (genre a 15), car le framerate est vilain et plombe pas mal flash en fin de compte, et met un timer de fou avec un updateAfterEvent, et finalement on gagne vachement et ca baisse très largement les erreurs d'affichage du player pour cause de rafraichissement pas synchrone avec le calcul, alors des fois c'est pas possible quand on utilise des movieclip d'animation fait main, mais pour les projets full sprite ou bitmap, ca trou le cul ~
my 2billion pence (oé parce que mon astuce c'est quand même pas de la merde XD)

[ghost]

merci pour le link frangois
même si c'est une optimisation de bout de chandelle qui sert à rien, j'aime bien pouvoir regarder ce qui se passe dans ma ram

[ghost]

leonerep> le problème pour faire des jeux 3d avec flash c'est surtout que c'est tellement plus efficace avec un plugin comme unity (il y'a une licence gratos maintenant) qu'il faut vraiment une motivation et une persévérance de geek passionné 10ème dan pour faire des moteurs de jeux 3d en flash... le côté bidouille et linux-friendly de la 3d flash est excitant mais les perfs sont décevantes, j'avais fait pas mal d'essais d'affichage 3d et j'ai jamais réussi à obtenir un framerate correct

flash c'est bien pour faire des jeux style années 80 mais difficile d'en tirer plus

[Leonerep]

Citation

c'est surtout que c'est tellement plus efficace avec un plugin

Faudrait se réveiller, la 3d sur le web c'est tellement plus efficace avec un autre plugin que flash depuis 10 ans au bas mot.
Pose toi la question : pourquoi cela n'a pas marché avant ? Pourquoi ce ne marchera pas plus maintenant ? Et surtout pourquoi la 3D en flash restera discrète malgré la popularité du plugin ?

Pour ce qui est de la 3D flash, ses limitations est une bénédiction sur beaucoup de plan ^3^/...