Blabla général Making

Bah merde, à 25 ans tes parents t'ont retiré ton PC ? x)
Tu as essayé le dialogue ? :p

Qu'entends-tu par machinima racontant une histoire ?

Ouais, moi aussi ça me troue le luc comme dirait Cartman, je pige pas. Nan j'ai pas négocié c'est pas mon genre, j'obéis :s , bref...
Une histoire utilisant RPG Maker, sans possibilité d'y jouer n'y d'interagir avec, juste celle de la regarder.

Citation :

Ouais, les ini se lisent très bien sur GM. Même n'importe quel fichier texte mais les ini sont structurés, donc déjà de base c'est rapide à lire en effet et GM a même des fonctions dédiées à ça ^^

Bon bah c'est cool, je sais pas trop encore quand je compte me pencher sur le Metroidvania mais c'est clairement un genre de jeu que j'ai envie de faire un jour (j'avais même commencé un Metroid ya longtemps, mais j'ai perdu les fichiers. J'avais fait une zone plus ou moins complète, c'était sympatoche ^^)

Après le must c'est le XML, mais MMF galère pour les lire...
Ahah bon courage en tout cas si tu te lances dans ce genre de jeu, je suivrais ça de très près !

Citation :

Cool !
Donc en gros on voit où on est car la salle est d'une couleur différente ?

Ahh non la salle de couleur différente c'est pour marquer des endroits clefs, par exemple les salles de save et teleport. En fait là le logiciel te fournis juste un fichier ini qui contient toute tes rooms, après c'est à toi de l'exploiter dans ton jeu ^^
Perso ça donne ça avec Inexistence :


