On a testé mon essai sur Google Chrome et ça marche, j'ajouterai ça sur la page d'accueil de mon essai. Je ne pense pas faire de pub à Internet explorer en proposant la dernière version à télécharger mais je vais le noter quelque part à côté.
Je laisse celui-ci à disposition des visiteurs de mon blog nounours tant que ta version n'est pas finie.
J'ai hier revu mon code avec pas mal d'include en php pour qu'ils soit plus modulable.
J'aimerais bien que l'on puisse choisir les persos qu'on veut dans mon essai et non un couple, comme actuellement.
Côté interface, ça sera très facile à changer, mais dans le canvas, soit je fais plein d'images avec toutes les combinaisons possibles, soit je change tes scripts, e qui ne sera pas une mince affaire pour moi.
Je dois créer des fonctions par-ci, par là pour améliorer mon code.

Mon but n'est pas de faire doublon avec ton boulot mais de m'entraîner en programmation, je le rappelle.

Dernièrement j'ai travaillé sur les trajectoires et les déplacements
des personnages et leurs intéractions avec le décors. Dans wardance
tout celà n'est pas parfait. J'ai tout refait à neuf pour le prototype
d'USF Web, pour pouvoir permettre d'avoir des personnages de tailles
différentes. Je prépare également l'introduction de plateformes mobiles.

J'ai amélioré l'aperçu:
1) agrandi l'espace de jeu (fenêtre et terrain)
2) intégré les graphisme de USF (Jungle).

C'est toujours le même principe. Il y  a deux personnages qui tombent de l'écran, afin de tester le système de collision,
l'un des personnage est controlable, l'autre pas.

Ajout de poses
Actuellement pour ajouter des poses à un perso, il est plus simple d'ajouter des images indépendantes et de
mettre à jour le XML.

Concernant Isoquest
Hélas la pluspart des textures sont issues de vieux jeux je ne pense pas
qu'elles soient librses de droit, pas plus que les graphismes des sprites
C'est pourquoi je ne peux pas faire grand chose de ce jeu.

Edition de niveaux / personnages
Je prend en compte tes remarques concernant les différents profils de joueur afin
d'imaginer un editeur de niveau.

Externalisation des donnée modifiables
Je garde à l'esprit que les données (niveaux, controle des personnages...) doivent être
facilement accessible et modifiables par des gens autre que programmeurs.

Harmonisation des animation
Oui, harmoniser les animations rendra l'intégration de nouveaux personnages plus facile.
Mais c'est une décision irreversible : il ne faut pas se tromper sur le nombre d'animation ou
de frames choisi.

Le cas Internet Explorer
Internet Explorer intègre le Canvas nativement dans sa toute dernière version.
Microsoft a toujours eu à coeur d'apporter la puissance d'hier au ordinateurs d'aujourd'hui.

A bientôt

Problème : Internet Explorer ne supporte pas la balise canvas, mon mari a essayé sur la version 10.

Je n'ai testé que sur Firefox (sous Ubuntu 12.04). J'évite les accents car le serveur du copain qui m'héberge a des problèmes d'encodage.
Merci de tester ce que j'ai fait.

L'idéal serait de mettre tout ça sous forme de classe mais je n'en suis pas encore là ! J'ai par contre beaucoup progressé en javascript, je pense. Faut dire que j'étais très nulle !

Quelques petits soucis rencontrés pendant mes (nombreux) essais :
Je n'arrive pas à faire référence à mes images situés en haut de l'arborescence si je range mes 2 niveaux dans un dossier "levels", donc je ne les ai pas regroupés dans un dossier mais les ai nommés avec le même mot au début (level-jungle, level-mangrove) pour qu'ils se classent l'un derrière l'autre. Pas génial non plus.

