Metroid Prime : Némésis (démo 2.9 : 7/6/2012)

manque de chance, ca veux pas ce telecharger :/ (je testerai plus tard)
maintenant... pour le poids de l'archive, je crois que la... je pense qu'il y a autant de dlls qu'il y a de pixel sur l'ecran de jeu :/

Je vous présente un début de démo.
Aujourd'hui deux bugs présents dans celle-ci sont corrigés :
- le petit arrêt quand on approche de la plateforme en tombant dessus ;
- la possibilité de ralentir son saut en relâchant la touche Up lorsque le personnage tombe.

De plus, un systèmé de mapping (avec un seul bug détecté qui plombe tout) est commencé : il y a possibilité de créer des cartes.

www.host-a.net/u/l0lmanPH/mpn_demo.zip
P.S : Lorsque je changerai la version de démo, elle sera accessible au même lien, cela permet aux visiteurs de tout le temps tomber sur la bonne.

il y a aussi un bug de tir : lorsque je viens pour tirer vers la gauche du perso, il prend la direction de droite (et inversé comparé à la gauche)-> c'est un probleme de trigo, regarde bien ta fonction pour tirer
maintenant, ton deuxieme bug est simple a gérer ! tu fais que si le joueur descent (à cause de gravité) tu n'execute pas la fonction dans l'evenement "relacher le bouton UP".
Le premier bug y est aussi dans GM, je ne sais pas comment le résoudre sans le code :/

en tout cas, le moteur a l'air bien construit ! encore deux/trois trucs et le jeu se fera tout seul !

J'avais aussi vu le bug de trigo, je l'ai déjà eu avec Genie Cereal Killer et je le réglerai aisément. ^^

Mais j'ai déjà corrigé les deux autres bugs !
Tu as raison il s'agissait de tester la vitesse verticale pour le release. Ensuite pour l'autre "bug" c'est la fonction de collision qui calcul en fonction de la vitesse verticale, et donc à ce moment là on arrêt le perso et on le colle à la plateforme, comme j'ai fait dans la nouvelle démo à venir !

En effet, une fois un bon moteur codé, le programme s'écrit tout seul. xD

Bon, comme mon dernier message date et que je suis tenu de pas vous tenir dans l'ignorance, voilà quelques nouvelles.
Pour nous, considérez que "no news is good news".

Concernant le forum... il y a beaucoup à dire, nous l'avons amélioré en fonction de vos commentaires et des imperfections faites remarquées par d'autres.
- Nous avons changé le background par un plus clair (mais moche), avec un effet mosaïque (moche également).
- Le bouton "téléchargement" fonctionne maintenant, est moins bogué visuellement sur tous les navigateurs et mène donc bien à la page de téléchargement (au cas où le lien direct est en infobulle).
- Pour les utilisateurs d'Internet Explorer (bouh), une alerte est affichée sur l'index ainsi qu'un message de type "attention" sur toutes les pages, vous prévenant que la navigation sur le forum est "perturbée" par l'interprêtation douteuse du code par le navigateur.
- Les menus sur l'index pour la plupart inutiles ont été retirés, et limités au nombre de deux (qui sont de petite taille) : "Profil" et "Navigation".
L'ergonomie du forum a donc été revue et convient normalement aux petites résolutions (les téléphones portables devraient s'en tirer).
- Le contenu même du forum a été trié, classé, etc. Nous avons fusionné toutes les catégories qui concernaient la présentation (Présentation, Recrutement, et une nouvelle : Partenariat) en une seule, à cause de problèmes de navigations (certains membres ne
comprenaient pas bien le système). De plus la présentation n'est plus obligatoire pour les membres simples.
- Le code en général a été amélioré, le forum est normalement plus rapide à charger (2-3 détails ont été changés).

Le jeu, le jeu !!!
Eh bien il avance, la démo 3.0 (oui grands changements) est en bonne voie.
Quelques bugs dont celui de la direction de tir (mini-problème du à un inversement de deux arguments de la fonction trigonométrique...) ont été fixés.
Et maintenant le plus intéressant... Le système de tuilage, qui constitue l'intégralité de la gestion des niveaux ! Comme annoncé sur Facebook (pour ceux qui suivent), un éditeur de niveaux arriiiive à grands pas ! (Vous l'entendez ? Tagada tagada...) Il permet - à partir d'un fichier - de générer une carte avec longueur d'une ligne paramétrable, et tiles (les images qui la constitue) aussi personnalisés. Je n'en dis pas plus sur ce point parce-que... je veux ménager votre suspense !

