Summer 11 – Milestone 1

Image hosted by uppix.net

Le projet d’été se poursuit tranquillement. Philippe et moi-même venons d’achever notre première milestone, ou jalon que nous nous sommes volontairement fixé histoire de rester motivé :

  • Désormais le jeu tourne sous une version modifiée de l’IGF, qui ressemble fortement à la version XNA sans SunBurn qui sera bientôt publiée. Résultat le moteur est bien générique et permet de facilement avancer.
  • L’éditeur de niveau est pleinement fonctionnel, et compatible avec ce nouveau moteur.
  • Les bases du jeu sont là : tetris, plateforme, chargement de niveaux.

Maintenant nous pouvons attaquer sereinement le meilleur, le plus important et le coeur du jeu : le gameplay. Il reste quelques inconnues dans le Game Design qui ne manquera pas de nous poser problème très bientôt.

Une petite vidéo montre les possibilités du moteur : caméra 2D, Tetris, plateforme (bon ok ça on ne le voit pas)

Summer 11 – Day 8

Image hosted by uppix.net

On progresse toujours, avec une première milestone définie pour vendredi.

  • Les blocs de Tetris (tétromino) peuvent désormais tourner. La détection de leur collision est au poil.
  • Le code actuel est porté vers un moteur adapté de l’IGF. Ainsi on aura une base propre, solide et bien architecturée.
  • Il nous reste quelques points de Level Design à discuter.

J’ai très rapidement attaquer la création de l’éditeur de niveaux. Il est moche et loin d’être fonctionnel, c’est plus un test pour le moment. XNA + WPF dans la même fenêtre.

Architecture d’un jeu vidéo – Sérialisation des données statiques

Image hosted by uppix.net

Nous venons d’éclater notre architecture hiérarchique en quelque chose de plus fonctionnel. Il est a présent bien plus simple de créer des objets du jeu qui ont un comportement précis et sans fioriture.

Nous allons maintenant nous attaquer au deuxième problème mentionner dans l’introduction : mettre les données statiques dans des fichiers XML compatibles avec un éditeur et plusieurs plate-formes, et pas seulement avec le jeu.

Lire la suite

Architecture d’un jeu vidéo – Pattern Entités (1)

Toujours dans le cadre de mes recherches sur l’architecture logicielle d’un jeu vidéo, je vais vous exposer le modèle le plus simple qui est utilisé dans The Great Paper Adventure.

Communément appelé architecture basé sur les entités (entities-based architecture), elle consiste à définir chaque objet du jeu (une arme, un véhicule, un personnage, un décor) comme une entité.

Bien sûr cela s’adapte parfaitement à la programmation objet : une superclasse Entité, et des spécifications de différents comportements qui en hérite.

A première vue très pratique, et elle l’est d’ailleurs clairement, elle est cependant limitée :

  • La plupart des langages modernes n’autorisent plus le multi-héritage. Impossible donc de définir une classe héritant d’une superclasse « Entité dommageable » et « Entité déplaçable ».
  • Chaque objet dispose donc d’un grand nombre de propriétés, attributs, méthodes, potentiellement inutiles. Une plante verte dans le décor n’a probablement pas besoin des mêmes routines de déplacement, de collision, d’IA, d’affichage que celles de personnages (encore que dans Mario, c’est faux !).

De plus, puisqu’on utilise une classe par objet du jeu, on se retrouve vite avec une grand quantités de classes à gérer, certaines étant probablement très similaires.

Pratique et rapide pour un petit projet (= peu d’objets différents), on pourra donc se pencher vers d’autres architectures pour un projet plus volumineux.

Un exemple d’application de ce pattern.

Image hosted by uppix.net

On voit ici que tous les ennemis doivent bouger. Bien sûr on peut imaginer que leur méthode de déplacement soit « hackée » pour que l’ennemi ne se déplace jamais, mais cela n’enlève rien à la limite de ce modèle.

De même tous les objets ont des points de vie, et une boîte de collision. Encore une fois, certains objets du jeu n’en auront probablement pas besoin et n’utiliserons pas ces propriétés, qui prendront pourtant de la place en mémoire.

Lire la suite : Partie 2 : décomposition du pattern en composants