Choix touche clavier
J'ai essayé de faire un fichier Keys.js (dans scripts) qui "pointe" vers Fairykeys mais je n'y arrive pas.
Par contre, avec mon fichier Keys.js qui est la version réduite de FairyKeys, il suffit de consulter Fairykeys pour savoir à quelle touche correspond quel numéro et de changer ce dernier dans Keys.js si on souhaite changer la touche. On ne touche plus aux autres fichiers, ainsi. Comme j'ai plusieurs fichiers qui utilisent Keys, ça va plus vite.
Bien sûr, ça obligerait à changer l'image des touches présentée à côté du jeu mais je n'en suis pas encore là !
-------------------------------------------------------------------------------
Tu as remarqué que le nombre de mouvements des persos d'USF est super variable. Je me demande s'il ne faudrait pas harmoniser tout ça, en prévoyant moins de mouvements différents et toujours le même nombre de frames par mouvements pour faciliter la création de nouveaux persos par la suite.
Surtout si on prévoit de pouvoir un jour les habiller, les armer ou les colorer différemment.

J'aurais bien aimé réussir à dissocier  le choix des touches de la construction du niveau, dans le fichier program.js mais comme ça fait partie d'une même classe, je n'y parviens pas.
L'intérêt d'USF réside justement dans le fait que tout est bien séparé et que les données sont bien indépendantes du reste.
J'ai vu qu'il y avait un fichier spécial pour les touches de clavier et les codes affectés (FairyKeys.js) , mais ce qui serait bien, c'est que le tableau aPlayerKeys soit placé hors de program.js, dans un fichier keys.js, par exemple.
Idem pour stateResourceLoading: function() et stateGameInitializing: function(), à placer ensemble dans un fichier level.js. Le tableau this.landConstruction pourrait même être indépendant du reste
La taille du background et éventuellement la taille des blocs sont également des données à pouvoir gérer seules, sans toucher au reste. Création d'un fichier screen.js ou background.js à prévoir ?

var oBG = this.createBackgroundLayer('bg', 640, 480);

L'upload du fichier persos.png devrait également être ailleurs, dans un fichier characters.js

Dans l'absolu, un graphiste pas trop doué en programmation devrait pouvoir s'y retrouver super facilement et ne toucher qu'aux data sans tout fiche en l'air ailleurs.

Concevoir un mini scénario ou au moins un objectif pour donner du sens au jeu me semble indispensable. Quelque chose de simple mais d'efficace un peu comme Mario avec sa princesse... Pour USF, j'ai proposé à un moment que ce soit une compétition intergalactique où l'on obtient le titre d'Ultimate Smash Friends mais je ne suis pas sûre que le jeu corresponde à ça actuellement.

L'interface de l'éditeur de niveaux demande de savoir comprendre un script. Je pense qu'il faut mieux proposer des boutons, des déplacements à la souris, au pire des chiffres à cocher dans un menu déroulant ou des champs simples à remplir. Quitte à offrir beaucoup moins d'options mais à rendre l'interface plus ludique.
--------------------------------------------------------------------------------------------
Pour tester USF, j'ai actuellement comme public:
- des enfants de maternelles (5-6 ans) qui aiment jouer à USF tel qu'il est actuellement. Un côté plus éducatif (axé sur l'adresse pour sauter et  la récolte de trésor) plairait sans doute plus aux instits et aux parents, mais les gosses, eux, aiment "jouer à la bagarre". Les persos en pixelart que je t'ai cités leur plaisent beaucoup. Le côté kawaï/cartoon de Miks ou Minkie, ils trouvent ça trop bébé !
J'aimerais leur faire dessiner des backgrounds avec Tuxpaint (608x472px, en png) et qu'ils puissent l'intégrer facilement dans USF, avec une simple bouton "parcourir"; le dossier de sauvegarde de Tuxpaint étant dans un dossier caché, il faut que je puisse le définir dans les options facilement.
Et/ou, ils pourraient concevoir leurs niveaux eux-mêmes en déplaçant des blocs par cliquer-glisser.
Un modificateur de perso, avec des couleurs ou des habits/accessoires différents à choisir, sur une même base, serait aussi sympa. Dans ce cas, on prévoit peu de mouvements mais beaucoup d'accessoires.

- nous recevons des classes de CE2 (8 ans) mais ils n'ont pas trop le droit de jouer chez nous. Dommage parce que je pense qu'USF pourrait leur plaire. Un concepteur de niveaux pour USF ultra-simple serait bien aussi pour eux.  Si on propose un programme de conception de jeu assez éducatif, on pourrait l'utiliser dans nos animations avec eux.

