ambi Compte Rendu de Réunion le 22.11.2010

Definition du cahier des charges :
  • Gestion de :
    • Sprite
    • Plane
    • Tilemap (carte de carreau) à 3 niveaux (couches)
    • Weather (sprites de la même image mais animé sur toute la zone d'affichage)
    • Animation (gestion de la temporisation entre chaque sprite + liste de sprites à afficher)
    • Viewport (zone dans laquelle est dessinée l'objet)
    • Bitmaps (données d'une image, equivalent de Graphics en Java)
      • Tableau de pixels
      • taille
      • ...
    • Window (plus basique que l'interface graphique en Java)
    • Scene
      • Exemples :
        • Scene de début
        • Scene de titre
        • Menu d'options
        • Joueur qui se déplace
        • ...

  • Création d'un framework ayant pour but d'afficher des maps

  • Contraintes
    • 60 fps
    • Utilisation de VolatilImage

  • Conventions de codage :

    class Toto
    {
          public void toto()
          {
                System.out.println("Toto");
          }
    }
    • Tout ce qui est boolean isVisible(), isEnable() ...
    • Attributs :
      • String       _test;
      • boolean    _b;
      • int            _i;
    • Projet : com.ensicaen.ecole.gwee
    • Nom de l'équipe : Neo-Galactica
ambi Compte Rendu de Réunion le 25.11.2010

Ajout au cahier des charges :
  • Gestion des transitions necesite :
    • Ecran de jeu
    • Image en Niveau (qui sert de "masque")
    • transition en bouclan sur les niveaux de gris c'est à dire que l'on prend le valeur du niveau de gris, si inferieur, on affiche la valeur du pixel d'arrivée, sinon le pixel de depart.
Puis :
ambi La cahier des charges avance... le 16.12.2010

Le cahier des charges prend forme, les parties 1 et 2 sont bien avancées.

Aujourd'hui nous avons attaqué les parties suivantes

  • 3.1 : Critères indicateurs pour l'acceptation / réception du produit
  • 3.2 : Prototypage
  • 3.3 : Contraintes de coût, délais, ressources
  • 3.5 : Conformité et système qualité du projet
  • 4.2 : Fourniture et livrables

Use Case version 2.0

use case
ambi Refexion sur l'architecture le 03.02.2011

Modèle décomposé en couches pour le moment sous cette forme :

6Weather, Tilemap ...
5Sprite
4SpriteGraphics
3TransitionProcessor, BitmapFilter
2Bitmap
1BitmapData

Qui signifie qu'un Weather contient un(des) Sprite(s), un Sprite contient un Sprite Graphics, un SpriteGraphics contient etc...

Pour ce qui est de BitmapFilter, son somportement est tel que le filtre est appliqué au niveau des classes filles (BitmapFilter est une classe abstraite). Le design pattern Factory Method sera alors utilisé pour cette partie.

SpriteGraphics s'occupe du rendu graphique.

Une couche est forcément dépendantes de la couche inférieur. Difficile de décomposer en packages mais possibilité de développer couche par couche si plusieurs choses sont à faire au sein de la couche. Sinon développer deux couches successives. D'après le diagramme de classe, il est déjà possible de savoir les méthodes accessibles sur des classes.

ambi Architecture du système le 10.02.2011

Aujourd'hui nous avons abordé la structure global du système. Il se base sur l'architecture en couche décrite ci-dessus.

Voici le diagramme ( non UML ) de l'architecture interne de Gwee.

architecture de gwee

Explications

Sprite

Il va contenir :
  • des propriétés de dessin (x, y, profondeur, couleur, alpha ...)
  • un objet Bitmap qui contiendra les données à dessiner
  • des BitmapFilters, objet permettant de créer des effet sur les Bitmap
  • un Viewport qui définit la zone de l'écran dans laquelle il sera visible

Sprite Graphics

Un Sprite va être associé à un objet SpriteGraphics. La classe SpriteGraphics s'occupera de récupérer les données d'un Sprite, i.e ses filtres, ses propriété des dessin, son Viewport, et dessinera le Sprite sur un Buffer.

SpriteManager

A sa construction, un SpriteGraphics devra s'enregistrer auprès d'un objet SpriteManager ( Singleton ).

SpriteManager permettra de stocker toutes les instances de la classe SpriteGraphics. Il garantira l'ordre dans lesquels il doivent être dessiné grâce à un tri préalable.

Comme son nom l'indique, il devra gérer les Sprites. Lorsqu'un Sprite sera détruit, il pourra "emmettre un signal" permettant au SpriteManager de le retirer de la liste afin qu'il ne soit plus dessiné à l'écran.

Transition

La classe Transition effectue une transition entre deux Bitmap selon une méthode spécifique. Cela permettra de créer des effets de fondu entre deux scènes de jeu. ( entre la Scène principale, et la scèene du menu par exemple )

Transition niveau de gris
La transition niveau de gris prendra une image en niveau de gris pour effectuer la transition.
Image précédente :
Image suivante :
Image de transition en niveaux de gris
Application de la Transition :

Stage

Le Stage est la classe ( Singleton ) qui se chargera du rendu graphique global.

  1. Il récupèrera les objets graphiques contenus dans SpriteManager.
  2. Il récupère le Buffer ( objet Bitmap ) de dessin
  3. Dessin chaque SpriteGraphics sur le buffer de dessin
  4. Applique la transition en cours ( récupération d'un Bitmap )
  5. Applique les effets graphiques globaux ( Buffer2 => Bitmap )
  6. Utilise les propriétés de dessin du Screen afin de dessiner le Buffer2 sur la fenêtre.

FrameRate

FrameRate sera un objet qui étant donné une période, un temps de début et un temps de fin, effectuera le calcul du frame rate du système, ainsi que du frame rate moyen.

Cet objet servira principalement, pour ne pas dire totalement, au debogage.

Reflexion sur le fonctionnement des Tilemaps