Voilà quelques liens que je tiens à partager :
Toymaker : le site de mon prof en Game Software Development. Il est remplit d'enormement d'informations sur la creation de jeux et propose aussi quelques articles comme par exemple "trouver un boulot dans l'industrie du jeu video" ou encore "les jeux videos sont bons pour la sante".
Kromatyk : le blog d'un gars encore plus geek que moi. Et également mon seul lecteur régulier à l'heure actuelle xD (yep bro, dédicace!!)
Teesside : là où j'étudie en ce moment. Super endroit, vraiment.
Me concernant :
Jackamikaz' Games : un petit site qui regroupe mes jeux.
Twitter : ma page twitter
Voyage en Nouvelle Zélande : le récit inachevé de mon stage en Nouvelle Zélande
mercredi 18 novembre 2009
Faire un renderer 3D basique en software
note : HAPI est une API qu'on est obligés d'utiliser en Game Software Development. En gros ca permet juste de créer une fenêtre, et manipuler le buffer de celle-ci. Aucune autre librairie externe n'est autorisée (à part STL quand même). Son but est de nous apprendre les bases des graphismes 2D, comme le blitting, le background scrolling, les sprites, les animations ...
Etant pas mal en avance sur la plupart de mes modules en ce moment, et après une discussion avec un camarade de classe sur "faire un jeu en mode 7 avec HAPI" ... l'envie m'est pris de faire coder un renderer 3D avec.
"Ca peut sembler dingue" pensais-je, mais pour obtenir quelque chose de basique, il ne faut pas grand chose!
Les pré-requis
Ils sont surtout mathématiques, et pas si dur que ça, on peut trouver et comprendre tout ça très rapidement sur wikipedia :
1) Les vecteurs :
4) Une expérience avec DirectX ou OpenGL ne fait vraiment pas de mal!
Les points à dessiner
C'est pas tout ca, mais il faut bien quelque chose à afficher!
Pour tester mon programme, j'ai commencé par créer un cube avec ces coordonnées :
Les matrices de transformation
Mais avant ça, il faut obtenir des matrices de transformation, qu'on va combiner entre elles pour obtenir une matrice de transformation finale, laquelle va être appliquée à nos points (d'où la multiplication de vecteur par matrice).
Vous pouvez trouver comment les produire avec la documentation OpenGL (que j'ai évidemment utilisée!).
Un autre lien intéressant, qui explique le principe de ces matrices, sur le site du zéro.
Il n'y a pas besoin de plus que ces matrices là, vraiment :
Pour obtenir la matrice de transformation finale, il est bon de savoir quelle matrice de transformation utiliser, à quel moment et dans quel ordre. C'est là qu'on voit trois catégories apparaître :
Projection des points
Enfin, lorsqu'on veut afficher un objet, il faut commencer par projeter tout ses points sur l'écran. Et là, rien de plus simple, à part qu'il ne faut pas négliger l'ordre de multiplication des matrices :
Dessin du triangle
Vous avez suivi? Si vous voulez expérimenter comme moi, le mieux serait d'abord d'afficher uniquement des points pour voir si la projection fonctionne.
En tout cas, maintenant on prend ces points projetés trois par trois, et on affiche un triangle à partir de ceci!
Si vous voulez un algorithme, réfléchissez-y vous même ou bien cherchez sur Google avec le mot clef "rasterize". Personnellement j'ai cherché de cette façon mais je n'ai pas trouvé quelque chose d'acceptable. Alors je me suis posé devant une feuille de papier et j'ai créé un algorithme. Ce n'est pas si compliqué, mais pas forcément le plus optimisé (j'utilise uniquement des nombres flottants, mais vu la puissance des processeurs actuels et le but de ce renderer c'est pas si grave je pense).
Le depth buffer
Le depth buffer est un tableau à deux dimensions de la même taille que l'écran. Chaque position correspond à une profondeur pour chaque pixel. A chaque fois qu'on ajoute un pixel, on vérifie si sa profondeur est plus ou moins grande que celle du depth buffer à cette position. Si la nouvelle profondeur est "plus profonde" alors on ne l'affiche pas, sinon ... ben on l'affiche.
Cette technique permet de régler le problème d'ordre d'affichage des triangles. En l'utilisant, on se fout de l'ordre et même deux triangles peuvent être en intersection. C'est aussi très facile à implémenter. N'oubliez pas d'interpoler la valeur z également lors du dessin du triangle!
Optimisation
On a maintenant assez pour afficher quelque chose de correct à l'écran! Mais on peut aussi ajouter un "backface culling", c'est à dire ne pas prendre en compte les triangles qui ne sont pas "tournés vers" la caméra. C'est utile pour l'affichage de formes fermées (comme le cube), mais ca implique de devoir spécifier les points du triangle dans le sens inverse des aiguilles d'une montre.
Implémenter un backface culling n'est pas dur non plus :
1) on récupère la normale du triangle avec ses points projetés
2) on vérifie si la valeur z est négative (ou positive, je sais plus...)
3) si oui, on l'affiche
Ce qui donne :
Prendre en compte des lumières! Dans mon cas, je me suis limité à une seule lumière directionelle. Une lumière ne fait que modifier la couleur d'une surface (d'un triangle quoi). Pour la lumière directionnelle, on multiplie la couleur qu'on veut attribuer au triangle par un produit scalaire entre les vecteur unitaires de la normale du triangle et de la direction de la lumière. En résumé :
Le mot de la fin
Voilà! Tout est dit! Je trouve ce sujet tellement passionnant que j'en suis même arrivé à en faire un tutoriel...
Je ne sais pas s'il est très clair, alors commentez-moi tout ca si vous voulez qu'il s'améliore! (le tutoriel hein)
Si j'en ai éventuellement le courage, je rajouterais peut-être quelques probables images pour illustrer le tutoriel. (en gros comptez pas dessus)
Ce qui est certain par contre, c'est qu'il y aura des images du jeu que je fais avec ce petit moteur! Et p't'êt' même que je mettrais les sources! Mais pour ces dernières, ce ne sera pas avant Janvier, car à Teesside ils sanctionnent violemment le plagiat, et moua je veut une bonne note. Rassurez vous tout de suite! Il ne m'ont jamais demandé de faire un moteur 3D, c'est juste mon esprit tordu qui m'a poussé à le faire, donc si vous envisagez de faire vos études là bas, que cela ne vous freine pas :P (et foncez même, elle est géniale cette école)
Etant pas mal en avance sur la plupart de mes modules en ce moment, et après une discussion avec un camarade de classe sur "faire un jeu en mode 7 avec HAPI" ... l'envie m'est pris de faire coder un renderer 3D avec.
"Ca peut sembler dingue" pensais-je, mais pour obtenir quelque chose de basique, il ne faut pas grand chose!
Les pré-requis
Ils sont surtout mathématiques, et pas si dur que ça, on peut trouver et comprendre tout ça très rapidement sur wikipedia :
1) Les vecteurs :
- Addition
- Soustraction
- Produit vectoriel
- Produit scalaire
- Identité
- Produit matriciel
4) Une expérience avec DirectX ou OpenGL ne fait vraiment pas de mal!
Les points à dessiner
C'est pas tout ca, mais il faut bien quelque chose à afficher!
Pour tester mon programme, j'ai commencé par créer un cube avec ces coordonnées :
p1( 1, 1, 1)L'étape suivante, c'est de transformer ces points pour obtenir leur position à l'écran.
p2( 1,-1, 1)
p3(-1,-1, 1)
p4(-1, 1, 1)
p5( 1, 1,-1)
p6( 1,-1,-1)
p7(-1,-1,-1)
p8(-1, 1,-1)
Les matrices de transformation
Mais avant ça, il faut obtenir des matrices de transformation, qu'on va combiner entre elles pour obtenir une matrice de transformation finale, laquelle va être appliquée à nos points (d'où la multiplication de vecteur par matrice).
Vous pouvez trouver comment les produire avec la documentation OpenGL (que j'ai évidemment utilisée!).
Un autre lien intéressant, qui explique le principe de ces matrices, sur le site du zéro.
Il n'y a pas besoin de plus que ces matrices là, vraiment :
- Translation
- Rotation autour d'un axe (X, Y, Z ou même quelconque)
- Perspective
- LookAt (pour la caméra)
- ViewPort (pour adapter à la taille de l'écran)
Pour obtenir la matrice de transformation finale, il est bon de savoir quelle matrice de transformation utiliser, à quel moment et dans quel ordre. C'est là qu'on voit trois catégories apparaître :
- La matrice de projection
- La matrice de la caméra
- La matrice "du monde"
Projection = ViewPort * PerspectivePour la caméra, un bon vieux LookAt reste toujours très efficace. Mais rien n'empêche de la bouger à coup de translate et/ou rotate. Si on choisit de fait comme ca, il faut garder à l'esprit que la position de départ de la caméra correspondrais à ce LookAt :
LookAt( 0,0,0, 0,0,-1, 0,-1,0)Pour la matrice du monde, c'est celle qui est utilisée pour transformer les objets qu'on veut afficher. Donc essentiellement du rotate et du translate. C'est aussi là que push et pop sont utiles pour les transformations locales.
Projection des points
Enfin, lorsqu'on veut afficher un objet, il faut commencer par projeter tout ses points sur l'écran. Et là, rien de plus simple, à part qu'il ne faut pas négliger l'ordre de multiplication des matrices :
pointProjeté = point * projection * caméra * mondeDans le cas du cube, on applique ceci pour p1 jusqu'à p8. Dans des points à part c'est mieux, histoire de ne pas avoir à redéfinir la position de base à chaque frame (question d'optimisation).
// ou pour être encore plus précis :
//(j'insiste sur l'ordre!)
pointProjeté = point * ViewPort * Perspective * LookAt * matriceMondeCourante
Dessin du triangle
Vous avez suivi? Si vous voulez expérimenter comme moi, le mieux serait d'abord d'afficher uniquement des points pour voir si la projection fonctionne.
En tout cas, maintenant on prend ces points projetés trois par trois, et on affiche un triangle à partir de ceci!
Si vous voulez un algorithme, réfléchissez-y vous même ou bien cherchez sur Google avec le mot clef "rasterize". Personnellement j'ai cherché de cette façon mais je n'ai pas trouvé quelque chose d'acceptable. Alors je me suis posé devant une feuille de papier et j'ai créé un algorithme. Ce n'est pas si compliqué, mais pas forcément le plus optimisé (j'utilise uniquement des nombres flottants, mais vu la puissance des processeurs actuels et le but de ce renderer c'est pas si grave je pense).
Le depth buffer
Le depth buffer est un tableau à deux dimensions de la même taille que l'écran. Chaque position correspond à une profondeur pour chaque pixel. A chaque fois qu'on ajoute un pixel, on vérifie si sa profondeur est plus ou moins grande que celle du depth buffer à cette position. Si la nouvelle profondeur est "plus profonde" alors on ne l'affiche pas, sinon ... ben on l'affiche.
Cette technique permet de régler le problème d'ordre d'affichage des triangles. En l'utilisant, on se fout de l'ordre et même deux triangles peuvent être en intersection. C'est aussi très facile à implémenter. N'oubliez pas d'interpoler la valeur z également lors du dessin du triangle!
Optimisation
On a maintenant assez pour afficher quelque chose de correct à l'écran! Mais on peut aussi ajouter un "backface culling", c'est à dire ne pas prendre en compte les triangles qui ne sont pas "tournés vers" la caméra. C'est utile pour l'affichage de formes fermées (comme le cube), mais ca implique de devoir spécifier les points du triangle dans le sens inverse des aiguilles d'une montre.
Implémenter un backface culling n'est pas dur non plus :
1) on récupère la normale du triangle avec ses points projetés
2) on vérifie si la valeur z est négative (ou positive, je sais plus...)
3) si oui, on l'affiche
Ce qui donne :
avec p1,p2 et p3 les points PROJETES du triangle :Et plus encore!
// c'est à cause de ce cacul
// que le sens dans lequel
// les points sont spécifiés est important
normale = produitVectoriel( p2 - p1, p3 - p1 )
si (normale.z < 0)
{
dessinerTriangle(p1,p2,p3)
}
Prendre en compte des lumières! Dans mon cas, je me suis limité à une seule lumière directionelle. Une lumière ne fait que modifier la couleur d'une surface (d'un triangle quoi). Pour la lumière directionnelle, on multiplie la couleur qu'on veut attribuer au triangle par un produit scalaire entre les vecteur unitaires de la normale du triangle et de la direction de la lumière. En résumé :
n = vecteurUnitaire(normale)Obtenir les vecteurs unitaires est très important.
d = vecteurUnitaire(directionLumière)
// j'appelle cette variable dot
// parce que produit scalaire
// en anglais donne dot product
dot = produitScalaire(n,d);
si (dot > 0)
{
couleurFinale = couleur * dot;
}
sinon
{
couleurFinale = noir;
}
Le mot de la fin
Voilà! Tout est dit! Je trouve ce sujet tellement passionnant que j'en suis même arrivé à en faire un tutoriel...
Je ne sais pas s'il est très clair, alors commentez-moi tout ca si vous voulez qu'il s'améliore! (le tutoriel hein)
Si j'en ai éventuellement le courage, je rajouterais peut-être quelques probables images pour illustrer le tutoriel. (en gros comptez pas dessus)
Ce qui est certain par contre, c'est qu'il y aura des images du jeu que je fais avec ce petit moteur! Et p't'êt' même que je mettrais les sources! Mais pour ces dernières, ce ne sera pas avant Janvier, car à Teesside ils sanctionnent violemment le plagiat, et moua je veut une bonne note. Rassurez vous tout de suite! Il ne m'ont jamais demandé de faire un moteur 3D, c'est juste mon esprit tordu qui m'a poussé à le faire, donc si vous envisagez de faire vos études là bas, que cela ne vous freine pas :P (et foncez même, elle est géniale cette école)
vendredi 6 novembre 2009
Shader showcase
Le boulot devient de plus intéressant en 3D Graphic Shading!
Voilà ce que je suis capable de faire après un peu plus d'un mois :
Voilà ce que je suis capable de faire après un peu plus d'un mois :
vendredi 9 octobre 2009
Teesside
Voilà, je viens de commencer mes études à Teesside. Titre du "degree" : "BSc Computer Games Programming".
Voilà mes cours :
- Algorithmic and Data Structures
- Game Software Development
- 3D Graphics Programming
- 3D Graphics Shaders
- Animation and Simulation Programmation
Que du bon qui s'annonce! Ca me permettra de remplir ce blog de choses intéressante :)
Voilà mes cours :
- Algorithmic and Data Structures
- Game Software Development
- 3D Graphics Programming
- 3D Graphics Shaders
- Animation and Simulation Programmation
Que du bon qui s'annonce! Ca me permettra de remplir ce blog de choses intéressante :)
mercredi 26 août 2009
Easy Animation Editor
lien sourceforge
Depuis le début des vacances d'été, j'ai une grosse envie de faire un jeu vidéo en C++. Mais je suis une grosse merdouille en graphismes. A chaque fois je me dis "tiens si je fesait ca ..." puis "hey! ca serait marrant de faire ca". Mais à chaque fois, le problème est le suivant : je n'ai pas de graphismes pour ces jeux. Alors je me dit que je pourrais juste faire des cubes. Mais ca me démotive énormément.Aprendre à utiliser Blender? Déjà essayé, déjà tout oublié, pas assez intuitif pour moi, une dizaine de fonctions réunies dans 10*10 pixels ... De plus, il faudrait créer un importeur ou exporteur de données qui conviendrait à mon jeu, et j'ai la flemme d'examiner leur structure de données (bon ya assimp que j'ai pu maîtriser dans mon stage mais bon).
Alors j'ai voulu me débloquer tout seul en me créant un éditeur pour graphismes en 3D, que j'ai baptisé : Easy Animation Editor.
Le principe, c'est qu'il soit dédié à l'animation de modèles en 3D uniquement. Avec une interface épurée et intuitive.
Pour l'instant, il n'est pas exploitable tel quel, mais ca va bientôt venir! Ce qui est sûr c'est qu'on peut déjà le tester et avoir les sources. Pour cela, il faut utiliser le repositery svn de sourceforge (lien ci-dessus).
Il a une particularité : l'interface graphique (ou GUI) a été totalement programmée de A à Z avec le gestionnaire d'évennements SDL. L'affichage est en OpenGL (je kiffe la combinaison SDL-OpenGL et je ne pense jamais la quitter).
Pourquoi cette particularité? J'ai d'abord pensé utiliser java (que je maîtrise pas mal également) pour sa facilité à créer une interface graphique. Mais j'avait besoin de la 3D. Sauf qu'elle n'est pas dans les package de base de java! Moi j'aime bien développer en java en ligne de commandes ("javac *.java" puis "java nomprogramme" c'est tout ce qu'il y a à connaître). Mais c'est ultra compliqué d'utiliser un package externe de cette façon, et j'ai d'ailleurs toujours pas réussi. J'ai fait l'effort d'utiliser un IDE pour java. Donc Eclipse. Mais en fait c'est juste tout joli joli avec de belles fonctionnalités, mais dur à comprendre et à faire marcher (comme Vista en fait).
Ensuite j'ai pensé utiliser Qt. C'est plutot pas mal, mais j'avait la flemme de me documenter et de découvrir un nouveau logiciel. Alors j'ai pas beaucoup accroché. Il y a des chances que je m'y remette certainement.
Enfin, ultime raison, j'adore réinventer la roue. Ca me fait progresser dans mes raisonnements et ma programmation.
Un petit screen pour vous faire baver ( j'espère :S )
Depuis le début des vacances d'été, j'ai une grosse envie de faire un jeu vidéo en C++. Mais je suis une grosse merdouille en graphismes. A chaque fois je me dis "tiens si je fesait ca ..." puis "hey! ca serait marrant de faire ca". Mais à chaque fois, le problème est le suivant : je n'ai pas de graphismes pour ces jeux. Alors je me dit que je pourrais juste faire des cubes. Mais ca me démotive énormément.Aprendre à utiliser Blender? Déjà essayé, déjà tout oublié, pas assez intuitif pour moi, une dizaine de fonctions réunies dans 10*10 pixels ... De plus, il faudrait créer un importeur ou exporteur de données qui conviendrait à mon jeu, et j'ai la flemme d'examiner leur structure de données (bon ya assimp que j'ai pu maîtriser dans mon stage mais bon).
Alors j'ai voulu me débloquer tout seul en me créant un éditeur pour graphismes en 3D, que j'ai baptisé : Easy Animation Editor.
Le principe, c'est qu'il soit dédié à l'animation de modèles en 3D uniquement. Avec une interface épurée et intuitive.
Pour l'instant, il n'est pas exploitable tel quel, mais ca va bientôt venir! Ce qui est sûr c'est qu'on peut déjà le tester et avoir les sources. Pour cela, il faut utiliser le repositery svn de sourceforge (lien ci-dessus).
Il a une particularité : l'interface graphique (ou GUI) a été totalement programmée de A à Z avec le gestionnaire d'évennements SDL. L'affichage est en OpenGL (je kiffe la combinaison SDL-OpenGL et je ne pense jamais la quitter).
Pourquoi cette particularité? J'ai d'abord pensé utiliser java (que je maîtrise pas mal également) pour sa facilité à créer une interface graphique. Mais j'avait besoin de la 3D. Sauf qu'elle n'est pas dans les package de base de java! Moi j'aime bien développer en java en ligne de commandes ("javac *.java" puis "java nomprogramme" c'est tout ce qu'il y a à connaître). Mais c'est ultra compliqué d'utiliser un package externe de cette façon, et j'ai d'ailleurs toujours pas réussi. J'ai fait l'effort d'utiliser un IDE pour java. Donc Eclipse. Mais en fait c'est juste tout joli joli avec de belles fonctionnalités, mais dur à comprendre et à faire marcher (comme Vista en fait).
Ensuite j'ai pensé utiliser Qt. C'est plutot pas mal, mais j'avait la flemme de me documenter et de découvrir un nouveau logiciel. Alors j'ai pas beaucoup accroché. Il y a des chances que je m'y remette certainement.
Enfin, ultime raison, j'adore réinventer la roue. Ca me fait progresser dans mes raisonnements et ma programmation.
Un petit screen pour vous faire baver ( j'espère :S )
Ma "traversée du désert"
Voilà les raisons pour lesquelles j'ai semblé ne pas avoir l'air actif depuis quelques années dans le monde du développement amateur. A la base je voulais expliquer pourquoi j'ai commencé le développement de Easy Animation Editor, mais c'est tellement long que j'en ai fait un billet à part. Ca prend la forme d'une sorte d'autobiographie tellement j'ai des choses à dire, et c'est pour ca que j'ai mis ce titre xD
Si je programme c'est par passion pour les jeux vidéos. J'ai déjà créé quelques jeux (qu'on peut voir sur http://jackamikaz.free.fr/) avec Game Maker. J'ai adoré ce logiciel, je l'ai tourné dans tout les sens pour en extraire chacune de ses fonctionnalités. Il vint un temps où mes ambitions grandissaient de plus en plus, de faire des projets de plus en plus faramineux. C'est là que je me suis rendu compte de plusieurs problèmes :
Je suis une grosse merde en graphismes (cf TCA sur mon site). J'ai un projet que je trimbale dans la tête depuis plusieurs années. J'ai voulu faire quelque chose d'agréable à jouer, avec un gameplay qui me semblerait totalement original. Mon but est là : le gameplay. Mais c'est une idée de jeu de combat. Le personnage a donc beaucoup de mouvements, ce qui implique beaucoup de sprites, étant chacun visuellement compréhensibles. Alors j'ai réfléchi à quelque chose de simpliste vu mon niveau : un personnage tout rond sans bras ni jambes (à la Rayman). Je me suis vite aperçu que ce n'était pas du tout suffisant pour différencier les mouvements du personnage. Alors je me suis tourné vers la modification de sprites. J'ai pris des sprites de Megaman X, et j'ai transformé le robot en une sorte de ninja tout noir, en affinant les jambes et en ajoutant des cheveux. Mais (je suis une grosse merde en graphismes) j'utilisais paint. Cela m'a pris un temps inconsidérable, juste pour faire des actions de mouvements et de sauts. Je me suis mis à programmer un moteur en me servant de ces graphisme. J'étais assez satisfait, mais je devais continuer à perdre mon temps sur des graphismes plus que moyens. De plus, ayant des idées de grandeur, je pensait faire ce jeu online avec possibilité de customization de son personnage. Autant dire qu'avec des sprites de cette qualité, c'était peine perdue.
Alors j'ai décidé de faire quelque chose de plus "vectoriel". En restant en 2D, j'ai programmé un éditeur de personnage squeletique constitués de plusieurs points qui sont les articulations. En déplacant les points, cela formait plusieurs positions, qui donnait des animations. Ensuite, entre chaque points, j'affichait un membre : une jambe, un bras, la tête ... Ca donnait quelque chose d'un peu carré, mais l'image était unique et les animations faciles à réaliser. Ca m'a fait un gain de temps considérable dans l'édition des graphismes. J'étais sur la bonne voie.
Seulement, dans la foulée, Game Maker avait sortit la possibilité d'utiliser la 3D. Je me suis dit que j'allait faire un Gameplay 2D, avec le personnage en 2D, tout en gardant des décors en 3D, c'était pas le plus joli, mais pour moi c'était un résultat extraordinaire compte tenu de mes capacités à faire des graphismes en 2D. Mais c'est là que tout se complique. Pour avoir ce résultat, je me retrouve dans les méandres de Game Maker et je bidouille énormément pour obtenir mes résultat. Du coup mon code est pas franchement clair et c'est dur de s'y retrouver. En plus, quand je fais tester le jeu à d'autres gens, des problèmes de compatibilité apparaissent. Rien de plus décourageant, sachant que ce logiciel est sensé marcher de façon égale sur toutes les machines. Alors j'ai recherché à taton des subtilités d'une machine à l'autre sans avoir une seule idée d'où cela peut venir. De plus quand l'autre machine est celle d'un correspondant internet qui n'a pas la version enregistrée de Game Maker (qui ne peut donc pas compiler le projet) ca fait que je dois renvoyer le projet à chaque fois ... Au bout de deux essais c'est l'abandon et l'espoir que ce problème ne soit que particulier.
Il a aussi le fait que l'animation des personnages, bien que beaucoup plus rapide, réduisait énormément l'intérêt de Game Maker, qui est de concentrer le développement d'un jeu vidéo en un seul logiciel, avec sprites et niveaux intégres etc; parce que mon système d'animation utilisait des fichiers textes externes. Game Maker permet l'utilisation de tels fichiers, mais n'est totalement pas adapté pour. Tout doit se faire par code, et le code c'est deux endroits possible seulement : les objets ou les scripts. Les animations étant spécifiques aux personnages, et n'ayant pas encore totalement l'intérêt des scripts à l'époque, j'ai choisi de le metre dans les objets. La lisiblité était donc beaucoup diminuée, à nouveau. Suite à tout ces problèmes, j'ai fini par abandonner ce jeu ...
La raison ultime qui me fit décrocher de Game Maker est le C++ !
En effet, j'étais en train de le découvrir et de l'aprendre par moi-même, et j'avais un autre projet original en tête sur Game Maker : Bactérie (cf mon site à nouveau). Dans la description, j'explique que j'ai abandonné ce jeu à cause d'un bug de Game Maker. En réalité j'ai dit ca pour faire simple, ce n'est pas vraiment un bug, mais un problème de performances. Au bout d'un certain de jeu, il y a plus d'une centaine de bactéries sur le terrain, et toutes doivent éviter d'avoir une colision avec une autre. Cela fait donc 100 x 100 = 1000 colisions à gérer à raison de 30 fois par secondes. Le tout en GML qui est un langage script interprété à partir de fichiers, donc non compilé. Le résultat est là : ca rame. Et C++, est plus proche du langage machine, donc plus performant. Ceci me décida à me concentrer davantage sur ce langage, entrainant un abandon progressif de Game Maker.
Me voilà donc à utiliser C++. Mais forcément, c'est beaucoup moins intuitif que Game Maker, et cela demande une réflexion plus intense pour la création de jeux. Au fur et à mesure que je progressais dans ce langage, je me suis rendu compte de plus en plus de la complexité de création d'un jeu. Mes idées de projet sont les mêmes, mais à chaque fois je me dis que je ne suis pas encore prêt. Deux ou trois fois, j'essaie quand même. Et bien croyez moi, c'est ce qu'il faut faire! Essayer! De cette façon j'ai entamé deux gros projets personnels. Le premier c'est Bactérie 2, avec un gameplay mieux pensé. Mais c'est la première chose sur laquelle je me suis lancé, et je n'était pas encore tout à fait prêt pour le réussir. Ca a donné quelque chose de peu exploitable, mais j'ai appris plus en quelques jours seul là dessus qu'en deux ans d'IUT informatique (je savais tout avant tout le monde là bas d'ailleurs, j'ai même tendance à m'en vanter et j'ai certainement du vexer beaucoup de gens). Le deuxième gros projet, c'était il y a 5 mois, lors de mon stage en Nouvelle Zélande (là huhuh =D ). Evidemment le stage lui même m'a beaucoup appris, mais j'étais arrivé tout seul là bas. En bon geek, je me suis peu socialisé, et j'ai passé beaucoup de mon temps libre à tenter la création d'un moteur 3D. Le résultat, une maîtrise accrue du C++, et un moteur ... plus un moteur de jeu tout cour que de 3D.
Avec cette expérience, maintenant je me sens prêt pour me remettre à des projets de jeux. Seul blocage, comme je l'ai expliqué : les graphismes. Ce qui nous amène à la note suivante : Easy Animation Editor.
Si je programme c'est par passion pour les jeux vidéos. J'ai déjà créé quelques jeux (qu'on peut voir sur http://jackamikaz.free.fr/) avec Game Maker. J'ai adoré ce logiciel, je l'ai tourné dans tout les sens pour en extraire chacune de ses fonctionnalités. Il vint un temps où mes ambitions grandissaient de plus en plus, de faire des projets de plus en plus faramineux. C'est là que je me suis rendu compte de plusieurs problèmes :
Je suis une grosse merde en graphismes (cf TCA sur mon site). J'ai un projet que je trimbale dans la tête depuis plusieurs années. J'ai voulu faire quelque chose d'agréable à jouer, avec un gameplay qui me semblerait totalement original. Mon but est là : le gameplay. Mais c'est une idée de jeu de combat. Le personnage a donc beaucoup de mouvements, ce qui implique beaucoup de sprites, étant chacun visuellement compréhensibles. Alors j'ai réfléchi à quelque chose de simpliste vu mon niveau : un personnage tout rond sans bras ni jambes (à la Rayman). Je me suis vite aperçu que ce n'était pas du tout suffisant pour différencier les mouvements du personnage. Alors je me suis tourné vers la modification de sprites. J'ai pris des sprites de Megaman X, et j'ai transformé le robot en une sorte de ninja tout noir, en affinant les jambes et en ajoutant des cheveux. Mais (je suis une grosse merde en graphismes) j'utilisais paint. Cela m'a pris un temps inconsidérable, juste pour faire des actions de mouvements et de sauts. Je me suis mis à programmer un moteur en me servant de ces graphisme. J'étais assez satisfait, mais je devais continuer à perdre mon temps sur des graphismes plus que moyens. De plus, ayant des idées de grandeur, je pensait faire ce jeu online avec possibilité de customization de son personnage. Autant dire qu'avec des sprites de cette qualité, c'était peine perdue.
Alors j'ai décidé de faire quelque chose de plus "vectoriel". En restant en 2D, j'ai programmé un éditeur de personnage squeletique constitués de plusieurs points qui sont les articulations. En déplacant les points, cela formait plusieurs positions, qui donnait des animations. Ensuite, entre chaque points, j'affichait un membre : une jambe, un bras, la tête ... Ca donnait quelque chose d'un peu carré, mais l'image était unique et les animations faciles à réaliser. Ca m'a fait un gain de temps considérable dans l'édition des graphismes. J'étais sur la bonne voie.
Seulement, dans la foulée, Game Maker avait sortit la possibilité d'utiliser la 3D. Je me suis dit que j'allait faire un Gameplay 2D, avec le personnage en 2D, tout en gardant des décors en 3D, c'était pas le plus joli, mais pour moi c'était un résultat extraordinaire compte tenu de mes capacités à faire des graphismes en 2D. Mais c'est là que tout se complique. Pour avoir ce résultat, je me retrouve dans les méandres de Game Maker et je bidouille énormément pour obtenir mes résultat. Du coup mon code est pas franchement clair et c'est dur de s'y retrouver. En plus, quand je fais tester le jeu à d'autres gens, des problèmes de compatibilité apparaissent. Rien de plus décourageant, sachant que ce logiciel est sensé marcher de façon égale sur toutes les machines. Alors j'ai recherché à taton des subtilités d'une machine à l'autre sans avoir une seule idée d'où cela peut venir. De plus quand l'autre machine est celle d'un correspondant internet qui n'a pas la version enregistrée de Game Maker (qui ne peut donc pas compiler le projet) ca fait que je dois renvoyer le projet à chaque fois ... Au bout de deux essais c'est l'abandon et l'espoir que ce problème ne soit que particulier.
Il a aussi le fait que l'animation des personnages, bien que beaucoup plus rapide, réduisait énormément l'intérêt de Game Maker, qui est de concentrer le développement d'un jeu vidéo en un seul logiciel, avec sprites et niveaux intégres etc; parce que mon système d'animation utilisait des fichiers textes externes. Game Maker permet l'utilisation de tels fichiers, mais n'est totalement pas adapté pour. Tout doit se faire par code, et le code c'est deux endroits possible seulement : les objets ou les scripts. Les animations étant spécifiques aux personnages, et n'ayant pas encore totalement l'intérêt des scripts à l'époque, j'ai choisi de le metre dans les objets. La lisiblité était donc beaucoup diminuée, à nouveau. Suite à tout ces problèmes, j'ai fini par abandonner ce jeu ...
La raison ultime qui me fit décrocher de Game Maker est le C++ !
En effet, j'étais en train de le découvrir et de l'aprendre par moi-même, et j'avais un autre projet original en tête sur Game Maker : Bactérie (cf mon site à nouveau). Dans la description, j'explique que j'ai abandonné ce jeu à cause d'un bug de Game Maker. En réalité j'ai dit ca pour faire simple, ce n'est pas vraiment un bug, mais un problème de performances. Au bout d'un certain de jeu, il y a plus d'une centaine de bactéries sur le terrain, et toutes doivent éviter d'avoir une colision avec une autre. Cela fait donc 100 x 100 = 1000 colisions à gérer à raison de 30 fois par secondes. Le tout en GML qui est un langage script interprété à partir de fichiers, donc non compilé. Le résultat est là : ca rame. Et C++, est plus proche du langage machine, donc plus performant. Ceci me décida à me concentrer davantage sur ce langage, entrainant un abandon progressif de Game Maker.
Me voilà donc à utiliser C++. Mais forcément, c'est beaucoup moins intuitif que Game Maker, et cela demande une réflexion plus intense pour la création de jeux. Au fur et à mesure que je progressais dans ce langage, je me suis rendu compte de plus en plus de la complexité de création d'un jeu. Mes idées de projet sont les mêmes, mais à chaque fois je me dis que je ne suis pas encore prêt. Deux ou trois fois, j'essaie quand même. Et bien croyez moi, c'est ce qu'il faut faire! Essayer! De cette façon j'ai entamé deux gros projets personnels. Le premier c'est Bactérie 2, avec un gameplay mieux pensé. Mais c'est la première chose sur laquelle je me suis lancé, et je n'était pas encore tout à fait prêt pour le réussir. Ca a donné quelque chose de peu exploitable, mais j'ai appris plus en quelques jours seul là dessus qu'en deux ans d'IUT informatique (je savais tout avant tout le monde là bas d'ailleurs, j'ai même tendance à m'en vanter et j'ai certainement du vexer beaucoup de gens). Le deuxième gros projet, c'était il y a 5 mois, lors de mon stage en Nouvelle Zélande (là huhuh =D ). Evidemment le stage lui même m'a beaucoup appris, mais j'étais arrivé tout seul là bas. En bon geek, je me suis peu socialisé, et j'ai passé beaucoup de mon temps libre à tenter la création d'un moteur 3D. Le résultat, une maîtrise accrue du C++, et un moteur ... plus un moteur de jeu tout cour que de 3D.
Avec cette expérience, maintenant je me sens prêt pour me remettre à des projets de jeux. Seul blocage, comme je l'ai expliqué : les graphismes. Ce qui nous amène à la note suivante : Easy Animation Editor.
Heure des messages
Comme je viens de créer le blog, je suis en train d'y mettre deux trois touches personnelles de mise en page etc.
Mais je me rend compte d'un problème, l'heure du message est totalement incorrecte! Pour celui ci par exemple, cela marque 10:03 alors qu'il est 19:03!
Pourtant dans mon profil, je dis bien que je suis en France, et je ne trouve pas non plus d'option pour définir le fuseau horaire.
Si quelqu'un a une explication, il peut laisser un commentaire. :)
Mise à jour : ayé trouvé, fuseau horaire dans Paramètres puis Mise en forme.
Mais je me rend compte d'un problème, l'heure du message est totalement incorrecte! Pour celui ci par exemple, cela marque 10:03 alors qu'il est 19:03!
Pourtant dans mon profil, je dis bien que je suis en France, et je ne trouve pas non plus d'option pour définir le fuseau horaire.
Si quelqu'un a une explication, il peut laisser un commentaire. :)
Mise à jour : ayé trouvé, fuseau horaire dans Paramètres puis Mise en forme.
Inscription à :
Articles (Atom)
