[SpinyENGINE 1.0] - Sonic The Hedgehog

[Anakin]

Bonjour à tous,

Je vous présente ici mon principal projet que je développe seul depuis le courant de l’année 2009 : SpinyENGINE.
www.spiny-engine.com

Bande Annonce

Voici la première bande annonce du projet.


Présentation

Avant-propos

Au premier abord, l'idée du projet peut paraître peu originale. En réalité elle est simplement née d'une certaine nostalgie et d'une volonté de relever un défi ambitieux, celui de reproduire le plus fidèlement possible le moteur de jeu de la série Sonic The Hedgehog des années 1990.

Le projet SpinyENGINE est destiné à tous les fans ou nostalgiques des premiers opus de la série Sonic The Hedgehog mettant en scène le célèbre hérisson bleu.

Le projet dans son ensemble

Le projet a débuté en 2009. L’ensemble du code a été réécrit au dernier trimestre 2011. Cette dernière refonte est également le point de départ du développement de l’éditeur de levels.

Le projet s’articule donc en réalité autour de 2 développements :

• SpinyENGINE / Sonic & Knuckles SFML : Le jeu
• SpinyMapEditor : Editeur de levels

En vrac

• L’équipe : 1 personne
• Type : jeu de plateformes
• Langage utilisé : C++
• Librairies utilisées : Qt et SFML
• Fenêtre : 640x480
• Scrolling horizontal
• Scrolling vertical
• Inspirations et modèles : Sonic 1, Sonic 2 et Sonic 3 sur SEGA Megadrive

Graphismes

Actuellement la plupart des images ont été reprises sur internet car mes compétences sont limitées dans ce domaine et je ne suis pas capable de les reproduire. Ainsi seules les plateformes et quelques images ont été créées.

Néanmoins les images ont été retravaillées. Le travail minimum consiste à créer une planche quadrillée afin de disposer les images avec un espace précis.

Voici un extrait de la planche du héros principal :


SpinyMapEditor

SpinyMapEditor est un éditeur de levels simple et efficace répondant aux besoins du projet en matière de création de levels.

Entièrement réalisé en C++ à l’aide de la librairie Qt, le programme est relativement optimisé.

Il permet de disposer à l’aide de la souris les différents éléments qui composeront les niveaux du jeu et propose un certains nombre de fonction telles que :

• Annuler / Rétablir
• Copier / Coller
• Suppression
• Sélection
• Déplacement des blocs
• Modification des paramètres (exemple : puissance d’un ressort)
• …

Chaque élément est défini par un fichier XML ainsi qu’un fichier PNG.

Les fichiers levels (*.LVL) sont écrits en binaire.

Le mot de la fin

Le site du projet vous permettra de trouver d’autres informations et d’accéder aux liens de téléchargement.
www.spiny-engine.com/site/download.php

Il est évident que toutes les remarques, critiques ou commentaires (positifs ou négatifs) sont les bienvenus et feront l’objet d’une attention particulière.

[Anakin]

Bonsoir,

Le programme utilise maintenant la version 2.0 de la SFML.

Autre nouvelle, l'éditeur de level"Spiny Editor" s'est vu ajouté la fonction "Play" qui permet aux utilisateurs de lancer le test de la map en cours de création. Cela sera disponible très prochainement dans la version 3.0 du programme.

[shingo]

C'est dommage que ton projet n'est encore populaire car je le trouve tout simplement énorme. Je suis un fan des premiers Sonic et cela ma donné envie de découvrir ce spy engine.

[Anakin]

Salut,

Merci beaucoup !
Le projet avance à grands pas et je suis sur le point de sortir une petite démo très prochainement 

[Cpl.Bator]

Vivement la démo , je croyais le projet mort.
tu comptes nous parlé de comment tu as géré les collisions ? ne me donne pas le lien du sonic physic guide ^^

[Anakin]

Salut, non le projet n'est pas mort, bien au contraire 

Pour les collisions oui je peux vous exposer comment je m'y prends. C'est du 100% made in home 
A mon sens il s'agit de la partie la plus complexe car le moteur gère les collisions à 360°.

Un début d'explication :

Mes entités physiques sont classées en 2 catégories distinctes. Une entité physique peut être :

• soit assimilable à un cercle (centre + rayon)
• soit assimilable à un polygone (ensemble de segments)

Ainsi les différents cas de collisions qui se présentent sont les suivants :
- cercle VS cercle (ex : 1 héros contre un ennemi)
- cercle VS polygone (ex : 1 personnage contre 1 plateforme)
- polygone VS polygone (très rare... ex : un bloc déplaçable par le héros)

En ce qui concerne les polygones, ils sont donc constitués de différents segments. Chaque segment se voit attribuer des propriétés de collisions.

Si cela intéresse du monde il faudrait que je m'attache à écrire un document pour présenter un peu le fonctionnement du moteur.


Annonce
Je poste également ce soir pour annoncer la sortie imminente d'une nouvelle démo ! 
Je reviendrai vers vous lorsqu'elle sera en ligne, d'ici quelques jours...


[attachment deleted by admin]

[Cpl.Bator]

