Ainsi nous n'aurons pas réussi à aller jusqu'au bout de notre projet, la faute à un moteur physique qui ne veut vraiment pas marcher et la reprise des cours.

Peut-être que dans quelques temps nous nous repencheront dessus, mais pour l'instant, c'est en pause.

Pour ceux que ça intéresse (ils doivent pas être nombreux !), voici un lien vers les sources : -> http://www.daytaycay.info/Carton_Slug/0.11/Carton_Slugv3.zip
(Même si Lapinou Fou ne  voulait pas les dévoiler, peut-être qu'un fou furieux essayera de nous aider ? qui sait...)

Je pense que nous avons fait un bon travail du côté de la gestion des fichiers, de l'organisation du code et des objets ainsi que de la documentation. De plus le code est en C++ et contient quelques idées pouvant être généralisées à plusieurs jeux en 2d.

Cela dit l'aventure Homebrew DS ne s'arrêtera pas sur ce demi-échec (demi car nous y avons appris beaucoup, bien que je pensais que l'on serait capable de finir), et Lapinou Fou ou moi-même vous présenteront sûrement un nouveau homebrew un jour, fini cette fois !

Bonne journée =)

Valryon

EDIT : j'ai quand même un peu continué le développement, et je rédige un message sur le forum pour raconter mon expérience. Pour ceux qui ont télécharger les sources, j'ai mis une nouvelle version un peu plus fonctionnelle :
-> http://www.daytaycay.info/Carton_Slug/0.12/Carton_Slugv3.rar

Et je suis en train d'écrire toutes les explications sur le code. Je posterai le lien après =)

C'est notre gros problème du moment d'ailleurs : nous on veut bien croire à la physique de newton, mais notre jeu, lui, refuse de s'y plier...

Nous avons suivi le très bon didacticiel de developpez.com sur les collisions :
http://fearyourself.developpez.com/tutoriel/sdl/pong/partie-4-collisions-ameliorees/

Et nous avons implémenter tout ce beau code dans le notre, en l'adaptant... malheureusement  pour nous ça ne marche pas >< Et pour débugguer, la DS n'est pas très pratique ! (Visual Studio me manque pour cet aspect).

Du coup j'ai essayé de tout recoder, sans les zones, un truc bête qui pourrait suffir dans un premier temps.

Un moteur physique qui se contente d'avoir une liste des éléments présents sur l'écran et le nombre de ces éléments.

A chaque frame on passe chaque objet au peigne fin et on le compare aux autres objets. En faisant des projections sur X et Y (rappelez-vous vos cours de maths de.. seconde ?) on peut déterminer s'il y a collision ou non (nos sprites sont tous carrés cela dit).

Et même ça, ça ne marche pas.

Les caisses chutent jusqu'au sol, mais pas plus. Flûte !

Une journée complète passée dessus hier, c'est rageant et démotivant de voir que rien n'a avancé (j'ai même régressé à force de bidouiller). Je m'accroche en me disant que notre homebrew est ambitieux (même si le concept de base est nul, on sait comment le rendre intéressant. Ce qu'il nous faut c'est.. du temps !) et que nous avons un bon potentiel grâce à nos études et notre culture en jeu vidéo.

Je crois que dans ces cas-là, le mieux est de laisser cette partie de côté et d'en avancer une autre. Dommage que ce soit une partie si importante :(

Mais on y croit toujours !


Dam (Tibo : à l'aide pour le moteur physique ! :p)

Rien de tel qu'une journée devant le même PC à coder (de l'extreme programming à la maison en quelque sorte) à deux pour avancer !

Surtout quand il s'agit de mathématiques : moteur physique et collisions. Nous avons désormais, grâce aux tutos de developpez.com et un peu de réflexion, un truc qui marche presque !

On découpe l'écran en zones, chaque zone contient plusieurs objets qui sont référencés. Quand on cherche si une collision a lieu on regarde seulement dans cette zone et pas sur toute la surface du jeu.

Pour calculer s'il y a collision ou non, on fait des projections sur l'axe des X et des Y et on fait des calculs tout simple.

Mais toute cette bonne théorie... marche pas aussi bien en vrai.

Seule la collision avec le sol marchent plutôt pas mal. La plupart des objets tombent au sol, grâce à l'application de la gravité sur eux. La plupart, certains font de la résistance... Pourtant c'est un calcul tout simple, puisque le sol est représenté par une valeur constante sur Y.

Une fois que le moteur physique sera prêt, il ne nous restera plus qu'à modifier un peu les sprites, ajouter du son et proposer des niveaux pour tester la beta :p

Bientôt !!!

Dam.

Salut à tous!
Vu que fin août arrive à grand pas Damien et moi même avons décidé de se retrouver IRL pour bosser!!! 
alors, à demain soir pour le compte rendu.

C'est vraiment hyper frustrant.

Genre là je suis presque arrivé à gérer des caisses de n'importe quelle taille, composée de sprite de 32x32, référencée dans un endroit facile d'accès et construite à partir des maps générées par l'éditeur mais... mais presque quoi.

Comment gérer correctement des grands sprites ? Par grand j'entends de taille infinie, pas 64x64 ou 128x128. Plutôt 256x192 quoi, un truc pas carré qui prend bien tout l'écran.

La solution que j'essaye d'appliquer n'est pas particulièrement très futée puisque j'ai voulu conserver au mieux l'ancien système de gestion de caisses, c'est-à-dire uniquement des caisses 32x32. Ce système présentait l'avantage d'être simple. Mais comment faire une caisse plus grande, genre 96x96 ? Eh bien certaines caisses ont comme sprite un "bout" de caisse, le coin haut droit par exemple. Si elle est à côté d'autres bouts de caisse, ça donne l'illusion d'avoir une énorme boîte monstrueusement féroce devant soi.

Sauf que pour la physique et même les collisions, c'est nul. On ne sait pas jusqu'où la caisse va. Donc si on en détruit une, seule celle-là tombe. Petit exemple :

          _ _ _                          _ _
         |X X X|                       _ X X|                  
o   -    |X X X|         ->     o     |X X X|
k        |X X X|                k     |X X X|   

Un bout de la caisse s'effondre, le reste n'a même pas conscience qu'il va être pulvérisé. Or nous avons décidé qu'aussi grande soit la caisse, si elle n'a plus de PV c'est sa totalité qui est détruit (comme Half Life premier du nom).

Nous sommes en C++, et comme on est super originaux on a fait une classe "Caisse". Cette classe représente... une caisse ! Avec sa position, son type (bois métal etc), sa vie, ... Et plutôt que de tout repenser, j'ai choisi d'ajouter comme attribut à cette classe un pointeur vers un tableau de Caisse.

Ce tableau contient la liste de toutes les caisses (appelées sous_caisses pour différencier) attachées à la caisse. Oui c'est compliqué, le code est tout aussi fouilli que mon explication qui servira à mon avis plus à Tibo qu'à vous chers lecteurs.

Ainsi, si on reprend la boîte du dessus :

M est la caisse "principale", et X sont les sous_caisses de M. Tout ça forme un ensemble dont on connaît les propriétés, et c'est bien ce qui nous intéresse.

N'empêche que ça ne marche pas...

A bientôt pour un billet pour dire combien mon système est génial et comment il marche trop bien :p

Aller, je lâche une image du menu (Tibo va me gronder !)  :







Pas très sexy, mais fonctionnel ;)
On se fera un vrai logo à l'occasion.

EDIT : Et voilà, mon algorithme marche... Que d'émotions ! Par contre je demande à voir les temps de chargement sur une grosse map :s y'a au moins 40 boucles for/while !

Générer des maps facilement, c'est bien.
Pouvoir les utiliser dans le jeu, c'est mieux !

Comme expliquer précédemment, un des fichiers générés est un header C++ (.h) qui peut être inclus directement au code source. On peut utiliser ce qu'il contient directement là où a été inclus le header. Dans ce fichier, on fait une méthode qui prend comme paramètre un numéro, et on associe celui-ci au niveau grâce à un bon gros switch.



Un truc du genre :

switch(numéro passé en paramètre)
{
 case 1:
  charger le niveau 1 avec tels paramètres
break;

etc
}

C'est d'ailleurs pourquoi pour l'instant il n'est pas possible de créer une map et de l'ajouter dans le jeu sans recompiler : le jeu ne cherche pas sur la carte mémoire la map, elle est directement dans son code source et il faut l'ajouter à la main. Question de vitesse à l'exécution, et de simplicité pour nous à coder.



Le chargement de la map consiste à lire le contenu du header et de générer ce qui nous intéresse en fait : une liste des caisses à afficher et à traiter. Beaucoup de boucles "for", un algorithme bête et méchant.

Une fois qu'on a ce tableau (qui est un attribut de la classe où est chargée la map), il faut afficher ce qu'il contient en fonction du contexte.
Ici le contexte, c'est le Parallax. Ce dernier utilise une variable pour le scrolling, qui représente la position où il est arrivé.
A chaque frame, on va donc examiner toutes les  caisses et déterminer si elles sont sur l'écran (cad si leur position horizontale - le scrolling est entre 0 et 256, taille de l'écran). Si elles le sont, on les affiche !

