Discussion :

[skysee]

Bonjour à tous,
Après un pong et un snake très basique, je souhaite passer au niveau supérieur.
J'en suis juste a la conception, donc aucun code de sortie.

Le jeu que je souhaite concevoir est un remake de micro machine.

Là où je coince, c'est que j'aurais mon décor qui défilera sur l'écran, donc en fait une grande map par circuit. Et donc je recherche les solutions me permettant de gérer les collisions entre une voiture et certains endroits de cette map tel que le bord de la piste par exemple.

J'ai penser à deux solutions :
1 - lors de la création d'une map, peindre les objets/contours sujet à collision d'une certaine couleur et tester à chaque boucle si la position d'une voiture est la même que celle d'un pixel de couleur prédéfini.
Mais la çà ne me paraît pas réaliste en terme de performance...
2 - Avoir une map faisant juste office d'arrière plan, et avoir en parallèle un tableau, au dimension de la map (la aussi ca me paraît énorme), ou chaque case représentant un pixel est a 0 ou 1 suivant s'il doit y avoir collision ou pas.

Voila j'en suis la, ces deux solutions ne me plaisent pas. Avez vous idée de ce qui se pratique couramment dans ce genre de cas ?

Merci à tous.

[bachir006]

tu crée un tableau d'objets, et pendant chaque tour de boucle, tu teste les collisions entre eux , tu peux meme utiliser un moteur physique 2D : Box2D
pour le scrolling, c'est la vue qui change deposition, pas les objets , par exemple le perso peut etre blitté ala position (200, 200) de l'ecran, et qu'il ait comme position (2982, 4412) par exemple

[Kurisu]

Tu peux obtenir des collisions en 3D trés basiques avec des sphere tests, c'est à dire, tu prends la distance entre 2 voitures et tu la compares à un rayon minimal de collision: si la distance < le rayon, alors il y a collision. (En 2D, tu peux faire la même chose, seulement ce seront des cercles, mais le principe est le même). Ce genre de procédé est très facile à comprendre et à réaliser, et peu cher en calculs. Bien sûr, ca ne fonctionne pas qu'entre les voitures, mais aussi avec le décor.

[raptor70]

Une petite astuce qui pourrait être interressante (juste une idée qui me passe par la tête..) .. et si tu utilisais le canal alpha de ton image pour définir les parties solides ? Vu que c'est une images de fond que tu as, tu n'aura pas de transparence ... donc le canal alpha peut t'être utile ..

[TheDrev]

utilise des structures de tiles avec les proprietes adéquate

Structure tile
Debut
cle : entier
traversable : booléen
Fin

Dans un tableau 2D de tile qui constitue ta carte.

[skysee]

Voila deux idées plutôt pas mal.

Je vais creuser ces deux idées et voir la plus simple a mettre en œuvre.

[skysee]

En fait, pour en revenir aux tuiles. Je ne comptais pas utilliser de système pour créer mes map. Je comptais créer directement une image entière.

Peut être est-ce une erreur?

[Polyfructol]

Tout est envisageable, mais les tiles ont l'avantages d'être réutilisable très facilement (et tu peux aussi repiquer les graphismes des anciennes consoles). C'est à dire qu'avec le même set de tiles, tu peux faire une infinité de niveau.

Mais c'est plus restreint niveau artistique (un jeu sans tiles, avec tiles).

En gros si tu n'es pas, ou n'as pas de graphiste sous la main, et que tu veux faire un jeu dans l'esprit des micro-machines 2D, je te conseille de choisir la technique la plus courante, avec des tiles.

[TheDrev]

En fait, rien ne t'empeche d'utiliser les deux. J'avais deja réver de faire un micro machine, tu peut utiliser les tuiles pour la plupart des décors, plus des images 'encrées' a une coord (des photos d'objets, un scan de tes copies de cours...)

[Frifron]

Sinon pour la collision avec les bords de la piste, il y a une technique très simple et très peu couteuse en performance et qui est totalement indépendante de la partie graphique.

