Poum pouloum pouloum.
Voilà la question de programmation du jour.
Comment sont gérées les attaques et les armes dans les Secret of?

Au début j'étais partis en me disant qu'il me fallait un truc de détections des collisions puis en donnant la partie dangereuse du sprite (la lame quoi) je saurais si j'ai touché l'ennemi.

Là dessus, premier constat: pour faire un jeu dans le style des Secret of, o­n a rarement besoin d'une précision au pixel près, surtout pour les attaques: il suffit lors de l'attaque de définir un rectangle "danger" dont la taille varie en fonction de l'arme et si l'ennemi est dedans, tant pis pour lui. o­n pourra à la rigueur se faire une détection entre un rectangle et un pixel près (pour l'ennemi), ça fera déjà moins ramer.
Je dis ça parce qu'on définira aussi le rectangle "pieds" et que le même genre de comparaison devrait servir pour les décors.
Cette technique semble être utilisée pour Secret of Evermore (lorsqu'on est de face, la hache ne fait qu'un pixel de large une fois abattu et o­n touche pourtant des ennemis en diagonale) en mode rectangle/rectangle.

Vient la deuxième partie du problême: avec une telle methode, je n'ai plus besoin de "séparer" l'arme et celui qui la porte et donc au prix que ça coute je peux me faire plusieurs images, avec chaque arme différente. Là encore, je sais que cette methode est utilisé pour Secret of Evermore: le personnage est plus petit lorsqu'il porte un os que lorsqu'il porte une hache :).
Par contre, je ne suis pas sûr qu'elle le soit pour Secret of Mana: en effet, dans cet opus, les armes sont régulièrement enchantées et change de couleur (ce qui n'est pas le cas dans SoE) et il semblerait donc que les armes soient des sprites indépendants.
Pour le vérifier, il faudrait voir si o­n peut infléchir la trajectoire du boomerang en se déplacant après l'avoir jeté. Si c'est possible, alors les armes sont des sprites indépendant. J'ai pas de sauvegarde de SoM, mais je suis sûr qu'il y en a un parmis vous qui en a une pas loin et qui va faire le test pour moi :D . (pour envoyer URB se faire voir, tappez 1).
En tout cas cela pose un problême si les armes sont indépendantes: les faire bouger avec le héros en étant sûr qu'elle resteront toujours dans sa main, ça va être technique. D'ailleurs, celui qui aura fait le test ci-dessus pourra tant qu'il y ait se demander si les trois persos manient les armes de la même façon (c'est le genre de truc qu'on regarde pas quand o­n joue mais qui en disent long sur comment a été fait la sauce).


Vous vous demander je le sais pourquoi je me prends la tête (et la votre au passage) avec ça. Ben, je n'ai toujours pas abandonné l'idée de faire plein de jeux-vidéos partout et puis c'est un problême de programmation interressant et je suis toujours à l'affut d'une explication sur comment marche les choses.


La prochaine nous nous demanderons:
"Et dans A link to the past? Les collisions se font cette fois au pixel près, c'est sûr, mais comment font ils pour que ça ne rame pas?"
Nous pourrons après nous demander:
"Comment enregistrer les cartes? Deux images: l'une intraversable (collision = rejet) et l'autre traversable? Plus un truc pour l'eau et l'herbe qui ne recouvre le personnage qu'à moitié? Et après un fichier .dat qui contiendra toutes les informations sur les évennements de la carte? Codé comment?"

Que de questions passionnantes sur la réalisation d'une jeu vidéo mes amis!

tsgk.captainn.net/index.php?p=showgame&t=sy&sy=8&ga=327&sec=32

Nan ?

Pour le coup du pixel par pixel, si tu fais un traitement intelligent (par exemple, pas tout l'écran mais une zone fortement restreinte) et en faisant un tantinet confiance aux capacités de la machine, ça n'est certainement pas si gourmand que tu veux bien le croire :-)