Et ça marche pas mal. Sauf que quand je supprime une caisse (PA_DeleteSprite), le personnage disparaît... Et qu'il va falloir trouver une solution pour limiter le nombre de caisses en mémoire sprite, et ne pas mettre 50 sprites de caisses en vue quand seulement 10 sont utilisés...

Une bonne avancée, on approche du but...

Release fin août ! Le temps passe vite !

Pour gérer plus facilement la création de niveaux, nous avons eu l'idée de créer une interface pour les créer et les exporter de telle manière qu'ils puissent être utilisés dans le jeu.

Le langage C# avec Visual C# est très pratique pour ce genre de tâche. L'interface se crée tout à la souris (ou presque), il "suffit" ensuite de coder les fonctionnalités derrière les jolis boutons.

Voici à quoi ressemble l'éditeur dans sa version actuelle :

Oui, ce n'est ni très joli ni très ergonomique. Mais cet éditeur n'est destiné qu'à nous, puisque les maps sont à inclure dans le code source à la compilation...

Revenons un peu sur le fonctionnement des maps que l'on a adopté. Une map de Carton Slug (au niveau du jeu, sur la NDS) est un grand tableau qui contient des entités "Caisses" possédant des propriétés évidentes comme : position x, y, points de vies, etc.

Pour rendre le jeu plus intéressant, il y a différents types de caisses : métal, explosive, donneuse de bonus... Une autre donnée à gérer par l'éditeur.