- les jeunes de 10-15 ans qui viennent jouer à mon boulot. C'est pour ces âges-là que je vois plus le côté RPGMaker (qu'on leur a présenté il y a 2 ans environ et qu'ils aimaient bien).
La plupart des ados que je connais voudraient créer des jeux mais il faut que tout soit à la fois très beau et sophistiqué côté jeu, et très simple à utiliser côté création (le moins mathématique possible, le plus ludique possible).
Ils jouent beaucoup sur Facebook (Le côté social compense la simplicité graphique des jeux) ou à Dofus aux jeux de voitures et aux FPS, avec des graphismes en 3D très travaillés et une bonne fluidité de jeu.
Si tu veux, je peux leur montrer ta démo d'Isoquest et leur demander ce qu'ils aimeraient y trouver.

- les visiteurs de mon site sur les nounours pourront y jouer même s'ils sont sous Windows. C'est à ce type de public que Miks ou Mikos peuvent plaire.
D'où mon idée : prévoir 2 ou 3 sets de persos différents, mais sans les mélanger tous pour ne pas troubler l'unité graphique (idem pour les décors: un style pour un jeu et non plusieurs style mélangés).
Miks et Minkie ne sont pas assez funs pour des casual gamers, il faudrait que je les retravaille. Rizzie est plus drôle. Mikos et Razz sont un peu plus réalistes. Je les vois plus dans un jeu un peu écolo/mignon (avec de la nourriture, des fleurs et des bisous à récupérer plutôt que de la baston !) que les grands-mères conseilleront à leurs petits enfants...

- J'ai un mari, des copains (35-50 ans) et des neveux (14-25 ans) joueurs qui pourront me donner leur avis sur notre futur jeu, en cas de besoin, même si USF ne correspond pas à leur style de jeu.
--------------------------------------------------------------------------------------------------------------------------------
Autant profiter d'avoir des testeurs pour déterminer le profil des joueurs finaux, sans pour autant penser que mon échantillon est ultra représentatif. Il faut en tout cas faire un choix parmi tout ça car on ne pourra pas tout faire.
De mon côté, je serai peut-être capable de programmer un jour un USF personnalisable pour les petits et les casual gamers, mais pas un nouvel RPGMaker basé sur Isoquest.