Mais effectivement vu que chaque room est gérée par un ID, tu peux in game faire en sorte que la salle ou tu te trouves sois d'une couleur différente, là dans mon cas j'ai rendu chaque room grisé (pour dire qu'on ne les a pas encore visité), et j'ai fait en sorte que celle ou tu te trouves soit éclairé en blanc.
La meilleur méthode aurait été de gérer directement la minimap via des calculs en fonction de ta map, mais c'est d'un level trop haut pour moi :P

Bon retour Caulfield1995 ! Et pas de chance pour tes parents, c'est vrai qu'à 25 ans c'est étrange, mais j'imagine qu'ils ont leur raisons :P

Ouais c'est ce que je me disais pour le positionnement plus précis. Je fais pareil avec FRQ, je montre juste la zone.

Mine de rien dans ces vieux jeux SNES, ils avaient quand même un positionnement précis, qui reste assez dur même aujourd'hui à faire sans perdre beaucoup de temps. Je me demande quelle technique ils utilisaient pour que ce soit optimisé.

Citation :

Mine de rien dans ces vieux jeux SNES, ils avaient quand même un positionnement précis, qui reste assez dur même aujourd'hui à faire sans perdre beaucoup de temps. Je me demande quelle technique ils utilisaient pour que ce soit optimisé.

A vrai dire c'est pas si dire, j'avais commencé un système du genre :
- Il faut commencer par créer sa minimap en fonction de la map, suffit juste de créer un réctangle x100 plus petit par exemple
- et la tu places un marqueur, qui se positionne à celle du héros mais /100, de ce fait, le marqueur se placera exactement sur ta minimap ou se trouve le héros.

(c'est une vulgarisation du truc évidemment :P)

Le problème il est surtout qu'il faut gérer ses maps d'une façon particulière, et avec MMF c'est un peu complexe...

Oui je vois.

Je me demande si ces mini map étaient des fois automatiquement générées via les maps in game. Histoire de ne pas à avoir à retoucher la mini map dès qu'une ajustement est fait in game.

C'est pas un retour lol, je suis sur un PC de la fac là lol
normalement on me rend mon Précieux ce week-end :/

Citation :

Je me demande si ces mini map étaient des fois automatiquement générées via les maps in game. Histoire de ne pas à avoir à retoucher la mini map dès qu'une ajustement est fait in game.

Je suis persuadé que oui en général, mais j'imagine que ça doit changer en fonction des jeux ^^

Mais ouais, ça intéresserait des gens un "film" fait sur RM ? Par film j'entends qu'on aurait aucun contrôle sur l'histoire (comme dans tous les jeux vidéo en somme) ni sur quoi que ce soit d'autre, on pourrait juste quitter le programme et le lancer au début.  

Pour la minimap oui c'est assez simple a faire si c'est fait de façon intelligente et prévu depuis le début, surtout pour un jeu par Tiles.

Il suffit au final d'afficher la map au survole a une échelle réduite et stylisée.

Pour les films sur RM, personnellement ça ne m’intéresse pas trop, je saluerai la performance mais quite à voir un film, je préfère voir un truc bien fait et ne pas me préoccuper de l'outils de création et simplement lancer un .avi ou un .mkv sur ma télé ^^

Si je joue à un jeu RM, c'est pour jouer et pas juste pour regarder.

Ce que tu veux faire s'appelle plus communément un Visual Novel.

Tout dépend du niveau de finition proposé.
Au pire, fais une intro de 5 minutes et montre la.

Cela dit, je pense que ce serait bien mieux de, au moins, proposer des choix pendant l'histoire.

Ah ouais pourquoi pas, merci ^^


J'ai fait ça à la va-vite... normalement c'est censé être un personnage de l'histoire.

Relm a écrit:

Ce que tu veux faire s'appelle plus communément un Visual Novel.
[...]
Cela dit, je pense que ce serait bien mieux de, au moins, proposer des choix pendant l'histoire.

A ma connaissance, les visual novels proposent généralement des choix dans l'histoire et sont sous forme d'images fixes (avec éventuellement des animations très minimalistes de personnages en premier plan). Un "visual novel" sous forme de jeu avec lequel on ne peut pas interragir (mais avec déplacement des personnages etc) je ne pense pas avoir déjà vu ça ailleurs.

Personnellement, tout comme Haru, je suis un tout petit peu sceptique sur le concept en ayant connaissance des limitations de RPG maker, j'ai du mal à voir comment on peut immerger le joueur dans l'histoire et l'univers et lui communiquer des émotions... Mais tu nous prouveras peut-être que c'est possible.

Pour avoir testé Orange Salvifique (6 bonnes heures et peu de gameplay), c'était un peu usant à la longue. Du coup je suis aussi sceptique sur le fait de ne rien faire.

Sinon en parlant de visual novel ça me rappelle que j'avais commencé un moteur de jeu de type livre à embranchement. Faudrait que je me repenche un peu dessus

6h pour un visual novel très peu accès gameplay c'est abusé...

Ceci dit je pense que ça reste une expérience intéressante (qu'on n'est pas obligé de faire d'une traite grâce aux sauvegardes heureusement).

Bah, ce serait comme regarder un film, en fait : en principe ça se regarde d'une traite ^^
A la limite découper l'histoire en petits épisodes, ça peut être mieux.

Sauf que dans les films tu peux retranscrire beaucoup plus de choses qu'avec RPG maker, avec différents plans de caméra, une animation beaucoup plus précise et détaillée (mimiques des personnages), tu peux par exemple rendre un passage où deux personnages se regardent sans se parler pendant un long moment très intéressant dans un film que tu ne peux pas reproduire sur RPG maker.

Pour rendre une "vidéo" rpg maker intéressante il va falloir trouver un scénario très original et accrocheur et, comme le disait Relm, un niveau de finition élevé et ne pas lésiner sur les animations, l'effet sonore...
Mais si tu es vraiment motivée pour le faire, surprends-nous !!

Waouh, hier il m'est venue une idee assez curieuse : un survival-horror du point de vue de l'antagoniste du scenario..
en gros on dirigerait un riche chercheur reclus sur son ile et s'adonnant a des experiences a l'ethique douteuse... sauf que ses creations (intelligentes pour la plupart se revolteraient), un peu comme le Docteur Moreau.

Je suis en train de coder un petit Zelda-like et je me pose quelques questions sur la méthode de collision utilisée dans les Alttp (SNES) et Link's Awakening (Game Boy) (ainsi que par les Oracles qui utilisent le même moteur donc). En effet je n'ai pas l'impression que le jeu utilise un moteur "physique" (newtonienne avec vitesses, forces de réactions...), en partie car cela aurait sûrement demandé trop de calculs à l'époque, que certains détails font penser le contraire (la vitesse en déplacement diagonal est égale à la somme des vitesses horizontales et verticales par exemple) et tout simplement car ce n'est pas dans la "philosophie" de Nintendo (peu d'intérêt pour un système réaliste, l'important est que ça réponde bien et soit fun).

Hors un simple système d'hitbox (AABB) qui invalide les déplacements en collision avec le décor ne donne pas le même résultat. Par exemple il ne reproduit pas ce genre de comportement (très utile pour passer dans les endroits étroits) :


J'ai lu plusieurs sources sur le net (ici et là par exemple) qui parlent d'un système de hotspots (points de collision plutôt de boites de collision) pour détecter ce genre de cas de figure. D'autres parlent d'un découpage des tiles en 8x8 pixels, ce qui me semble effectivement plus cohérent que 16x16 (notamment car certains assets graphiques sont effectivement en 8x8, comme les bordures de Link's Awakening). Enfin il y aurait apparemment un trick dans le premier Zelda (NES) qui ferait que lorsque l'on change de direction, le jeu nous réaligne sur la grille de 8x8 pixels (mais ce trick n'est plus présent dans Alltp ou Link's Awakening).

Vu que certains d'entre vous s'y connaissent beaucoup sur la série, ou ont déjà programmé ce genre de jeu, ou ont beaucoup utilisé ZQuest, je me demandais si vous auriez des informations ou un avis là dessus ?

Zquest découpe chaque tile de 16*16 pixels en 4 pour ce qui est des collisions.
Et je pense qu'il y a très peu de réalignement (clairement moins que sur ton gif).
J'imagine que le réalignement se fait seulement quand tu es bloqué par 1-2 pixels.

Je ne sais pas ce que vaut cette réponse (utile ou non, vraie ou non), mais je transmets. Je m'attends à en avoir une deuxième de la part de quelqu'un d'autre.
Cela dit, coco, tu peux aussi répondre là-bas : http://famas.majz.com/t42-Les-trucs-de-making-en-vrac.htm?start=1155#p49530

Nemau a écrit:

Concernant le découpage des tiles, oui, pour avoir bien étudié les graphismes de LsA (noir et blanc) je suis certain que le chipset est fait de tiles en 8*8 et qu'ensuite le jeu recrée un second chipset "virtuel" de tiles en 16*16 à partir du premier chipset (gain de place dans la mémoire). Pour ALttP j'en suis moins sûr mais je pense que ça fonctionne également ainsi. Pour ALttP toujours il semblerait, contrairement à LsA, que pour certains tiles le système de placement soit en grille de 8*8, pour les rochers (16*16) dans l'eau par exemple : j'avais commencé à tous les ripper dans le cadre de mon rip pour The Spriters Resource (je voulais inclure toutes les frames des objets animés) mais je m'étais vite rendu compte qu'en respectant la grille de 16*16 j'obtenais un nombre anormalement immense de tiles, et que donc ils avaient été placés sur une grille de 8*8.

Concernant le système présenté dans le gif : en fait dans LsA, et dans ALttP aussi il me semble, les collisions des coins de tiles non passables (arbres, rochers...) fonctionnent comme ceci :



Lorsque un coin de la hitbox de Link arrive sur le segment de collision en vert Link "glisse" en diagonale, vers le nord-est si le joueur avançait vers le haut et sud-ouest s'il avançait vers la gauche. Ainsi lorsque qu'un passage ne mesure qu'un tile de large le joueur n'est pas obligé d'aligner manuellement Link au pixel près avec le passage, l'alignement se fait tout seul. Ici j'ai représenté cette diagonale alignée sur le carreau de 8*8 mais en fait il est possible qu'elle soit un peu plus petite.

En fait mon image ci-dessus n'est pas tout à fait exacte car un autre aspect bien connu de LsA (j'ignore si on retrouve cet aspect dans ALttP), notamment des speedrunners, est le fameux wall cropping (rognage de mur) :



Si le joueur avance vers un tile non passable (ici : les falaises) de manière perpendiculaire à ce dernier (flèches violettes) la ligne de collision va être égale à la limite du tile (jusque-là rien d'inhabituel). Mais si le joueur se dirige vers le bord d'un tile non passable de manière parallèle (flèches vertes) il peut rogner de quelques pixels (5 ?) le bord du tile bloquant.



Ça rend l'entrée dans les passages étroits (1 carreau de large) encore plus facile.

PS : je pense qu'en terme de système de collisions LsA est un peu mieux fichu qu'ALttP, aussi je conseille à cette personne d'E-magination de se référer à ce dernier plutôt qu'à l'opus SNES.

Merci de vos réponses

Hum, donc les collisions en 8x8 sont confirmées, ça serait intéressant d'analyser pourquoi pratiquement tous les sprites sont en 16x16 (d'un premier coup d'oeil, on a vraiment l'impression que le jeu est en 16x16). Pour faciliter la compréhension de l'espace par le joueur ?

Merci Zim d'avoir partagé ma question, la réponse de Nemau est intéressante, je vais sûrement lui répondre là bas après m'être renseigné sur le wall cropping. Et je suis d'accord avec lui, je trouve les collisions de LsA mieux fait que celui de ALttP (je saurais pas vraiment dire pourquoi, mais je le trouve plus fluide, c'est une des principales raisons pour lesquelles je préfère globalement LsA).

Deuxième remarque attendue (toujours au même endroit) :

Roi of the Suisse a écrit:

Quelques remarques :

- En effet Link's Awakening, même si au premier abord a l'air d'être en 16*16, est en 8*8, ce qui permet de centrer les portes des donjons :



Ici en bas du screenshot.


- Une technique qui n'est pas souvent mentionnée mais qui est pourtant très importante et très facile à mettre en oeuvre, c'est d'avoir un héros de taille inférieure au tile. Pour Kujira no Java, j'utilise un héros de taille 24 dans un couloir de taille 32, ce qui laisse au joueur une certaine marge de manœuvre pour s'aligner avec le couloir.


- Links awakening possède, comme aLttP, un système d'alignement automatique à l'approche d'un coin :



En plus de la possibilité, mentionnée par Némau, de traverser le décor partiellement lorsqu'on avance parallèlement. On aperçoit les deux phénomènes dans ce gif.


- Une autre chose très très importante, qui peut sembler évidente, mais si jamais on oublie de le vérifier le résultat est catastrophique : la boîte de collisions du héros doit être égale à son image d'apparence (ou incluse dedans). C'est-à-dire qu'il ne faut surtout pas laisser du vide solide autour du héros.

Concernant l'intérêt des sprites en 16*16 (et des éléments de décor), je dirais que ça sert plutôt à la lisibilité des graphismes, tout bêtement. C'est un bon compromis entre abstraction, figuration, et esthétique.
Note : selon la fiche Wiki de la GB, la console peut afficher des sprites de 8*8 ou 8*16. Link par exemple serait composé de 2 sprites (ce qui n'a rien d'extraordinaire sur Nes par exemple, beaucoup de sprites sont formés ainsi, pour augmenter leur taille, et sur Nes, enrichir leur palette de couleur (un sprite sur Nes a quatre couleurs max, dont celle réservée à la transparence, autrement 3 utilisables seulement)).

J'ai finalement opté pour un système assez simple : je découpe la hitbox du joueur en 4 petites hitboxs (une pour chaque quart du rectangle initial) et je teste les collisions pour chacune des hitboxs, si seule une des deux hitboxs qui sont à "l'avant" (suivant la direction dans laquelle on va) est en collision avec la map, alors je décale le joueur dans la direction de la hitbox qui n'est pas en collision.

Ca n'implémente donc pas la possibilité de traverser le décor partiellement lorsque l'on avance parallélement, mais permet bien de "glisser" sur les coins des obstacles :

(ici la hitbox du perso fait la taille d'un tile, je suis étonné que ça marche aussi bien)

EDIT : et en réfléchissant aux messages de Nemau et RotS, je pense que L'sA utilise effectivement des hotspots plutot que des hitboxs, aux moins pour les collisions avec la map, ç'est un moyen simple d'à la fois glisser sur les coins et faire le wall cropping (et c'est ce que dit un des posts des liens que j'avais cité où l'auteur.e fait du reverse engineering).

Ca rend plutôt bien. C'est un Zelda like basique que tu fais ? Tu le fais avec quel langage / librairie / moteur ?