A ce propos, nous cherchons toujours des LEVEL DESIGNERS !

Voilà, c'est tout pour cette news de transition.

P.S : Onilink va avoir une sensation de déjà vu. x)

Bon allez je vous donne un screen vous montrant un iota d'une parcelle d'un peu de l'aperçu entrevu (en JPEG sinon c'est pas marrant :-°) : .

J'ai fini d'implémenter la possibilité de paramétrer les tiles via le fichier .map et de coder la ligne avec des 0, 1, 2, 3, 4... en conséquence ce soir (cette nuit en fait...) !

Les images sont de moi (non pas de copyright ^^).
Au moins vous avez du concret là.

See you next news!

Tu t'amuse bien a ce que je vois. En tout cas prend bien soin de ton systeme de carte, c'est très important et vaux mieux faire un truc super optimiser direct, histoire de pas avoir a ce retaper tout le boulot.

Ouais ouais c'est même la grande réunion des sages sur le forum. Je fais plein de topics dans "Programmation" pour prendre les bonnes décisions.
Parce-que le mapping c'est plein de choses : les collisions, tile = objet ? des tilesets ? etc., et euh. les maps LOL. xD

Bon je viens d'ajouter une commande qui permet de mettre un background perso (plus tard je ferai un objet background qui permettra de le répéter, le faire bouger blabla).

Et là je m'attaque à l'éditeur de maps lui-même (GUI, parce-que modifier dans le fichier direct c'est pour les programmeurs fous, et pis' de toute façon ils seront cryptés, pas envie de faire plein de tests de sécurité), enfin je dois d'abord faire du travail I.R.L (grumpf).