Dans mon public, je verrai bien les maternelles et les CE2 jouer à USF-quest, avec un jeu très basique doté d'un objectif clair, sans trop d'options (sauf peut-être pour le choix des persos) et avec le minimum de texte (choix par cliquer-glisser et icônes simples à comprendre). Les ados, eux, concevraient les niveaux, les classes de persos et les quêtes (sous forme d'items à trouver) avec une interface simple et sympa.

De ton côté, qu'est-ce qu'aiment bien les joueurs et/ou programmeurs que tu connais ?

J'ai commencé à modéliser Pixie avec Blender, on pourrait aussi faire de la fausse 3D avec des persos en 3D évoluant dans un univers en 2D mais ça va compliquer la conception du jeu. C'est plus pour te montrer à quoi je m'amuse en ce moment !

Je vais tenter de répondre à la pluspart des questions.

Mais avant, voici une version évoluée de l'aperçu des personnages. Il permet de voir les personnages et de les controler avec les touches du clavier. Les personnages peuvent marcher et sauter. Les personnage testables sont :

• Bearsum

• Lila

• Mikos

• Miks

• Minkie

• Pixie

• Rizzie

• Rohon

• Sorlo

APERCU DES PERSONNAGES
on peut toujour utiliser l'ancienne version (même lien que dans les messages précédent).

Spritesheet
Il y a une spritesheet par personnage, toutes les animations sont contenue dans la spritesheet. Les spritesheets complètes sont disponibles ici : http://www.laboralphy.org/usfgfx/2de/rsc/gfx/sprites. Ces spritesheet sont générées par un programme à partir des données XML et des image PNG associées produites par l'éditeur de personnages actuellement utilisé.
Donc le plus pratique pour moi c'est qu'on continue d'utiliser l'éditeur de personnage actuel. En effet les données XML qu'il produit me sont très précieuses.
On n'excluera pas de refaire un éditeur de personnage si le besoin se fait sentir, mais si l'actuel peut faire l'affaire autant l'utiliser.

Concernant l'aperçu des personnages
Il se compose d'une classe PHP spécialisée dans l'analyse des fichiers XML produits par l'éditeur de personnages. Je ne crois pas qu'il soit très interressant à étudier. Néanmoins tu trouveras une partie du code source ici http://www.laboralphy.org/usfgfx/source/usfgfx.zip. La classe fait appel à une bibliothèque d'analyse XML ainsi qu'un chargeur de classe dynamique que je n'ai aps inclu dans le zip.

Décors
On peut réellement faire différents niveaux de différentes tailles. Il y aura un défillement de l'écran comme dans la version Python, et on peux même envisager un zoom arrière lorsque les personnages s'éloignent. La taille de l'écran peut être de 800x600 ou plus ce n'est pas un soucis.
Pour la taille des grille 40x40 me parait bien.

USF / RPGMAKER
J'ai de l'expérience dans la conception d'outils permettant de faire son propre jeu de role en vue isométrique : Le projet ISOQUEST. Je me suis vautré car je n'avais pas une vision précise du produit final ou du public visé. Si nous voulons créer ce genre de service pour USF nous aurons besoin de bien se fixer des objectifs et des limites, et de bien cibler l'utilisateur final. En tout cas rien ne me dit que c'est impossible.

Je suis encore en phase d'étude. Je repasserai prochainement sur le forum pour poster un plan d'action, poster des questions ou des réponses.

Persos
Pour l'instant, il me semble qu'on peut se contenter des persos en pixelart qui ont plus de poses et une version upgraded, et laisser de côté ceux en vectoriel, je les retravaillerai après.
  Possum  Xeon    Sorlo  Pixie  Bearsum  Rohon

Penses-tu faire plusieurs spritesheets comme tu as commencé à le faire ou une seule par perso ? Qu'est-ce qui est le plus pratique et le moins gourmand ?
Redshrike a en effet fait des spritesheets toute prêtes : awesumpossum_sheet.bmp - xeonsheet.bmp - voir aussi sorlo, sur fond gris. Ce dernier est un peu embêtant car certaines frames sont super larges, mais c'est juste les lancers de rayons qui font cet effet, ils pourraient être à part comme dans Wardance.

Si c'est plus simple graphiquement qu'en programmation, je peux te faire des spritesheets avec mes persos à moi pour peu qu'on définisse bien la taille de la grille.

Aperçu des personnages
Dans ton Aperçu des personnages, les persos apparaissent sur fond noir. J'aurais préféré de la transparence ou un vert pétant pour éviter la confusion avec les contours (comme le fait Redshrike créateur de Possum, Sorlo et Xeon). Mais si c'est trop compliqué de tout refaire, laisse tomber.

J'ai noté que le nom des images générées par ton aperçu était un peu étrange quand on souhaite les enregistrer via un clic droit :www.laboralphy.org.png. Est-ce que ça peut se changer de manière à ce que ton Aperçu des personnages soit plus pratique pour moi ? C'est pas super important, mais ce serait plus "propre". On peut imaginer que cet aperçu serve à d'autres personnes plus tard.

Est-ce que tu peux mettre le code source en lien quelque part pour que je comprenne comment tu as fait ton Aperçu des personnages, je n'ai pas trop bien compris comment tu as fait ça et j'aimerais apprendre. Le code source généré ne me donne pas assez d'élément.

Décors
Pour les décors, la gestion par blocs n'est pas problématique, il faudra juste adapter les décors existants, ce n'est pas super compliqué.
Sur Mangrove que je n'avais pas dessiné,  j'ai réussi à adapter avec un peu de copier-coller par-ci par-là.
Je ne penses pas que la précision soit si importante, surtout pour le public d'enfants visé.
Dis-moi la taille du canevas et de la grille que l'on va utiliser pour le jeu (inutile de s'embarrasser d'une gestion de différentes taille selon moi) et j'adapterai les décors.
On peut faire 800x600 pour rentrer dans les basses résolutions d'écran mais être quand même plus grand que Wardance ? Les premières versions d'USF étaient dans ce format. On peut alors faire une grille de 40x40px, soit 20 colonnes sur  15 lignes.

Ce que j'imaginais à une période, c'est de pouvoir faire d'USF une sorte de RPG-Maker open source, et avec le système de blocs, on pourrait un jour arriver à cela, non ?

Sauts
Sur le niveau Jungle de Wardance-USF, les persos ont du mal à sauter d'un seul coup du sol jusqu'à la première plate-forme, ce qui complique le jeu pour les 5-6 ans que je reçois à mon boulot. Il faudra faire un peu attention à ça en créant la grille ou régler la hauteur de saut correctement.

La classe permet de convertir à la volée, les données XML + Images en spritesheet au format du moteur de wardance.

Vous pouvez visualiser les spritesheet avec le lien ci-dessous.
Aperçu des personnages

J'ai testé sur 8 personnages de USF sans aucun soucis. Je vais donc partir sur cette base.
Je proposerai bientôt une démo permettant d'animer ces personnages dans un décor.

d'ici là...

Ma question est : Avons-nous besoin d'une précision au pixel près pour la position des blocs des niveaux ?

Je suis absolument certain qu'une gestion par bloc permettrai d'économiser beaucoup la taille des ressource graphique (et donc accélérerait le chargement des texture online). Il est également plus simple de faire du pathfinding sur un monde composé de bloc (cela peut aider l'IA à aller débusquer un adversaire). Il serai également possible de créer des niveaux aléatoires basés sur le même graphisme, voire des niveau extrêmement grand.

Évidemment on y perdrait en liberté de conception et en beauté du résultat final, mais un éditeur serai bien plus simple a réaliser et exploitable peut-être même par des enfants.

Cependant un compromis peut être réalisé pour les niveaux déjà existants en considérant que ces niveaux disposeraient d'une grille très petite de l'ordre de 4 pixels par exemple, le XML serait réutilisé et les coordonnées existantes des blocs seraient arrondies à la volée au "bloc de 4 pixels" près...

Je vais tenter de répondre à certaines de tes interrogations :

Clavier
Presque toutes les touches sont exploitables. Les touche délicates sont "Ctrl et Alt" qui combinées à d'autre touche peuvent interrompre le jeu pour effectuer une opération indésirable.
Espace et Entrée ne posent pas de problème.

Personnages
J'ai examiné la structure du XML de définition des personnages d'USF.
Je dois concilier rapidité d'affichage et souplesse de l'éditeur de personnage.
Le moteur de Wardance est prévu pour gérer des spritesheets, dont les frames ont toutes des tailles rectangulaire (pas forcément carrés) identiques (mais deux persos peuvent avoir des tailles différentes).
Les spritesheets et les dimensions fixes pour toutes les frames permettent d'optimiser le moteur et accélérer l'affichage en économisant la mémoire (dans la plus part des cas), mais rien n’empêche d'exploiter un XML de définition de perso existant, de télécharger les images associées et de reconstruire les spritesheets dynamiquement en mémoire à l'initialisation du jeu.
Donc à priori je devrai pouvoir exploiter les XML issus de l'éditeur dans le format qu'ils sont actuellement.
Je m'assurerai que les personnages apparaissent dans les mêmes tailles et aspect qu'ils seraient apparus dans USF python en exploitant les mêmes XML. L'éditeur actuel de personnage devrait encore être utile.

Niveaux
J'ai peur de devoir conserver la gestion des niveaux par grille et par blocs (carré ou rectangulaires), c'est une méthode très efficace pour gérer la collision sprite/décors et donner des propriétés spéciales à certaines briques du niveau. Il faut voir la grille comme un moyen facile et rapide d'indexer, de sectoriser l'espace, pour notamment calculer des collisions entre plusieurs objets de la même case. C'est également une manière plus simple et rapide de gérer les blocs animés, les blocs qui changent d'état (trappes, portes, autres mécanismes), les blocs cassables, la possibilité d'ajouter des blocs...
Il peut y avoir une grille de niveau qui soit de la même taille que le niveau lui même.
La discussion reste ouverte mais je pense qu'on peut arriver à un résultat satisfaisant pour tout le monde. Peut-être pas dans un premier temps, mais assez vite quand même.

Plateformes mobiles
Choisir une gestion par blocs tend à imposer une certaine immobilité au niveau, mais je pense qu'avec un peu de boulot je peux créer des plate formes mobiles à la manière de Mario, j'ai plusieurs pistes à suivre pour réussir.

Taille des niveaux
Comme le défilement est géré, la taille des niveaux n'est pas fixée.

Taille des blocks
Les blocs peuvent être rectangulaires, et les personnages n'ont pas besoin d'avoir la même taille que les blocs. Par contre tous les blocs devront être de la même taille (toujours cette histoire d'optimiser l'espace en secteurs).

Cette gestion brute en blocs et spritesheet semble éloignée de ce que gère USF, mais peut être traité par des couches supérieures du moteur. Ces couches supérieures peuvent faire interface entre les fichiers de définition de données de haut niveau de USF (coordonnées vectorielles ; temporisation fine des animations...) et la gestion plus terre-à-terre du moteur de Wardance. On peut voir ça comme une compilation des ressources de USF pour les adapter à un modèle plus simple. Les très légères simplifications ne devrai pas être visibles à l’œil.

De toute façon j'espère pouvoir sortir une ébauche assez rapidement afin de pouvoir continuer la discussion.

J'espère avoir répondu au mieux à tes interrogations.
A+

- flèches de direction + 2 ou 3 touches faciles à trouver pour des petits (espace, entrée) pour le joueur 1 et pavé numérique  pour le joueur 2

- version française de préférence (ou bilingue)

- 2 joueurs pour commencer, mais avec un choix de 4 à 6 persos en pixel art dont au moins un ours pour mon site Oursement Vôtre - dans l'ordre d'importance : Bearsum, Pixie (pour le côté féministe !), Possum et Xéon, et éventuellement Sorlo, Rohon et Blob.
- Pour les persos, peut-on conserver les tailles originales pour ne pas avoir à redimensionner toutes les frames, et peut-on avoir des frames qui ne sont pas carrées ? Est-il obligatoire de faire les spritesheets ?
- Le nombre de mouvements et de poses par mouvements peut être réduit mais la version upgraded plaît aux gamins.
- Il faudrait revoir l'éditeur de persos pour avoir non seulement la hardshape (si tu en as besoin en javascript) mais aussi les vecteurs, pour les coups.
- Comme je veux faire une version "mignonne" (USF-teddy), avec mes autres persos en vectoriel, il faudrait pouvoir changer facilement les persos, soit par un upload des images ou des dossiers du perso afin que tous en profitent en ligne, soit en proposant une version à télécharger et à personnaliser hors connexion.

- La recherche de trésors et la course sur les plate-formes est à mettre en avant pour plaire aux parents et aux instit's, avec un aspect baston moins prononcé (même si les gosses, eux, adorent)

- Pour l'éditeur de niveaux,  le système de Wardance ne m'a pas trop posé de problème mais la logique de la feuille de plate-formes ne m'a pas tout de suite sauté aux yeux.
- Dans USF, on a aussi des blocs mobiles en plus des plate-formes, indispensables par exemple pour Troglo. J'ai bien aimé les petits détails animés des décors, à reprendre.
- Il faudrait déterminer la taille idéale pour les décors, je ne pense pas que ce soit utile au début de proposer plusieurs résolutions. La taille de wardance est sympa, mais si les persos font 60px de haut, il faudra agrandir le background.
Est-ce que la grille de décor peut avoir des cases rectangulaire au lieu de carrées ? Est-ce que la taille des persos doit être identique à celle de la grille ?
- Il faudrait faire un modèle graphique avec les cases qui correspondent à ton système, car sur Gimp, les grilles ne se positionnent pas forcément comme il faut (est-ce que ça se règle dans les préférences, le point de départ des coordonnées de la grille ?). Je crois pouvoir faire ça facilement. Garder le système xml serait encore mieux mais c'est peut-être un peu compliqué pour la programmation de récupérer tout à l'identique.
- Plus tard, on pourrait imaginer des images à uploader par les joueurs pour rajouter d'autres niveaux (au moins les backgrounds et l'apparence des plate-formes, même si le gameplay ne varie pas)