Messages : 11
|
Première partie > Généralités.
Le moteur d’exploration ne se conçoit pas sans un environnement, un monde dit “rpg”.
Un mode d’emploi > Game Play.
Que ce soit avec une solution intégrée, ou un langage de programmation, réaliser un moteur d’exploration sur une map 2D, revient à penser, l’ossature d’un jeu vidéo.
Voici le schéma d’un moteur de jeu 2D, avec ses “sous” moteurs.
Le moteur de déplacement du PJ (personnage joueur), gère, des animations, des collisions, des plans.
Le mapping, fait déjà référence à une stratégie d’ensemble.
Une stratégie d’ensemble consiste d’abord à déterminer tous les objectifs à atteindre, ensuite de choisir ou de trouver les moyens de finaliser à coup sûr.
Sans parler de l’optimisation, un détail à voir plus tard.
Le coder d’un jeu vidéo doit avoir à sa disposition une base de données moteurs, graphiques et sonores.
Il est préférable d’avoir un minimum de vocabulaire, si vous souhaitez vous lancer dans des recherches, des études de cas, indispensables, avant de plonger dans le grand bain.
Tile:
Tuile, élément graphique de base d’un jeu vidéo 2D, un carré multicolore, de 32x32 pixels, est un tile, prévu pour un gain de mémoire vive, principe encore valable de nos jours pour un rpg sur téléphone portable.
Tileset:
Paquet de tuiles, pièces du puzzle qui forment une carte, un monde rpg, au lieu d'afficher un monde rpg complet, la machine affiche seulement une partie de ce monde à l'écran. Avec tgf la mise au point d'un éditeur de carte rpg est inutile, voir grotesque (antinomique).
Sprite:
Ensemble de pixels mobiles, à l'origine pour interaction avec le joueur (collisions Pong).
Dans un rpg le personnage joueur est un sprite, capable de passer au premier plan, en arrière plan.
Sprite Sheet:
Planche de sprites, succession de tuiles permettant d’obtenir une ou plusieurs animations concernant un personnage, un objet, une partie du décor (mouvement d'eau, ailes d'un moulin à vent, etc).
Spriter:
Auteur de tuiles pour un jeu vidéo.
Sprite Art:
Réalisation de tuiles pixel par pixel (pixel art).
Map:
Carte, avec un click soft, plusieurs scènes peuvent constituer une carte ou un niveau.
Layer:
Couche qui permet de réaliser une carte rpg.
Mapping:
Art de réaliser une carte rpg avec des couches superposées, visibles ou invisibles, voir semi transparentes, sous entend une stratégie mapping.
Moteur de déplacement:
Élément premier (testé) du moteur d’un jeu vidéo, doit être mis au point sans faille.
Système de sauvegarde:
Enregistre et charge des données, numériques (chiffre), alphanumériques (lettre). Objet Tableau ou Objet Ini.
Editeur de niveau:
Avec un click soft, confondre éditeur de décors (carte) et éditeur d’objets interactifs avec le joueur, est une erreur courante. Réaliser un éditeur de décors avec tgf ou mmf est une perte de temps, avec un scrolling cela devient une galère.
Deuxième partie > Notions basiques.
Constatations sommaires concernant le moteur d’exploration d’origine rpg maker xp:
4 directions, gestion des collisions (arrêt net du PJ sur un obstacle), des animations (stop, marche), des plans (avant et arrière).
Remplir les mêmes objectifs avec tgf, peut paraître facile, en regardant de plus près ce moteur, un autre constat s’impose, ce n’est pas du déplacement libre, mais du case par case simulant un déplacement libre 4 directions, plutôt logique avec un éditeur de cartes.
Vous l’aviez remarqué?
Le plus dur à cerner est sans doute un moteur d’exploration.
Pourquoi?
Parce que souvent les notions manquent à la pelle.
Notion > Abstraction (notions valables pour tous les “coders” en herbe).
Avec un logiciel “case à cocher”, les abstractions se matérialisent, avec des objets graphiques.
Case libre, case non libre:
Collision ou non collision (superposition) > Obstacle, peut être un objet actif (mapping).
Objet invisible:
Sprite fantôme > Invisible à l’œil du joueur, le plus connu est le détecteur de collisions.
Variable:
Valeur modifiable.
Un compteur déposé dans la scène est semblable à une variable.
Touches en attentes:
Taper sur deux touches du clavier, c’est taper d’abord sur l’une ou l’autre, rarement sur les deux en même temps > “key wait”.
Contre moteur:
Avec un logiciel “case à cocher”, se fait généralement, en activant désactivant, un ou plusieurs groupes d’événements.
Par exemples, il est possible de désactiver toutes les conditions qui déplace un sprite, quand ce dernier est en collision avec un obstacle et vise versa.
Les grands classiques du moteur de déplacement sur map 2D:
Moteur d’exploration libre 4 directions.
Moteur d’exploration libre 8 directions.
Moteur d’exploration case par case 4 directions.
Moteur d’exploration case par case 8 directions.
Comment réaliser un moteur d’exploration?
On commence par le cahier des charges, les notions nécessaires acquissent à force de pratique, le matériel graphique. En filigrane bien sûr les objectifs à atteindre, imposés par la nature du moteur.
Le b.a.ba de tout moteur de déplacement, étant de tester l’activité du joueur, les impulsions sur le clavier, de gérer les directions, les vitesses, les collisions.
La vitesse du sprite invisible, est la même quelque soit la direction.
Le sprite joueur ne rebondit pas (ne tremble pas) sur un obstacle.
Les animations du sprite joueur sont cohérentes.
A la fin seulement mise en place du sprite joueur ou personnage joueur, mouvement statique, animation arrêté, marche.
Troisième partie > Schématique d’un moteur d’exploration.
Optimiser un moteur passe obligatoirement par la phase schématique.
Connaître les mécanismes d’un moteur afin de les simplifier, demande du recul, de jouer seulement avec les éléments primaires (symbolisation).
Entre parenthèses l’optimisation d’un moteur de jeu rpg 2D et donc de tous ses “sous” moteurs est préférable, sinon le programme risque de ramer, buguer, laguer, etc.
L’environnement.
Les objets invisibles, avec un mot clé, anticipation.
Descriptif du moteur:
La vitesse du test clavier est supérieur à zéro > Ajoute 1 au compteur Key Wait.
Key Wait (temps d’attente) est supérieur à deux > Prendre en compte la direction du test clavier.
La direction est confirmée, le pré détecteur de collisions (Fixe) devance le sprite fantôme du PJ (Ball), à la position x,y du centre de la case suivante.
La case est libre, Ball rejoint Fixe (vitesse constante > fluidité).
Le pré détecteur de collisions est sur une case non libre, ne confirme pas la direction.
Le meilleur moteur est celui que l’on comprends de A à Z.
Comment optimiser un moteur d’exploration?
Avec des astuces, il est possible d’imposer un régime minceur à l’éditeur d’événements.
Le but étant une exécution rapide et fiable du projet.
J’ai vu la démo d’un site très connu avec un PJ qui reste bloqué (super jouable), un moteur de déplacement libre 8 directions d’une centaine de lignes (super optimisé), un jeu avec des ressources graphiques aussi belles que l’exploration laisse à désirer (encore du super jouable). Pour faire rapide, si le départ est mauvais, le reste le sera aussi.
Avant de parler game play, un peu de bon sens.
A l’origine, le sprite à été mis au point en vue d’une interaction avec le joueur.
En règle générale, moteur de déplacement rpg avec tgf > Touches du clavier.
Évitez le déplacement à la souris à moins d’avoir une autre notion > Pathfinding (déplacement le plus court du point A au point B sur une map > IA).
Vous avez nodes (notez) et restez dans l'algorithme (le rythme), jeu de mots si vous voulez faire des recherches avec un moteur très connu.
Quatrième partie > Conclusion.
Ce petit cours m’a obligé à décomposer mon travail, à le mettre sur pause.
Voici les trois phases lors de la réalisation d’un moteur de déplacement.
1) La phase schématique > Répondre aux caractéristiques générales.
2) La phase d’ajustements > Atteindre tous les objectifs (répondre aux exigences du projet).
3) La phase test sur map > Limite et fiabilité sur plusieurs scènes.
“Faire” une map avec un click soft est très facile, la solution la plus expéditive pour des tests, étant de se servir d’un éditeur de carte (rpg maker par exemple), de faire des captures d’écran.
La méthode la plus laborieuse, faire tout de A à Z, la méthode intermédiaire consiste à choisir des ressources graphiques, à découper les tuiles, à les assembler.
Il existe deux moteurs afin de gérer les plans (2D, 2D iso), un pour tgf1, un autre pour tgf2 (se fait en 2 lignes).
L’optimisation d’un moteur de jeu rpg 2D avec un click soft, n’est hélas pas, à la portée du premier venu > Travail, persévérance, expérience.
Par contre, constituer une base de données “sous” moteurs, est réalisable, les faire tourner ensemble sera une question de logique, découlant du moteur d’exploration.
Pour compléter ces explications, je vous conseille d’étudier un monument, le jeu “Nethack”, son histoire, son interface d’origine très “design”, son mode d’emploi, son moteur de déplacement (case par case 8 directions, il traverse parfois les obstacles sur les diagonales).
Un jeu freeware très riche et prenant.
En espérant être clair et afin que le plus grand nombre puisse saisir des notions misent en pratique.
L’exemple schématique commenté, d’un moteur d’exploration 4 en 1 ( *.exe et *.gam sans extension, compatible avec toutes versions click).
http://www.megaupload.com/?d=KB0I7VEA
Bon courage si vous avez un rpg en cours.
|