Chez moi il y a une console qui se lance et il ne se passe rien (je suis sour w7 64bits).
Sinon GG et la SFML à l'air d'être une très bonne librairy (je viens de tester et je vais l'adopter).

Ah oui j'ai compilé sous un 7 32bits.
Ca devrait quand même marcher non ?

Enfin à l'avenir j'y penserai, merci de l'avoir fait remarquer, et désolé.

Bon choix pour la SFML.

La sortie de l'éditeur de niveaux sera retardée.
En effet, j'en recode la majeure partie afin qu'il offre plus de dynamisme.

Actuellement, les blocs sont placés en fonction de leur index dans le tableau (coordonnées du genre i * TILE_w ; j * TILE_H) et sont donc condamnés à une éternelle immobilité : il est impossible par exemple de faire une plateforme mouvante avec ce système là.

Et pour faire un outil de glisser/déposer comme je le prévois, il aurait fallu faire une manipulation complexe pour rien (écraser les index "survolés" en copiant les valeurs une par une).

Chaque tile aura donc ses propres coordonnées, ce qui change un peu la manière dont est fait le fichier .map.

J'en profite également pour créer de nouvelles classes comme Background (avant .map contenait ses attributs).

4 mois ?
Oh, le temps passe... vite.

Je n'ai pas vu le travail I.R.L me tomber dessus alors qu'il était déjà trop tard, les news ont donc été mises de côté. Ce qui a fait que la majorité du STAFF a baissé le rythme de travail pendant une partie de cette longue période ; toutefois nous avons récemment mis en place un système qui veut que même en temps de "crise" chacun ait un petit quelque-chose à faire - même très simple - et travaille plus régulièrement (dès que possible), ainsi même si je ne peux avancer de mon côté (en grande partie programmation/ergonomie) je peux donner à faire.
Désormais, je considère qu'il s'agit d'une priorité et ferai en sorte de donner des nouvelles au moins une fois par mois.

Mais enfin...

Nous voilà de retour.

Pour vous prouver que le screen d'un des news précédente n'est pas un montage bidon réalisté avec Paint, enfin un éditeur graphique ; voici une première version de l'éditeur de niveauuuux !

Aujourd'hui-même a été entre autre la rotation des tiles et le zoom/dézoom (vous pouvez les imaginer pour compenser).

Avant de faire une quelconque démo (bonne nouvelle : avec de vrais sprites faits maison, peut-être définitifs), je m'empresserai de donner une version stable de l'éditeur à l'équipe.
En effet, DarkHunter17, un membre récent, génère une map tous les deux jours, à ce rythme il n'aura vite plus rien à faire ; je peux encore retarder cette échéance.
Par ailleurs ce programme ne sera pas public jusqu'à ce qu'il se dote d'une interface, soit plus "robuste". Si on le réclame beaucoup il sera fourni avec la démo qui arrive ou la suivante, afin de s'amuser (Samus... é) sur ses propres cartes.

En parlant du staff, je suis heureux qu'on trouve encore le projet malgré l'absence de messages récents.
D'ailleurs, 2 visiteurs (pas nécessairement inscrits) du CBNA - Crowba et DRAKOMEGA, l'ont miraculeusement trouvé et sont tous deux pixel artists (je t'aime la fonction "recherche").

Le forum se dotte d'une bannière pour le projet (voir ici : [url=http://metroidprime4.xooit.fr/index.php]http://metroidprime4.xooit.fr/index.php[/url)]. Concernant le site (LE VRAI) je ne sais pas quand je vais m'y remettre.

Voyons... Le scénariste (Keliaran) continue a faire l'OST de MPN (Metroid Prime : Némésis) - d'ailleurs on vous fera écouter une musique un de ces jours - et a planché sur les scénarios de trois autres jeux (dont une TRILOGIE) qui ne seront pas des fangames (= argent =D ?).

D'autres faits qui pourraient vous intéresser ont certainement survenu et j'espère en avoir oublié peu.

Pour éviter de partir sur cette dernière phrase, je vous laisse admirer un sprite réalisé hier par DRAKOMEGA :

Ce n'est pas encore fini.
Petite précisions :
- les cheveux qui dépassent seront désactivables pour des raisons de "logique" ;
- le style graphique : on prend une échelle de taille de 1.5 par rapport à Metroid : Zero Mission en utilisant des couleurs plus "réalistes", du moins en évitant ce qui est uni et vif.

Vous avez certainement des questions : BALANCEZ-LES.

4 mois pour cette editeur de niveau, ca fait long.
et au niveau du jeu Metroid Prime Nemesis, ou est ce que ca en est, parce que la on a que l'editeur de niveau.

En fait ça fait 4 jours pour l'éditeur de niveaux.
Le reste du temps, il s'agissait soit de s'occuper de la vie réelle soit du character design, de la jouabilité, ...

Du côté de MPN, avant cette période et même encore avant, peu de temps après le prototype 2 (un carré bleu sur une plateforme grise) ; la gestion des cartes, de la musique, la possibilité de mettre le jeu en pause (wah), et la correction de 4 bugs (stopper la chute une fois, frottement à l'approche du sol à une vitesse élevée, sprite du tir invisible, direction du tir erronée) ont été apportés.

Nous maîtrisons mieux la SFML ainsi que le C++ en général, et avons appris à utiliser Mercurial (j'en profite pour ajouter cette info), un SCM décentralisé. Un dépôt a été créé sur un hébergeur et dès que la priorité redevient la démo, alors le code sera poussé là-bas.

houuu c'est bourré de pillow shading, la palette est complètement dés-saturé et on se croirais dans wind waker (petites james grand corps)

Sinon pour l'éditeur de level je vois pas l'intérêt des fonctions pour la rotation et le zoom des tiles, mis a part que les cartes seront bien plus lourdes en mémoire, et en fichier..

Entk j'attend toujours quelque chose de joueable moi

Oui le corps de Samus est trop grand.
Finalement j'ai choisi le mauvais sprite xD.

La carte plus lourde en mémoire ?
Pour le zoom certainement pas, quand tu utilises la loupe sur Paint un éditeur graphique le fichier ne grandit pas en mémoire, la rotation évite que l'on utilise 4 fichiers pour le même tile mais tourné, ou simplement ça permet de faire des plateformes tournantes...
Le moins lourd aurait été de coder le fichier de la map en binaire et de charger tout ça dans un tableau à 2D ; toutefois un système un peu plus demandant en performances et en mémoire (c'est vraiment peu...) vaut le coup pour avoir plus de possibilités d'interaction, on fait pas un Pacman !

Je ne suis pas d'accord pour les tailles du fichier, un fichier .map (les tiles étant séparés, ainsi que le background) pèse vraiment rien (pour l'instant ils font tous 1ko, pour jusqu'à 50 tiles).
De plus, avec la rotation, ça évite de créer des copies tournées de fichiers, donc ça réduit la taille totale de ceux-ci, sans compter que c'est plus flexible et moins années-90.

Vous l'aurez, le jeu x).

P.S. : Une autre image, toujours de DRAKOMEGA.

Pas très dynamique le sprite je trouve, je pense qu'il peut être bien de s'inspirer de l'aspect graphique des Megaman (même si ça risque d'être dur d'atteindre leur qualité :p )

Drako fait une animation du sprite de Samus que je vous ai montré juste avant, peut-être sera-ce moins "robotique", enfin figé.

Cette image est mieux oui.

Sinon 1ko pour 50 tile, c'est très très lourd. Une map a peut près normale devrais prendre plus de 50ko alors que 6ko devrais suffire avec un système plus optimisé.
De plus je sais pas si t'est au courant, mais faut bien différencier le décors (statique) et les instances (dynamique). Donc des plateformes qui tournent c'est pas des trucs du décors.

Enfin je dit ça parce que j'ai étudié le système de cartes de pleins de jeux professionnels 2d, notamment les pokémon, zelda et metroid, et ils s'y prennent vraiment pas du tout de cette façon.
Après si t'est un adepte de GM bien sur qu'on peut s'en foutre de l'optimisation
(je t'enquiquine hein ? haha)

Le fichier .map contiendra le "décor" et les "instances".
Ces dernières seront des tiles que des contrôleurs s'occuperont de bouger.

1ko pour 50 tiles...
Si tu veux vraiment une valeur je vais voir jusqu'à combien je peux en mettre, ce chiffre n'est pas la valeur maximale !
Au niveau des fichiers je vois mal comment je pourrais optimiser plus... Tu pourrais me donner une "structure" qui selon toi conviendrait ?
Et puis on va pas chipoter pour quelques octets -_-...

L'optimisation ? Je fais ce que je peux, pour l'instant je sais qu'il y a mieux à faire mais si vous voulez une démo il faudra remettre ça à plus tard.
Ne dis quand-même pas que je n'en ai cure, chaque variable est déclarée avec soin, avec le type le plus adapté possible (selon moi) ; je n'utilise qu'un seul sprite pour l'affichage, ...

Désolé du double-post.

Pour 100 tiles et deux images ça donne environ 2ko.

Mais c'est totalement aléatoire, tu peux avoir la moitié de tiles avec 50 images différentes et le fichier pèsera plus lourd (sauf si les noms des images ne sont faits qu'à partir d'un caractère).

D'un autre côté tu peux avoir des grosses images de plateformes (ce qui fait un tile, avec le système que j'utilise il n'y a pas de grille, les coordonnées sont absolues et ne dépendent pas de l'index dans le tableau) qui font la moitié d'une vraie map, et tu te retrouves avec 2ko pour une map qui avec ton système ferait 6ko avec ton système plus limité.

Je ne considère pas ma façon de faire comme mauvaise, loin de là...

J'aime bien de faire râler ctou, pis ton système est pas assez optimisé pour moi

Pour te donner un exemple, les maps de Pokémon (gba) fonctionnent de cette manière (je me souviens plus exactement :/ par contre) :
1 octet et demi par case. (pas sur, mais pas plus de 2octets)
4 bits pour le type (vide, solide, rebord, eau, etc)
8 bits pour les données du tile. Et les cartes utilisent deux tileset (spécifiés dans le header) (la par contre je suis pas sur du nombre de bits. Faut que j'aille vérifier ça)
Et tu vois que les cartes Pokémon ne manquent de rien, et sont extrêmement légères.
Après le système d'instance est a part, et non matriciel.

Comme tu vois le système est très simple et très bien foutu. (même si j'ai oublié trop de détails...)

Attention à me faire râler tu ne gagneras que des spams remplis de D&D.

Je serais curieux de voir à quoi ressemblent les fichiers eux-même.
En tout cas :
1. ok c'est bien foutu, mais c'est aussi Pokémon → professionnel → expérience + staff ;
2. leurs tiles sont emprisonnés dans des cases de taille fixe ;
3. Pokémon est avant tout un RPG, vu de haut, où cette manière de faire suffit ; alors que non pour nous ;
4. il n'y a PAS de 4.

De même pour le sprite, ça vaut pas Megaman mais c'est pas mal pour un travail de quelques heures, fanmade, et ça a le mérite de ne pas reprendre les sprites de Fusion/Zero Mission utilisés dans 1 billion de fangames.

Bah attend je vais essayer de retrouver les structures de données utilisées dans Metroid Fusion comme ça t'auras rien a redire

MPN est prévu pour être plus interactif.

Tu m'excuses, les tiles ont pour seules données : la position, l'index de l'image utilisée, la rotation (en short), et bientôt le calque (enfin la couche).
Ou sinon je fais un tableau de tableau de X index pour X calques et c'est réglé plus d'attribut layer...
Peut-être même ajouterai-je un attribut scale.

De toute façon, à la fin, les animations seront gérées à part.
Ce n'est que temporaire, toutes ces variables en vrac bien emballées dans une structure.

Il y aura toujours moyen de faire mieux plus tard, on se consultera avec les autres développeurs ; et si tu as mieux à proposer oni, je veux bien voir .
C'est le premier jeu d'un studio amateur, qui sera tout de même en C++ donc plus performant qu'avec le Game Maker actuel. Il pourra l'être encore plus si on se débarrasse de la SFML qui - bien qu'elle soit pratique - nous oblige à créer entre autres des attributs en doublon et à certaines fois faire des étapes inutiles.

l0lmanPH a écrit:

MPN est prévu pour être plus interactif.

Tu m'excuses, les tiles ont pour seules données : la position, l'index de l'image utilisée, la rotation (en short), et bientôt le calque (enfin la couche).
Ou sinon je fais un tableau de tableau de X index pour X calques et c'est réglé plus d'attribut layer...
Peut-être même ajouterai-je un attribut scale.

Bwaaa mais quelle horreur xD
Ça te parle si je dit matrice ?


Sinon je me demandais, votre jeu seras completement différent de fusion ou zéro mission ?
Parce que sinon y a le rom hacking.

D'ailleurs si tu veux récupérer les tileset originaux, les cartes et autres t'as le logiciel de romhack doublehelix :
http://www.zophar.net/download_file/21281

Vraiment excellent, tu peut refaire un métroid complet juste avec ça en modifiant ou zero mission ou fusion.
Y en a un pour super metroid aussi si je me souviens bien :p

(D'ailleurs observe bien comment les cartes sont foutues, ça ne te seras que bénéfique)

NON PAS DE MATRICE. Ne me suis-je pas assez clairement exprimé x( ?
Le précédent système fonctionnait ainsi ; c'était moins lourd mais offrait moins de possibilité, par exemple celle de stocker des tiles de taille variable.

Oui il sera différent. On ne va pas juste changer les sprites les tiles et les maps, lol...
Hors de question. Même si on aurait pu le faire, étant donné que DarkHunter17 en faisait déjà avant.
Je ne pense pas avoir détaillé l'aspect gameplay dans les news, vous pouvez me questionner si ça vous intrigue.

Boh moi j'attend de voir. Mais si les jeux sont constitués comme je te dit c'est pas pour rien.

En tout cas j'attend de voir ce que ton système "plus souple" donneras, et surtout si le jeu sortiras un jour lol.


Bon moi je retourne bosser sur le moteur pour le concours de design.
D'ailleurs j'en pleure presque de faire ça avec GM tellement qu'il est lent.
J'ai été contraint a ne pas utiliser d'instance et faire mon propre système sinon je me retrouvais avec du 30 fps xD

Bien évidemment que le jeu sortira un jour...
...
...

On a pas passé deux ans pour rien sur la conception, naméoh.
Faut pas croire, même si on débute on est motivés et sérieux.

Ouai enfin s'il sort dans 10ans pas sur que je me souvienne d'y jouer lol