Il fallait que l'éditeur soit un minimum visuel. Or ce n'est pas facile de programmer un truc où il est possible de faire glisser les éléments pour placer où on veut... Du coup pour le moment, la map est découpée en case de taille et position fixe et en quatre lignes horizontales. On place donc les caisses comme on veut sur ces cases.

L'astuce est qu'une case ne correspond pas forcément à une caisse, sinon on serait limité à des petits caisses de 32x32. Or nous voulons pouvoir faire une grande caisse qui prend tout l'écran si cela nous chante ! C'est pourquoi une case peut contenir un "bout" de caisse, qui est en fait un sprite qui représente seulement une partie de la caisse (le coin supérieur gauche par exemple).
A programmer, c'était répétitif car il a fallu ajouter tous les types (6), et toutes les parties possibles pour chaque type (au moins 6 à chaque fois)...

Une fois la map créée, on la sauvegarde. Cette action a pour but de créer deux fichiers : un ".carton" qui contient des données simples pouvant être chargées dans l'éditeur, et un ".h" qui doit être inclus dans le jeu.

Ainsi on a par exemple :

Ce dernier fichier reprend la syntaxe C++ de tableaux à une dimension. Une méthode permet ensuite de traiter toutes ces données pour construire le niveau comme il faut.

Enfin en théorie, c'est précisément où est arrivé le développement pour l'instant du côté de la gestion des niveaux :P

A bientôt pour de nouvelles aventures !

Dam, Carton Slug developper

Re-bonjour,

Voici un petit historique et état des lieux du projet à l'heure d'aujourd'hui.

Le projet est né d'idées farfelues pendant un cours ennuyeux, fin 2007.

Il est temps d'expliquer le concept du jeu : Dans Carton Slug, vous incarnez un personnage de Metal Slug (Marco pour le moment), et vous devez le faire sortir d'un niveau remplie de caisses destructibles ou non, explosives, en utilisant diverses armes tirés des jeux de SNK. A la fin du niveau, un Boss à vaincre vous attend. Un autre mode de jeu vous proposera un autre moyen de sortir : à dos de missiles ! Le tout contrôlable au stylet pour ce mode (pad sinon).

Après un premier contact avec la programmation NDS, et surtout la PALib, une première version a été developpée avant que tout motivation soit achevée par le manque de connaissances en programmation de jeux, tant en 2D qu'en gestion d'un moteur physique.

Le temps passe et les versions de PALib évoluent. Les nouvelles fonctions et les retouches de celle-ci, auxquelles s'ajoutent de nouvelles idées pour le projet  et une motivation renaissante ont fait que nous avons recommencé à zéro la programmation au début de l'été 2008.

Après une nouvelle version (avec Paralax, tirs, déplacement du personnage), de nouvelles limites ont fait leur apparition et l'utilisation d'un langage objet compatible PALib (C++) au lieu de C ANSI a vite été nécessaire.

Passer au C++ a nécessité de tout reprendre à 0 encore une fois. Mais avant de coder, un peu d'analyse ! On commence avec un petit diagramme des classes (pas du tout aux normes UML) et quelques connaissances sur comment coder des jeux en règle générale acquises sur les forums et FAQs de developpez.com :



Cinq classes principales : Son, Affichage, Réseau, Input et Physique servent le moteur du jeu.
D'autres classes concernent les entités du jeu, qui seront affichées / utilisées.

Le reste est le jeu à proprement parlé.

Depuis bientôt deux semaines nous utilisons ce modèle pour coder, et il faut avouer que l'objet est une aide incroyable (surtout pour des habitués du Java).

A celà il convient d'ajouter la gestion des versions (un peu à l'arrache, mais on fait très attention) du projet sur un FTP. Nous utilisons le Template PALib et à côté (hors du dossier Template) nous avons tout nos médias, sprites prêts à être transformés par PAGFX, etc. On gère donc très facilement nos fichiers.

Le projet a pris un sérieux coup de fouet qui, j'espère, va continuer !