En fait il faut séparer sa piste en portions. Chaque portion étant un quadrilatère composé du coté droit de la piste, du coté gauche, de l'avant qui est la jonction avec la portion suivante, de l'arrière qui est la jonction avec la portion précédente. On a donc 4 points par portions et quatre vecteurs. En fait on va utiliser le produit scalaire pour connaitre la position relative d'un point par rapport a un vecteur.

Pour cela, rien de plus simple, on calcul le produit scalaire entre la normale (vers l'interieur de la portion attention au sens) d'une des droites de la portion et le vecteur (position de la voiture - point arbitraire sur la droite). Si le résultat est inférieur a 0, le point est en dehors de la portion sinon il est a l'interieur.

On teste chaque coté de la portion a chaque frame, ce qui reviend a calculer 4 produits scalaire, ce qui n'est rien du tout :

si le test du coté avant de la portion Pn est faux, on passe a la portion Pn+1 et on reteste
si le test du coté arrièrede la portion Pn est faux, on passe a la portion Pn-1 et on reteste
si le coté gauche de la portion Pn est faux, le point sort de la piste, il faut donc interpoler sa position sur la piste avec son ancienne position
si c'est le coté droit pareil.

L'avantage de cette méthode outre le fait quelle soit très rapide et que tu connais la portion sur laquelle est la voiture (ce qui permet de gérer checkpoints, compteur de tours, classement temps réel...) et surtout te permet de filtrer pas mal les tests de collisions car tu ne testes que les collisions entre les objets (avec un test plus classique genre sphere/sphere comme proposé plus haut) étant sur la même portion (et eventuellement sur les portions voisines).

Un petit exemple (en utilisant le schéma) :
on veut tester que le point ne sort pas par le coté p0p1.
on a le vecteur p0p1 qui vaut (x0,y0)
la normale N a ce vecteur vaut (y0,-x0) (attention au sens, en fonction du sens de la normale les signes pourrait être inversé : (-y0,x0))
Ensuite on calcul le vecteur p0P avec P la position du point a tester. ce vecteur vaut (x1,y1)

on fait le produit scalaire entre les vecteurs N et p0P :
test = y0 * x1 - x0 * y1

Si le test < 0 le point est en dehors de la portion donc hors de la piste
si test > 0 le point est sur la piste
si test = 0 le point est juste sur le bord de la piste

Voila en gros j'ai peut être pas très bien expliqué mais c'est de la géométrie 2D toute simple entre vecteurs qui est bien plus approprié qu'un test de sphere/sphere ou box/box car une piste est défini par des segments et non des formes. Après je parle de point mais la voiture ne sera bien evidemment pas un point, c'est possible de faire ca avec une sphere et avec un box très facilement.

J'ai utilisé cette technique dans pas mal de jeu de voiture 2D et aussi 3D notamment sur mobile et ca marche très bien, après il y a bien sur plein d'autres techniques.

[Djakisback]

Pour un micromachines je pense qu'un tilesset ne va servir à rien du tout (et pour un jeu de caisse en général d'ailleurs, à la rigueur un offroad ou un spy hunter). Mais de toute façon tu peux très bien gérer tes sprites par tiles et tes solides différemment. La méthode de Frifron est intéressante mais tu dois pouvoir aussi faire simplement du test d'intersection de segments, a priori t'auras pas plus de quelques centaines de tests pour un circuit ce qui est peu optimisé mais qui devrait très bien tourner quand même. (déjà testé sous Java => 400 fps pour une moyenne de 5000 tests par cycle)

Mais c'est plus restreint niveau artistique (un jeu sans tiles, avec tiles).

Heu, je crois que le jeu 1 est un jeu 3d et le jeu 2 n'utilise pas de tiles ^_^

[Polyfructol]

Heu, je crois que le jeu 1 est un jeu 3d et le jeu 2 n'utilise pas de tiles ^_^

Je te confirme que non, Odin Sphere (le 1er), bien qu'utilisant la 3D pour les effets spéciaux, se sert de la 2D pour les personnages et les décors.

Et le deuxième est Castelvania, sur DS si je me trompe pas, et utilise assurément des tiles ! (16x16 pixels)


Mais bon quand je dis "utiliser un système par tiles", c'est plutôt utiliser un système par cases (même chose pour moi). Dans un jeu comme micro machines, les éléments du décors se répètent, il n'y pas grand intérêt à créer "une image entière".

