slowfrog / chickenpix Goto Github PK

La démo actuelle déplace l'objet décor.
En fait, il faut créer un object caméra qui pointe généralement sur le héros et qui est pris en compte par le système de Render pour savoir ce qu'il faut afficher.
La caméra peut se détacher du héros dans certains cas :

• quand on arrive en bord de carte
• pour de la mise en scène cinématique

On a bien joué avec les graphiques, mais on n'a pas encore testé le son.
Il faudrait au moins vérifier qu'on arrive à jouer un .wav ou un .ogg avec ClanLib et SFML.

Exemple d'utilisation : quand on veut changer l'animation ou l'image d'une entité, le plus simple c'est de supprimer le composant Visual existant et d'en mettre un nouveau.

Comme pour main(), une bonne partie du code est commune. Aujourd'hui dans CLLoader et SFMLLoader il y a deux blocs de code :

• le chargement des resources
• la création des entités

Le code de la deuxième partie est déjà compatible entre CL et SFML, il suffit de le monter dans Loader.
Celui de la première demande un peu plus de bricolage.

Des boutons, du texte déroulant, j'ai l'impression ce c'est à peu près tout ce qui serait réellement nécessaire.
Pour info, un article potentiellement intéressant sur une façon de faire de l'IHM, spécifiquement dans des jeux : http://iki.fi/sol/imgui/

La durée d'affichage de chaque frame d'une animation n'est pas correctement prise en compte, ni dans la version ClanLib, ni dans la version SFML.

Pour avoir un héros, une héroïne de base, avec une tignasse et des vêtements collés par dessus indépendamment.

Dans les frameworks existants, il est possible de retrouver des entités par un tag ou dans un groupe.
La différence entre les deux c'est généralement :

• une entité appartient au plus à un groupe
• une entité peut avoir plusieurs tags

Par états, j'entends des choses globales comme :

• état menu de démarrage
• état déplacement libre sur la carte
• état dialogue
• état combat.

Un seul état est actif à un moment donné.
Il existe des transitions définies entre certains états.

Une première piste envisagée en discutant avec Fred était de faire correspondre un état avec un EntityManager, et d'organiser des enchaînements avec passage de données.

Aujourd'hui, les sprites sont forcément en mode boucle. Pour certaines animations, on n'en a pas besoin. On voudrait que l'animation s'arrête. Soit sur rien, soit sur la première frame, soit sur la dernière.

Ajouter le chargement de fonte depuis un fichier TTF.

Ajouter un composant permettant à une entité d'exécuter du script (Python) à chaque frame ou sur événement.
Attention ! On va peut-être vouloir d'une même entité puisse avoir plusieurs composants scripts. Avec l'architecture actuelle, ça n'est ni interdit ni vraiment supporté.

La boucle de jeu est la même, seules les classes instanciées au départ sont différentes. Du coup, ce serait bien de mettre en commun le code commun (c'est une bonne idée de Nico V.)

Les Visual devraient posséder un z-order pour permettre d'afficher par dessus ce qui doit être devant.

Le "perso" qui bouge doit changer de visuel en fonction de la direction prise

Implementation du mode de combat.
https://github.com/slowfrog/chickenpix/wiki/Combat-tour-par-tour

Avec le bout de XML ci-dessous dans resources.xml, l'appli se bloque. Avec d'autres commentaires ça passe. Je soupçonne ClanLib de faire des choses pas claires avec les Node de type commentaire dans certains cas.

<sprite name="wait">
  <image file="img/male_walkcycle.png">
    <grid pos="0,128"
          size="64,64"
          array="1,1" />
  </image>
  <!--animation loop="yes"
             pingpong="yes"
             speed="100"/>
  <frame nr="0"
         speed="4000" />
  <frame nr="13"
         speed="1000" /-->
</sprite>

Pour permettre, par exemple, de ramasser la pièce d'or qui tourne...

Utiliser la bibliothèque tmx-parser http://code.google.com/p/tmx-parser/