Un jeu sur ordinateur est une boucle sans fin de:
- Mise à jour: avancez l'état du jeu d'une petite tranche de temps (comme 1/80 seconde).
- Peignez l'état actuel du jeu.
Il en existe des variantes. Certains jeux ont plus de mises à jour entre chaque peinture, ou il peut les faire varier pour rendre le jeu également fluide sur différentes machines. Mais ce sont des détails techniques.
La phase de mise à jour qui se produit entre 50 et 100 fois par seconde (oui c'est souvent) fait ceci:
- Mettez à jour la physique des jeux. Disons qu'un acteur a une vélocité. La mise à jour devrait le déplacer un tout petit peu dans la bonne direction. De plus, si vous utilisez un moteur physique, il devrait vérifier les collisions avec d'autres actos ou obstacles.
- Mettez à jour les règles du jeu. C'est ce qui en fait un jeu et non une expérience physique. Disons qu'une balle a touché l'acteur joueur. Les règles du jeu indiquent au joueur de déduire X points de vie et la balle de disparaître.
- Mises à jour de l'IA. Parfois, les acteurs contrôlés par ordinateur devraient décider quoi faire. Allez à gauche ou à droite? Trouvez un chemin vers un endroit agréable. Tire une arme.
- Contrôle d'entrée. Mettez à jour l'acteur joueur en fonction des boutons enfoncés sur le clavier.
- Mettre à jour le graphique de scène. Cela peut faire avancer une animation d'une étape ou mettre à jour l'interface graphique pour montrer que le joueur a maintenant 10 points de vie en moins. Son seul but est de rendre le jeu agréable et agréable.
Par où commencer?
La condition de base pour un jeu graphique est de programmer des graphiques. Assurez-vous que vous pouvez ouvrir une fenêtre et y dessiner une balle.
Je suppose que vous pouvez faire une sorte de cours. Faites un cours de balle. Il comprend les membres suivants: x, y, deltaX, deltaY. Tous sont des entiers et des échelles de pixels. Maintenant, écrivez cette boucle.
forever, do this {
start measure time (in milliseconds)
//physics part
add deltaX to x
add deltaY to y
if x is bigger than the screen width, assign -deltaX to deltaX
if y is bigger than the screen height, assign -deltaY to deltaY
if x is less than 0, assign -deltaX to deltaX
if y is less than 0, assign -deltaY to deltaY
//paint
paint the ball at x, y
stop measuring time, assign this to workTime
make the thread sleep for (25 - workTime) milliseconds
}
Cela fera rebondir la balle des limites des fenêtres. Ce n'est pas encore un jeu, mais plutôt une simulation physique. Si vous écrivez la mise à jour de la physique des balles dans la classe de balles, il est facile d'ajouter plusieurs balles. Stockez-les dans une liste et mettez à jour et peignez chacun pour chaque cadre.
Vous pouvez ajouter une palette (simuler la physique et la rendre contrôlable avec la souris ou le clavier) et un objectif de jeu tel que d'empêcher la balle d'atteindre le mur de gauche. Si le jeu ajoute de plus en plus de balles au fil du temps, la difficulté augmentera. Vous avez un jeu.
Pourquoi dormir pendant (25 - workTime) millisecondes? Si vous le faites comme ça, la simulation s'exécutera à un rythme constant de 40 mises à jour et peintures par seconde. Ce sera assez lisse. Si vous sautiez la partie sommeil, l'animation serait saccadée et occuperait 100% du processeur. De plus, la vitesse de la balle dépendrait de la vitesse de la machine qui la fait fonctionner. Maintenant, la vitesse verticale de la balle est de 40 * pixels deltaY par seconde.
Ce que vous devez comprendre, ce sont des matrices. Ils sous-tendent les jeux. Une fois que vous aurez compris la puissance des matrices, vous verrez comment les jeux se réduisent à de simples mathématiques.
Vous prenez une position de sommet dans l'espace de jeu. Vous le projetez en utilisant une matrice sur l'écran (trouvez ses coordonnées d'écran). Vous interpolez quelques pixels entre lui et ses sommets voisins, et vous avez terminé. C'est évidemment une simplification excessivement grande, mais les principes de base de la pixellisation ne sont pas du tout complexes une fois que vous avez des matrices.
la source