Tant mieux ^^ , j'ai hâte de voir cela , Tu découpes aussi la physique en 4 suivant la vitesses et la direction du joueur pour le faire "coller" aux mur ou tu t'y prends autrement ? si je comprends bien , pas de collisions au pixel alors.

[Anakin]

Tant mieux ^^ , j'ai hâte de voir cela

D'ici quelques jours si tout va bien 

Tu découpes aussi la physique en 4 suivant la vitesses et la direction du joueur pour le faire "coller" aux mur ou tu t'y prends autrement ? si je comprends bien , pas de collisions au pixel alors.

Non pas de pixel perfect. La partie physique est complétement dissociée de la partie graphique.
Pas de découpe par 4 non plus car je gère les collisions à 360° (courbe / looping), et donc il est nécessaire d'utiliser la notion de vecteur.

[Cpl.Bator]

Non pas de pixel perfect. La partie physique est complétement dissociée de la partie graphique.
Pas de découpe par 4 non plus car je gère les collisions à 360° (courbe / looping), et donc il est nécessaire d'utiliser la notion de vecteur.

ce que je voulais dire par 4 , c'est que ton personnage à un vecteur gravité "v(0,9." par exemple, mais lorsque qu'il cour très vite
& qu'il entame une pente vers la droite qui le mène à un angle droit son vecteur gravité change en v(9.8,0). en lisant le physic guide de sonic , j'ai compris qu'il gérais les collisions 360 de cette manière.

[totorigolo]

Même si je ne suis pas un grand fan de Sonic, j'ai hâte de voir une démo de ton moteur

Mais je me demande si tu compte aussi reproduire les glitch du jeu original    J'imagine bien un mode "avec glitch"... 

[Anakin]

Non pas de pixel perfect. La partie physique est complétement dissociée de la partie graphique.
Pas de découpe par 4 non plus car je gère les collisions à 360° (courbe / looping), et donc il est nécessaire d'utiliser la notion de vecteur.

ce que je voulais dire par 4 , c'est que ton personnage à un vecteur gravité "v(0,9." par exemple, mais lorsque qu'il cour très vite
& qu'il entame une pente vers la droite qui le mène à un angle droit son vecteur gravité change en v(9.8,0). en lisant le physic guide de sonic , j'ai compris qu'il gérais les collisions 360 de cette manière.

Ah oui je vois ce que tu veux dire 
Effectivement dans les jeux officiels la détection des collisions se fait grâce à des "capteurs", sorte de lignes associées au héros et qui servent à détecter la position par rapport aux pixels des plateformes.

Quand je me suis lancé dans le développement de mon moteur je n'avais aucune idée de la façon dont la physique était gérée dans les jeux Megadrive. J'ai opté pour l'utilisation de segments et j'ai eu l'idée d'assimiler les personnages à des cercles pour les calculs.

Ainsi tous mes calculs de détection de collisions est basée sur des calculs de projection de position (cercle / extrémités de segment), ainsi que des calculs d'intersections entre cercles et segments.

Au final je suis très satisfait de ce choix car il m'a mené à une gestion de collisions relativement fiable 

Par ailleurs je te remercie car je n'avais jamais lu ce fameux "Sonic Physic Guide". J'avais visionné des centaines de vidéos    mais certains points de ce guide vont compléter tout ça et vont me permettre de paufiner certaines choses. Donc merci à toi 

[Anakin]

Même si je ne suis pas un grand fan de Sonic, j'ai hâte de voir une démo de ton moteur

Mais je me demande si tu compte aussi reproduire les glitch du jeu original    J'imagine bien un mode "avec glitch"... 

Merci pour ton message ! Ne compte pas trop sur les glitch mais la démo va arriver d'un jour à l'autre

[Cpl.Bator]

je suis très intéressé par ton système de collision , j'ai hâte de voir tout ça en action , y a intérêt que ca colle à la mégadrive !   
Tu t'es bricolé un éditeur de tuiles segment alors ?

[Anakin]

Salut !

Bien sûr que ça colle à la Megadrive  En tout cas c'est l'objectif 1er du projet !

En ce qui concerne l'éditeur, j'ai développé un programme avec Qt qui permet de créer de fichiers binaires charger par le jeu.
Chaque élément est défini par un fichier XML et un fichier PNG.

Exemple :

• objet_ressort_h.png
• objet_ressort_h.xml

<?xml version="1.0" ?>
<element id="2000022">
        <z>3500</z>
        <Propulsion>1500</Propulsion>
</element>
 

L'éditeur ne gère ainsi que des éléments simples (1 image + des paramètres modifiables). Je les place avec différents outils. Je peux donc créer mon level très rapidement en ne me souciant que de la position de mes éléments et de quelques paramètres.

Ce n'est ensuite que dans le jeu que les segments sont fixés dans le code pour chaque élément.
Exemple pour le ressort, il est constitué de 4 segments (autour de l'image).

Un petit aperçu de l'éditeur en fichier joint.

Par ailleurs une démo du moteur sera mise en ligne ce week-end, sans doute demain soir si je ne trouve rien à corriger d'ici là 

[Cpl.Bator]

Haa , Compatible linux j’espère ?