Surtout que maintenant les machines d'aujourd'hui sont capables de charger des textures largement supérieures à celles des anciennes consoles. Rien n'empêche d'avoir des tiles de 128x128 pixels voir plus.

Après je m'y connais pas en collision, je ne fesait que répondre à :

En fait, pour en revenir aux tuiles. Je ne comptais pas utilliser de système pour créer mes map. Je comptais créer directement une image entière.

Peut être est-ce une erreur?

[Frifron]

Castlevania est en effet tilé mais en tiles très petits et avec une grande variété. Ce qui fait que le tiling ne saute pas aux yeux. Le hardware 2D de la DS gère les background en tile de 8x8 de toute facons. Donc les developpeurs ont tout interet à utiliser cette feature.

Concernant les collision, le test de position d'un point par rapport a une droite est plus rapide qu'un test d'intersection de 2 segments. En fait cela permet une première passe avant de vraiment calculer l'intersection de 2 segments pour déduire la position exacte de la collision s'il y a sortir de piste. Apres il est tout a fait envisageable de faire direct un test d'intersection entre 2 segments. Le truc c'est que dans 99,99% des tests, il n'y aura pas de collision donc pas de point a calculer.

[Djakisback]

Concernant les collision, le test de position d'un point par rapport a une droite est plus rapide qu'un test d'intersection de 2 segments. En fait cela permet une première passe avant de vraiment calculer l'intersection de 2 segments pour déduire la position exacte de la collision s'il y a sortir de piste. Apres il est tout a fait envisageable de faire direct un test d'intersection entre 2 segments. Le truc c'est que dans 99,99% des tests, il n'y aura pas de collision donc pas de point a calculer.

Oui effectivement, en plus ça évite l'effet de solides trop fins traversables si t'es pas en mode continu.


[HS:]
Au sujet d'Odin Sphere je l'ai terminé il y a quelques temps et je dirais que c'est de la 3d car l'axe Z semble être géré à part entière et non comme un simple Z-layer, justement pour y intégrer les FX, si je me souviens bien certains bouts de décors sont d'ailleurs en 3d, quand t'es dans la neige et dans la ville de Cornielius. Mais c'est assez dur à voir. Enfin peut-être que je délire complètement mais je me suis posé la question à l'époque et j'en avais déduit ça ^^

Pour Dawn of Sorrow il me semblait que ce n'était pas un bon exemple car j'étais persuadé que les background étaient des images complètes (sans parler des trucs collidables, murs, plafonds, etc.). Surtout qu'il y a un paquet de backgrounds non répétitifs et je vois pas vraiment l'intérêt de tiler cela.

Edit : effectivement c'est que des tiles de 8x8

[/HS]

[skysee]

En fait, je tourne en rond la dessus.
Ce que je trouve pratique avec les tuiles est qu'on les dispose par programmation ce qui induit que l'on connaisse la position de chaque tuiles. De plus la mise en oeuvre est aisée, il ne s'agit que d'un tableau par circuit

Mais dans ce que Djakisback et Frifron me disent, j'y vois un gros inconvénient. En effet il faut décomposer chaque circuits, chaque segments de chaque circuit, puisque dans vos cas on part d'une map unique, on a aucun aucun point de repère.

[Frifron]