Ceci dit, le coup des rectangles, il me semble que c'est la "norme" pour la 3D, m'enfin ça doit être relativement compliqué à réaliser (et c'est bien pour ça que des gens sont payées/donnent de leur temps pour réaliser des moteurs physiques qui poutrent des ours). ogre3d.org

Oui enfin ton machin là il est fait à partir de screenshot (ripped and captured, c'est écrit au dessus), ça prouve pas grand chose.
De plus si tu regarde l'épée tu remarqueras qu'elle est toujours soit tout dessus, soit tout derrière le héros, ce qui va dans le sens que ce sont deux sprites séparés.
Par contre, quelques tests sur des lapins me laisse à penser que là encore ce n'est pas du pixel près.

En ce qui concerne la ramouille, voici un .exe tester:
http://perso.orange.fr/rayve/FileSender/Pixelpres.rar
Tu dirige la carré vert avec les flêches, en laissant controle droit appuyer pour qu'il bouge ses fesses.
Lorsqu'il est en dehors du truc bleu, pas de problême, c'est du test rectangle/rectangle, c'est fluide.
Maintenant rentre dans la forme bleu (dans le rectangle qui la contient), il commence à faire du pixel près et là ça ramouille sévère (chez moi en tout cas, et mon PC n'est pas mauvais).
Pour info c'est codé en C++, et c'est pas moi qui ait rédigé l'algo donc je pense que c'est un peu optimisé (peut-être pas monstrueusement mais quand même)
(c'est déjà une zone restreinte: o­n va pas tester un pixel qui n'appartient à aucune des deux rectangles)

Pour finir je dirais qu'on reste dans le domaine de la 2D pour l'instant :D
(cela dit, tuer un ours à coup d'unité centrale, ça doit être drole)

Je pense que l'effet "zone de colision avec l'ennemi" et l'animation de l'arme sont deux choses bien séparées.
Bien sur, ça n'empeche pas de préparer à l'avance différentes manières de toucher un ennemi et de l'associer à tel ou telle arme. :)

Après j'en sais rien du tout.

Faut bien garder à l'idée qu'en développement, on sépare toujours l'aspect visuel de l'aspect technique.


J'espère avoir pu t'aider

Perso je gererais ca par coordonnees et dimensions. En principe, les developpeurs connaissent la taille des images qui vont ensuite servir de sprites.
Suffit alors de faire appel a une methode evenementielle pour faire le calcul de coordonnees.
Apres, si on veut faire plus complique, les algorithmes de collision, y'en a partout sur le net...

Nigel a dit:Je pense que l'effet "zone de colision avec l'ennemi" et l'animation de l'arme sont deux choses bien séparées.

C'est aussi la conclusion à laquelle je suis arrivé. o­n calcule un rectange à partir de la position du personage, plus long et plus étroit si il manie une lance.
Cependant, moi j'aimerai bien pouvoir faire des magies bien compliqués genre un truc en étoile qui apparait sur l'écran, et donc dans le cas de forme compliquée, ce serait plus simple de juste avoir à plaquer l'image de la magie sur l'écran et dire "tout ceux qui sont dessous pan dans les dents!"
Cela dit, pour la plupart des magies, o­n devra surement pouvoir déclarer mathématiquement les zones de contact ou faire comme dans les Secret of: touché automatique.

Par contre pour les bords du décors: tant que c'est rectangulaire o­n peut le faire simplement (et encore, si y'a plein de rectangle o­n risque de grandement se prendre la tête) mais dès qu'il y a un mur un peu tordu, plutôt que de chercher la fonction mathématique qui lui corresponds bien, ça parait plus facile de faire un truc au pixel près, en réduisant le personnage à un rectangle autour de ses pieds.

Ensuite, même en prenant l'animation de l'arme séparée, je suis toujours pas très chaud pour placer le sprite de l'arme au pifo en espérant qu'elle tombe dans la main du personnage. Bien sûr àprès de nombreux test o­n doit pouvoir y arriver, et je crois pas qu'il y ait vraiment d'autre methode si o­n veut pouvoir l'enchanter, enfin jouer avec séparément du personnage.

Tu cherche à développer un jeu de A à Z ou tu utilise des outils particuliers ?

A mon avis il est en train d'essayer ca en CPP, mais ca changera rien au fait qu'il va devoir faire appel a des librairies externes.
Perso je lui recommanderais de commencer par un truc plus simple avant d'essayer de s'attaquer a un truc avec une geometrie complexe, meme si le principe reste le meme.

Quel est ton A? Je ne fais pas de langage machine non, mais je n'utilise pas non plus RPGMaker :D.
Jusqu'ici, j'utilise le C++ et la librairie SDL.
Mais bon, je cherche pas trop hein! Tant que je suis en prépa je sais que j'aurais pas le temps donc je cherche juste un peu pour le plaisir de l'esprit quoi.

J'ai passé pas mal de temps à implémenter l'algo donc je vous parlais avec une des deux formes qui est un bête rectangle. Et ben tenez vous bien: c'est pire encore que celui avec deux formes compliqués! Et en plus ça bug de partout, et ça ne marche pas.
Je pense que je code comme un pied, mais je si en train de tenter de rectifier le tir.

EDIT pour Dreamer: En fait, c'est plus simple quand la figure est zarb, parce que je suis obligé de faire du général donc de ne jamais utilisé les spécificités de la figure.

EDIT2:Voilà, ça marche mais ça rame toujours autant.
Pourceux que ça interresse:
http://perso.orange.fr/rayve/FileSender/Pixelpres2.rar
Appuyer sur la touche a (en azerty) pour passer d'un mode à l'autre: soit pixel près pour deux formes quelconque, soit pixel près mais avec l'une des deux formes considéré comme un rectangle.

Je comprend pas du tout ton application en fait, il doit se passer quoi ?

Okay, je rééxplicite:
Le but est de tester deux methodes de détection de collision.

Tu as sur l'écran trois choses:
- Une barre verte en haut à gauche que tu peux déplacer avec les flêches.
Si tu veux l'accélérer (pixel 10 par 10 au lieu de 1 par 1), laisse Ctrl droit appuyer pendant que tu la déplace.
- Une forme bizarroïde bleue qui est l'obstacle. Si tu essaye de la traverser, la barre verte refuse: elle a détectée la collision.
- Un fond psychedélique. Il varie avec le temps, et donc sa vitesse de variation te donne une idée d'à quel point ça rame.

La chose bleue est englobé dans un rectangle facile à deviner. Tant qu'on est en dehors de ce rectangle, les deux méthodes savent qu'elles n'ont pas besoin de faire de test (les rectangles ne se croisent pas) et donc c'est fluide. Une fois que la barre est rentrée dans la zone intérieur truc bleu, les choses se corsent et les test au pixel près se lancent à chaque déplacement.

Enfin, appuyer sur la touche A (en azerty) permet de passer d'une mode de détection à l'autre avant de voir que ça rame pareil.

Voilà, ai-je été assez explicite?

(Me semble pas que tu avais expliqué les choses de cette manière là ;) )

En effet ça rame sec dès que tu tente la collision !

Jpense que tu peux trouver ton bonheur ici :
Dévellopez point com
Bibliothèques
Vraiment bien foutu

Bon, j'ai eu un e bonne idée cette nuit:
je ne fais plus des tests que aux quatres coins du rectangle. Bien sûr en forçant (et en sachant cela) o­n peut lui faire traverser des trucs qu'il devrait pas mais au moins ça rame plus et pour tester la collision avec le décor, c'est bien suffisant.

Je me demande quand même qu'elle était la méthode utilisée en général pour ce genre de jeux...

J'ai lu un peu de tes liens Nigel, j'ai pas le temps de tout lire mais je le place dans un coin de favoris, au cas où.
(je connaissait devellopez, o­n y revient régulièrement)

La gestion des collisions et le pathfinding au pixel près, c'est vraiment pas de la tarte pour avoir expérimenté ça sur un petit RTS 2d que je m'amusais à développer (et que j'espère poursuivre un jour).

J'ai pas trop cherché de doc sur le web (à part sur l'algo A* pour le PF), mais pour ce que j'avais pu voir y a largement de quoi se creser les méninges.

J'avoue avoir la flemme de tester son exe mais a mon avis ca rame parce qu'il fait des tests en continu dans une boucle. Dans un jeu, c'est plutot gere de facon
evenementielle.