Faire un bon Sonic 2D ?
5 réponses à ce sujet
3
14
21
Depuis quelque temps, et particulièrement depuis la sortie de sonic rush, j'ai envie de m'essayer à la conception d'un bon jeu sonic en 2D. Cependant, je me vois mal développer un moteur 2D à partir de rien. Donc j'aurais voulu savoir si certain d'entre vous connaissent des moteurs existants ou de bonnes adresses pour développer son propre moteur.
1
2
Si ca t'interresse et que tu as des connaissance en C, je peux t'expliquer
comment developper un moteur 2D pour faire un sonic. J'ai malheureusement supprimé les sources de mes travaux suite a une
mauvaise manip, mais j'ai souvenir de mon developpement. Depuis faute
de temps, je n'ai pas recommencé. Des traces sont dispo sur:
http://projectsonic2d.free.fr . Avec des demos beta tres vite fait sur
les scrolling, la derniere mettait en place un effet de vague, que j'avais
amelioré par la suite mais jamais publiée, je devais peaufiné la facon
d'afficher les textures d'un niveau avant d y inserer le perso a controler.
comment developper un moteur 2D pour faire un sonic. J'ai malheureusement supprimé les sources de mes travaux suite a une
mauvaise manip, mais j'ai souvenir de mon developpement. Depuis faute
de temps, je n'ai pas recommencé. Des traces sont dispo sur:
http://projectsonic2d.free.fr . Avec des demos beta tres vite fait sur
les scrolling, la derniere mettait en place un effet de vague, que j'avais
amelioré par la suite mais jamais publiée, je devais peaufiné la facon
d'afficher les textures d'un niveau avant d y inserer le perso a controler.
3
14
21
En fait, je vais utiliser Blitz, un moteur 2D avec un langage haut niveau qui ressemble à du C, mais avec pleins de fonctions déjà codées pour gérer les colisions d'images au pixel près.
Et je viens de récupérer un moteur de jeu Sonic développé par un gars sur Blitz. Je vais voir ce que je peux faire avec.
En fait, j'aurais voulu connaitre les grands principes de la programmations d'un jeu de plateforme. Je sais par exemple que les niveaux sont composés de blocs, surement pour limiter le nombre d'image en mémoire, mais comment sont stockées les infos de "où se trouve chaque bloc". Comment les blocs sont loader au début du niveau, etc...
Et les principes pour déplacer la caméra avec le déplacement du perso, gérer l'inertie du mouvement, etc...
Et je viens de récupérer un moteur de jeu Sonic développé par un gars sur Blitz. Je vais voir ce que je peux faire avec.
En fait, j'aurais voulu connaitre les grands principes de la programmations d'un jeu de plateforme. Je sais par exemple que les niveaux sont composés de blocs, surement pour limiter le nombre d'image en mémoire, mais comment sont stockées les infos de "où se trouve chaque bloc". Comment les blocs sont loader au début du niveau, etc...
Et les principes pour déplacer la caméra avec le déplacement du perso, gérer l'inertie du mouvement, etc...
3
Pour gérer un tilemap (les blocs) , la solution la plus adaptée est un tableau d'entier tout con avec chaque entier correspondant à un bloc, du genre (cay du C , je connais rien à la syntaxe du Blitz)
Pour faire encore mieux , on peut aussi faire un tableau de structures (chaque structure représentant un tile) pour pouvoir associer plus de propriétés à un tile
Ensuite tu parcours le tableau avec deux boucles en multipliant les indices de boucle avec la hauteur et la largeur de tes tiles pour avoir leur position dans le niveau.
J'avais fait un petit moteur de tilemap avec cette technique et ca marchait plutot bien. Par contre je blittais tout les tiles dans un bitmap énorme pour ensuite blitter la surface corespondante à la caméra sur l'écran , ce qui est pas une bonne solution (du tout) niveau performances.
Une solution serait de blitter les tiles s en collision avec la surface d'affichage (voire avec une surface un peu plus grande afin d'éviter que des tiles ne s'affichent pas tout de suite si la vitesse de la caméra est trop grande)
Voilà un petit schéma (fait à l'arrache en 5 min sous paint) qui résume ca :
Sinon je suis pas sur que les collision pixel-perfect soient les plus adaptée s pour un Sonic. Ca risque de donner un style "TGF" à tes mouvements
Si t'as le temps (et l'envie) de t'interesser aux collision avec des polygones, voici un article sur le sujet (en anglais avec plein de vecteurs dedans !) http://www.fluidstudios.com/pub/FluidStudios/CollisionDetection/Fluid_Studios_Generic_Collision_Detection_for_Games_Using_Ellipsoids.pdf
Code:
int tilemap1[largeur_niveau][hauteur_niveau];
Pour faire encore mieux , on peut aussi faire un tableau de structures (chaque structure représentant un tile) pour pouvoir associer plus de propriétés à un tile
Code:
typedef struct{
int numTile;
int largeur;
int hauteur;
int truc;
int machin;
}tile;
tile tilemap[largeur_niveau][hauteur_niveau];
Ensuite tu parcours le tableau avec deux boucles en multipliant les indices de boucle avec la hauteur et la largeur de tes tiles pour avoir leur position dans le niveau.
J'avais fait un petit moteur de tilemap avec cette technique et ca marchait plutot bien. Par contre je blittais tout les tiles dans un bitmap énorme pour ensuite blitter la surface corespondante à la caméra sur l'écran , ce qui est pas une bonne solution (du tout) niveau performances.
Une solution serait de blitter les tiles s en collision avec la surface d'affichage (voire avec une surface un peu plus grande afin d'éviter que des tiles ne s'affichent pas tout de suite si la vitesse de la caméra est trop grande)
Voilà un petit schéma (fait à l'arrache en 5 min sous paint) qui résume ca :
Sinon je suis pas sur que les collision pixel-perfect soient les plus adaptée s pour un Sonic. Ca risque de donner un style "TGF" à tes mouvements
Si t'as le temps (et l'envie) de t'interesser aux collision avec des polygones, voici un article sur le sujet (en anglais avec plein de vecteurs dedans !) http://www.fluidstudios.com/pub/FluidStudios/CollisionDetection/Fluid_Studios_Generic_Collision_Detection_for_Games_Using_Ellipsoids.pdf
"Ma parole Blake, mais vous êtes un communiste !"
-- Derrick
-- Derrick
2
4
22
Il y a un an, j'ai commencé à lire un bouquin sur le C mais ne voyant pas d'application graphique réelle, je me suis arrêté au milieu.
Apparement il est possible de faire des trucs assez sympas avec ce language donc je serais assez intéressé si vous aviez des liens faisant office d'initiation aux jeux en C (genre sonic si possible :p )
Apparement il est possible de faire des trucs assez sympas avec ce language donc je serais assez intéressé si vous aviez des liens faisant office d'initiation aux jeux en C (genre sonic si possible :p )
1
2
pour le langage C et C++ je recommande vivement l'utilisation de la libSDL dispo sur libSDL.org
elle a l'avantage de generer facilement des fenetre/plein ecran, de charger des images (avec l'extension SDL_image on peut loader autre chose que du bmp) et ca capture tres bien les evenements clavier/souris, lecteur CD...
et ca peut utiliser opengl (ut2004 utilise la SDL et OpenGL sous linux)
autre avantage, le meme code peut servir et est compilable sous windows et de nombreux unix ainsi que linux, et je crois qu'elle existe sur bien des consoles de jeu.
dans mon developpement je parts d'un principe d'utiliser des fichiers de conf, chaque lecture de ces fichiers me permet d'y gerer facilement la resolution est divers effet que j'ai programmé. l'avantage? pas besoin de recompiler le programme quand on modifie ce fichier de conf le moteur le lit.
au niveau des levels, deja, tres important loader toutes les images dont on aura besoin et tester si elles sont bien chargée, en cas d'echec on coupe tout, ca evitera les plantage. apres avoir finis une carte/level, on decharge tout ce dont on a plus besoin (image etc...) pour liberer la memoire car meme si on load un jpg, dans la ram ca pese aussi lourd qu'un bmp. donc ca peut grimper tres vite.
les images qui sont afficher en arriere plan sont de grande images et avec une habile fonction coder par mes soins, je n'affiche qu'une surface egale a la taille de la fenetre, c'est tres louable au niveau des performance.
j utilise plusieurs plans (au moins 2 sans compter le plan ou evolue le personnage) qui subissent un scrolling a differentes vitesses, ca accentue un effet de profondeur.
pour le plan ou evolue le hero ce sont des blocs. chaque bloc est definis dans un fichier binaire (ca prends moins de place qu'un fichier texte, et c'est plus pratique si on veut faire un editeur de niveau), il suffit donc de lire le fichier binaire, octet par octet pour connaitre: l'image a choisir (on met un reference de son choix) suivi de ses coordonée x et y et enfin le tyle de collision (si on peut passer au travers ou que d'un seul coté ou pas du tout etc..)
le moteur lit ca et stock dans une liste chainée. une fois le fichier chargé on tape uniquement dans la liste, c'est plus rapide que de lire sans arret. 1er condition si les coordonnée du bloc se situe dans la fenetre on affiche (oui car on peut afficher a l'exterieur de la fenetre, c'est pas grave ca se voit pas, mais ca bouffe de la ressource.) une fois afficher on regarde l'interaction possible avec le hero si il se trouve a proximité et on applique.
une fois le level finis on vide la liste pour liberer la memoire.
bref, deja avant d'en arriver la, on se casse pas la tete, on se creer une fenetre, on commence afficher un image, on essaye apres de faire du scrolling, apres on peut s'essayer au sprite et une fois qu'on sait faire au moins ca, on peut passer a la suite.
elle a l'avantage de generer facilement des fenetre/plein ecran, de charger des images (avec l'extension SDL_image on peut loader autre chose que du bmp) et ca capture tres bien les evenements clavier/souris, lecteur CD...
et ca peut utiliser opengl (ut2004 utilise la SDL et OpenGL sous linux)
autre avantage, le meme code peut servir et est compilable sous windows et de nombreux unix ainsi que linux, et je crois qu'elle existe sur bien des consoles de jeu.
dans mon developpement je parts d'un principe d'utiliser des fichiers de conf, chaque lecture de ces fichiers me permet d'y gerer facilement la resolution est divers effet que j'ai programmé. l'avantage? pas besoin de recompiler le programme quand on modifie ce fichier de conf le moteur le lit.
au niveau des levels, deja, tres important loader toutes les images dont on aura besoin et tester si elles sont bien chargée, en cas d'echec on coupe tout, ca evitera les plantage. apres avoir finis une carte/level, on decharge tout ce dont on a plus besoin (image etc...) pour liberer la memoire car meme si on load un jpg, dans la ram ca pese aussi lourd qu'un bmp. donc ca peut grimper tres vite.
les images qui sont afficher en arriere plan sont de grande images et avec une habile fonction coder par mes soins, je n'affiche qu'une surface egale a la taille de la fenetre, c'est tres louable au niveau des performance.
j utilise plusieurs plans (au moins 2 sans compter le plan ou evolue le personnage) qui subissent un scrolling a differentes vitesses, ca accentue un effet de profondeur.
pour le plan ou evolue le hero ce sont des blocs. chaque bloc est definis dans un fichier binaire (ca prends moins de place qu'un fichier texte, et c'est plus pratique si on veut faire un editeur de niveau), il suffit donc de lire le fichier binaire, octet par octet pour connaitre: l'image a choisir (on met un reference de son choix) suivi de ses coordonée x et y et enfin le tyle de collision (si on peut passer au travers ou que d'un seul coté ou pas du tout etc..)
le moteur lit ca et stock dans une liste chainée. une fois le fichier chargé on tape uniquement dans la liste, c'est plus rapide que de lire sans arret. 1er condition si les coordonnée du bloc se situe dans la fenetre on affiche (oui car on peut afficher a l'exterieur de la fenetre, c'est pas grave ca se voit pas, mais ca bouffe de la ressource.) une fois afficher on regarde l'interaction possible avec le hero si il se trouve a proximité et on applique.
une fois le level finis on vide la liste pour liberer la memoire.
bref, deja avant d'en arriver la, on se casse pas la tete, on se creer une fenetre, on commence afficher un image, on essaye apres de faire du scrolling, apres on peut s'essayer au sprite et une fois qu'on sait faire au moins ca, on peut passer a la suite.