C'est sur, il y a une phase de conception de circuit préalable mais je dirais que c'est quasiment une obligation de faire un éditeur (en java ou en c# plutot qu'en C/C++ histoire de réduire la phase de dev de outils. D'ailleurs tu codes ton jeu en quoi ?) de circuit lorsque l'on réalise un jeu de voiture. Après il peut être plus ou moins user friendly (c'est ca qui prend beaucoup de temps aussi)

Après tu parles de tiles mais il faut bien séparer la couche graphique de la couche physique. Les tiles concernent les graphismes, ca ne va pas te définir les bords du circuit et les objets collisionables sur les tiles. Quelque soit la technique choisi il y a forcément un boulot pour définir un circuit de facon physique. L'avantage de la technique par segment est qu'un circuit est défini avec très peu de donnée.

Sinon si tu utilise des tiles pour construire tes circuits rien ne t'empeche de définir les données physiques pour chaque tile dans le tile set et ensuite de reconstituer les données physiques du circuit entier en fonction de la tile map, quelque soit la forme des données physiques (c'est même de cette facon qu'il faut procéder)

[skysee]

J'ai choisi le c++ bien sur, et j'ai envie d'essayer sfml ou lieu de sdl. J'ai parcouru la doc, c'est tres clair.

Je n'ai rien codé encore. Le projet est quand même assez conséquent. Je veux savoir exactement comment le réaliser.

Pour les tuiles, c'est exactement ce que je voulais faire, c'est à dire définir des propriété physiques à celle-ci.

Seulement l'idée que tu as apportée permet une plus grande liberté au niveau des graphismes. Mais j'ai un peu de mal a voir comment la mettre en oeuvre.

[Frifron]

C'est très simple, pour chaque tile tu définie les portions. En fait tu positionne des points sur les tiles (j'ai fait un petit schéma). Ensuite a partir de la tile map et du tile de départ et du sens de rotation de la piste, tu construit toute les portions de la piste en recalculant les positions a partir de la position des points dans le tile et de la position du tile dans la tile map. Tu soude les points confondus (les points des extrémités de chaque tile doivent être confondu) et tu as ton set de segment pour le circuit.

Sinon quelle était ta solution choisie pour définir les propriétés physique du tile ?

Après il y a plein de solution pour gérer les collisions, je ne fait que t'en proposer une moi je l'aime bien car elle est rapide, robuste et quel te donne des infos supplémentaires pour faciliter la gestion d'autre partie du jeux (checkpoints, classement, construction de la minimap...). C'est la solution que j'ai utilisé dans des jeux mobiles style micro machine 2D et aussi jeux de voitures 3D. Mais après j'ai également fait des collisions de bords par collision cercle/cercle (mais c'était un cas particulier car c'était un jeu de karting ou les bords de la piste était défini par des pneus) . Après t'a aussi une technique qui consiste toujours a utiliser des portions mais a faire un changement de repère dans le repere défini par la portion (u,v), si la position de la voiture en u est < 0 ca on passe dans la portion précédente, si c'est supérieur a 1 dans la portion suivante. et en v ca défini les collisions avec les bords. Une autre consiste à utiliser un tile set physique noir et blanc avec blanc tu peux y etre et noir tu ne peux pas y etre. Et ce tile set peut être de résolution plus ou moins grande pour affiner les collisions (tout en prenant plus de mémoire et plus de temps de calcul)....

Bref il y a la dose de méthodes. A toi de choisir celle qui te convient le mieux en fonction des contraintes sur l'architecture de tes circuits, de la faciliter a level designer un circuit, de l'algo que tu estime le plus facilement implémentable, le plus rapide, le plus robuste...

[skysee]

Ma solution était jusqu'à présent vraiment simpliste.

Un jeu de tuile identique pour tout les circuits. Je définis que quelque soit le circuit la tuile T sera toujours bloquante a l'inverse de la tuile N. Je représente l'écran sous la forme d'un tableau a 2 dimensions avec dans chaque case une tuile. Les tuiles ayant toutes les mêmes dimensions il est facile de connaître les points bloquants. Voila un peu simpliste et limité.

Je vais réfléchir à ta proposition.

Merci beaucoup

[Kurisu]

Pour les tuiles et les maps, une chose qui peut te convenir, c'est d'utiliser une image en niveaux de gris (256 couleurs, mais en fait, c'est selon tes besoins), avec chaque couleur représentant un index sur une palette de tuiles (un tableau d'éléments du type tuile, donc). C'est assez direct comme approche, et tu restes flexible au niveau de la map (facile à "dessiner" avec n'importe quel soft de dessin) et au niveau des tuiles (facilement interchangeable pour adapter/changer le style de ta piste).

... Par la suite, une image ayant 4 canaux de couleurs par pixel, tu pourrais même avoir 4 index vers des palettes différentes: le style graphique, la propriété de "vitesse" d'une case, la traversabilité... etc. Puis, rien ne te limite à une image, soit 4 palettes...